クラウドかオンプレミスか: SREがサービスの下で確認すること

インフラプロバイダーは、どんなサービスにとっても最大の単一依存先であり、SREはそれを他のあらゆる依存先と同じように扱う。実際に何をコミットしているかを読み、どこが一緒に落ちるかを地図にし、応答しなくなったとき何が起きるかを確認する。これはプロバイダーがAWSであろうと、2階下でラックを運用するプラットフォームチームであろうと変わらない。問いは両者で同一で、変わるのは誰が答えるかだ。クラウドではプロバイダーが答え、あなたが検証する。オンプレミスではあなたが答え、あなたを検証する者は誰もいない。この記事はそのチェックリストを6つの領域で示す。コミットメント、障害ドメイン、コントロールプレーン、上限、キャパシティ、保守だ。

これは Budget for Failure の第4回、2つ目の201レベルの回であり、シリーズの最終回だ。第1回が役割を定義し、第2回が数字を与え、第3回がそれをアプリケーションコードへ持ち込んだ。この回はコードの下へ潜る。

1. コミットメント: 依存先があなたのSLOに上限をかける

第2回では4つのAWS SLAが何をコミットしているかを列挙した。今度は、大半のアーキテクチャレビューが飛ばす算術をやろう。ロードバランサー、コンピュート層、データベース、オブジェクトストレージを通らなければならないリクエストは、4つすべてが成功したときにだけ成功する。障害が独立なら、可用性は掛け算になる:

ALB (multi-AZ)      0.9999
EC2 (multi-AZ)      0.9999
RDS (Multi-AZ)      0.9995
S3 Standard         0.9990
------------------------------
product             0.9983   =  99.83%
allowed downtime    about 73 minutes in 30 days

あなた自身のコードが例外をひとつ投げる前に、このスタックの契約上の床は99.83パーセントだ。AWSは通常SLAの床をかなり上回って動いているので実際の数字はもっと良いが、結論は変わらない。99.9をコミットするハードな依存先の上に99.99パーセントを約束することはできない。約束を下げるか、第3回のようにキャッシュ、キュー、フォールバックで依存先をソフトにするかだ。

オンプレミスには掛け合わせるSLA文書がないので、自分の履歴から同じ表を作る。ストレージアレイ、ハイパーバイザークラスター、コアネットワーク、電源の測定済み可用性だ。誰もその数字を持っていないなら、それがレビューの最初の発見事項になる。

2. 障害ドメイン: 何が一緒に死ぬか

掛け算は独立性を前提にしている。障害ドメインとは障害の原因を共有するものの集合であり、SREの仕事はそれを知り、レプリカをそれらにまたがって配置することだ。

レベル	クラウド	オンプレミス
最小	インスタンス、その下のホスト	サーバー、ディスクシェルフ
共有ハードウェア	プレイスメントグループ、ラック(デフォルトでは見えない)	ラック、トップオブラックスイッチ、PDU
施設	アベイラビリティゾーン	電源系統、冷却ゾーン、データホール
サイト	リージョン	データセンター、キャンパス、メトロ
サイトの上	グローバルサービス、アカウント、プロバイダーそのもの	キャリア、DNSレジストラ、IDプロバイダー

3つの確認がどちらの側にも当てはまる。各ステートフルシステムのレプリカは本当に別のドメインにあるのか、それともクォーラムの3ノードが1つのゾーンや1つのラックに座っていないか? 3つのゾーンに供するNATゲートウェイが1つだけ、あるいは同じ電源系統上の「冗長な」スイッチが2つといった、シングルホームのものがマルチホームのものの経路上にないか? そして、生き延びる計画の最大のドメインが失われた後、残るキャパシティは全負荷を運ぶのに十分か? 3ゾーンでゾーン喪失を生き延びるとは、各ゾーンを3分の2以下で動かすことを意味する。

Nothing Fails Aloneシリーズはまさにこれを扱った4本のインシデント解説で、AWSアカウント内のシングルゾーン集中を見つける読み取り専用スクリプトも含む。

3. コントロールプレーンとデータプレーン

すべてのプラットフォームには2つの半身がある。データプレーンは仕事をする。インスタンスが動き、ロードバランサーが転送し、DNSが応答する。コントロールプレーンは物事を変える。インスタンスを起動し、ルートを変更し、グループをスケールする。コントロールプレーンのほうが複雑で、より頻繁に落ち、そして大きなインシデントの最中に落ちる傾向がある。復旧計画がそれを使いたいまさにそのときだ。

だから各復旧手順への問いは、成功するためにコントロールプレーンの呼び出しが必要かどうかになる。キャパシティがすでに別の場所で動いているからゾーン喪失を生き延びる設計は静的に安定している。オートスケーリングが代替を起動するから生き延びる設計は、他のすべての顧客が呼んでいるその瞬間のEC2コントロールプレーンに依存している。Amazon Builders' Libraryの静的安定性の記事が参照先だ。

オンプレミスでも同じ分割が別の名前で存在する。Kubernetes APIサーバー、vCenter、IPAMとDNSの自動化、すべてのログインとすべてのサービストークンが依存するIDプロバイダー。それぞれが落ちたとき何がまだ動くか、そして障害を直すために使うツール(VPN、踏み台、デプロイパイプライン、チャットシステム)が、それが修復するはずのインフラの上で動いていないかを問うこと。

4. 上限: クォータに見える障害

第1回のゴールデンシグナルにあった飽和には、ホストメトリクスには決して現れないプロバイダー側の形がある。AWSでポストモーテムに登場する上限は、CPUであることは稀だ:

サービスクォータ。 インスタンスファミリーごとの稼働中オンデマンドvCPU、アカウントごとのLambda同時実行数、Elastic IP、セキュリティグループあたりのルール数。クォータに当たったスケールアウトは最悪の瞬間に失敗する。
APIレートリミット。 コントロールプレーンAPIはアカウントとリージョンごとにスロットルされる。デプロイツール、オートスケーラー、監視エージェントがそろってDescribe*を呼ぶと、互いをスロットルしうる。
アドレス空間。 空きIPを使い切ったサブネットは、新しいPod、新しいLambdaのネットワークインターフェース、新しいインスタンスを止める。しかもそのどれにも触れないエラーで。
リソースごとの天井。 EBSボリュームのIOPSとスループット、RDSインスタンスクラスの接続数、NATゲートウェイのポート数。

それぞれを飽和SLIとして扱い、100パーセントのかなり手前でアラームを置く。多くのクォータについてCloudWatchはAWS/Usage名前空間に使用量を発行し、メトリクス数式関数SERVICE_QUOTA()が現在の上限を返すので、1つの式でクォータ使用率が得られる。残りについては、スケジュール実行のインベントリスクリプトで足りる。

オンプレミスでは上限は物理的で、引き上げるのに時間がかかる。ラックユニット、ラックあたりの電源と冷却、スイッチポート、ライセンスされたコア数、ストレージコントローラーのスループット、5年前に作ったアドレス計画の規模だ。

5. キャパシティ: 弾力的は無限ではない

クラウドの約束は、キャパシティが分単位で届くことだ。たいていはそうなり、SREはそうならないときのために計画する。特定のゾーンの特定のインスタンスタイプはInsufficientInstanceCapacityを返しうる。最も多いのはゾーンイベントの最中で、全員が同じ生き残ったゾーンへフェイルオーバーしているときだ。防御は多様性(Auto Scalingグループ内の複数のインスタンスタイプとすべてのゾーン)、フェイルオーバーの場合に備えた事前プロビジョニング、そして待てないワークロードのためのオンデマンドキャパシティ予約だ。

オンプレミスではリードタイムが数週間から数か月なので、キャパシティプランニングは予測の規律になる。測定された成長、調達カレンダー、上の障害ドメインに対してN+1またはN+2で見積もった余裕。信頼性に最も影響する判断は購入時に下され、それを試すインシデントのはるか前だ。

どちらの世界でも、最初の上限は見積もるのではなく負荷テストで見つけること。重要な数字は、第2回のSLIが劣化し始めるトラフィック水準と、どのリソースがそれを引き起こしたかだ。

6. 保守: 日付の付いたインシデント

インシデントの大きな割合は、誰かが事前にスケジュールし、そして忘れられたものだ。クラウドでは、インスタンスリタイアの通知、データベースのメンテナンスウィンドウ、エンジンやKubernetesのバージョンの標準サポート終了、証明書の期限切れ、非推奨のランタイム。AWSはこれらの大半をアカウントごとにAWS Healthで公開しており、EventBridge経由で他の運用作業と同じキューに流せる。読まれなければ、それは予期せぬ再起動になる。

オンプレミスではリストはより長く、完全にあなたのものだ。ファームウェア、ハイパーバイザーとOSのパッチ適用、ディスクとバッテリーの交換、ハードウェア更新サイクル、ベンダーサポート契約、現地の予備部品。それぞれにオーナーとカレンダーが要る。メジャーバージョンが3つ遅れているプラットフォームは、エラーバジェットを前借りしている。

この領域の最後の確認は、プロバイダーの調子が悪い日をどうやって知るかだ。ステータスページはインシデントの最中に人が書くもので、遅れる。プロバイダーを自分で、外側から測ること。別のネットワークから本物のユーザー経路を実行する合成カナリアは、ダッシュボードより先にリージョンの問題を教えてくれるし、本物のトラフィックがあなたに届けないときにもSLIの分母を生かし続けてくれる。

誰が何を担うか

関心事	クラウド: SREの担当分	オンプレミス: SREの担当分
施設、電源、冷却	ゾーンに分散し、信頼しつつ検証する	電源系統と冷却ゾーンを把握し、それに応じてラックを配置する
ハードウェア障害	インスタンス喪失が何事でもないよう設計する	同じ、加えて予備部品、交換プロセス、ベンダー契約
キャパシティ	クォータ、インスタンスの多様性、予約	予測、調達リードタイム、余裕
コントロールプレーン	復旧でそれに依存しない	運用し、冗長化し、それでもなお依存しない
ネットワーク	ゾーン内ルーティング、NAT、DNS、冗長なプライベートリンク	すべて: キャリア、BGP、ファイアウォール、DNS
パッチ適用とライフサイクル	プロバイダーの期限を追跡し、ゲストOSとバージョンを自分で持つ	ファームウェアからアプリケーションまで全層
コスト	リクエストあたりコストを数字として持つ。遊休のフェイルオーバー容量は保険	固定購入に対する利用率

どちらの列も、仕事が消えたから短くなったわけではない。クラウドは下の行を、ほぼどの単一企業よりもそれに慣れたプロバイダーへ移し、引き換えにあなたは検査できない依存先を抱える。この取引はたいてい正しい。それでも取引であり、SREはその両面を述べられる人だ。

障害モードと注視すべきこと

SLAを予測として扱う。 それはクレジットの付いた価格条件だ。ページ上のパーセンテージではなく、測定した振る舞いと障害ドメインに対して設計すること。

図の上だけのマルチゾーン。 サブネットリストには3つのゾーン、稼働状態には1つ。あるいは一度も試したことのないフェイルオーバー。エラーバジェットの範囲内で、意図的にテストすること。

壊れているものを必要とする復旧。 最初のステップが、影響を受けたリージョンでのコンソールログインやパイプライン実行であるランブック。

本番で発見する上限。 セクション4のすべてのクォータと天井は、負荷テストで見つけるのは安く、ローンチの最中に見つけるのは高くつく。

ここから先

シリーズの道筋を一気に。信頼性をエンジニアリングの問題として自分のものにし、解く時間が残るよう手作業に上限を設ける(第1回)。サービスがどれだけ信頼できるべきかをSLOとして述べ、その差を署名されたポリシー付きのエラーバジェットとして意図的に使う(第2回)。リポジトリに入って、その数字を決めるタイムアウト、リトライ、ロールアウトを直し、CPUではなくバーンレートでページする(第3回)。そして足元のプラットフォームが何を約束し、どこが一緒に落ち、そうなったとき自分が何をするかを知っている(第4回)。4つすべてのツールは、ほとんどのエンジニアがすでに使っているものだ。この仕事をSREにするのは、そのひとつひとつがいまやひとつの問いに答えていることだ。ユーザーは合意した信頼性を得ているか、そしてそれを保ち続ける最も安い方法は何か?

次に読む

このシリーズの第3回、コードベースの中のSRE: タイムアウト、リトライ、コードとしてのアラート。
修正は障害と運命を共にする。復旧経路が、落ちていたコントロールプレーンに依存していた3件のインシデントだ。
ercan.aiのYour LLM Bill Is an Observability Problem。同じプロバイダー依存の考え方をモデルAPIに適用したもので、そこではクォータとコストが飽和シグナルになる。

AWS、クラウドアーキテクチャ、SREプラクティス、CI/CDパイプライン、Linuxなどのコンサルティングは、ercanermis.comからどうぞ。