ワークロード対利用率

2つの異なる数値、両方必須

チームが2つの本質的な次元のうち1つだけを測定するとき、キャパシティプランニングは失敗します。

ワークロード：外部からのシステムへの需要。1秒あたりのリクエスト、1分あたりのトランザクション、1秒あたりのメガバイト、同時ユーザー。ワークロードは世界があなたに求めていることを説明します。

利用率：その需要を提供しながらシステムが実行する満度。CPU％、メモリ使用、キュー深さ、ネットワーク帯域幅、ディスクIOP。利用率は、その需要下でシステムがどのように感じられるかを説明します。

ワークロードだけでは、何が来るかは分かりますが、あなたがそれを提供できるかどうかは分かりません。利用率だけでは、あなたがどれだけいっぱいであるかは分かりますが、明日何を期待するべきかは分かりません。キャパシティの決定を下すために、両方の側を並べてプロットする必要があります。

キャパシティレート = ワークロード／利用率。1000リクエスト/秒を50% CPUで提供する場合、キャパシティレートはサーバーあたり100% CPUあたり2000 RPSです。この変換係数により、予測されたワークロードを必要なサーバー数に変換できます。

Allspawは適切な粒度での測定を強調しています。1分ごとに1サンプルは30秒のピークを隠します。1時間ごとに1サンプルはすべてを隠します。実際のキャパシティ作業には、ピークイベント用の分以下の解像度と、トレンド用の分解像度が必要です。それより粗いものはすべて危険な誤った自信を生成します。

何を計測するか

あなたのチームは新しい製品ローンチ(ビデオトランスコーディングサービス)にキャパシティ計測をデプロイしています。最大8つのメトリクスを分以下の解像度で追跡できます。サービスはビデオアップロードを取り込み、キューに入れ、複数の形式にトランスコードし、出力をオブジェクトストレージに書き込みます。

トレンド、季節性、不確実性

すべての予測の3つのレイヤー

AllspawとGoogle SREブックは有用な予測の構造に同意します：トレンド、季節性& 不確実性の境界。1つだけをスキップすると、予測は誤解を招くようになります。

トレンド：数か月または数年にわたる需要の傾斜。短い期間の線形回帰、複合成長のための指数または区分線形でモデル化されることが多い。トレンド線は「需要は一般的にどこに向かっているのか？」に答えます。

季節性：複数の時間スケールでの周期的なパターン。毎日(午後のピークトラフィック)、週ごと(ウィークエンドスパイク)、年ごと(ブラックフライデー、税務シーズン、学年度)。乗法的季節性はトレンドでスケーリングします。加算的季節性は一定のオフセットを追加します。

不確実性の境界：予測円錐。境界のない予測は推測です。実際の予測は、明示的な上下の境界を持つ中心推定値を公開します。通常、90％または95％の信頼性で。円錐は将来に投影されるほど広くなります。4週間の予測は±10%の境界を持つかもしれません。12か月の予測はしばしば±50%を持ちます。

ビジネス成長と技術需要の分離：キャパシティプランニング予測は技術的なワークロードですが、ビジネスチームは収益、サインアップ、またはキャンペーンを予測します。キャパシティプランナーの仕事は、ビジネス予測を技術需要に変換することです：30%のサインアップ成長は30%のAPI呼び出し増加を意味するかもしれませんが、新しいユーザーがシステムをより頻繁に使用する場合は80%を意味する可能性があります。または彼らがより低い率で変換する場合は15%だけ。変換レートは基礎となるビジネス予測と同じくらい重要です。

ホリデートラフィック予測

あなたのサービスはeコマースサイトを提供しています。昨年のブラックフライデーのトラフィックは11月の平均の5倍で、12時間続きました。ビジネスは年間ベースで40%成長しています。マーケティングはブラックフライデーのトラフィックに追加で20%が追加されると予想される有料プロモーションをローンチしています。

あなたの天井を知る

本番環境がそれを見つけるまえに天井を見つけてください

予測は何が来るかを教えてくれます。天井テストはシステムがそれを提供できるかどうかを教えてくれます。Allspawは天井テストをキャパシティプランニングへの交渉不可能な入力として扱います：制御された負荷の下でシステムをテストするまで、あなたの実際のキャパシティを知りません。

3つの天井テストタイプ：

- 合成負荷テスト：負荷ジェネレータ(k6、Locust、JMeter、vegeta)が対象サービスをステージングで駆動します。何かが壊れるまで負荷を増やします。破損点は天井です。隔離されたサービステストに最適です。

- 本番火を演習：故意にキャパシティを本番で削減し(サーバーの割合をドレイン、リージョンを削除)、残りのキャパシティが実トラフィックをどのように処理するかを観察します。真の本番環境の動作をテストします(予期しない相互作用を含む)。最高の信頼性ですが最高のリスク。

- シャドウ負荷：実本番トラフィックを並行して本番に対して実行中の対象サービスで再生します。実トラフィックパターン(稀なクエリミックス、奇妙なユーザーエージェント)をキャプチャ、ユーザーに影響を与えずに。強い中間。

ヘッドルームは現在の負荷と天井の間のバッファです。SREの経験則：

- 定常状態で50%のヘッドルーム(リージョン障害がサバイバルリージョンを枯渇させない)

- N+2冗長性を持つマルチリージョンサービスの場合30%のヘッドルーム

- 既知のピークイベント(ブラックフライデー、スポーツファイナル)に近づいているときに100%+のヘッドルーム

ヘッドルームは廃棄物ではありません。 これは、午前3時にエンジニアをページング電話しないこと、スパイク中に顧客を失わないこと、1つのリージョンが失敗したときにカスケード障害を被らないことの費用です。ファイナンスチームはヘッドルームの削減を押す場合があります。キャパシティエンジニアは、その会話が感情的ではなく事実に基づくものにするために、ぴったりの実行のコストを明確にする必要があります。

天井テストの設計

あなたは、文書化されたキャパシティ天井がないサービスを継承します。現在の本番環境の負荷は12台のサーバーで800リクエスト/秒、平均CPU 35%です。マーケティングはピークで3000 RPSにトラフィックを駆動すると予想されるキャンペーン発表をしています。

上、外、または対角

電力を追加するか、ボックスを追加するか、または両方を追加するかのタイミング

3つのコアスケーリング戦略、各を異なるコストと信頼性プロフィール：

垂直スケーリング(スケーリング)：より大きなマシン。8コアサーバーを32コアサーバーに交換します。最もシンプルなパス。単一マシンの制限に達するまで機能します。単一障害点は残ります。コストは非線形に成長します：32コアマシンはしばしば8コアの4倍以上の費用がかかります。

水平スケーリング(スケーリング)：より多くのマシン。ロードバランサーの後ろにサーバーを追加します。キャパシティはサーバー数に線形にスケーリングします。障害モードはシフトします：分散調整を処理する必要がありますが、単一サーバーの障害ではサービスが破壊されません。運用の複雑さが増加します。

対角スケーリング(Allspawの用語)：最初にスケーリング、快適なサーバーごとサイズに、次に外側にスケーリングします。より大きなサーバーの単純な運用を複数のサーバーの冗長性と組み合わせます。ほとんどの本番環境サービスは対角スケーリング領域に住んでいます。

予約対需要価格設定：クラウドプロバイダーは予測可能性に報います。予約容量はオンデマンドより30-60%安いですが、1-3年の承認が必要です。キャパシティプランナーは通常、定常状態の需要を予約容量で固定し、ピークをオンデマンドにバースト。これの分割の誤りは、お金を浪費する(過剰予約)か、予算を曝露する(ピーク中の驚き)ができます。

スポットインスタンスと先制可能なワークロード：オンデマンドより60-90%安いですが、数分の通知で回収されます。バッチジョブ、分析、トレーニングワークロード、または優雅な割り込みのために設計されたサービスに適しています。本番ユーザー向けのトラフィックは通常スポットを避けます。

スケーリングパスの選択

あなたのビデオトランスコーディングサービスは、8つの中型クラウドインスタンス(各8コア)で実行します。次の6か月で3倍の成長が予想されます。ワークロードはCPU制限、ビデオごとに並列化可能& 各ビデオトランスコードは90秒の end-to-end。予約インスタンスはオンデマンドの50%の費用がかかります。スポットインスタンスはオンデマンドの30%の費用がかかりますが、2分の通知で終了される可能性があります。

キャパシティプランニングキャリア

キャパシティプランニングのスキルが支払う場所

キャパシティプランニングはそれ自体でめったに仕事のタイトルです。スキルは複数の役割の下で表示されます：

サイト信頼性エンジニア：キャパシティプランニングはコアSRE責任です。ほとんどのSREチームには、キャパシティを専門とする1、2人のエンジニアがいて、予測モデル、天井テスト& プロビジョニングの自動化を所有します。

クラウドコスト/ FinOpsエンジニア：クラウド支出最適化に焦点を当てた新しい役割。キャパシティプランニングを金融モデリング、契約交渉& 予約インスタンスポートフォリオ管理と組み合わせます。大規模なクラウドネイティブ企業では非常に上手く支払われます。クラウド請求はしばしば給与の後で2番目に大きい費用だからです。

パフォーマンスエンジニア：ノードごとのefficiencyと天井テストに焦点を当てます。仕事：プロファイリング、最適化& アーキテクチャの変更を通じた同じハードウェアからより多くのキャパシティを抽出します。重いシステムと言語ランタイムの知識。

キャパシティプランニングスペシャリスト：非常に大規模な企業(Google、Meta、Amazon、Netflix)では、専用のキャパシティプランニングチームが存在します。彼らはフリート全体にわたる予測モデル、スケール調達& マルチ年ハードウェアロードマップの調整と財務を所有します。

複合スキル：時系列分析(R、Python statsmodels、Prophet)、キューイング理論(M/M/1、M/M/c、Little's Law)、少なくとも1つの構成管理ツール、少なくとも1つのクラウドコストダッシュボード& CFOが理解し、行動できる予測レポートを書く能力。技術的なスキルはあなたをインタビューに入れます。コミュニケーションスキルはあなたに予算を取得させます。

ラッピングアップ

あなたが今知っていること

キャパシティプランニングは継続的な規律であり、年間演習ではありません。カバーしました：

- アンダープロビジョニングとオーバープロビジョニングの間の通路

- 測定の2つの次元としてのワークロード対利用率

- すべての予測の3つのレイヤーとしてのトレンド、季節性& 不確実性の境界

- 天井テスト(合成、影、火演習)本当のキャパシティを知る唯一の方法として

- ヘッドルームバッファとそれが廃棄物ではない理由

- 対角スケーリングと予約/オンデマンド/スポット価格決定

- これらのスキルが予算権を獲得するキャリアパス

2つのアイデアが最も重要です。単一ポイントで境界ではなく、予測してください。 & 本番環境がそれを見つけるまえに、天井を測定してください。 これら2つを前進させて、残りが続きます。

推奨読書：Allspawの『The Art of Capacity Planning』(O'Reilly、2017第2版)、Google SRE Bookの関連章(sre.google/books/で無料)& Brendan Greggの『Systems Performance』基礎システム作業のために。ジオメトリー-コンパニオンレッスンはより深く掘り下げます：Little's Lawをエリアとして、キューイング曲線、トレンドスロープ& ヘッドルームエンベロープ。