# インターネットスケールサービス設計 ## 定義 インターネットスケールサービス設計は、数千〜数万台のサーバ上で稼働する大規模サービスを、低コストかつ高信頼に運用するための設計原則群を指す。[[James Hamilton]] が [[@2007__LISA__On Designing and Deploying Internet-Scale Services]] で体系化した概念であり、「障害を前提とした設計（design for failure）」「すべてを自動化」「単純さの保持」の 3 信条を基盤に、障害前提設計・冗長性・コモディティハードウェア・単一バージョンソフトウェア・マルチテナンシーの 5 原則を柱とする。運用問題の 80% は設計・開発に起因するという経験則に基づき、サービスの設計段階で運用フレンドリーな特性を組み込むことが核心である。 ## 横断的知見 - Hamilton（[[@2007__LISA__On Designing and Deploying Internet-Scale Services]]）の「障害前提設計」原則は、同年の Dynamo 論文（[[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]]）において、ステートフルなキーバリューストアの設計判断として具体化されている。Hamilton が「コモディティハードウェアで冗長性により信頼性を確保する」と述べた方針を、Dynamo は一貫性ハッシュ法・スロッピークォーラム・ヒンテッドハンドオフにより実装し、整合性を犠牲にしてでも可用性を保つ設計を本番で検証した。両者とも 2007 年の Amazon/Microsoft 由来であり、「障害は常態」という認識が同時期に大規模サービス運営企業から独立に体系化された点が注目に値する。(Source: [[@2007__LISA__On Designing and Deploying Internet-Scale Services]], [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]]) - Cassandra（[[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]]）は、Dynamo と同じく「障害は常態」の前提に立つが、さらに一歩進んで**完全非中央集権**を志向した。しかし実装上は Zookeeper を用いたリーダ選出が必要となり、「一定の協調機構は分散機能の実装を容易にする」と認めている。Hamilton の「単純さの保持」原則と「完全非中央集権」の理想との間に実用上の緊張関係が存在することを、Dynamo（中央集権的なシードノード）と Cassandra（Zookeeper 依存）の双方が示している（Source: [[@2007__LISA__On Designing and Deploying Internet-Scale Services]]、[[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]]、[[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]]）。 ## 未解決の問い - Hamilton の原則はステートレスサービスに最適化されているが、ステートフルサービス（データベース、分散ストレージ）ではどの原則がどこまで適用可能か。Dynamo（[[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]]）と Cassandra（[[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]]）はステートフルサービスでの障害前提設計を実践した事例であり、ともに整合性を緩和して可用性を確保した。しかし、強い整合性が要求される領域（金融取引、在庫管理）での Hamilton 原則の適用可能性は未検証のままである。 - 「本番でテストされていないものは動かない」という原則は、カオスエンジニアリング（[[障害注入]]）として体系化されたが、Hamilton が示した「正常停止せず常にハードフェイルさせる」方針を実際に採用しているサービスはどの程度あるか。 - 2007 年時点の「コモディティハードウェアスライス」原則は、GPU クラスタ（[[GPUクラスタ運用]]）やアクセラレータ中心のインフラにどこまで移転可能か。ハードウェアの多様化と標準化のバランスはどう変化したか。 - マイクロサービスアーキテクチャ時代において、Hamilton の「依存先は規模・複雑性が正当化できる場合のみ許容する」原則は、数百のマイクロサービスが相互依存する現代の設計にどう適応するか。 - Hamilton が「ビッグレッドスイッチ」と呼んだグレースフルデグラデーションの仕組みは、現代のロードシェディング・サーキットブレーカ・フィーチャーフラグとどう対応し、どこが拡張されたか。 ## 関連 - ソース: [[@2007__LISA__On Designing and Deploying Internet-Scale Services]] / [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]] / [[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]] - 概念: [[サービスレベル目標]]（SLA/SLO の定量化）/ [[インシデント管理]]（障害ライフサイクル）/ [[障害注入]]（本番テストの体系化）/ [[agentic SRE]]（AI による自律運用の展望）/ [[べき等性]]（依存関係管理の基盤）/ [[GPUクラスタ運用]]（現代のハードウェアスケール）/ [[結果整合性]]（可用性優先の整合性モデル）/ [[一貫性ハッシュ法]]（分散パーティショニング）/ [[ゴシッププロトコル]]（非中央集権メンバーシップ） - エンティティ: [[James Hamilton]] / [[Microsoft]] / [[Amazon]] / [[Werner Vogels]] / [[Dynamo]] / [[Apache Cassandra]] / [[Facebook]] - 関連 MOC: [[LLM4SRE - MOC]] / [[SRE - MOC]] ## 出典 - [[@2007__LISA__On Designing and Deploying Internet-Scale Services]]（全体——10 領域のベストプラクティス、5 設計原則、3 信条） - [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]]（ステートフルサービスにおける障害前提設計の実践——結果整合性・スロッピークォーラム・99.9 パーセンタイル SLA） - [[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]]（障害常態前提の分散ストレージ設計、完全非中央集権と実用上の協調機構のトレードオフ）