English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

ゲスト
1 / ?

L = λ × W:長方形

リトルの法則:キャパシティプランニングで最も有用な方程式

ジョン・リトルは1961年に、安定したキューについて、その内部構造に関わらず、L = λ × Wであることを証明しました。ここで:

- L = システム内のアイテムの平均数(キュー + 処理中)

- λ(ラムダ)= 単位時間あたりのアイテムの平均到着率

- W = 各アイテムがシステムに費やす平均時間

幾何学的解釈:一つの軸に到着率λをプロット、もう一つに滞在時間Wをプロット。積Lはそれらが形成する長方形の面積です。キャパシティプランニングはこの長方形の内部で展開されます。

なぜ重要か:3つの量のうちいずれか2つが3番目の量を決定します。スループットとレイテンシを測定すれば、占有率がわかります。占有率とスループットを測定すれば、レイテンシがわかります。この法則は堅牢です:ウェブリクエスト、レストランのテーブル、スーパーマーケットのキュー、CPUパイプラインなど、修正なしに適用されます。

3つの具体例:

- ウェブサービスが毎秒200リクエストを処理し、平均レイテンシが50 ms(0.05秒)です。L = 200 × 0.05 = 常に飛行中のリクエストは10個です。

- コーヒーショップは時間あたり60人の顧客にサービスを提供し、平均滞在時間は15分(0.25時間)です。L = 60 × 0.25 = 平均して店内に15人の顧客がいます。

- 工場ラインは時間あたり100個のウィジェットを生産し、各ウィジェットはエンドツーエンドで2時間かかります。L = 100 × 2 = 処理中のウィジェットは200個です。

プロビジョニングの意味:L(同時処理中のアイテム)のサイズを決められれば、システムのサイズが決まっています。ワーカースレッドの数、データベース接続数、またはキュースロット数は、すべてLから導き出されます。

リトルの法則を長方形として:x軸にλ、y軸にW、面積 = L

ワーカープールのサイジング

あなたのビデオトランスコーディングサービスは、平均到着率が1分あたり30個のトランスコーディングジョブで、各ジョブはエンドツーエンドで90秒かかるように、サイズが設定されています。現在のワーカープールには30人のワーカーがいます。

リトルの法則を適用して、現在のプールが十分にサイズ設定されているかどうかを判断してください。計算を示してください。その後、到着率が2倍になった場合に何が変わるか、および個々のトランスコード時間が2倍になった場合に何が変わるかを説明してください。どのシナリオがシステムに最もストレスをかけるか?

利用率が80%を超えるとレイテンシが爆発する理由

キャパシティプランニングで最も重要な曲線

x軸に利用率(0%~100%)をプロット、y軸に平均レイテンシをプロットします。この形状は運用の中で最も重要な曲線の1つです:チームが100%よりもはるかに低い利用率を目標とする理由、予約済みのヘッドルームが無駄ではない理由、高い利用率で「効率的に」実行されているシステムが予告なく停止する理由を説明します。

M/M/1キューイング曲線:ポアソン到着(ランダム)と指数分布のサービス時間(ランダム)を持つシステムの場合、平均待機時間は次のようになります:

W_q = ρ / (μ(1-ρ))

ここで、ρ(rho)は利用率(0~1)、μはサービス率です。分母(1-ρ)がポイントです:ρが1に近づくと、分母は0に近づき、待機時間は無限大に近づきます。

数値例(M/M/1のレイテンシ倍数対ρ):

- ρ = 0.5:レイテンシ比率 1.0(ベースライン)

- ρ = 0.7:レイテンシ比率 ~2.3

- ρ = 0.8:レイテンシ比率 ~4.0

- ρ = 0.9:レイテンシ比率 ~9.0

- ρ = 0.95:レイテンシ比率 ~19.0

- ρ = 0.99:レイテンシ比率 ~99.0

肘は70~80%の利用率の周辺にあります。肘の下では、負荷を追加するとレイテンシが遅く増加します。肘の上では、レイテンシが非線形に爆発します。これが正統的なSREルールが次の理由です:定常状態の利用率を80%以下に保つ、90%以上で継続して実行しないこと。

従来のオペレーションチームがこれを過小評価する理由:60% CPUのサーバーは「ビジーに見える」が、レイテンシのヘッドルームは十分です。90% CPUのサーバーは「生産的に見える」が、ワークロードの1つのバンプからレイテンシ災害まで1歩です。幾何学的真実:曲線の傾斜が実際の脅威であり、その現在のy値ではありません。

M/M/1キューイング曲線:x = 利用率、y = レイテンシ、肘~80%

曲線を読む

チームは85% CPU利用率の定常状態でサービスを実行しています。現在のp99レイテンシは200 msです。彼らは廃止予定の別のサービスからワークロードを統合するために、トラフィックを30%増やすことを検討しています。

キューイング曲線を使用して、85%が大体110%(容量超過)になるとレイテンシに何が起こるかを予測してください。なぜCPU利用率は100%以上で文字通り維持できないのか、そしてそれに代わる目に見える症状は何か?統合ワークロードのターゲット利用率を推奨し、残しているヘッドルームを正当化してください。

勾配、切片、予測コーン

勾配から成長を読む

多くの場合、需要予測は履歴データを通す正しい線を描くことに要約されます。その線の幾何学的特性:勾配、切片、および不確実性コーンは、予測全体をエンコードします。

線形トレンド(y = mx + b):短い期間または真の線形プロセスに適切です。勾配mは単位時間あたりの成長率です。切片bは開始値です。成長が安定しているときに便利です。プロセスが実際に複合しているときに過小評価する傾向があります。

指数トレンド(y = b × e^(mx)):複合成長に適切です:ウイルス採用、ユーザーネットワーク効果、乗法的な季節性。対数スケールのy軸では、指数成長は線形になり、勾配推定が簡単になります。対数スケール上の勾配mは単位時間あたりの成長率です。

区間線形:成長に異なるレジームがある場合に適切です。スタートアップは18ヶ月間ゆっくり成長し、その後ウイルス変曲点があり、6ヶ月間の爆発的成長を産む可能性があり、その後プラトーに達します。3つの線形セグメントは、任意の単一曲線よりもこれに適合します。

予測コーン:中央推定値と上限および下限、将来へ広がるコーンで描画されます。コーンの幅は時間とともに増加します。これは不確実性が複合するためです。4週間の予測は±10%の境界を持つ可能性があります;12ヶ月の予測は多くの場合±50%以上です。

季節性分解:実際の需要は、トレンド+季節サイクル+ノイズの組合せです。統計ライブラリ(statsmodels、Prophet)は、系列をこれら3つのコンポーネントに分解し、トレンドを季節パターンから独立して投影できます。幾何学的には、トレンドは基本的なドリフト、季節性はトップの周期的な波紋、ノイズは残差ジッターです。

予測コーン:トレンド線、季節波紋、広がる不確実性境界

トレンドモデルを選択する

24ヶ月の月次リクエストボリュームがあります。月1~12は1Mから2Mに成長しました(線形に見える、+83K/月)。月13~18は2Mから4Mに成長しました(より急峻、+330K/月)。月19~24は4Mから12Mに成長しました(さらに急峻)。マーケティングはウイルス製品機能が月13で開始され、変曲点を駆動していることを確認しています。

どのトレンドモデルが最適に適合するか:純粋な線形、純粋な指数、または区間線形?勾配の動作を使用して選択を正当化します。次に、月25~30の予測を提案します:明示的な中央推定値、上限、下限。どの現実世界のイベントがどちらかの境界を破ることができるか?

需要と容量を2次元幾何学として

すべてのキャパシティチームが内部に住むプロット

x軸に時間をプロット。y軸に需要と容量を2つの別々の線としてプロットします。任意の時点でそれらの間の垂直間隔は、ヘッドルームです。曲線間の2次元面積は、ヘッドルームエンベロープです。

3つの参照形状:

- 健全なエンベロープ:容量線は需要線を快適に上回ります。ピーク時にギャップが狭くなる可能性がありますが、消滅することはありません。エンベロープは安全のバンドです。

- 閉鎖中のエンベロープ:容量の成長が需要より遅くなります。ギャップは時間とともに狭くなります。将来の交差点は、システムがヘッドルームを実行するときです:チームが容量を追加する必要がある日付。

- 反転エンベロープ:需要は容量を超えています。システムはインシデント領域内にあります。反転の垂直大きさは、どういうわけか提供する必要があるある赤字です(キューオーバーフロー、エラー率、カスタマー影響)。

標準キャパシティプランニングチャートプロット:

- 最近の需要履歴(実線青)

- 予測需要と境界(破線+影付きコーン)

- 現在の容量(実線緑)

- 配信日付を持つ計画されたキャパシティ追加(ステップ関数)

- 予測需要が現在の容量を超える交差点日付:これは次のプロビジョニングのための期限です

視覚的決定ルール:容量ステップ関数を予測コーンの上限より常に上に保つ。中央推定値にプロビジョニングしないでください;上限にプロビジョニングします。オーバープロビジョニングのコストは有限です(アイドル容量);アンダープロビジョニングのコストは無制限です(失われたユーザー、カスケード障害、評判の悪化)。

ヘッドルームエンベロープ:需要線、容量ステップ関数、予測コーン、交差点日付

エンベロープを読む

キャパシティチャートは次のようになっています:現在の需要は1,500 RPSで、月20%成長しています。現在の容量は2,500 RPSです。新しいサーバーバッチ(+1,500 RPS容量)は8週間後に到着します。予測コーンは8週間の地平線で±15%の範囲を持っています。

予測需要(中央推定値、上限)が現在の容量に達する日付を計算します。新しいサーバーバッチは時間内に到着するか?今後8週間から新しいバッチ到着の間のエンベロープの視覚的な形は何ですか、上限需要が新しいバッチが到着する前に現在の容量と交差する場合、どのようなアクションを取るか?

キャパシティの幾何学:まとめ

将来を予測する形状

キャパシティプランニングの下に走る4つの幾何学的構造を進みました:

- リトルの法則(L = λ × W)定常状態の占有率を定義する長方形の面積として

- キューイング曲線その肘が80%利用率、実行ホット性のコストをエンコード

- トレンド勾配と予測コーン履歴データを実行可能な投影に変換する

- ヘッドルームエンベロープ容量対需要の2次元プロット、プロビジョニング期限をマークする交差点日付


キャパシティプランニングは、その視覚的なコアでは、時間をかけて1つの曲線を別の曲線より安全に保つ規律です。数字は調味料です;形状は真実を運びます。キューイング曲線を正しく読む容量エンジニアは、CPUダッシュボードがシステムがすでに燃えているまで隠す問題をキャッチします。


キャパシティプランニング上の同盟者のレッスンは、実践をカバーしました:測定、予測、天井テスト、ヘッドルーム、スケーリング。このレッスンはそれらの下にある幾何学を覆いました。一緒に彼らは、サプライズなしにスケーリングされるサービスを実行する視覚的および分析的なスキャフォルディングを形成します。