キャパシティ計画
Google SRE Book 18章「Software Engineering in SRE」を取得して読み、 理解した内容を自分の言葉で書いたもの。
どれだけの資源を、どこに、いつ用意するかを決める話。
限界を見つける手順(壊れるまで負荷をかける)は 分散システムにある。 ここはその結果を使って次の四半期に何台いるかを決める側。
従来のやり方と、その脆さ
繰り返しの4段階でできている。
1. 需要予測を集める
2. 構築と割り当ての計画を立てる
3. 計画をレビューして承認する
4. 資源を配備して設定する
問題は、この計画が静的な仮定の上にしか立っていないこと。
小さな変更でも、計画全体が今も成立するかを突き合わせ直す必要がある。 資源の納入遅れや製品戦略の変更のような大きな変更だと、計画を作り直すことになる。
崩れる要因は日常的に起きる。
サービスの効率が落ちた(1リクエストあたりの資源が増えた)
利用の伸び方が予測と違った
資源の納入が遅れた
製品戦略が変わって、配置する範囲が変わった
もう一つは手間。ビンパッキングは NP困難で、人間が手で解くものではない。 スプレッドシートが破綻するのは、規模の問題ではなく問題の性質の方にある。 検算する仕組みもないので、遅いうえに間違う。
意図を指定する
要件を指定する。実装ではなく。
「どの資源が欲しいか」ではなく「何を成立させたいか」を書くと、 実装の自由度が残り、かつ本当の動機が計画に残る。
抽象度には段がある。
| 段 | 書き方 |
|---|---|
| 1 | 「サービス Foo に、クラスタ X, Y, Z で 50コア欲しい」 |
| 2 | 「地域 YYY 内のどれか3クラスタで、50コア分の設置面積が欲しい」 |
| 3 | 「各地域で Foo の需要を満たし、N+2 の冗長性を持ちたい」 |
| 4 | 「Foo を5ナインの信頼性で動かしたい」 |
収穫が最も大きいのは3段目とされている。 自由度が十分に取れて、しかも要求の意味が上位の言葉のまま理解できる。
ここが実務的に重要なところで、4段目(SLO で書く)まで抽象化しなくてよい。 1段目のまま運用している限り、資源の都合が変わるたびに人間が計画を作り直すことになる。
意図が書けるための前提
3つが揃っていないと、意図は具体的な資源に翻訳できない。
依存関係
どのサービスがどのサービスを必要とし、どんな制約があるか。
例: 利用者向けの Foo がストレージの Bar に依存していて、 Bar は Foo からネットワーク遅延30ミリ秒以内になければならない。
この制約は依存グラフ全体に連鎖する。Foo の配置先を動かすと Bar の配置先も動く。
性能指標
依存関係を数量に変える。
Foo が N クエリを捌くのに、計算資源はどれだけ要るか
Foo の N クエリごとに、Bar には何 Mbps 出るか
この数字の出どころが負荷試験と監視。 分散システムで見つけた限界点と、 可観測性で常時取っている実測が、そのまま計画の入力になる。
QPS で容量をモデル化しないのと同じ理由で、 クエリ数ではなく実際に消費する資源で測る。
優先順位
資源が足りないとき、どの要求を諦めるか。
意図ベースで書くことの副産物として、この決定が表に出る。 「今期は Foo の N+2 を諦めて N+1 にする」と明示的に決めることになるので、 暗黙のうちに一部のサービスが痩せていく、ということが起きにくい。
自動化(Auxon)
Google の実装。SRE 内の少人数のソフトウェアエンジニアと TPM が2年かけて作った。
入力。
| 入力 | 中身 |
|---|---|
| 性能データ | 「クラスタ Y で需要 X なら、依存 Z がどれだけ要るか」のスケーリング関係 |
| 需要予測 | サービスごとの利用の伸び。予測を持たないサービスもある |
| 資源の供給 | 使えるマシン・コア。計画の上限になる |
| 資源の価格 | 最適化の目的関数に入る |
処理。
Intent Config 人が読み書きする設定層。他の要素を配線する
Configuration Language Engine 設定を機械可読な要求に変換し、軽い妥当性検査をかける
Solver 混合整数計画・線形計画を解く。数百〜数千台で並列に走る
出力は Allocation Plan — どの資源をどのサービスへどこで割り当てるか。 満たせなかった要求も一緒に出るのが要点で、 「計画が立たなかった」ではなく「何が満たせないか」が結果として返る。
作り方から学べること
道具そのものより、こちらの方が持ち出せる。
- 近似で始める。 最初は単純なヒューリスティックで解く「愚かなソルバー」だった。 ソルバーのインターフェースを抽象化しておいたので、後から賢い実装に差し替えられた。 最適解の設計を待たずに出せた
- 道具に中立でいる。 予測・性能データ・自動化のどれについても特定のツールを前提にしない。 「今持っているもので動かす」という立て方が、そのまま導入の障壁の低さになった
- 期待値を分けて置く。 「短期の資源要求を手でビンパッキングする苦痛がなくなる」という 即座の効果と、コスト削減という長期の話を、混ぜずに約束した
- 金メッキしない。 全社100%の導入は目指さない。 ロングテールのすべてに対応する最後の一歩は、得られるものが急速に減る