ボトルネック
システムや通信経路で、そのときの処理能力や負荷によって全体の性能を制限している箇所。英語で瓶の首を意味する語である。通信では処理できる量を超えてデータが集まると待ち行列ができ、遅延の増加やパケットの破棄につながる。
イマシルちゃんの解説
ネットワークやシステムで、全体の性能を制限している箇所をボトルネックというよ。
例えば1Gbit/sのLANどうしを100Mbit/sの回線でつなぐと、拠点間の通信は100Mbit/sより速くならないんだ。
社内のスイッチだけを高性能な製品に替えても、この上限は変わらないの。
一方で、速い回線でもほかの通信で混み合っていれば、そこが制約になることもあるよ。
だから性能を上げたいときは、機器の仕様だけでなく実際の通信量や処理の混み具合も調べるんだ。
どこを改善すれば効果があるのかを見極めることが大事なんだね。
この解説はわかりやすかったですか?
より深い解説
位置付けと考え方
ボトルネックは、ある処理や通信の流れの中で、全体の性能を制限している構成要素を指す。ネットワークの回線だけでなく、ルータやファイアウォールの処理能力、サーバのCPU・メモリ・ディスク、データベースのロック、さらにはTCPの設定まで、あらゆるものがボトルネックになり得る。
重要なのは、ボトルネックは固定された部品の名前ではなく、その時点の条件で決まるということである。利用者が増えたり、ある箇所を増強したりすると、別の箇所が新たなボトルネックになる。性能改善は「見つける → 解消する → 次を探す」の繰り返しになる。
経路の性能は最も遅い区間で決まる
データが複数の区間を順に通る場合、端から端までのスループットは各区間の能力のうち最小の値を超えない。次の独自例で考える。
| 区間 | 能力 |
|---|---|
| PC → アクセススイッチ | 1Gbit/s |
| アクセススイッチ → コアスイッチ | 10Gbit/s |
| 拠点のWAN回線 | 200Mbit/s |
| データセンターのサーバ接続 | 10Gbit/s |
PCからサーバへの通信は、最大でも200Mbit/sである。PCのNICを10Gbit/sにしても、コアスイッチを更改しても、この値は変わらない。
回線は複数の利用者で共有される点にも注意する。この拠点の20台のPCが同時に大きなファイルを転送すれば、WAN回線の200Mbit/sを分け合い、1台あたりは平均10Mbit/s程度になる。1台で測ったときに速くても、利用者が集中すると遅くなるのはこのためである。
回線の帯域以外が上限を決める例も多い。
| ボトルネックの種類 | 例 |
|---|---|
| 機器の処理能力 | ファイアウォールでIPSやTLSインスペクションを有効にすると、転送性能が大きく下がる |
| 機器の表の上限 | 同時セッション数やNATの変換表がいっぱいになり、新しい接続を受け付けない |
| プロトコルの待ち時間 | TCPのウィンドウが小さく、RTTが大きい経路で回線を使い切れない |
| サーバの資源 | CPU、メモリ、ディスクの読み書き、データベースの同時接続数 |
| 共有媒体 | 無線LANで多数の端末が同じチャネルを使い、送信の機会を奪い合う |
TCPの例では、1本のコネクションのスループットは「ウィンドウサイズ ÷ RTT」を超えられない。回線が十分に速くても、送信側と受信側のバッファ設定がボトルネックになり得る。
ボトルネックで起きること
ボトルネックの手前では、届くデータの量が送り出せる量を上回る。あふれた分は機器のバッファで順番を待つ。この順番待ちの列をキューという。列が伸びるほど遅延が増え、バッファの容量を超えた分のパケットは破棄される。後ろから来たパケットを捨てる方式をテールドロップという。
パケットが失われると、TCPは輻輳制御によって送信量を減らす。そのため利用者には「エラーが出る」というより「遅い」「ときどき止まる」と感じられることが多い。音声通話や映像では、遅延とジッタの増加が品質の低下として現れる。
利用率が高くなるほど待ち時間は急に増える。M/M/1モデルでは、平均待ち時間は平均サービス時間の「利用率 ÷(1 − 利用率)」倍になる。
| 利用率 | 平均待ち時間(平均サービス時間の何倍か) |
|---|---|
| 0.5 | 1倍 |
| 0.8 | 4倍 |
| 0.9 | 9倍 |
利用率が0.8から0.9に上がるだけで、待ち時間は2倍以上になる。実際の通信はこのモデルの仮定どおりではないが、「利用率が100%に近づくと遅延が急増する」傾向は共通である。回線や機器の利用率が高止まりしている箇所は、ボトルネックの有力な候補になる。
バッファを大きくすれば破棄は減るが、キューが長くなる分だけ遅延が増える。過大なバッファが遅延を悪化させる問題はバッファブロートと呼ばれる。RFC 7567は、待ちを短く保つ能動的キュー管理(AQM)の利用を推奨している。
速度の違う接続と集約の比率
ボトルネックは、速い区間から遅い区間へ移る場所に生まれやすい。10Gbit/sで接続されたサーバから1Gbit/sの端末へ送る場合、スイッチの出力ポートで一時的にデータがたまる。ごく短い時間だけ通信が集中するマイクロバーストは、数分間隔の平均利用率では見えないことがある。それでもバッファがあふれればパケットが破棄される。
スイッチの設計では、端末側ポートの合計帯域とアップリンクの帯域の比を考える。この比が1を超える状態をオーバーサブスクリプションという。例えば、1Gbit/sのポートが48個あり、アップリンクが10Gbit/s × 2本のスイッチでは次のようになる。
(48 × 1Gbit/s)÷(2 × 10Gbit/s)= 2.4
全端末が同時に上位へ最大速度で送ることはまれなので、ある程度の比率は許容される。ただし、サーバ同士の大量通信やバックアップが集中する構成では、比率を小さくする必要がある。
ボトルネックを見つける手順
「遅い」という申告だけで機器を増強すると、効果がないまま費用だけがかかる。次の順に事実を集め、制限している箇所を絞り込む。
- 症状の範囲を確かめる:特定の利用者・拠点・アプリケーション・時間帯に限られるか
- 通信の経路を図に描き、各区間の帯域と機器を書き出す
- 各区間のインタフェースの利用率と、破棄・エラーのカウンタを確認する
- 経路上の機器のCPU使用率、メモリ、セッション数などの資源を確認する
- 区間を分けてスループットやRTTを測り、どこで値が落ちるかを特定する
- サーバ側の資源と応答時間を確認し、ネットワーク以外の要因を除外する
症状と疑う箇所の対応の例を示す。
| 観測した状態 | 疑う箇所 |
|---|---|
| ある回線の利用率が業務時間中ずっと100%近い | その回線の帯域 |
| 利用率は低いが出力キューの破棄が増えている | 速度差のある接続や短時間の集中 |
| 回線は空いているが、遠い拠点との通信だけ遅い | TCPのウィンドウとRTT |
| 機器のCPU使用率が高く、検査機能の有効化後に悪化した | 機器の処理能力 |
| 通信量に関係なく応答が遅い | サーバやアプリケーションの処理 |
解消の方法とその限界
原因が分かったら、その箇所の能力を上げるか、そこを通る量を減らす。
| 方法 | 内容と注意点 |
|---|---|
| 増速・機器の更改 | 最も直接的。費用と、次のボトルネックへの移動を見込む |
| リンクアグリゲーション | 複数の回線を束ねる。通常はフロー単位で振り分けるため、単一のTCPコネクションは1本の物理リンクの速度を超えない |
| 負荷分散・スケールアウト | 処理を複数の機器やサーバに分ける |
| 通信量の削減 | キャッシュ、CDN、圧縮、不要な通信の停止、時間帯をずらしたバックアップ |
| QoS | 重要な通信を優先する。帯域は増えないので、全体の不足は解決しない |
| TCPの調整 | 受信バッファやウィンドウスケールを見直し、遅延の大きい経路を使い切る |
ボトルネックを解消すると、全体の性能は次に能力の低い箇所の水準まで上がる。そこから先は、その箇所が新たなボトルネックになる。200Mbit/sのWAN回線を1Gbit/sに増速した結果、500Mbit/sしか検査できないファイアウォールが上限になる、といった具合である。改善の効果を見積もるときは、増強する箇所だけでなく、経路上の二番目に遅い箇所も確認する。
午後での問われ方
- 構成図と各区間の速度から、通信の上限を決めている区間を答えさせ、その理由を説明させる
- 回線を増速しても改善しなかった理由を、機器の処理能力やTCPのウィンドウから説明させる
- 監視データ(利用率、破棄の数、CPU使用率)を読み、どの機器・回線を増強すべきか判断させる
- リンクアグリゲーションで帯域を増やしても、特定の通信だけ速くならない理由を問う
- 拠点の統合やクラウドの利用で通信の流れが変わり、新たに混雑する箇所を予測させる