# インターネットスケールサービス設計 ## 定義 インターネットスケールサービス設計は、数千〜数万台のサーバ上で稼働する大規模サービスを、低コストかつ高信頼に運用するための設計原則群を指す。[[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]]）。 - **「すべてを自動化」原則は人為ミスを減らす一方で、単一の自動化ミスを組織全体の障害へ増幅させうる——Facebookの2021年障害はこの二面性を実例で示す**: 本ページはHamiltonの「すべてを自動化」原則を、運用コスト削減とヒューマンエラー回避の手段として肯定的に記録してきたが、[[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 6 集権化と非集権化]]は同じ原則の裏面を示す。著者(Bruce Davie)は2015年のFacebook講演から「ネットワークの運用に関しては人間よりソフトウェアのほうが良い仕事をする」という教訓を引用しつつ、2021年には自動化されたステップ(DNSサーバがバックボーンとの接続喪失時にBGP経路広告を自動的に無効化する挙動)が障害の連鎖を増幅させた事例を報告する。著者自身「自動化はヒューマンエラーを減らす一方で、自動化によって一つのミスが別の不具合を呼び起こして結果として大きな被害になることもある」と見解を修正しており、これはHamiltonの原則が前提とする「自動化は常に人手より安全」という単純化に対する限定を加える。(Source: [[@2007__LISA__On Designing and Deploying Internet-Scale Services]], [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 6 集権化と非集権化]] ch.6 §6.2) - **「本番でテストされていないものは動かない」というHamiltonの信条は、第6章が提起する「デプロイ前のネットワーク検証」という具体的な処方箋と直接対応する**: 本ページはHamiltonの3信条の一つとして「本番でのテスト」を記録してきたが、第6章はネットワーク領域でこれがまだ実践されていない現状を指摘する——自動テストを組み込んだCI/CDはソフトウェアシステムでは当たり前になっているが、ネットワークの世界ではまだ一般的でなく、Batfishのようなデプロイ前のBGP設定検証ツールが「とかく欠落しがちな堅牢性のレイヤー」として位置づけられる。これはHamiltonが2007年に体系化した「本番相当の検証」という一般原則が、2021年時点でもネットワーク運用の領域では未達成であったことを示す事例であり、原則の普遍性とドメインごとの実践速度の差を示す。(Source: [[@2007__LISA__On Designing and Deploying Internet-Scale Services]], [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 6 集権化と非集権化]] ch.6 §6.2) ## 未解決の問い - Facebookの2021年障害が示す「自動化ミスの増幅」は、Hamiltonの原則をどう修正すべきかを示唆するか。「自動化するかどうか」ではなく「自動化された変更をデプロイ前にどう検証するか」という一段手前の設計原則を、本ページの5原則に追加すべきか。 - 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]] / [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 6 集権化と非集権化]] - 概念: [[サービスレベル目標]]（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]]（障害常態前提の分散ストレージ設計、完全非中央集権と実用上の協調機構のトレードオフ） - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 6 集権化と非集権化]]（ch.6 §6.2: 自動化による障害増幅の実例(Facebook 2021年障害)、デプロイ前ネットワーク検証の必要性）