# Thinking about Availability in Large Service Infrastructures > [!abstract] > 大規模クラウドサービスインフラストラクチャの可用性確保には、精密かつ原則的な定義が不可欠でありながら、その定義自体が困難である。本論文は、(1) 可用性の多次元性・次元削減・サブシステム目標分解という定義上の課題、(2) セキュリティと同様の思考法(スレットモデリング、深層防御、設計レビュー、侵入テストの類比)を可用性に適用する提案、(3) フェイル・スタティック、循環依存の回避、多層協調などの具体的設計原則を示したポジションペーパーである。過去50年の研究成果が工学実践に与えた影響は限定的であり、エンドツーエンドの可用性フレームワーク構築を今後の課題として提示する。 ## 論文情報 | 項目 | 内容 | |---|---| | タイトル | Thinking about Availability in Large Service Infrastructures | | 著者 | Jeffrey C. Mogul, [[Rebecca Isaacs]], [[Brent Welch]](Google Inc.) | | 会議 | HotOS '17, Whistler, BC, Canada | | 発表日 | 2017年5月8〜10日 | | DOI | [10.1145/3102980.3102983](https://dl.acm.org/doi/10.1145/3102980.3102983) | | ページ数 | 6 | | 種別 | ポジションペーパー | ## 概要 インターネット・クラウドコンピューティングの普及に伴い、サービスは複雑に依存し合うスタックとして運用される。クラウドプロバイダはより多くの「ナイン」(可用性)を提供する圧力にさらされている一方、研究コミュニティはエンドツーエンドの可用性問題にポイントソリューション以上の注意を払ってこなかった。 著者らは Google での大規模プラネタリースケールサービスの設計・運用経験を背景に、3つの問題提起を行う。 1. **可用性の精密な定義がなぜ困難か**——多次元性、次元削減、サブシステムへの目標分解という三重の障壁 2. **セキュリティと同じ思考法を可用性に転用できる**——スレットモデリングの類比 3. **高可用性インフラストラクチャ設計のための一般原則**——フェイル・スタティック、循環依存回避など ## 問題設定 ### 可用性定義の困難さ 大規模インフラストラクチャにおける可用性の定義は、以下の三重の困難を抱える。 **多次元性の問題** サービスレベル指標(SLI)は本来多次元である。確率的 SLO、レイテンシなどのパフォーマンス指標、操作種別(読み取り対書き込み、コントロールプレーン対データプレーン)ごとの保証が必要になる。例えばトラフィックエンジニアリングスタック(Bandwidth Enforcer: BwE → Current-Model Service → Long-term Model Store / Spanner)では、BwE が停止しても仮想マシン通信を継続できるか(データプレーン可用性 > コントロールプレーン可用性)という異なる次元の目標が共存する。 **次元削減の問題** 全 SLI を実測することはコスト的に不可能であり、代理指標や加重和が使われる。「ゴールド・シルバー・ブロンズ」型の階層化 SLO はある種の次元削減をユーザーに委ねるが、概念的複雑性も転嫁する。 **サブシステム SLO の分解問題** トップレベル SLO からサブシステム SLO を導出する際、素朴なアプローチ(確率の積算や停止時間予算の分割)は誤りを生む。依存関係に含まれる未知の相関がシステムリスクを過小評価させ、上位層が下位層の障害を吸収するフォールトマスキング機構は、単純な数値計算を無意味にする。 ### 戦術的 SLO と戦略的 SLO の分離 戦術的 SLO(パケット損失率など、運用判断向け・短い時間スケール)と戦略的 SLO(クライアント設計者が前提にできる長期保証)は目的も計測スケールも異なる。同一の指標で両者を兼ねようとすることが混乱を生む。 なお同ワークショップの別論文(Huang et al. [23])は「グレー障害」——プロバイダの障害検知器をすり抜けるが利用者には影響するサブシステム劣化——を論じており、本問題設定と相補する。 ### インフラストラクチャ依存の不可視性 図1のトラフィックエンジニアリング事例では、あるルータが実際には軽負荷のリンクを「使用率 100%」と誤報告した。コントロールプレーンはこの「代替事実」を忠実に BwE に伝達し、BwE はトラフィックを絞り続けた。すべてのサービスは公称「可用」でありながら、ネットワーク全体が一部サーバへ不到達になりかけた。これは既存の障害モデルでは捕捉しにくい依存関係の例である。 ## 提案手法 ### セキュリティ的思考法の可用性への転用 著者らはセキュリティ分野で確立された思考法(Saltzer & Schroeder [36] に相当)を可用性に適用することを提唱する。 **設計時の類比** - スレットモデル(脅威モデル)[42] を可用性でも策定する。設定ミス、未知の依存関係、誤った前提、システム過負荷が「脅威」となる - 6ナイン以上の可用性では、ほぼすべての可用性損失は新種の障害である(Google ネットワークは 2 年で 103 件以上の未知障害を経験)——これはゼロデイ脆弱性との類比 - 過去の可用性実績は将来の保証にならない——過去のセキュリティ侵害記録が将来の免疫を意味しないのと同様 **緩和策の類比** - 設定ミスはセキュリティ侵害と可用性問題の双方に共通する根本原因であり、設定ミスを表現しにくくする設計が理想 - **フェイル・スタティック**——依存先が障害を起こしても継続動作するよう設計する。セキュリティにおける「デフォルト拒否」原則と相同で「どうすればよいか分からなければ、最も害の少ないことをせよ」という原則 - 大規模・急速拡散の障害に対して原因判明前から緩和する——セキュリティのロックダウン(インターネット切断、認証データベースの変更停止)に相当する「ビッグレッドボタン」機構[21] **システム全体の類比** - 可用性とセキュリティはどちらも実行速度と衝突する。ショートカットは排除すべきリスク源 - どちらも単一機構では全体を保証できず、深層防御が必要 **運用慣行の類比** - 設計レビューはセキュリティ専門家を外部から招く。同様に可用性にも専門家コンサルタントを用いた早期レビューが必要 - 侵入テスト(ペネトレーションテスト)の類比として、SRE の「Wheel of Misfortune」ゲームによる障害対応ロールプレイが挙げられる ### 高可用性インフラストラクチャ設計の原則 **多層協調による可用性** IaaS プロバイダはテナントに対してゾーン・リージョン間でサービスを複製するよう促し、一方向に可用性を担保するより低コストで高可用性を実現できる。ただしアカウント作成・認証など本質的にグローバルなサービスは高い可用性目標を維持しなければならない。 **フェイル・スタティック設計** BwE の例では、カレントモデルサービスが停止した場合に直前モデルをキャッシュして動作継続する。時間とともに帯域推定の精度は低下するが、新たな需要には対応できる(切断コンピューティングにおける「ホーディング」[27] との類比)。フェイル・スタティックの一般化には——障害検知の信頼性、継続動作設計、困難な障害に対するテスト、サブコンポーネントにフェイル・スタティックを有効化した場合の全体可用性推定——という課題が伴う。 **循環依存の回避** 大規模組織は複雑な分散システムを構築する過程で意図せず依存循環を導入しがちだ。循環は障害時の回復を極めて困難にし、障害検知器自体が依存する系が停止すれば障害が見逃される。コンポーネント間依存関係の明示的な登録を義務付けることが有効である。 **その他の原則(概要)** - カナリアリリースと段階的ロールアウトによる設定変更の相関制御 - 障害復旧機構の平時テスト（緊急コードパスを通常運用でも実行できる設計） - キャパシティプランニングによる予測可能な過負荷の防止 - 「カラーリング」によるシステムの N 分割（設定ミスや保守エラーの影響を 1/N に局限） - 冗長性なしに容量損失をもたらさない障害リスクの継続評価 - MTBF の低下より MTTR の短縮による可用性向上の費用対効果 ## 新規性 - **可用性定義の三重困難の整理**——多次元性・次元削減・サブシステム分解という問題構造の明確化は、それまで散逸していた議論を統一する枠組みとして新しい - **セキュリティ類比フレームワーク**——可用性をセキュリティと同等の「敵対的思考が必要な問題」として位置づける提案は体系的であり、設計レビュー・侵入テスト・スレットモデリングという実践的手法を直接転用できる - **戦術的 SLO と戦略的 SLO の明確な分離**——これを混在させることが根本的な混乱源であるという指摘は実践的に重要 - **フェイル・スタティックの一般原則化**——Govindan et al. [21] が示した SDN コントローラの事例を原則として抽象化し、サービス層一般へ適用可能にした ## 考察 ### トラフィックエンジニアリング事例によるインサイト BwE スタックの事例は以下の点で示唆に富む。 - **依存関係の不可視性**——ルータの誤報告がコントロールプレーン経由でトラフィック制御に連鎖した。このような「下位層がすべて稼働しているにもかかわらず上位層が機能不全になる」パターンは SLO の素朴な積算では検出不可能 - **BFT の限界**——ルータを 3f+1 で複製するのは実用的でなく、コントロールプレーンが異常入力を検知する設計が必要。しかし BFT リスクと可用性・パフォーマンスをトレードオフする枠組みが欠如している ### 研究の影響と空白 50年にわたる研究成果(Paxos、BFT、分散合意、状態機械複製など)は主にポイントソリューションとして工学実践に影響を与えてきた。BFT プロトコルは性能・スケーラビリティへの懸念から広く採用されていない。著者らが求めるのは **performability**(性能と可用性の統合形式モデル[32])の双対——可用性がノード性能の関数として変化することを表現する形式的手法——である。 ## 強み / 弱点・課題 **強み** - 6ページのポジションペーパーとして問題空間を簡潔に整理し、多くの実践的課題を提起している - Google の運用経験に基づく具体的事例(BwE スタック、Google ネットワーク障害統計)が議論を接地させている - セキュリティ類比は直感的であり、可用性の「解決されていない本質的困難」を浮かび上がらせる **弱点・課題** - 解決策を提示するより問題を提起することに重心があり、フレームワークの具体的形式化は「今後の課題」にとどまる - 提案する SLO 分解の原則(フェイル・スタティック、循環依存回避など)は定性的であり、定量的評価手法は示されていない - セキュリティ類比は有用だが、その類比自体の適用限界(攻撃者のインセンティブが存在しない可用性問題での差異など)については簡潔にしか触れられていない - 2017年時点の論文であり、その後の AIOps、LLM ベース障害診断などの進展は反映されていない