> [!abstract] > システム対管理者比率は大規模サービスの管理コストを示す概算指標として広く用いられる。小規模で自動化が進んでいないサービスではこの比率は 2:1 程度だが、業界最高水準の高度に自動化されたサービスでは 2,500:1 に達する。自動管理は重要だが、最も重要な要因はサービスそのものの設計——すなわち自動化しやすいか、運用フレンドリーか——である。運用フレンドリーなサービスは人的介入をほとんど必要とせず、最も稀な障害を除くすべてを自動的に検知・復旧する。本論文は MSN および Windows Live の大規模サービス群を数十年にわたりスケーリングしてきた経験から蓄積されたベストプラクティスを体系的に整理する。 ## 論文情報 - タイトル: On Designing and Deploying Internet-Scale Services - 著者: [[James Hamilton]]（Windows Live Services Platform, [[Microsoft]]） - 媒体: 21st Large Installation System Administration Conference（LISA '07, 2007-11-11〜16, Dallas, TX） - URL: https://www.usenix.org/conference/lisa-07/designing-and-deploying-internet-scale-services - 関連研究: Recovery Oriented Computing（Patterson, Berkeley）、Crash-Only Software（Fox, Stanford） ## 概要 [[James Hamilton]] が MSN・Windows Live・Exchange Hosted Services 等の大規模サービス運用で蓄積した 20 年以上のベストプラクティスを、サービス設計・自動管理・依存関係管理・リリースサイクル・ハードウェア標準化・運用計画・監視とアラート・グレースフルデグラデーション・顧客コミュニケーション・セルフプロビジョニングの 10 領域にわたって体系化した論文である。障害を前提とした設計と自動化の徹底が、低コストかつ高信頼なサービス運用の鍵であると説く。 ## 問題設定 インターネットスケールのサービスでは、10,000 台以上のサーバと 50,000 台以上のディスクを運用する段階に達すると、障害は日常的に複数回発生する。ハードウェア障害のたびに即座の管理者介入を要するサービスは、コスト効率と信頼性の両面でスケールしない。加えて、24 時間 365 日の運用チームは高コストであり、圧力下の人的判断は約 20% の確率で誤りを生む。この構造的問題に対し、サービスの設計段階から運用フレンドリーな特性を組み込み、人的介入を最小化する原則とプラクティスを整理する必要がある。 ## 提案手法 Hamilton は「障害を予期せよ」「単純に保て」「すべてを自動化せよ」の 3 つの信条（Bill Hoffman に由来）を基盤に、以下の 5 つの設計原則と 10 領域のベストプラクティスを体系化する。 ### 5 つの設計原則 1. **障害を前提とした設計（design for failure）**: 多数の連携コンポーネントは頻繁に障害を起こす。人的介入なしにサービスが存続できなければならない。障害復旧パスは単純であり、頻繁にテストされるべきである。Armando Fox（Stanford）は「正常停止を行わず、常にハードフェイルさせる」ことが障害パスをテストする最良の方法だと論じる。 2. **冗長性と障害復旧**: メインフレームモデル（高価な単一障害点）に代え、同期冗長による無停止データ保護を採用する。任意のサーバをいつでも停止でき、ワークロードのドレインなしに SLA を満たせることが酸性試験（acid test）となる。 3. **コモディティハードウェアスライス**: サービスはコモディティハードウェア（$1,000〜$2,500 の 2 ソケット、2〜4 コアシステム）を対象とすべきである。大規模コモディティクラスタは少数の大型サーバより安価であり、消費電力はクロック周波数の 3 乗でスケールするため高性能サーバは運用コストが高い。 4. **単一バージョンソフトウェア（single-version software）**: 過去バージョンの長期サポートを不要にし、1 バージョンのみをホストする。リリース間のユーザ体験変更を最小化しつつ、顧客にバージョン管理の自由を与えない代わりに低コストを実現する。 5. **マルチテナンシー**: 物理的隔離なしにすべての利用者を同一サービスに収容する。単一バージョンサポートと同様、自動化と大規模化に基づく低コスト提供の前提条件である。 ### 10 領域のベストプラクティス **1. サービス全体設計**: 高速ヘルスチェック、フル環境での開発、すべてのコンポーネント障害モードの文書化、下位コンポーネントのゼロトラスト、機能の重複排除、ポッド/クラスタ間の独立性確保、稀な緊急時の人的介入の許容、単純さと堅牢さの保持、全レベルでの流入制御（admission control）、細粒度パーティショニング、ネットワーク設計の理解、スループットとレイテンシの分析、運用ユーティリティのサービス同等の扱い、アクセスパターンの把握、全コンポーネントのバージョニング、単一障害点の回避。 **2. 自動管理とプロビジョニング**: すべてを再起動可能かつ冗長に保つ。地理分散をサポートする。自動プロビジョニングとインストールを行う。設定とコードを単一ユニットとして配信・デプロイする。サーバ個体ではなくロール（パーソナリティ）を管理する。多系統同時障害を想定する。サービスレベルで復旧を行い、ローカルストレージに回復不能な情報を保持しない。デプロイはファイルコピーで単純に保つ。定期的にサービスを故意に停止させる。 **3. 依存関係管理**: 依存先の規模・複雑性が正当化できる場合のみ依存を許容する。レイテンシを予期し、適切なタイムアウトとべき等性（idempotency）を設ける。障害を分離しカスケードを防ぐ（常にフェイルファスト）。出荷済みの実証済みコンポーネントを使用する。サービス間の監視とアラートを実装し、依存先は同等以上の SLA を持つ。 **4. リリースサイクルとテスト**: 頻繁にリリースする（3 か月周期以下を推奨）。本番データで問題を発見する。実測値を常に収集する。偽陽性を最小化する。傾向を分析して問題を予測する。サービスの健全性を組織全体に可視化する。エンジニアリングに投資する。バージョンロールバックを必須とし、テスト済みにする。前方互換性と後方互換性を維持する。単一サーバデプロイをサポートする。負荷のストレステストを行い、キャパシティ・性能テストを新リリース前に実施する。本番データでテストする。 **5. ハードウェア選定と標準化**: 標準 SKU のみを使用する。フルラック単位で購入する。サービスはハードウェア抽象化に対して書く。ネットワークと命名を抽象化し、常に CNAME を使用する。 **6. 運用とキャパシティ計画**: 開発チームに運用責任を持たせる（Amazon の "you built it, you manage it" の思想）。ソフトデリートのみを行い、データを物理削除しない。リソース割り当てを追跡する。一度に 1 つの変更のみを適用する。すべてを構成可能（configurable）にする。 **7. 監査・監視・アラート**: すべてを計装する。データが最も価値ある資産と認識する。顧客視点でサービスを見る。本番テスト用に計装する。レイテンシが最も困難な問題であると認識する。十分な本番データを保持し、全操作にパフォーマンスカウンタを設ける。全操作を監査する。障害耐性メカニズムを追跡する。構成可能なログを提供する。すべてのエラーをアクション可能にする。 **8. グレースフルデグラデーションと流入制御**: 「ビッグレッドスイッチ」——緊急時に非重要ワークロードを切り離し、重要な処理を継続する設計をテスト済みの状態で保持する。流入制御で過負荷時にサービス全体の劣化を防ぐ。段階的な利用者復帰（1 名→10 名/秒→段階的増加）をサポートする。 **9. 顧客・報道対応計画**: 障害時の状態を RSS・ウェブ・メール等の複数チャネルで顧客に伝達する。状況の透明性が顧客満足度を向上させる。大規模データ損失・セキュリティ侵害・長時間停止に対するコミュニケーション計画を事前に策定する。 **10. セルフプロビジョニングとセルフヘルプ**: 顧客がウェブ経由で自らサービスを開始できる仕組みがコスト削減と顧客満足度向上の双方に寄与する。 ## 新規性 本論文の新規性は個々の技術的貢献ではなく、インターネットスケールサービスの設計・開発・デプロイ・運用にわたる運用知の体系的な成文化にある。20 年以上にわたる複数の大規模サービス（MSN、Windows Live Search、Windows Live Mail、Exchange Hosted Services、Xbox Live、Live Communications Server 等）の経験と、Berkeley の Recovery Oriented Computing・Stanford の Crash-Only Software の研究知見を統合し、10 領域にわたる再現可能なベストプラクティスとして構造化した。2007 年当時、このような運用知は各組織に暗黙知として閉じており、体系的に公開された文献はほとんどなかった。 ## 実験設定 本論文は実験論文ではなく経験論文（experience paper）である。Hamilton が直接率いた Exchange Hosted Services（約 700 サーバ、220 万ユーザ超）を主要な事例とし、Windows Live Search・Windows Live Mail・Xbox Live・Messenger Operations・[[Microsoft]] Global Foundation Services Operations 等の複数チームからの知見を統合する。一部のサービスは 2.5 億ユーザ超に成長している。 ## 実験結果 定量的な比較実験は含まないが、以下の運用上の数値・経験則が示される。 - システム対管理者比率: 低自動化サービスで 2:1、高自動化サービスで 2,500:1。最も手動的なサービスと最も自動化されたサービスで人件費に 2 桁の差が存在する。 - 10,000 台以上のサーバと 50,000 台以上のディスクを擁するサービスでは、障害が 1 日に複数回発生する。 - 運用エンジニアが圧力下で判断を誤る確率は約 20%。 - 2,000 台規模のサービスが数日間で 400 台まで縮小したが、障害耐性メカニズムが障害を隠蔽したため当初気づかれなかった。 - アラート対トラブルチケット比率の目標は 1 に近づけ、アラートなしの健全性問題は 0 に近づける。 - リリースサイクルは 3 か月が推奨、多くのサービスは週次リリースへ移行しつつあり、3 か月超は危険。 ## 考察 本論文が提示する原則は、後年の SRE（Site Reliability Engineering）の基本思想と多くが重なる。特に「開発チームが運用責任を持つ」（Amazon の "you built it, you manage it"）、「本番でテストされていないものは動かない」、「障害は常態であり例外ではない」という認識は、2016 年の Google SRE 本の基盤と同じである。また「ビッグレッドスイッチ」によるグレースフルデグラデーションの概念は、現代のロードシェディングやサーキットブレーカの先駆的な整理と位置づけられる。 Hamilton が強調する「運用問題の 80% は設計・開発に起因する」という観察は、インシデント管理（[[インシデント管理]]）や AIOps の研究において繰り返し確認されている。同様に、コンフィギュレーション変更を監査ログで追跡し、障害時に「最近何が変わったか」を即座に特定する手法は、現代のオブザーバビリティ基盤の設計思想と直結する。 依存関係管理における「フェイルファスト」「タイムアウトの徹底」「べき等性（[[べき等性]]）」の主張は、マイクロサービスアーキテクチャ時代の耐障害設計パターン（サーキットブレーカ、リトライバジェット、バルクヘッド）の原型である。 ## 強み / 弱点・課題 ### 強み - 複数の大規模サービスの横断的な経験を体系化しており、個別事例の偏りを緩和している。 - 原則が具体的かつアクション可能であり、設計・開発・運用の各段階で直接適用可能である。 - Recovery Oriented Computing や Crash-Only Software といった学術研究と産業実践を橋渡ししている。 - 20 年後の現在でも多くの原則が有効であり、SRE・DevOps・クラウドネイティブ設計の源流として参照され続けている。 ### 弱点・課題 - 経験論文であり、各ベストプラクティスの効果を定量的に検証する対照実験は含まない。 - 2007 年時点の技術環境（Windows Live、Exchange Hosted Services）を前提としており、コンテナ化・マイクロサービス・サーバレスといった現代のアーキテクチャパターンは対象外である。 - 主に [[Microsoft]] 社内の経験に基づくため、異なる組織文化・技術スタックにおける適用可能性は検証されていない。 - 分散システムの形式的な信頼性モデルや可用性定義（[[サービスレベル目標]]）との接続が弱い。 - セキュリティ設計については「セキュリティ脅威モデリング」への言及にとどまり、深い議論がない。