9.7 キャパシティ計画と需要予測

概要と動機

すべてのシステムには天井があります。計算コアは尽き、ディスクは満杯になり、コネクションプールは枯渇し、朝食時には空だったキューが昼食時にあふれます。キャパシティ計画とは、計算、ストレージ、ネットワークの供給を、期待する需要に、普通の日が天井に近づくことが決してなく、悪い日が壊滅的ではなくグレースフルに失敗するだけの余裕を持って合わせる規律です。需要予測はもう半分です。どれだけの負荷が、いつ、なぜ来るかを予測し、供給が停止の後ではなく需要より先に届くようにします。

この章は二つの隣接する章の間に位置し、どちらとも補完的です。3.5章は、アーキテクチャの性質としてのスケーラビリティを扱います。ステートレス性、シャーディング、水平スケーリングを通じて、システムがそもそも育てるようにどう築くか。9.1章は、容量が守らなければならない信頼性の目標を設定する、サイトリライアビリティエンジニアリング(SRE)を扱います。ここでは、アーキテクチャを所与とし目標を固定されたものとして、量的な問いに答えます。システムが、予測された需要と予測しなかった急増を通じてサービスレベル目標(SLO、9.1章の信頼性の目標)を満たすよう、すべてをどれだけ買い、予約し、予備として保持する必要があるか。オートスケーリングとパフォーマンスエンジニアリング(2.16章)はここで使う道具ですが、計画の代わりにはならず、それを計画と取り違えることは、よくある高価な間違いです。

大きなチームにとって、容量は、エンジニアが保つスプレッドシートでなくなり、多くのサービスが依存する共有のモデルになります。数百のサービスのプラットフォームは、有限のプールを共有します。データベースのコネクション、メッセージブローカーのスループット、クラウドアカウントのクォータ、ネットワークの外向き転送。誰も全体像を持たなければ、あるチームの成長が別のチームを飢えさせえます。企業の設定では、容量の誤りは、遊んでいるインフラストラクチャに無駄にされる数百万か、最も重要な瞬間の恥ずかしい停止として現れます。政府では、賭け金はさらに鋭くなります。納税の期限、給付の登録期間、公衆衛生の登録キャンペーンは、国の需要を数時間に集中させ、負荷は任意ではなく法的に義務づけられ、人々は、自ら設けた期限に屈したサイトを覚えています。キャパシティ計画は、それらの約束を守る方法です。

主要原則

予測された需要に意図した余裕を加えた容量を計画し、飽和の近くで動かさないこと。
キャパシティ計画、オートスケーリング、パフォーマンスエンジニアリングを分けること。それぞれが異なる問題を解く。
先週だけからではなく、傾向、季節性、既知のイベント、事業の成長から予測すること。
推測や、本番が見つけるのを待つことではなく、負荷テストとベンチマークで本当の限界を見つけること。
飽和の近くのレイテンシは傾斜ではなく崖として扱うこと。稼働率の目標は待ち行列理論のために存在する。
硬いボトルネックを知ること。コネクションプール、クォータ、単一点はオートスケールしない。
コストと信頼性のバランスを意図してとり、インシデントの後ではなく定期的な周期で容量をレビューすること。

推奨事項

キャパシティ計画、オートスケーリング、パフォーマンスエンジニアリングを分ける

これら三つの規律はしばしば混同され、混同は間違った修正を買うことにつながります。キャパシティ計画は、数週間、数四半期、数年にわたって、どれだけの総リソースをプロビジョニングし、予約し、予算化しなければならないかという、中期から長期の問いです。オートスケーリングは、分単位で負荷を追うようにリソースを調整する、短期の自動化された調整です。計画がプロビジョニングした範囲の中で動かしますが、予約していないクォータを生み出したり、冷たいデータベースを温めたり、単一のインスタンスとしてしか動かないコンポーネントをスケールしたりはできません。パフォーマンスエンジニアリング(2.16章)は、仕事の単位あたりのコストを下げて問題の形を変えるので、同じハードウェアがより多くの需要に仕えます。

この区別は実用的です。システムが負荷のもとで遅いとき、オートスケーリングはインスタンスを増やし、パフォーマンスエンジニアリングは各インスタンスを速くし、キャパシティ計画は、そのインスタンスを賄えるか、下流のデータベースがそれらの開くコネクションを受け入れられるかを決めます。オートスケーリングだけに手を伸ばすチームは、計画していなかった硬い限界にぶつかり、パフォーマンスエンジニアリングだけに手を伸ばすチームは、アカウントのクォータが上限を課す間もコードを最適化します。三つすべてが必要で、特定の問題がどれを求めるかを知る必要があります。

傾向、季節性、イベント、事業の成長から需要を予測する

先週の平均で作った予測は、あらゆる興味深い瞬間を見逃します。四つの異なる構成要素から作ってください。傾向は、根底にある方向です。需要は増えているか、平坦か、縮んでいるか、どれだけ速くか。季節性は繰り返すパターンです。午前9時の日々のピーク、週末の週ごとの凪、休日前の年ごとの急増。イベント駆動の急増は一回限りの集中です。プロダクトのローンチ、マーケティングキャンペーン、テレビでの言及、政府の申告期限。事業駆動の成長は、自社のロードマップが生む需要です。新しい市場、大きな顧客のオンボーディング、セッションあたりのリクエストを3倍にする機能。

それぞれに適切な技法を使います。傾向と季節性に分解された、過去の負荷の時系列は、定常的な需要の擁護できるベースラインを与えます。イベントは履歴を持たないので、履歴から外挿できません。事業と話し、ロードマップを読み、マーケティングとプロダクトに何をローンチしようとしているかを尋ねることから来ます。最も痛手となる容量の失敗は、ほとんど常に、エンジニアリングが聞いたことのなかったイベントです。治療は統計的ではなく組織的です。プロダクト、マーケティング、運用が、それに向けてプロビジョニングできるだけ前もって、来る急増を宣言する常設のチャンネル。

稼働率の目標を設定し、待ち行列理論の崖を尊重する

お金を節約するために90パーセントの稼働率でインフラストラクチャを「熱く」動かす本能は罠で、その理由は待ち行列理論で、11.3章で深く扱います。リソースが完全な稼働率に近づくにつれ、待ち時間は緩やかに線形には上がらず、爆発します。稼働率50パーセントのサーバーは快適な余裕がありますが、同じサーバーが90パーセントだと、レイテンシが数倍悪くなりえ、95パーセントでは、キューが暴走しえます。飽和の近くのレイテンシは傾斜ではなく崖で、ユーザーはその崖を、リソースが技術的に「満杯」になるずっと前に、タイムアウト、リトライ、エラーとして感じます。

これが、キャパシティの計画者が稼働率の目標を100パーセントよりずっと下に設定する理由で、レイテンシに敏感なサービスでは通常50パーセントから70パーセントの範囲、キューイングを許容するスループット志向のバッチの仕事ではより高く設定します。目標は無駄ではなく、予測可能なレイテンシの代価です。目標をSLOから選びます。レイテンシの目標が厳しいなら、稼働率の上限は低くなります。待ち行列が生む裾のレイテンシが、まさにSLOを吹き飛ばすものだからです。余裕と安全マージンは、二つの方向から見た同じ考えです。余裕は、通常の負荷と容量の隙間で、安全マージンは、高く出た予測、負荷を集中させるフェイルオーバー、見えなかった急増への保険として表現されたその隙間です。

負荷テストとベンチマークで本当の限界を見つける

測定していない限界を軸に計画することはできません。負荷テストは、合成あるいは再生されたトラフィックをシステムに向けて、負荷が上がるにつれてレイテンシ、スループット、エラー率がどう振る舞い、どこで壊れるかを観察します。ベンチマークは、コンポーネントを単独で測定して上限を確立します。インスタンスあたりの毎秒リクエスト数、データベースのノードあたりの毎秒書き込み数、ブローカーのパーティションあたりの毎秒メッセージ数。合わせて、計画が必要とする二つの数字を教えます。容量の一単位がどれだけ届けるか、そしてシステム全体がどこで倒れるか。

いくつかの異なるテストを行います。負荷テストは、期待されるピークまで上げて、SLOが余裕を持って保たれることを確認します。ストレステストは、壊れる点を越えて押し、システムがどう失敗するかを見ます。グレースフルに縮退するシステムは、崩壊するシステムとまったく違うからです。ソークテストは、中程度の負荷を数時間から数日保ち、時間が経って初めて現れるメモリリーク、コネクションの枯渇、ディスク満杯の問題を露呈させます。スパイクテストは、突然負荷を叩きつけ、ユーザーが気づく前にオートスケーリングとバッファが吸収するかを確認します。本番に近いデータとトポロジーに対してテストしてください。おもちゃのデータセットで測った限界は嘘をつくからです。システムが変わったらこれらのテストを再実行し、数字が、1年前のものではなく、今あるシステムを記述するようにします。

プロビジョニングの戦略を意図して選ぶ

クラウドプロバイダーは、価格を柔軟性と交換する方法で同じ容量を買わせてくれ、それらをうまく混ぜることが、本物のお金が節約される所です。オンデマンドの容量は柔軟で高価です。いつでも開始と停止ができる能力に満額を払い、予測できず短命な負荷に合います。リザーブドの容量(1年あるいは3年のコミットメント、またはセービングプラン)は、使い続ける約束と引き換えに単位あたりが安く、安定したベースラインに合います。スポットインスタンスは、余った容量を深い割引で売りますが、ほとんど警告なしに回収されうるので、バッチ処理やステートレスなワーカーのような、耐障害で中断可能な仕事に合います。

うまく働くパターンは層状です。最も低い単位コストのために、安定したベースラインをリザーブドの容量でカバーし、日次と週次の変動をオンデマンドのオートスケーリングで吸収し、割引を収穫するために、中断可能なバッチの仕事をスポットに押し出します。ゼロからのスケーリングのコールドスタートの遅延に耐えられないサービスのために、事前にプロビジョニングされた容量の温かいバッファプールを保ち、急増が、新しいインスタンスの起動中のキューではなく、準備のできた容量に出会うようにします。正しい配合はポートフォリオの決定で、需要の形とプロバイダーの価格が変わるにつれて移るので、見直してください。

オートスケールしない硬いボトルネックを地図にする

オートスケーリングは危険な自信を育てます。多くの限界が、スケールするものの下流にあり、それがスケールしても動かないからです。データベースのコネクションプールが典型的な例です。ステートレスな層を10から100のインスタンスにスケールすると、それぞれが同じデータベースへのコネクションを開き、データベースには同時コネクションに硬い上限があり、新しいものの拒否を始めます。クラウドのアカウントは、ほぼすべてにクォータを負います。リージョンあたりのインスタンス、IPアドレス、毎秒のAPI呼び出し、関数の同時実行。アーキテクチャのどの単一点、主データベース、リーダーノード、共有キャッシュ、ライセンスされたアプライアンスも、他の場所での水平スケーリングでは引き上げられない天井です。

これらを明示的にしてください。リクエストと応答の間のすべての硬い限界の書面の目録を保ちます。プールのサイズ、クォータの値、単一インスタンスのコンポーネント、サードパーティのレート制限、ライセンスの席数。それぞれについて、現在の値、現在の使用量、それが拘束する負荷を記録します。この目録が、システム全体を記述する容量計画と、コネクションプールがローンチを終わらせるのを静かに待つ間、容易で弾力的な部分だけを記述する計画の違いです。プロバイダーのクォータ引き上げの承認に数日かかりうるので、必要になる前にクォータを引き上げます。

平均だけでなく、ピークのイベントに向けてプロビジョニングする

平均は、重要な瞬間を隠します。平均負荷でサイズ化されたシステムはピークで失敗し、多くの組織にとってピークこそ要点のすべてです。最大のショッピングデーの小売の急増、生中継の決勝のストリーミングの急上昇、申告期限の納税ポータル、登録が開く時の給付サイト。これらの名前の付いたイベントを個別に計画します。事業からピークを見積もり(期待される同時ユーザー数、セッションあたりのリクエスト、通常の日に対する倍率)、余裕を持ってそのピークに向けてプロビジョニングし、その水準で負荷テストし、イベントの最中に慌てるのではなく、前もって容量を配置します。

ローンチや期限を、ランブックを伴う運用上のイベントとして扱います。キャッシュとバッファプールを事前に温め、クォータを前もって引き上げ、窓の間は危険なデプロイを凍結し、予測が低かったとき行動できる人間をオンコールに置きます。イベントの後には、実際のピークと限界にどれだけ近づいたかを捉えます。その数字は、来年の計画への最良の入力だからです。政府の期限は特別な注意に値します。それらは自ら課され、公に知られ、動かせないので、驚く言い訳はなく、驚いたときに隠れる方法もありません。

容量を計装し、周期的にレビューする

キャパシティ計画はデータで動き、データは9.2章のオブザーバビリティから来ます。制約のあるすべてのリソース(CPU、メモリ、ディスク、ネットワーク、コネクションプール、キューの深さ)の稼働率を、その限界に対して追跡し、余裕が消える前に縮むのを見られるようにします。飽和のシグナルを直接見ます。キューの長さ、待ち時間、拒否率が、待ち行列の崖の接近を明らかにします。これらを数週間にわたって傾向づけ、現在の成長率でリソースがいつ天井に達するかを予測し、現在の値だけでなくその予測にアラートして、壁の前に、壁の所ではなく、プロビジョニングします。

インシデントの後だけでなく、月次あるいは四半期の定期的な周期で、容量のレビューを行います。各レビューで、予測を実際の需要と比較してモデルを修正し、硬い限界の目録を歩いてそれぞれに対する余裕を確認し、今後のイベントと事業計画を見て、何を予約し、引き上げ、退役させるかを決めます。生きた容量のモデルを保ちます。需要の駆動要因をリソースの必要量に対応づける単純な文書あるいはスプレッドシートで、誰でも「トラフィックが倍になったらデータベースはどうなるか」と尋ねて、停止ではなくモデルから答えを得られるようにします。モデルは決して完全ではありませんが、書かれて定期的に修正されるモデルは、常に直感に勝ります。

トレードオフ: 長所と短所

アプローチ	長所	短所
高い稼働率の目標	単位あたりのコストが低い。遊んでいる容量が少ない	飽和の近くでレイテンシが爆発。急増やフェイルオーバーの余地がない
気前の良い余裕	予測可能なレイテンシ。急増とフェイルオーバーを吸収	高い定常コスト。非効率を隠しうる
リザーブドの容量	安定したベースラインで最も低い単価	需要が落ちる、あるいは移るとコミットメントのリスク
オンデマンドの容量	柔軟。分単位で変動する負荷に合う	最も高い単価。予算を驚かせうる
スポットインスタンス	中断可能な仕事に深い割引	通知なしに回収される。ステートフルやレイテンシが重要な仕事には不向き
オートスケーリング	範囲内で負荷を自動的に追う	予約したクォータを超えられない。コールドスタート。下流の限界を隠す
バッファプール(温かい容量)	突然の急増を即座に吸収	急増の間、遊んでいる容量に払う

中心的な緊張は、コスト対信頼性で、両方を最適化する設定はありません。無駄なく動かせば、急増が飽和したリソースに出会い、レイテンシが待ち行列の崖から落ちる日まで、お金を節約します。気前よく動かせば、ほとんどの時間遊んでいる余裕に払いながら、よく眠れます。緊張を、恐れや倹約ではなく、SLOで解決してください。予測されたピークに余裕を加えた分を通じて、信頼性の目標を満たすのに十分な余裕をプロビジョニングし、それ以上はせず、それからSLOを守らない無駄を、FinOps(クラウド支出の財務運用、9.4章)に狩らせます。目標は意図したバランスです。余裕に払うすべてのドルは、既知の量の信頼性を買うために意図して買われ、無駄のすべてのドルは、何も買わないから意図して取り除かれる。

チームで議論すべき問い

硬いボトルネックのそれぞれが拘束する負荷を本当に知っていますか。それとも、オートスケーリングが救ってくれると想定していますか。 ほとんどのチームは、インスタンスがオートスケールすると言えますが、主データベースの同時コネクションの上限、最も重要なサードパーティのAPIのレート制限、関数の同時実行に上限を課すアカウントのクォータは言えません。それらがローンチを終わらせる限界で、ステートレスな層がスケールしても動きません。硬い限界の書面の目録があれば持ち込み、なければ、その不在が発見です。各限界について、三つの数字が欲しい。上限、今日の使用量、両者が出会う需要の水準。三つすべてを出せない所はどこでも、希望で管理しているボトルネックがあります。
最後に、本番に近いデータで最悪の今後のピークの水準まで負荷テストしたのはいつで、SLOは余裕を持って保たれましたか。 キャパシティ計画は、システムが負荷のもとでどう振る舞うかについての主張の集まりで、テストされていない主張は、スーツを着た推測です。重要なピークは先月の平均ではなく、次のローンチ、休日、期限で、テストは、データとトポロジーが本番に似ている場合にだけ意味を持ちます。おもちゃのデータセットで測った限界は嘘をつくからです。最近のストレスとソークのテストの結果を、システムがどこで壊れ、壊れたときどう失敗したかを含めて持ち込んでください。誠実な答えが、システムを意図して壊れる点まで駆動したことがないなら、その点を本番で、最悪の時に、ユーザーが見ている中で発見することになります。
プロダクト、マーケティング、運用は、急増が起こる前に、どうやって、どれだけ前もってエンジニアリングに伝えますか。 最も高価な容量の失敗はモデルの誤りではなく、トラフィックが到着するまでエンジニアリングが聞いたことのなかったイベントです。予測は履歴から傾向と季節性を外挿できますが、イベントには履歴がないので、それを計画している人々からしか来ません。最近の三つの需要の急増を持ち込み、それぞれについて、エンジニアリングが何日の警告を得て、それが容量を予約して負荷テストするのに十分だったかを尋ねてください。欲しい証拠は、プロビジョニングできる十分なリードタイムを持つ常設のチャンネルです。クラウドのクォータの引き上げだけでも数日かかりうるからです。チャンネルが存在しなければ、キャパシティ計画は、それが守るために存在するまさにその瞬間に盲目です。
レイテンシに敏感な各サービスは実際にどの稼働率の目標で動いていて、その数字をコストの目標ではなくSLOまでたどれますか。 これが重要なのは、インフラストラクチャを熱く動かす圧力が絶え間なく、請求書は見るが待ち行列の崖は見ない組織の部分から来るので、目標が書き出されてレイテンシの目標から正当化されなければ、急増が縁を見つけるまで上方へずれていくからです。相反する考慮は、一方に本物のお金、もう一方に裾のレイテンシで、誠実な立場は、100パーセント未満の余裕は、削るべき無駄ではなく、予測可能なレイテンシの代価だということです。上位数サービスの現在の稼働率、それぞれが守るSLO、負荷のもとでその稼働率で測定したレイテンシを持ち込み、議論が本能ではなく証拠から行われるようにしてください。一つの共有プールが多くのサービスを支える企業あるいは政府のプラットフォームでは、目標を中央で合意し、誰がそれを変えてよいかを記録してください。一つのチームが静かに上限を上げることで、他が依存するリソースを、全員にとっての崖から突き落としうるからです。
リザーブド、オンデマンド、スポットの容量の配合は何で、最後に見直したのはいつで、それはまだ需要の形に合っていますか。 配合は、最大の持続的な節約と最大の持続的な無駄の両方が隠れる所です。オンデマンド価格で払われる安定したベースラインは毎時お金を燃やし、コミットしすぎたリザーブドの持ち分は、需要がその後超えた、あるいは下回った容量に払うからです。緊張は、コスト対柔軟性とコミットメントのリスクです。リザーブドは単位あたり最も安いがロックインし、スポットはさらに安いが通知なしに回収されうるし、オンデマンドはプレミアムで自由を買います。コスト別の現在の配分、それがカバーすべき需要の曲線、スポットのワークロードの回収率と影響範囲を持ち込み、中断可能な仕事が本当に中断可能かを部屋が見られるようにしてください。企業と政府の設定では、リザーブドのコミットメントを調達と予算の周期に結びつけてください。複数年のコミットメントとセービングプランは、財務と監査が、先四半期の都合ではなく予測された需要に対して正当化を求める財務上の義務だからです。
名前の付いたピークのイベントが近づくとき、事前の暖機、クォータの引き上げ、デプロイの凍結、実行か中止かの判断を誰が所有し、それはリハーサルしたランブックとして書かれていますか。ピークのイベントは、キャパシティ計画が守るために存在する瞬間で、それらが失敗するのは、計画が間違っていたからではなく、当日に圧力のもとでそれを実行する説明責任を誰も負わなかったからであることが最も多いです。ここで競合する考慮は、速度と自律対調整です。チームは出荷し続けたいが、急増の窓の間の危険なデプロイは、数か月分のプロビジョニングを台無しにしうるので、誰かが凍結し、ローンチを止める権限を持たなければなりません。次の大きなイベントのランブック、クォータの引き上げとバッファプールの暖機のリードタイム、前回各役割を誰が担い、引き継ぎが保たれたかの記録を持ち込んでください。自ら課され、公に知られ、動かせない政府の期限では、説明責任のある所有者とエスカレーションの経路を明示的に名指ししてください。負荷を落としたり市民に後で戻るよう頼んだりする選択肢がなく、誰も所有しないピークは、到来したときに誰も守らないピークだからです。

セクター別の視点

スタートアップ。 最も乏しい資源はエンジニアリングの注意なので、キャパシティ計画を安く無駄なく保ち、日々の変動にはクラウドプロバイダーの弾力性に頼ってください。飛ばせない唯一のことは、オートスケールしない硬い限界の書面の一覧です。主データベースのコネクションの上限、最も重要なサードパーティのレート制限、突然の機能やプレスの急増でぶつかるアカウントのクォータ。最初の本物の急増の前に、本番サイズのデータで通常のピークの数倍まで負荷テストしてください。オートスケーリングが与える脆い自信こそ、データベースがコネクションを拒否したときに壊れるものだからです。

小規模事業者。 キャパシティの専門家はおらず予算も厳しいので、これをモデル化のプロジェクトではなく、買って設定する問題として扱ってください。スケーリングを代わりに吸収してくれるマネージドなサービスを好み、暴走する請求書や飽和するリソースが早期に見えるよう、支出のアラートと単純な稼働率のダッシュボードを設定し、一年を定義する少数の名前の付いたイベント(季節の繁忙、大きな顧客の稼働開始)を知ってください。請求書を削るために安定したベースラインの容量を予約し、需要の形がほとんど動かないときに保守できない予測の仕組みを築くのは控えます。

大企業。 問題は、数百のサービスの背後にある共有の有限のプールなので、キャパシティは、保守された硬い限界の目録、SLOから中央で導かれる稼働率の目標、ライブの価格に対して見直されるリザーブド、オンデマンド、スポットの意図した配合というポートフォリオのガバナンスになります。すべてのチームが本番に近いデータで同じように測定するよう、負荷、ストレス、ソーク、スパイクのテストを標準化し、縮む余裕をインシデントの前に捉える周期で容量のレビューを行います。調整に明示的に予算を付けてください。誰も全体のモデルを持たなければ、あるチームの成長が別のチームを飢えさせうるからです。

政府。 需要はしばしば、動かせず公に知られた期限に法的に集中するので、その名前の付いたピークに特化して計画し、負荷を落としたり市民に後で戻るよう頼んだりできないため、広い安全マージンをプロビジョニングしてください。調達規則がプロビジョニングを形づくります。複数年のリザーブドのコミットメントとベンダーのクォータの合意は、予測された需要に対して正当化され、監査に耐えなければならないので、予測、負荷テストの証拠、硬い限界の目録を、文書化して擁護できるようにしておきます。可能な所では現実的な期待を公表し、窓のずっと前にプロバイダーの限界を引き上げ、サイクルごとに本当のピークを記録してください。公的な説明責任は、自ら設けた期限に屈するポータルが、国全体が目にする失敗だということを意味するからです。

事例

スタートアップ。 10人のスタートアップは、オートスケーリングするクラウドのインフラストラクチャで消費者向けアプリを動かし、インスタンス数が負荷とともに増えるので安全だと感じます。最初のテレビでの紹介が1時間でトラフィックを3倍にし、ステートレスな層は見事にスケールするものの、それでもアプリは倒れます。新しいインスタンスがどれもデータベースのコネクションを開き、データベースがコネクションの上限に達して拒否を始めたのです。この教訓が実践を作り変えます。データベースの前にコネクションプーラーを加え、リクエストと応答の間のすべての硬い限界を書き出し、本番サイズのデータセットで通常のピークの数倍まで負荷テストします。割引のために安定したベースラインをリザーブドの容量のコミットメントでカバーし、次の急増が準備のできた容量に出会うよう、小さな温かいバッファプールを保ちます。変更には1週間かかり、脆い自信を、擁護できる計画に変えました。

大企業。 世界的な小売業者は、最大のセールの日を一年のキャパシティのイベントとして扱います。数か月前に、部門横断のチームが、過去の年の傾向と季節性にマーチャンダイジングの計画を加えた需要予測を作り、キャパシティモデルを通じて予測をリソースの必要量に翻訳し、気前の良い余裕を持って予測されたピークにプロビジョニングします。本番に近いデータで経路全体の負荷、ストレス、ソーク、スパイクのテストを行い、関連するクラウドのクォータをすべて数週間前に引き上げ、キャッシュとバッファプールを事前に温め、前後の窓の間は危険なデプロイを凍結します。リザーブドの容量がコストのために安定したベースラインをカバーし、オンデマンドのオートスケーリングが日々の曲線を吸収し、中断可能なバッチの仕事はスポットで動きます。オブザーバビリティは、イベントの間、制約のあるすべてのリソースをリアルタイムでその限界に対して追跡し、現在の値ではなく予測される飽和にアラートします。その日は劇的なことなく過ぎ、それがまさに計画が買った結果です。

政府。 国の税務当局は、国全体が一斉に申告する、動かせない期限前の数日に需要が法的に集中する、申告ポータルを運営します。機関は、意味をなさない年間の平均ではなく、そのピークに特化して計画します。過去の年と人口のデータから同時申告者数を見積もり、負荷を落としたり市民に後で戻るよう頼んだりする選択肢がないので、広い安全マージンでそのピークにプロビジョニングし、現実的なデータで予測された同時実行数まで負荷テストします。チームは、あらゆるクォータと単一障害点の書面の目録を保ち、窓のずっと前にプロバイダーと限界を引き上げ、待ち行列の崖が期限の急増から遠く離れるよう、稼働率の目標を十分低く設定します。各申告の季節の後に、本当のピークと残った余裕を記録し、来年のモデルにフィードバックします。国民は、設計された日に落ちないポータルを目にし、それこそが組織の約束の要点のすべてです。

ビジネスケース: 動機、ROI、TCO

キャパシティ計画の見返りは、反対方向に引く二つの回避されたコストとして現れ、それがこの規律を価値あるものにします。プロビジョニング不足は停止のコストがかかり、ピークのイベント中の停止が最も高くつきます。失われた収益、失われた取引、まさに聴衆が最大のときの評判の毀損。最大の日に落ちる小売サイトや、申告期限に崩れる政府のポータルは、一度の悪い1時間で何年分もの計画の元を払います。過剰なプロビジョニングは逆向きのコストがかかります。遊んでいる容量のクラウドの請求書で、企業の規模では、フリート全体にわたる慢性的な過剰プロビジョニングの数ポイントが、年に数百万ドルになります。キャパシティ計画は、意図した中間を見つける実践です。ピークを通じてSLOを守るのに十分で、それ以上ではない。

採用のコストは、ツールよりも規律がほとんどです。需要予測を作り、硬い限界を書き出し、周期的に負荷テストを行い、プロビジョニングの戦略を配合し、定期的な容量のレビューを行います。総所有コスト(TCO)は両側から同時に改善します。容量に起因するインシデントが減ることで停止と緊急対応のコストが下がり、継続的な適正サイズ化と賢明なリザーブドとスポットの配合が、定常的なインフラストラクチャの請求書を下げます。リーダーシップに論拠を示すには、容量を、彼らがすでに見ている数字に結びつけてください。プロビジョニング不足を、ピークの停止1時間あたりの失われた収益と、契約上のペナルティを伴うSLO違反に結びつけ、過剰なプロビジョニングを、9.4章のFinOpsの無駄の報告に結びつけます。論拠は抽象的な慎重さではなく、意図して設定できる目盛りの両側のお金です。

アンチパターンと落とし穴

計画としてのオートスケーリング: 弾力的なインスタンスを信頼する一方で、データベースのコネクションプール、アカウントのクォータ、単一点が、システム全体に静かに上限を課すこと。
お金を節約するために熱く動かす: 90パーセント超の稼働率を目標にして、待ち行列の崖に出会い、レイテンシが爆発してSLOが破られること。
ピークではなく平均: 平均負荷でサイズ化して、構築を正当化したまさにそのピークのイベントでシステムが失敗すること。
履歴だけからの予測: エンジニアリングが聞かされなかったローンチやキャンペーンを見逃しながら、傾向と季節性を外挿すること。
テストされていない限界: 誰も測定していない壊れる点を軸に計画し、本番で最悪の瞬間にそれを発見すること。
おもちゃのデータでの負荷テスト: 非現実的なデータとトポロジーで容量を測定し、本物のシステムについて嘘をつく数字を生むこと。
硬い限界の目録がない: クォータ、プール、単一点を、書面の保守された一覧ではなく、記憶と希望で管理すること。
すべてを予約するか何も予約しないか: 需要が超えるか下回るリザーブドの容量にコミットしすぎるか、安定したベースラインにオンデマンドの満額を払うこと。
インシデントの後だけの容量レビュー: 計画を、必要に先んじてプロビジョニングする定期的な周期ではなく、反応的な火消しとして扱うこと。

成熟度モデル

レベル1: 開始: 容量は反応的でその場しのぎです。チームは、尽きた後でリソースを加え、すべてをオートスケーリングが扱うと信頼し、予測も硬い限界の目録も負荷テストもありません。ピークのイベントは希望で迎えられ、ローンチと期限の間の停止は不運として扱われます。
レベル2: 発展: 基本的な実践が現れますが、チームごとに異なります。一部の監視が稼働率を示し、大きなイベントの前にいくらかの負荷テストが行われ、主要なクォータは知られ、大まかな予測が所々に存在しますが、モデルは保守されず、下流のボトルネックはしばしば見逃され、余裕はSLOからではなく経験則で設定されます。
レベル3: 標準化: キャパシティ計画は、文書化され組織全体で徹底される規律です。需要予測は傾向、季節性、イベント、事業の成長を組み合わせ、書面の硬い限界の目録が保守され、稼働率の目標はSLOから導かれ、負荷、ストレス、ソーク、スパイクのテストが本番に近いデータに対して周期的に走り、プロビジョニングはリザーブド、オンデマンド、スポットを意図して配合します。常設のチャンネルが、プロダクトとマーケティングからエンジニアリングにイベントの警告を運びます。
レベル4: 管理: 容量が、ベースラインに対して測定され制御されます。予測は各周期で実際の需要と比較され、誤差が追跡されて押し下げられ、稼働率、飽和のシグナル、すべての硬い限界に対する余裕が、傾向づけられ、現在の値ではなく予測としてアラートされ、ピークのイベントは後から真の観測されたピークに対してレビューされ、プロビジョニングの配合、リザーブドのコミットメントのカバレッジ、SLOあたりのコストは、実行か中止かの決定をゲートする指標として報告されます。何を予約し、引き上げ、退役させるかを、直感ではなくデータが決めます。
レベル5: オーケストレーション: キャパシティ計画は継続的に改善され、組織全体に統合されています。予測は自動的に検証され洗練され、飽和は到来する前に予測されプロビジョニングされ、プロビジョニングの配合はライブの価格に対して最適化され、ピークのイベントはリハーサルされたランブックから運営され、コストと信頼性はプラットフォーム全体にわたってSLOに対して意図してバランスがとられます。キャパシティのモデルは、需要の形とプロバイダーの価格が移るにつれてフリートを再均衡させる、共有で適応的な資産です。

議論のためのアイデア

レイテンシに敏感なサービスの現在の稼働率の目標は何で、お金を節約したい願いからではなく、SLOと待ち行列の振る舞いからそれを正当化できますか。
どのコンポーネントがまったくオートスケールできず、その一つが飽和したとき、システムの残りに何が起こりますか。
来四半期にトラフィックが倍になったら、どのリソースが最初に天井に達し、それを引き上げるのに何日のリードタイムが必要ですか。
リザーブド、オンデマンド、スポットの容量の配合をどう決め、実際の需要の形に対して最後に見直したのはいつですか。
ピークのイベントが近づいているとき、事前の暖機、クォータの引き上げ、実行か中止かの判断を誰が所有し、それはランブックとして書かれていますか。
容量のアラートは、数週間先の予測される飽和に発火していますか。それとも、壁がすでに近いときの現在の稼働率にだけですか。

要点

キャパシティ計画は、意図した余裕を持って供給を予測された需要に合わせます。オートスケーリング(範囲内の短期)やパフォーマンスエンジニアリング(より安い仕事の単位)とは別のものです。
傾向、季節性、既知のイベント、事業の成長から予測し、イベントには外挿できる履歴がないので、プロダクトとマーケティングからイベントの警告を得ます。
待ち行列理論の崖(11.3章)を尊重します。飽和の近くでレイテンシは爆発するので、SLOから稼働率の目標を設定し、本物の余裕を保ちます。
本番に近いデータでの負荷、ストレス、ソーク、スパイクのテストで限界を見つけ、オートスケールしない硬いボトルネックの書面の目録を保ちます。
リザーブド、オンデマンド、スポットの容量を温かいバッファプールとともに配合し、名前の付いたピークのイベントを個別に計画し、停止の後ではなく周期的に容量をレビューします。

参考文献とさらなる読み物

Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne (eds.), The Site Reliability Workbook: Practical Ways to Implement SRE
John Allspaw, The Art of Capacity Planning: Scaling Web Resources in the Cloud
Neil J. Gunther, Guerrilla Capacity Planning: A Tactical Approach to Planning for Highly Scalable Applications and Services
Martin L. Abbott and Michael T. Fisher, The Art of Scalability: Scalable Web Architecture, Processes, and Organisations for the Modern Enterprise
Brendan Gregg, Systems Performance: Enterprise and the Cloud
Leonard Kleinrock, Queueing Systems, Volume 1: Theory
J. R. Storment and Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management