# Architecture and Dependability of Large-Scale Internet Services > [!abstract] 概要 > 3 つの大規模インターネットサービスにおけるアーキテクチャと障害原因を分析すると、開発者は可用性を最大化する信頼性の高いシステムを計画しやすくなる。 ## 論文情報 | 項目 | 値 | |---|---| | タイトル | Architecture and Dependability of Large-Scale Internet Services | | 著者 | [[David Oppenheimer]], [[David A. Patterson]](いずれも University of California at Berkeley) | | 発表 | IEEE Internet Computing, 2002 年 9・10 月号, pp. 41–49 | | 形式 | 雑誌記事(9 ページ、抄録なし。冒頭のリード文のみ) | | 対象 | 匿名化された 3 サービス(Online・Content・ReadMostly) | | 詳細分析 | 同著者の技術報告 UCB-CSD-02-1185(2002 年 5 月)。後続の [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] | ## 概要 AOL・Google・Hotmail のような大規模インターネットサービスについて、アーキテクチャ・運用・障害の 3 面から 3 つの実サービスを調査した予備的報告である。3 サービスは負荷分散層・ステートレスなフロントエンド層・ステートフルなバックエンド層という共通の構成を持ち、多段の冗長化で可用性を得ている。それでも障害は頻発し、オペレータエラーとネットワークが主要な原因であり、HW・SW の障害は冗長化でほぼ隠蔽されていた。 ## 問題設定 - 大規模インターネットサービスは、数千台規模の廉価な PC・カスタムソフトウェア・人手による運用と、拠点間の冗長化で 24 時間 365 日の可用性を目指す。そのアーキテクチャ(HW・SW・運用)は場当たり的に発展し、体系的に調査・分析された例は少ない。 - 既存の障害研究は、Gray の Tandem、Kuhn の公衆電話網、Murphy & Gant の VAX、Xu らの Windows NT 網など、インターネットサービスとは異なる基盤や運用環境を扱っていた。 - 高可用・保守容易なサービス構築の原則を定式化する第一歩として、既存サービスのアーキテクチャと信頼性を調べる。 ## 提案手法 新しい手法の提案ではなく、実サービスの調査である。 **アーキテクチャ調査**: 匿名化した 3 サービスの構成を比較する。3 サービスの規模と特性は次のとおり(表 1・表 2 参照)。 - Online: オンライン/ポータル。約 1 億ヒット/日、約 500 台(2 データセンター)。Sparc と x86、Solaris。読み書き比は高。 - Content: グローバルなコンテンツホスティング。約 700 万ヒット/日、約 500 台(4 データセンターとクライアント側拠点)。x86 とオープンソース OS。読み書き比は中。 - ReadMostly: 読み取りが極めて多い高負荷サービス。約 1 億ヒット/日、2,000 台超(4 データセンター)。x86 とオープンソース OS。読み書き比は非常に高(ユーザはほとんどデータを更新しない)。 表1(Table 1): インターネットサービスと従来型アプリケーションの特性比較。 ![[_attachments/2002__IEEE-Internet-Computing__Architecture-operation-and-dependability-of-large-scale-Internet-services-three-case-stud/tab01-comparison.png]] 表2(Table 2): 調査した 3 サービスの特性。 ![[_attachments/2002__IEEE-Internet-Computing__Architecture-operation-and-dependability-of-large-scale-Internet-services-three-case-stud/tab02-characteristics.png]] **地理的分散**: 3 サービスとも可用性のために拠点を分散する。Online は本社と近隣のコロケーション施設、ReadMostly は米東海岸 2 拠点と西海岸 2 拠点、Content は アジア・欧州・米東西の 4 拠点を使う。Content 以外は冗長拠点も要求処理に参加する。利用者の振り分けは、Content がクライアントのカスタムソフトで主・副の拠点を指定し、Online は本社のサーバが最適サーバの一覧を返し、ReadMostly はスイッチベンダー独自のグローバル負荷分散(DNS 応答の書き換え)を使う。Content は拠点をペアにし、更新は主拠点から副拠点へ毎晩伝搬する。 **単一拠点の 3 層構成** - 負荷分散: スイッチで負荷に応じ振り分ける。調査した 3 サービスは L7 スイッチングを使わず、ラウンドロビン DNS または L4 分散を使う。Online はステートフルな部分でユーザ ID からサービスグループ(クラスタ)を選ぶ状態付きの層を上に足す。一般原則として、拠点間・クラスタ内フロントエンド間・クラスタの部分集合間で多段に負荷分散する。 - フロントエンド: ステートレスなコードで要求を受け、バックエンドからデータを取得して返す。既製の Web サーバではなくカスタムソフトを使う。バックエンド対フロントエンドの台数比は Online の 1:10 から ReadMostly の 50:1 まで幅がある。Online は機能(ステートフル用・ステートレス用・Web プロキシキャッシュ)とデータ(サービスグループ)で分割するが、Content と ReadMostly は分割せず全フロントエンドが全バックエンドへアクセスする。 - バックエンド: 永続データを持ち、ノード構成の差が最も大きい。データ分割はスケーラビリティ・可用性・保守性の鍵である。冗長化方式は 3 サービスでスペクトルをなす。 - Online: 1 サービスグループ(約 6.5 万ユーザ)を 1 台の Network Appliance ファイラ(RAID-4)に割り当てる。ディスク 1 本の障害は許容するが、ファイラ障害ではグループ全員がデータを失う。性能も向上しない。 - Content: RAID を使わず、各データを別拠点の双子のストレージサーバに複製する。ディスク・サーバ・拠点の単一障害を隠蔽できるが、既定の取得先は 1 拠点のため性能は上がらない。 - ReadMostly: ノード間・拠点間で完全複製する。要求を複製へ分散できるので可用性と性能がコピー数に比例して向上する。ただし更新を全複製へ伝搬するため、書き込みが多いサービスには向かない。 図1(Figure 1): Online サイトのアーキテクチャ。 ![[_attachments/2002__IEEE-Internet-Computing__Architecture-operation-and-dependability-of-large-scale-Internet-services-three-case-stud/fig01-online-architecture.png]] 図2(Figure 2): Content サイトのアーキテクチャ。 ![[_attachments/2002__IEEE-Internet-Computing__Architecture-operation-and-dependability-of-large-scale-Internet-services-three-case-stud/fig02-content-architecture.png]] 図3(Figure 3): ReadMostly サイトのアーキテクチャ。 ![[_attachments/2002__IEEE-Internet-Computing__Architecture-operation-and-dependability-of-large-scale-Internet-services-three-case-stud/fig03-readmostly-architecture.png]] - ノード構成: いずれも 2 CPU 級の廉価な x86(Online の worker のみ Sparc)、100 Mbps Ethernet、メモリ 256 MB〜1 GB である。 表3(Table 3): 3 サービスのノード構成。 ![[_attachments/2002__IEEE-Internet-Computing__Architecture-operation-and-dependability-of-large-scale-Internet-services-three-case-stud/tab03-node-architectures.png]] - ネットワーク: 拠点のネットワークは、コロケーション施設の網から 1 段目スイッチ、Gigabit Ethernet で各ラックの 2 段目スイッチ、100 Mbps でノードという共通の形をとる。1〜2 段目スイッチ間は冗長化するが、ノードと 2 段目スイッチ間は 3 サービスとも冗長化せず、施設網と 1 段目スイッチ間を冗長化するのは ReadMostly のみである。VIA や InfiniBand ではなく UDP/TCP over IP を使うのは、100BaseT の NIC が 50 米ドル未満なのに対し VIA の PCI カードが約 1,000 米ドルというコストのためとみられる。 **運用面の調査** - テスト: 開発 QA が単体・回帰テストを単一ノードと小規模テストクラスタで行う。Online は 3 段階(開発グループのテストクラスタ、運用グループのテストクラスタ、本番への alpha/beta 段階リリース)を踏み、大きなリリースは一部の利用者へ最長 2 週間先行して展開する。この過程は運用者を最初から第一級のユーザとして組み込む。 - デプロイ: 社内開発の自動化ツールで、3 サービスとも ローリングアップグレードを使う。Online は常に 2 バージョンを全マシンに置き、5 分未満で旧版へ戻せる。 - 日常運用: 監視・切り分け・修復が難しい。理由は変更頻度、規模、停止して切り分けられないこと、アプリ・OS・各種ネットワーク・複数組織の運用者が絡む相互作用である。データの再分割の判断は人が行い、ツールは場当たり的である。運用者と開発者の対話が多く、両者の境界をあえて曖昧にしている。 **障害の調査**: 集計の可用性統計ではなく個別の障害報告(Online と Content は障害追跡 DB、ReadMostly は事後報告書)を調べる。コンポーネント障害(部品が期待どおり動かないこと)が、理論上ユーザのアクセスを妨げるか、ユーザから見える性能を大きく下げたとき、サービス障害とみなす。サービス障害は連鎖の最初に壊れたコンポーネントに帰属させ、位置(フロントエンド・バックエンド・ネットワーク・不明)と種別(ノード HW・ノード SW・ネットワーク HW・ネットワーク SW・オペレータ・環境・過負荷・不明)で分類する。 ## 新規性 - 実運用の大規模サービス 3 本のアーキテクチャ(冗長化方式・負荷分散・ノード/ネットワーク構成)と運用(テスト・デプロイ・監視)を並べて調べた点。 - 集計統計ではなく個別の障害報告を原因別に分け、コンポーネント障害がサービス障害へ至る割合を原因種別ごとに示した点。オペレータエラーは他より隠蔽されにくいという構造を数で示す。 - 運用者をソフトウェアの利用者と位置づけ、開発工程全体でその使い勝手を考えるべきだと主張した点。 ## 実験設定 - 対象: Online(コンポーネント障害 85 件に基づく 18 のサービス障害、4 か月分)、Content(同 99 件に基づく 20、1 か月分)、ReadMostly(サービス障害 21、6 か月分)。 - 入手データ: Online と Content は障害追跡 DB、ReadMostly は事後報告書。サービスの同定を避けるため情報を一部抽象化している。 - 影響の判定: 障害報告の内容(壊れた部品・顧客からの苦情報告など)とサービス構成の知識から「理論上」の影響を推定する。 - 詳細な分析は技術報告(UCB-CSD-02-1185)に譲り、本稿は Content と ReadMostly の一部の属性だけを示す。 ## 実験結果 - Content では、コンポーネント障害がサービス障害に至る割合が原因で大きく異なる。ノードのオペレータエラーだけがコンポーネント障害 18 件のうち 9 件(半数)でサービス障害に至り、それ以外の分類は 11% 以下である(ノード SW は 41 件中 5 件、原因不明のネットワーク障害は 27 件中 3 件、ノード HW は 4 件中 0 件)。 図4(Figure 4): Content サイトのコンポーネント障害とサービス障害の件数。 ![[_attachments/2002__IEEE-Internet-Computing__Architecture-operation-and-dependability-of-large-scale-Internet-services-three-case-stud/fig04-failure-rates.png]] - サービス障害の原因別内訳(%)は、Content でノードのオペレータ 45・ネットワークのオペレータ 5・ノード SW 25・不明ネットワーク 15、ReadMostly でノードのオペレータ 5・ネットワークのオペレータ 14・ネットワーク HW 10・ノード SW 5・ネットワーク SW 19・不明ネットワーク 33 である。両サービスともノード HW・環境・不明ノードは 0 である(表は各列の合計が 100 にならない)。 表4(Table 4): Content と ReadMostly のサービス障害の原因種別(%)。 ![[_attachments/2002__IEEE-Internet-Computing__Architecture-operation-and-dependability-of-large-scale-Internet-services-three-case-stud/tab04-failure-causes.png]] - 観察 1: オペレータエラーは Content で最大、ReadMostly で 2 番目の障害原因である。障害はスケール・HW 交換・再設定・デプロイ・アップグレードなど、システムを変更したときに生じ、多くは障害修復中ではなく通常の保守中に起きた。 - 観察 2: 冗長化などの高可用技法は Content と ReadMostly の HW・SW 障害をほぼ完全に隠蔽した。一方、ネットワークは単一障害点になりやすく、意外に大きな原因である。集約が進んだコロケーション・回線事業者の「冗長」網が近傍で同じ物理リンクやスイッチを共有し、運用センターが 1 か所のため拠点間・対顧客の網の問題が見えないことも理由である。 - 観察 3: 障害の切り分けと修復は複数の管理主体(自社運用・開発者・コロケーション施設・回線事業者・顧客)の調整を要し、電話・メールで手作業で行われる。traceroute 程度のツールしかなく、壊れた機器を持つ主体が修復手段を握るため、修復時間が延びる。 ## 考察 - 運用者もサービスソフトウェアの利用者であり、開発者は運用者の使い勝手を開発工程全体で考慮すべきだ。運用作業の多く(設定・原因特定・修復)が未自動化で、切り分けや構成管理のツールを高度化・標準化する余地が大きい。 - 開発者は高信頼システムやその監視・制御ツールの設計でオペレータエラーをほぼ無視しているという批判である。 - 管理主体をまたぐ問題切り分けの改善は、.Net や SunOne のような合成ネットワークサービスの時代にいっそう重要になる。 - 今後: 対象サービス・障害報告の追加による統計的有意性の向上、MTTR や影響ユーザ数などの指標の追加、相関障害の原因の分析。 ## 強み / 弱点・課題 - 強み: 実運用の 3 サービスを同じ観点で比較し、アーキテクチャの設計選択と障害原因を対応づける。個別の障害報告を分析し、隠蔽されにくい障害(オペレータエラー)を数で示した。 - 弱点・課題: 対象が 3 サービスのみで、匿名化のため詳細を抽象化している。ReadMostly の内訳は件数の記載が図にない。障害のサービスへの影響は報告から「理論上」推定した値で、MTTR などの指標もない。本稿は予備的報告であり、詳細な分析と修復時間・緩和技法の有効性は [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] に持ち越された。 ## 関連 - 概念: [[運用障害分析]] / [[インターネットスケールサービス設計]] / [[人的要因]] / [[Webロードバランシング]] - エンティティ: [[David Oppenheimer]] / [[David A. Patterson]] / [[UC Berkeley ROC Project]] - ソース: [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]