IT運用:サイト信頼性 ライブモデル

あなたはWebサービスのオンコール担当です。インスタンス群の前にロードバランサー、データベースの前にキャッシュがあり、可用性目標は99.9 %です。モデルは毎分、待ち行列遅延、タイムアウト、キャッシュヒット、データベース負荷を教科書の式から計算し、あなたの判断のコストも計上します。

学べること

シミュレーター

時刻 0 分
リクエスト 1125 · エラー率 0.00% · p99レイテンシ 342 ms · 稼働中のインスタンス 10 (+0) · キャッシュヒット率 77% · データベース利用率 19% · 残りのエラーバジェット(30日) 50.0%⇉1125 req/秒▶▶▶▶▶▶▶▶▶▶······························▶ 10 · ⚙ 0 · 52% · p99 342 msフリート利用率 52%キャッシュヒット率 77%データベース利用率 19%⚠ 0.00% · 🔥 0.0×50%$ 4.00/h · Σ $0.00
  • 稼働中のインスタンス
  • 起動中のインスタンス
  • 不良ビルドのインスタンス
  • 空きスロット
  • 受信リクエスト

操作

フリートの下限。引き上げるとインスタンスはすぐ起動しますが、サービス開始までには起動遅延が必要です。

利用率に対するターゲット追跡。インスタンスが起動中の間は新しいスケールアウトをしません。オフ = ちょうど最小値。

低い = 余裕が増え、コストも増えます。測定される利用率は100 %を超えられないため、飽和したフリートは一歩ずつしか増えません。

TTLが長い = ヒットは増えますが、応答は古くなりえます(平均年齢 ≈ TTL/2)。

ホットキーを6分間読み込みます(1分あたりキャッシュの+12 %)。代償としてデータベースクエリが毎秒600件増えます。

低優先度30 %(プリフェッチ、バッチ、クローラー)のうち、ロードバランサーで「後で再試行」として拒否する割合。

重い機能はリクエストごとに20 msのCPUとデータベースクエリ1回を追加します。オフ = グレースフルデグラデーション。

直近の正常なビルドを新しいフリートに再デプロイし(5分、二重課金)、その後トラフィックを切り替えます。もう一度押すと準備をやり直します。不良ビルドが稼働していないときは、お金がかかるだけです。

指標

エラー率
0.00%
正常
p99レイテンシ
342ms
正常
残りのエラーバジェット(30日)
50.0%
正常
フリート利用率
52%
正常
バーンレート(1時間)0.0 ×
リクエスト1125 req/s
稼働中のインスタンス10
起動中のインスタンス0
キャッシュヒット率77 %
データベース利用率19 %
遮断したトラフィック0 %
フリートのコスト4.00 $/h
ここまでのコスト0.00 $
キャッシュ応答の平均年齢30 s
不良ビルドのトラフィック0 %
利用可能なレコメンデーション100 %

推移

エラー率: — %20.000.00

危機シナリオ

レベル1 · 不良リリース

新しいビルドが09:10にリリースされます。今月はすでに厳しく、エラーバジェットは20 %しか残っていません。デプロイの数分後、バーンレートのページが鳴ります。バジェットを守ってください。

  • 終了時のエラーバジェット残り ≥ 18.5 %
  • デプロイ後の平均エラー率 ≤ 0.65 %
  • フリートコスト ≤ $9.50

レベル2 · フラッシュクラウド

サービスへのリンクが急速に広まっていて、今朝のどこかでトラフィックの急増が予想されます。いつ来るのか、どれほど大きいのかは誰にも分かりません。今日、新しいインスタンスは起動に8分かかります。急増が来たときに、遊休容量にお金を燃やさずに、エラーとレイテンシを低く保ってください。

  • 平均エラー率 ≤ 0.2 %
  • 平均p99レイテンシ ≤ 400 ms
  • 平均遮断トラフィック ≤ 5 %
  • 総コスト ≤ $21
  • レコメンデーションが利用可能 ≥ 時間の85 %

レベル3 · コールドキャッシュ

昼のピークに、メンテナンススクリプトがキャッシュ全体をフラッシュします。すべてのリクエストがデータベースに向かいますが、そのデータベースは通常のヒット率85 %を前提に設計されています。データベースを過負荷にせずにサービスを復旧してください。

  • 平均エラー率 ≤ 1.5 %
  • 最初の1分以降、データベース利用率が90 %を超えない
  • キャッシュ応答の平均年齢 ≤ 平均90 s
  • 総コスト ≤ $9
  • レコメンデーションが利用可能 ≥ 時間の80 %
  • 平均遮断トラフィック ≤ 5 %

根拠:数字の背後にあるモデル

シミュレーターが使うすべての関係式を、出典とともに示します。前提と記された定数は例示的な校正値です。

リクエストは1日の曲線に外乱が加わったもので、毎分の件数は少しのバースト性を持つランダム(ポアソン、正規近似)です。
λ(t) = base × (1 + 0.25·sin(2π(t + clock − 6 h)/24 h)) × surge(t), clock = time of day at the start (peak at 12:00); count/min ≈ N(60λ, √(60λ)) × (1 + N(0, 0.02))[6]前提:ワーカー数、サービス時間、データベース容量、キャッシュサイズ、補充速度、価格、不良ビルドのエラー率は、中規模のWebサービスを想定した例示的な値です。
アーランC:M/M/Nシステムで、リクエストが空きワーカーを待たなければならない確率。
N = instances × 16 workers, a = λ·S; C(a, N) = B / (1 − (a/N)(1 − B)), B = Erlang B[3][6]
待ち時間の裾:t より長く待つ確率は指数関数的に下がります。2秒のタイムアウトでまだ待っているリクエストは失敗します。容量を超えた分は失敗します。
P(W > t) = C·e^(−(N/S − λ)·t); timeouts = P(W > 2 s); a ≥ N ⇒ failed share = 1 − N/a[3]
サービス時間と待ち時間の分位数から求めるp99レイテンシ。
p99 ≈ S·ln 100 + ln(C/0.01)/(N/S − λ) (service + waiting quantile, an approximation)[3][6]近似:サービス時間と待ち時間の分位数を足しても、その和の正確なp99にはなりません(少し高くも低くもなりえます)。リクエストはミリ秒で処理されるため、キューは各分の間は定常とみなしています。
リトルの法則:使用中のワーカー数 = 到着率 × サービス時間。
busy workers L = λ·S ⇒ utilization = λ·S / N[4]
TTLキャッシュ:ランダムなリクエストでは、ミスのたびにTTL期間が始まり、その間リクエストはヒットします。
hit = warm × rT/(1 + rT), r = λ / 20,000 objects; mean age of a cached answer ≈ T/2[5]
キャッシュミスはデータベースに負荷をかけます。その待ち行列遅延は、データベースに触れるすべてのリクエストを遅くし、アプリのワーカーも埋めます。
DB load = λ·q·(1 − hit); query time = 5 ms/(1 − ρ_db) (≤ 250 ms); S = S_app + (1 − hit)·q·query time[6]前提:ワーカー数、サービス時間、データベース容量、キャッシュサイズ、補充速度、価格、不良ビルドのエラー率は、中規模のWebサービスを想定した例示的な値です。
SLOとエラーバジェット:バーンレートは、許容より何倍の速さでバジェットを消費しているかを示します。
budget = 1 − SLO = 0.1 %; burn = error rate / 0.1 %; Δbudget per min = burn / 43,200; burn (1 h) = mean error rate over the last 60 min / 0.1 % (window pre-filled with the opening minute)[1][2]
起動遅延とクールダウンを持つ、ターゲット追跡型のオートスケーラー。
desired = ⌈serving × utilization / target⌉ (utilization saturates at 100 %); new instances serve after the boot delay[6]前提:ワーカー数、サービス時間、データベース容量、キャッシュサイズ、補充速度、価格、不良ビルドのエラー率は、中規模のWebサービスを想定した例示的な値です。
モデルが使うその他の運転定数。
16 workers/instance · app time 50 ms (+20 ms and +1 query with the feature on) · 2 queries/request · DB 4,000 queries/s · 20,000 hot objects · cache refill τ = 30 min (slower while the DB is saturated) · warm-up job +12 %/min for 6 min, +600 queries/s · timeout 2 s · 30 % low-priority traffic · bad build +5 % errors, ×1.25 CPU · rollback 5 min · $0.40 per instance-hour · scale-in by ≤ 20 % of the fleet after 10 quiet minutes · up to 40 instances前提:ワーカー数、サービス時間、データベース容量、キャッシュサイズ、補充速度、価格、不良ビルドのエラー率は、中規模のWebサービスを想定した例示的な値です。

乱数:シード付きのmulberry32ジェネレーター。使用する分布は一様分布、指数分布(逆CDF法)、正規分布(Box–Muller法)、ポアソン分布(Knuth法)。シードは表示され、共有できます。

出典

  1. Site Reliability Engineering — Ch. 3 Embracing Risk (error budgets), Ch. 4 Service Level Objectives — Beyer, Jones, Petoff, Murphy (eds.), O'Reilly, 2016
  2. The Site Reliability Workbook — Ch. 5 Alerting on SLOs (burn rate; 14.4× over 1 h = 2 % of a 30-day budget) — Beyer, Murphy, Rensin, Kawahara, Thorne (eds.), O'Reilly, 2018
  3. Teletraffic Engineering Handbook — Erlang C formula; waiting-time distribution for M/M/n, FCFS — ITU-D Study Group 2 Question 16/2 (V. B. Iversen), 2005
  4. J. D. C. Little — A Proof for the Queuing Formula: L = λW — Operations Research 9(3):383–387, 1961
  5. J. Jung, A. W. Berger, H. Balakrishnan — Modeling TTL-based Internet Caches — IEEE INFOCOM 2003, 2003
  6. M. Harchol-Balter — Performance Modeling and Design of Computer Systems: Queueing Theory in Action (M/M/k, server farms, capacity provisioning) — Cambridge University Press, 2013

これを仕事にしている人

教育用モデルです。運用上の判断には使用しないでください。実際の現場では、すべての定数を自社の設備とデータに合わせて校正します。