容量見積もりツール

キューは飽和した時点ではなく、飽和する前に爆発するからです。平均 95% 忙しい CPU は、トラフィックが揺れるたびにキューが際限なく伸びる CPU です。そしてトラフィックは常に揺れます。利用率の目標は、ピーク、デプロイ、リトライ、そして 1 つの遅い依存先を吸収する余裕です。70% はレイテンシに敏感なサービスの業界標準であり、遅延を許容できるバッチワーカーはもっと熱く動かせ、ユーザー向けでスパイクのあるものは何でももっと冷たく動かすべきです。

答える質問が違います。コア数は CPU サービス時間から来ます。各リクエストがどれだけのプロセッサを消費するかです。処理中のリクエスト数は Little's law から来ます。レートに応答時間を掛けたもので、測るのはプロセッサ負荷ではなく同時処理数、つまり接続、スレッド、開いたまま保持されるメモリです。下流の呼び出しが遅いサービスは、2 コアを使いながら 500 件のリクエストを処理中に保持でき、CPU が尽きるずっと前に接続プールが尽きます。両方を規模算定してください。無視した方が障害になります。

負荷テストは通常、暖まって安定し、キャッシュが熱いサービスが、余裕のあるクライアントから 1 種類のリクエスト形状に答える様子を測ります。本番ではコールドスタート、TLS ハンドシェイク、リトライ、遅いリクエストのロングテール、うるさい隣人、そして 10 分間容量を半分にするデプロイが加わります。この見積もりツールは意図的に保守的です。平均 CPU 時間、利用率の上限、サーバー単位の切り上げ、冗長性の追加。負荷テストは可能性の上限として、この数字は用意すべき下限として扱ってください。計画にとっての真実は下限です。

1 回の障害からです。死んだホスト、ローテーションから外された悪いデプロイ、単一インスタンスを持っていく可用性ゾーンのイベント。N+1 があれば、残りの N 台のサーバーでも目標を満たします。まずトラフィックから N を規模算定し、その後に予備を加える意味はそこにあります。2N は別の約束です。通常はリージョンをまたいだ 2 つの完全なコピーで、コピー全体を失っても生き残らなければならないサービスのためのものです。料金は 2 倍になるため、その不在が見出しで測られるサービスのために買われます。

推測ではなく測定してください。稼働中のサービスでは、ある時間枠で消費された CPU 秒数の合計を、同じ時間枠で処理したリクエスト数で割ります。アプリケーションパフォーマンス監視ツールはリクエストごとの CPU として直接報告します。Linux では /proc のプロセス CPU 時間やコンテナのメトリクスから導出できます。全日の平均ではなく、現実的な最も忙しい 1 時間の数字を使ってください。平均から計画した容量は、それを買った目的であるピークでこそ失敗します。