待ち行列理論(Queueing Theory)とITシステム性能モデリング
1. 概要
A. 定義
待ち行列理論とは、サービスを要求する客(リクエスト・トランザクション・パケット)の到着過程とサーバのサービス過程を確率モデルで記述し、待ち行列の長さ・待ち時間・サーバ利用率といった性能指標を数学的に予測する理論である。1909年にデンマークの数学者アグナー・アーラン(A. K. Erlang)が電話交換網の回線数を算定するために創始し、今日ではITシステムの応答時間分析と容量計画(Capacity Planning)の理論的基盤となっている。
待ち行列が生じる根本原因は「到着の不規則性とサービスの有限性」にある。リクエストが完全に一定の間隔で入り、サーバがそれより速く処理するなら待ちは発生しない。しかし現実のリクエストはランダムに集中したりまばらになったりを繰り返し(バースト性)、サーバは一度に有限の数しか処理できないため、瞬間的に処理能力を超えるリクエストが集中すると待ち行列が積み上がる。重要なのは、この待ちがサーバが飽和するはるか前から現れるという事実である。平均利用率がわずか50%でも変動性のために待ちはすでに存在し、利用率が高まるほど待ちは線形ではなく非線形(幾何級数的)に急増する。待ち行列理論はまさにこの「変動性が生む遅延」を定量化する道具である。
B. 登場背景とIT分野での必要性
ITシステムの性能要求(応答時間、スループット、同時利用者数)は、たいてい「平均」ではなく「裾(tail)」で問題になる。平均応答時間が50msでも、上位1%(p99)が2秒を超えれば利用者体験は崩れる。この裾遅延の相当部分はCPU演算そのものではなく資源を待つ待ち時間で発生するため、単に「サーバCPUが何%か」だけを見ても性能は説明できない。待ち行列理論は、CPU・ディスクI/O・スレッドプール・コネクションプール・ネットワークリンクのように「有限のサービス資源を複数が奪い合う」すべての地点を一つの共通した数学モデルに還元し、資源をどれだけ増やせば目標遅延を満たすかを予測可能にする。
実務的にこの理論が答える問いは具体的である。「トラフィックが2倍になれば応答時間は何倍になるか」「目標p95応答時間を守るにはWebサーバインスタンスを何台に増やすべきか」「コネクションプールの大きさをいくつにすればスレッドが飢えないか」といった設計・運用の意思決定がすべて待ち行列モデルに収束する。測定(APM・負荷テスト)が「いま何が起きているか」を見せるとすれば、待ち行列理論は「まだ経験していない負荷で何が起こるか」を外挿(extrapolation)させてくれるという点で相互補完的である。
C. 性能の三つの軸 — スループット・遅延・利用率
待ち行列理論は、性能をスループット(throughput)・応答時間(latency)・利用率(utilization)という三つの軸の関係として理解させてくれる。よくある誤解は、この三つを独立に改善できるという考えだが、実際には互いに緊密に絡み合っている。利用率を高めれば(資源を切り詰めて使えば)応答時間が悪化し、応答時間を守るには利用率を譲らねばならず、スループットの限界は結局サービス率μとサーバ数cが定める。性能設計とは、この三軸の間でビジネス要求に合う均衡点を見いだす作業である。
この視点は性能問題を診断するとき特に有用である。応答時間が悪いとき、その原因が「サービス自体が遅いこと(μ低下)」なのか「待ちが長いこと(ρ過多)」なのかを区別してこそ正しい処方が出るからである。前者はコード・クエリ最適化で、後者は資源増設・負荷分散で臨むべきであり、両者を混同すると見当違いの所に投資してしまう。待ち行列指標(ρ、Wq、待ち行列長)は、まさにこの二つの原因を切り分けて見せる診断道具である。
2. 待ち行列システムの構成と表記法
待ち行列システムは以下のように到着 → 待ち行列 → サーバ → 離脱の流れに抽象化される。どのIT資源であっても(Webリクエストを処理するスレッドプール、ディスクI/O待ち行列、メッセージブローカのコンシューマなど)この共通の枠組みに対応づけられるという点が、このモデルの強力さである。
flowchart LR
SRC["リクエスト到着(到着率 λ)"] --> Q["待ち行列(Queue)"]
Q --> SV["サーバ(サービス率 μ, サーバ c個)"]
SV --> OUT["処理完了後に離脱"]
Q -.->|"待ち行列飽和時に拒否/消失"| DROP["破棄(ブロッキング)"]
style Q fill:#fff3cd,stroke:#d39e00,stroke-width:2px
style SV fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
A. 構成要素
待ち行列を特性づける要素は四つである。第一に、到着過程(Arrival Process)はリクエストが入る時間間隔の分布であり、ITトラフィックはしばしば互いに独立してランダムに到着するポアソン過程(指数分布の到着間隔)で近似する。これは多数の独立した利用者が各自リクエストを送る状況をよく説明するからである。第二に、サービス過程(Service Process)はサーバが一つのリクエストを処理するのにかかる時間の分布であり、分析の便宜のため指数分布を仮定する場合が多いが、実際の処理時間はそれより変動が大きかったり小さかったりしうる。
第三に、サーバ数(c)は同時にリクエストを処理できる窓口の数であり、Webサーバインスタンス数やスレッドプールの大きさ、DBコネクション数に対応する。第四に、待ち行列規律(Queue Discipline)は待機中のリクエストを処理する順序であり、大半はFIFO(先入れ先出し)だが、優先度待ち行列・LIFO・処理時間基準(SJF)などもあり、この選択が裾遅延の分布を大きく変える。ここに待合室容量(K)と客の母集団の大きさ(N)を加えてシステムを完全に規定する。容量が有限なら(K有限)待ち行列が満杯のときリクエストが拒否されるが、これがまさに過負荷時にロードバランサやサーバが返す503/タイムアウトの数学的原型である。
これらの構成要素をIT資源に対応づける「抽象化」そのものが待ち行列モデルの実践的価値である。たとえばTomcatのスレッドプールはc個のサーバと有限待ち行列(acceptCount)を持つM/M/c/Kに、データベースコネクションプールはc個のコネクションをサーバと見るモデルに還元される。異なる階層のボトルネックを同じ言語で記述できるため、リクエストがどの段階で待つのかを一貫して追跡し、最も先に飽和する地点(ボトルネック)を識別できる。
B. 待ち行列規律が性能に与える影響
同じ資源・同じ負荷でも、待機中のリクエストをどの順序で処理するか(待ち行列規律)によって性能特性は大きく変わる。最も一般的なFIFOは公平だが、処理時間の長いリクエスト一つが前を塞ぐと後ろの短いリクエストがすべて遅延するヘッドオブラインブロッキング(head-of-line blocking)が生じる。逆に短い仕事を先に処理するSJF(Shortest Job First)は平均待ち時間を最小化するが、長い仕事が後回しにされ続けて飢餓(starvation)が発生しうる。ネットワークのWFQ、OSスケジューラの優先度待ち行列、メッセージブローカの優先度トピックは、いずれもこのトレードオフを扱う仕掛けである。
実務では待ち行列規律は「SLAの重要なリクエストを保護する」手段として使われる。たとえば決済のような中核トランザクションを優先度待ち行列の上位に置けば、全体負荷が高くても中核リクエストの裾遅延を抑えられる。ただし優先度を導入すると低優先度リクエストの待ちが急増するため、クォータや重みで最小スループットを保証し飢餓を防ぐ設計が並行されねばならない。このように待ち行列規律の選択は「平均」と「公平性」と「裾遅延」の間の均衡問題であり、待ち行列理論は各規律がこの三軸に与える影響を定量的に比較させてくれる。
C. ケンドール表記法(Kendall's Notation)
待ち行列システムはA/S/c/K/N/D形式のケンドール表記法で簡潔に分類する。たとえばM/M/1は「マルコフ(指数分布)到着 / マルコフサービス / 単一サーバ」を、M/M/cは多重サーバを意味する。この表記法のおかげで、まったく異なって見えるIT資源も同じ数学モデルに束ねて再利用できる。
| 記号 | 意味 | ITシステム対応例 |
|---|---|---|
| A | 到着分布 (M=指数, D=決定的, G=一般) | 利用者リクエストパターン |
| S | サービス分布 (M/D/G) | リクエストあたり処理時間分布 |
| c | サーバ(窓口)数 | スレッド・インスタンス・コネクション数 |
| K | システム最大収容量 | 待ち行列バッファサイズ, バックログ上限 |
| N | 客の母集団の大きさ | 全クライアント数 |
| D | 待ち行列規律 | FIFO/優先度/SJF |
3. 中核となる法則と性能指標
A. リトルの法則(Little's Law)
待ち行列理論で最も広く使われる普遍法則はリトルの法則であり、L = λ × Wで表される。すなわちシステム内に滞在する平均リクエスト数(L)は到着率(λ)と滞在時間(W)の積という関係である。この法則の威力は、到着・サービス分布についてのいかなる仮定もなく「安定状態」であれば常に成り立つという普遍性にある。分布を知らなくても、三つの値のうち二つを測れば残り一つを即座に求められる。
実務適用例として、毎秒500件のリクエスト(λ=500)を処理するAPIゲートウェイで平均滞在時間が40ms(W=0.04秒)なら、リトルの法則によってシステム内部に平均L = 500 × 0.04 = 20件のリクエストが同時に「処理中または待機中」であると分かる。これはすなわち、コネクションプールやスレッドプールを最低20以上に取らなければリクエストが資源不足で飢えるという容量設計の根拠になる。逆にスレッドプールの大きさを固定した状態でスループットを測れば、平均遅延を逆算することもできる。
B. M/M/1モデルの数式と状態遷移
最も基本であるM/M/1モデル(単一サーバ、ポアソン到着、指数サービス)は出生死滅過程(Birth-Death Process)としてモデル化される。システム内のリクエスト数が状態であり、リクエストが到着すると状態がλの率で増加(出生)し、処理が終わるとμの率で減少(死滅)する。以下はこの状態遷移を表したもので、各状態間の遷移率がλ(前進)とμ(後退)で一定である点が核心である。
flowchart LR
S0(("0")) -->|"λ"| S1(("1"))
S1 -->|"μ"| S0
S1 -->|"λ"| S2(("2"))
S2 -->|"μ"| S1
S2 -->|"λ"| S3(("3以上"))
S3 -->|"μ"| S2
style S0 fill:#f1f8e9,stroke:#558b2f
style S3 fill:#fde0e0,stroke:#c0392b
この均衡方程式を解くと中核指標が導かれる。サーバ利用率はρ = λ/μであり、システム内の平均リクエスト数はL = ρ/(1−ρ)、平均滞在時間はW = 1/(μ−λ)、待ち行列での平均待ち時間はWq = ρ/(μ−λ)である。具体的に、サーバが毎秒100件を処理でき(μ=100)毎秒80件が到着すれば(λ=80)、ρ=0.8なのでL = 0.8/0.2 = 4件、W = 1/(100−80) = 0.05秒 = 50ms、待ち行列の待ちだけならWq = 0.8/20 = 0.04秒 = 40msとなる。すなわち実際の処理には10msで足りるのに、待ちのせいで体感遅延が50msに伸びたわけである。
ここで注目すべきは、滞在時間Wが「純粋なサービス時間(1/μ)」と「待ち時間Wq」の和(W = 1/μ + Wq)に分解される点である。上の例でサービス時間10msはコードをいくら最適化しても待ち40msには触れられず、待ちはただρを下げてこそ(増設・負荷分散)縮まる。この分解は「同じコードなのになぜピーク時だけ遅くなるのか」というよくある疑問に答えを与える — 遅くなったのはサービスではなく待ちであり、待ちはトラフィックがサービス率に近づくほど非線形に大きくなるからである。性能チューニングの方向(コード最適化 vs 資源増設)を分けるこの区別こそ、待ち行列モデルが与える最も実用的な洞察である。
C. 利用率と飽和 — 非線形な急増
待ち行列理論が与える最も重要な直観は、利用率が100%に近づくほど遅延が幾何級数的に暴騰するということである。上のM/M/1式でL = ρ/(1−ρ)はρが1に近づくと分母が0に収束して発散する。先の例で到着率を90(ρ=0.9)に上げるとL = 0.9/0.1 = 9件、W = 1/10 = 100msで遅延が2倍になり、ρ=0.95ならW ≈ 200msで再び2倍になる。トラフィックが12.5%(80→90)増えただけなのに遅延が2倍になるこの非線形性が、普段は何ともなかったシステムがピーク時間に突然崩れる「性能の崖(performance cliff)」の数学的正体である。
このため性能工学では平均利用率を70〜80%水準に縛っておくことを経験則とする。残る20〜30%は「無駄」ではなく、変動性を吸収して裾遅延を抑える「バッファ」である。これは単に資源を目一杯使うのが費用効率的だという直観と真っ向から反し、待ち行列理論なしには説得しがたい設計原則である。
D. 安定条件とポアソン仮定の含意
待ち行列モデルが意味のある有限の指標を出すには、必ず安定条件(ρ < 1)、すなわち長期平均到着率がサービス処理能力より小さくなければならない。ρ ≥ 1なら待ち行列は無限に積み上がり滞在時間は時が経つほど発散するが、これがまさに過負荷のシステムで応答時間が「一定値に収束せず増え続けるだけ」の現象の正体である。運用でリクエストが絶えず積み上がるだけで減らないなら、チューニングで解決する問題ではなく、処理容量自体が不足する構造的な飽和状態であることを意味する。したがって監視では瞬間遅延だけでなく待ち行列長の趨勢を併せて見て、増加趨勢が折れないかを早期警報の信号とすべきである。
ポアソン到着仮定にはPASTA(Poisson Arrivals See Time Averages)という有用な性質が伴う。ポアソン過程で到着するリクエストがシステムに入る瞬間に観測する平均状態(待ち行列長など)が時間平均と等しいというもので、「ランダムに到着したリクエストが平均的に経験する待ち」をそのままシステムの長期平均として解釈できるようにしてくれる。ただしこの性質は到着がポアソンのときだけ成り立つため、バッチ作業のようにリクエストが束で(バッチ到着)入ったり、再試行の爆発(retry storm)で到着が自己相関を帯びる場合には理論値が実際を過小評価しうる。再試行の爆発は特に危険で、遅くなったサーバにクライアントがタイムアウト後の再要求を浴びせると到着率が非線形に跳ね上がって飽和を加速するため、指数バックオフとサーキットブレーカで到着過程そのものをなだらかにすることが待ち行列的観点の核心的な防御策である。
4. モデル比較と適用事例
実際のIT資源は単一サーバだけではないため、状況に合うモデルを選ばねばならない。以下の比較に見るように、サーバ数と容量制約をどう置くかによってまったく異なる運用特性が現れ、その違いは「並列処理の効果」と「過負荷時の挙動」で分かれる。
| モデル | 特性 | 代表的なIT適用 | 核心的含意 |
|---|---|---|---|
| M/M/1 | 単一サーバ, 無限待ち行列 | 単一スレッドワーカ, 直列I/O | 飽和時に遅延発散 |
| M/M/c | 多重サーバ, 無限待ち行列 | Webサーバプール, スレッドプール | サーバ追加で待ち急減(Erlang C) |
| M/M/c/K | 多重サーバ, 有限待ち行列 | バックログ制限サーバ, ロードバランサ | 待ち行列飽和時にリクエスト拒否(503) |
| M/G/1 | 一般サービス分布 | 処理時間のばらつきが大きい作業(バッチ) | サービス変動性が待ちを大きくする |
A. サーバ統合効果とサービス変動性
特に注目すべきはM/M/cの「サーバ統合効果」である。毎秒160件(λ=160)を処理しつつサーバ一台が100件を処理する場合、それぞれ80件ずつ受ける独立したサーバ2台より共用待ち行列を共有するサーバ2台(M/M/2)のほうがはるかに短い待ち時間を示す。独立構成では一台のサーバにリクエストが集中して暇なとき別のサーバが遊びうるが、共用待ち行列は空いたサーバへ即座にリクエストを割り当てるからである。これがロードバランサの後ろにサーバを集めて共通待ち行列のように運用するほうが、利用者ごとにサーバを固定割り当てするより有利な理由である。サーバ数が多くなるほどこの統合効果はより大きくなり、同じρでも大型プールが小型プールより裾遅延が小さい。マルチテナント環境でテナントごとに資源を割って固定割り当てする設計が、全体資源を共有プールで運用する設計より非効率な根本理由がここにあり、隔離がどうしても必要な部分だけクォータで限定するのが待ち行列的観点の模範設計である。M/G/1モデルはサービス時間の分散が待ちに直接影響を与えるというポラチェック・ヒンチン(Pollaczek–Khinchine)公式を通じて、処理時間のばらつきが大きい作業(例: 大きさがまちまちのファイルアップロード)がなぜ平均処理時間が同じでもより長い待ちを引き起こすかを説明する。
B. 産業適用事例
待ち行列理論の元祖の事例は通信網である。電話交換網は加入者数よりはるかに少ない回線で運用されるが、このとき「通話損失確率を1%以下に保つには回線が何本必要か」をアーランB公式で算定する。同じ原理が今日のVoIPトランク容量、移動通信基地局の同時呼収容設計にそのまま使われる。数万人の加入者を少数の資源で安定的に収容する集約(trunking)効率の根拠が、まさに待ち行列モデルである。
Web・クラウド領域ではコネクションプールのチューニングが代表的である。アプリケーションサーバがDBコネクションプールを過度に大きく取ると、DB側でロック競合とコンテキストスイッチが増えてかえってスループットが落ちるが、これはM/M/cでcをむやみに大きくするとき現れる逆効果とUSLの競合項で説明される。多くの性能ガイドが「コネクションプールをCPUコア数の数倍水準に小さく保て」と勧めるのは、サービス資源(DB)が有限であるため待ちをアプリケーション待ち行列へ吸収するほうが、DB内部の競合で全体が遅くなるよりましだという待ち行列的洞察の結果である。
5. 深化: 性能工学における実務適用と拡張モデル
A. 容量計画(Capacity Planning)への適用
待ち行列モデルは、新規サービスのサーバ台数を算定したり、予想されるトラフィック増加に備えた増設時点を予測したりするのに直接使われる。たとえば目標p95応答時間が200msでリクエストあたりサービス時間が平均50msのとき、M/M/c公式(Erlang C)で目標遅延を満たす最小サーバ数cを逆算する。コールセンターの相談員数算定に使われていたアーランC公式が、そのままマイクロサービスのインスタンス数、コネクションプールの大きさの算定に再利用されるのである。クラウドのオートスケーリングポリシー(目標CPU利用率70%など)も、事実上「ρを安全区間に縛っておく」という待ち行列原理を自動化したものと解釈できる。
具体的な増設判断の事例を見よう。ある決済APIがサーバ1台あたり毎秒50件(μ=50)を処理し、現在のピークトラフィックが毎秒160件(λ=160)だとする。サーバ4台なら総処理能力200件に対してρ=160/200=0.8で安全区間だが、マーケティングイベントでトラフィックが1.5倍(λ=240)に跳ねると4台ではρ=240/200=1.2となって安定条件に違反するため、待ち行列が無限に積み上がり決済が次々とタイムアウトする。目標ρを0.8に保つには必要な処理能力は240/0.8=300件、すなわちサーバ6台が必要だという結論が即座に出る。このように待ち行列理論は「イベント前に何台を前もって立ち上げるべきか」という実務の問いに、測定だけでは得にくい先取りの答えを与える。実際、大規模コマースのフラッシュセールに備えた事前スケールアウトや、連休トラフィックに備えた増設がいずれもこの計算を前提としている。
B. 普遍的拡張性の法則(USL)と現代的拡張
単純なM/M/cモデルはサーバを増やせばスループットが線形に伸びると見るが、現実では競合(contention)と一貫性維持コスト(coherency)のためそうはならない。ニール・ガンサー(Neil Gunther)の普遍的拡張性の法則(Universal Scalability Law, USL)はここに二つの減衰項を加え、サーバ・スレッドを増やすほどスループットの増加が鈍化し、ある点を過ぎるとむしろ減少(逆拡張)する現象を説明する。ロック競合がひどいDBにコネクションをむやみに増やすとかえって遅くなる経験がUSLで定量化される。これは「資源を増やせば速くなる」という素朴な仮定を正し、水平拡張の限界とアーキテクチャ改善(シャーディング、ロック競合の除去)の必要性を判断する根拠になる。
USLの二つの係数はそれぞれ異なる処方を指すという点で診断的価値が大きい。競合係数(直列処理の割合、アムダールの法則と連結)が大きければ並列化できない共有区間(グローバルロック、単一リーダ)がボトルネックなのでその区間を分割せねばならず、一貫性係数(ノード間の調整コスト)が大きければノードが増えるほど相互通信コストが二乗で大きくなるのが問題なので、調整の要らない設計(シャーディング・パーティショニング、シェアードナッシングアーキテクチャ)へ転換せねばならない。負荷テストデータにUSLをフィッティング(fitting)してこの二つの係数を推定すれば、現在のアーキテクチャが何ノードまで効果的に拡張するか(ピークスループット地点)を事前に予測して過剰増設による費用の無駄を防げる。
C. 非同期・イベント駆動アーキテクチャでの再解釈
現代のマイクロサービスは同期呼び出しをメッセージ待ち行列基盤の非同期処理に変える場合が多いが、待ち行列理論はこの転換の効果を明確に説明する。同期構造ではピーク負荷がただちに下流サービスのρを1以上に押し上げて連鎖タイムアウトを招くが、メッセージ待ち行列を挟むと待ち行列がバッファの役割を果たし瞬間負荷を平準化(load leveling)する。コンシューマは自身の安定したサービス率μで着実に処理し、ピーク時に積み上がったリクエストは待ち行列に留まって暇なときに消化される。これはM/M/1/KモデルでK(待ち行列容量)を大きくして瞬間拒否を吸収するのと同じ原理である。
ただし非同期化がρ<1という根本制約をなくしてくれるわけではない。長期平均到着率がコンシューマの処理能力を超えれば待ち行列は果てしなく積み上がってメッセージ遅延(consumer lag)が累積するため、結局コンシューマを増やして処理能力を高めるか(スケールアウト)、生産者に逆圧(backpressure)をかけて到着率を抑えねばならない。すなわち非同期待ち行列はバーストは吸収するが持続的な過負荷は吸収できないというのが待ち行列理論の与える明確な境界線であり、コンシューマラグの趨勢監視がρ推定の実務的な代理指標になる。
D. 測定との結合
近年の可観測性(Observability)ツールは利用率・待ち行列長・滞在時間をリアルタイムで収集するため、待ち行列公式と結合すれば「現在のρでトラフィックが1.5倍になればp99がいくつになるか」を運用中に予測できる。ただし実際のITトラフィックは完全なポアソン過程ではなく自己相関・バースト性を帯びる場合が多いため、理論値と実測値に乖離が生じうる。したがってモデルは「正確な予言」ではなく「傾向と限界を見るレンズ」として使い、重要な決定は必ず負荷テストで検証するのが安全である。
実務でこの結合を実装する一つの方法は、負荷テストで測定した(ρ, 応答時間)のいくつかの点にM/M/c曲線を合わせ、まだ測定できていない高負荷区間をその曲線で外挿することである。こうすれば実際に障害を経験せずとも「サービスが崩れ始める臨界ρ」を推定でき、オートスケーリングの閾値やアラーム基準をデータに基づいて設定できる。測定が過去を、モデルが未来を担うこの協業が、成熟した性能工学の姿である。
6. 考慮事項および示唆点 (技術士の観点)
- 利用率を安全区間(70〜80%)に縛って設計する。 遅延がρに非線形に反応するため、資源を100%埋めて使おうとする設計はピーク時に性能の崖を招く。残る余裕容量は変動性吸収用のバッファと見て、オートスケーリングの閾値とSLAをこの原理に合わせて設定すべきである。
- 「平均」ではなく「裾遅延」を管理する。 利用者体験とSLAはp95・p99で決まり、裾遅延の相当部分は待ちで発生する。サービス時間の変動性(分散)を減らすこと(リクエストの大きさの平準化、遅いクエリの除去)が平均短縮と同じくらい重要である。
- 資源共有(共用待ち行列)が分割より有利である。 サーバ・コネクションを利用者/テナントごとに固定分割するより、共用プールに束ねて遊休資源を再活用すれば同じ資源で待ち時間を減らせる。ただし公平性・隔離(Noisy Neighbor)の要求とトレードオフがあるため、優先度待ち行列・クォータで補完する。
- 水平拡張は無限ではない(USL)。 競合・一貫性コストのため、サーバを増やしてもある点から効果が減ったり逆転したりする。増設前にボトルネックが資源不足か競合かを区別し、後者ならシャーディング・ロック除去などアーキテクチャ改善を並行せねばならない。 [[consistent-hashing]]
- 理論と実測を併せて使う。 待ち行列モデルは経験していない負荷を外挿するレンズであり、実際のトラフィックはバースト性のため理論と食い違いうる。容量計画はモデルで仮説を立て、負荷テスト・可観測性データで検証する二重体系で運用する。
- 過負荷は「拒否」で防御する。 安定条件(ρ<1)を超える負荷ではすべてのリクエストを受け入れると待ち行列が発散して全面障害に広がる。有限待ち行列(M/M/c/K)モデルが示唆するように、収容限界を超えるリクエストは速やかに拒否(load shedding・admission control)し、再試行の爆発をバックオフ・サーキットブレーカで抑え、受け入れたリクエストの分だけはSLAを守るほうが全体崩壊よりましである。
参考資料
- Neil J. Gunther, "Guerrilla Capacity Planning", Springer: https://www.perfdynamics.com/Manifesto/USLscalability.html
- Wikipedia, Queueing theory: https://en.wikipedia.org/wiki/Queueing_theory
- Wikipedia, Little's law: https://en.wikipedia.org/wiki/Little%27s_law
一言まとめ: 待ち行列理論はリクエストの到着の不規則性とサービスの有限性が生む待ちを確率モデルで定量化し、リトルの法則とM/M/c公式で応答時間・容量を予測し、利用率が高まるほど遅延が非線形に急増することを明らかにして、IT性能設計と容量計画の数学的基盤を提供する。