ネットワーク監視・トラブルシュート

ボトルネック分析ぼとるねっくぶんせき

パフォーマンススループット制約理論レイテンシ帯域幅キャパシティプランニング

ボトルネック分析について教えて

簡単に言うとこんな感じ！

「どこが詰まってシステム全体が遅くなってるの？」を突き止める作業だよ！水がボトル（瓶）の首で詰まるように、処理の流れの中でいちばん細い箇所を見つけて、そこを改善することで全体の速さを上げるんだ！

ボトルネック分析とは

ボトルネック分析とは、システムやネットワークの処理速度・スループット（単位時間あたりの処理量）を低下させている「最も遅い箇所＝ボトルネック」を特定し、その原因を究明・改善するための手法です。「ボトルネック（bottleneck）」とはボトル（瓶）の首の部分を意味し、どれだけ瓶を傾けても液体は首の細さ以上の速さでは出てこないことから、処理の詰まりポイントを指す言葉として使われています。

重要なのは「全体の速度は、いちばん遅い箇所によって決まる」という原則です。たとえばサーバーのCPUをどれだけ強化しても、ネットワーク回線が細ければ全体のパフォーマンスは改善しません。逆にいうと、ボトルネックを正確に特定して集中的に改善すれば、コストを最小限に抑えながら最大の効果を得られるというメリットがあります。

情報システムの発注・改善を判断する立場では、「なんとなく遅い」というふわっとした現象を数値で分析し、「どこにいくら投資すれば効果的か」を根拠を持って判断するためのフレームワークとして活用されています。

ボトルネックが生まれる仕組み

処理の流れは「パイプライン」に例えられます。データがA→B→C→Dと順番に処理されるとき、いちばん細い管の部分が全体の流量を決定します。

入力 ──[A: 1000Mbps]──[B: 1000Mbps]──[C: 100Mbps]──[D: 1000Mbps]──> 出力

                                         ↑
                                ここがボトルネック！
                             全体のスループットは100Mbps

代表的なボトルネックの種類

分類	代表的な原因	主な症状	調査ツール例
CPU	処理量過多・非効率なコード	CPU使用率が常に90%超	top, htop, Task Manager
メモリ	メモリ不足によるスワップ発生	ディスクI/Oが急増、応答が断続的に遅延	free, vmstat
ディスクI/O	HDDアクセス集中・RAID構成の問題	読み書き待ちキューが増加	iostat, iotop
ネットワーク帯域	回線容量の上限到達	転送速度が頭打ち、パケットロス発生	iperf3, Wireshark
データベース	インデックス不足・スロークエリ	特定の操作だけ極端に遅い	EXPLAIN, スロークエリログ
アプリケーション	ロック競合・非効率なループ処理	スレッドが詰まり応答が止まる	APMツール, プロファイラ

ボトルネック分析の基本ステップ

計測する　── まず現状を数値で把握。「なんとなく遅い」はNG
可視化する　── 処理フロー全体をマップにして流量・待ち時間を並べる
最遅箇所を特定する　── 統計的に最も処理時間・待ちが多い箇所を絞る
原因を仮説立てる　── 過負荷なのか、設計の問題なのかを切り分ける
改善して再計測する　── 効果を数値で確認し、次のボトルネックを探す

⚡ ポイント：ボトルネックを1つ解消すると、次の最遅箇所が新たなボトルネックになります。「改善→計測→次の問題発見」を繰り返すサイクルが重要です。

歴史と背景

1984年　物理学者エリヤフ・ゴールドラットが著書『ザ・ゴール』で制約理論（TOC: Theory of Constraints）を提唱。工場の生産ラインにおける「制約（ボトルネック）」を管理することで全体最適を図る考え方を体系化。ITにも応用された
1990年代　インターネット普及に伴いネットワーク帯域のボトルネックが社会問題化。ISDNからADSLへの移行、バックボーン増強などが進む
2000年代　Webサービスの爆発的拡大により、サーバーサイドのパフォーマンス分析が必須に。Apache JMeter（2001年）などの負荷テストツールが普及
2010年代　クラウド化が進み、APM（Application Performance Management）ツール（New Relic、Dynatraceなど）が登場。コード単位での詳細なボトルネック可視化が可能に
2020年代　マイクロサービスアーキテクチャの普及により、複数サービス間の依存関係が複雑化。分散トレーシング（OpenTelemetryなど）がボトルネック分析の標準手法として定着

制約理論（TOC）とボトルネック管理の考え方

IT分野でのボトルネック分析は、ゴールドラットの制約理論（TOC）に基づく5ステップが実務の基本フレームワークになっています。

ネットワーク系ボトルネック vs. アプリケーション系ボトルネックの違い

観点	ネットワーク系	アプリケーション系
主な原因	帯域不足・遅延・パケットロス	コードの非効率・DBスロークエリ
影響範囲	全ユーザー・全サービスに同時	特定機能・特定ユーザーに限定されやすい
計測ツール	ping, traceroute, iperf3, Wireshark	APMツール, プロファイラ, DBの実行計画
改善手段	回線増強・CDN導入・QoS設定	コード最適化・インデックス追加・キャッシュ
発注判断	ベンダーへの回線増速依頼	開発ベンダーへの改修依頼

規格・RFC番号	内容
RFC 2544	ネットワーク機器のベンチマーク試験手法の標準規格（スループット・レイテンシ計測）
RFC 6349	TCP スループット試験のフレームワーク（実環境でのボトルネック特定に活用）
RFC 7799	パフォーマンス計測の分類と定義（Active/Passive計測の整理）
ITIL v4	パフォーマンス管理プロセスとして容量・可用性管理にボトルネック分析を位置づけ