# 事業継続計画（BCP） ## 定義 事業継続計画(BCP: Business Continuity Plan)は、災害・事故・誤操作によるサービス機能停止に備え、事業を継続できるようにするための計画である。[[Mike Christian]]([[Yahoo!]] インフラストラクチャーレジリエンシーディレクタ)は、BCP の主眼を「飛行機がビルに突っ込む」ような稀な大災害への保険としてではなく、毎日起きうる小さなミスや機器故障(データセンタの屋根からの水漏れ・ルータ故障・誤操作でのボリューム削除など)への備えとして捉える。最も単純な BCP は「二重化」だが、冗長化を積み重ねるほどシステムは複雑になり、複雑さそのものが新たな障害点を生む。冗長性・自動化の追加が行き過ぎると BCP のメリットが薄れ、最終的にマイナスの効果しか得られなくなるというジレンマがある。このジレンマは、サービスを地理的に分散させ、災害時にトラフィックを自動的に他地域へ移すというマクロなレベルの対策で緩和できる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]] 冒頭, §17.1) ## 高可用性(HA)の技術類型 BCP を実現する具体的な HA アーキテクチャとして4類型が整理される。 - **ホット/ホット**: 全データセンタでアプリケーションを常時利用可能にし、フェイルオーバーを自動化できる最上級の構成。複数拠点への同時書き込みによるレプリケーション衝突が課題で、最新版が到達する前に他拠点から読み取ってしまう「致命的な読み取り」の回避が必要。 - **ホット/ウォーム**: 読み取りは全拠点からホット/ホットで受け、書き込みは1拠点に限定する構成。データ一貫性は保たれるがフェイルオーバーに時間がかかり、非同期レプリケーションの遅延(数秒〜数時間)がそのまま許容停止時間になる。 - **ホット/コールド**: 同一構成の予備を用意するだけの構成。実際に災害時に動作するか不確実なまま長期間放置されがちで、著者は「あまり価値があるとは言えない」と評する。 - **障害復旧(disaster recovery)**: 事故から守るのでなく事故後に復旧できるだけの計画。著者は「最悪の技術であり、ベーパーウェアである」と述べ、テストされないまま契約(月額の保険料)だけに依存する危険性を、買収先企業の事例(サーバと記憶装置が別建物に置かれギガビットイーサネットのみで結ばれていた)で示す。 (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]] §17.1) ## RTO/RPO と「9 はいくつ」 経営層に許容停止時間を聞けば「ゼロ」という答えが返るが、コストとパフォーマンスへの影響を伝えると答えは変わる。「5 つの 9」は通信インフラのような生命に関わるライフラインの水準であり、個々のインターネットアプリケーションにそこまでの可用性を求めるのは酷である。著者は可用性を「9 の数」で語るのでなく、**RTO(目標復旧時間: 停止後の復旧にかかる時間)**と**RPO(目標復旧時点: 失ってもよいデータの量)**で分析するほうが実務的だと論じる。両者は通常トレードオフの関係にあり、RPO を 0 にするにはレプリケーション遅延分の停止が必要になり、RTO を 0 にするにはトランザクション量を犠牲にした即時フェイルオーバーが必要になる。両方を同時に実現するには同期レプリケーションで性能を犠牲にするしかない。金融システムのような例外を除けば、RTO・RPO は現実的な値に設定してよい。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]] §17.2) ## 「影響継続」対「事故継続」と GSLB 災害発生時にまず行うべきは事故そのものの解決でなく、ユーザトラフィックの退避による**被害の最小化**である。事故の解決は被害を止めたあとに考えればよく、事故が続く時間(事故継続)でなく被害が続く時間(影響継続)を短くするアーキテクチャに注目すべきである。この退避を担うのが **GSLB(広域サーバ負荷分散、Global Server Load Balancing)**であり、距離と可用性を考慮して最適な IP アドレスを返す動的な DNS コンテンツサーバである。ただし GSLB には2つの構造的な限界がある。(1) ブラウザは GSLB でなく ISP の DNS キャッシュサーバに問い合わせるため、キャッシュサーバの距離で代理判断せざるを得ない。(2) DNS の結果はキャッシュサーバやブラウザでキャッシュされるため、TTL(通常1〜5分)が切れるまで新しい IP アドレスが反映されず、TTL を無視するクライアントが一定割合残り続ける。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]] §17.3) ## データセンタの足跡(数の決定要因) データセンタの数はコスト・複雑さ・性能の3要因で決まり、**可用性は要因に入らない**——2つ以上のデータセンタが離れた場所にあれば、すべてを同時に失う可能性はきわめて低いためである。2拠点構成では互いに2倍のキャパシティが必要でコスト増は200%、3拠点なら各拠点が半分ずつ負荷を分担できコスト増は150%で済むが、追加インフラ・ホスティング費用を考えると総コストは変わらないこともある。3拠点以上にすると、1拠点が落ちた際にトラフィックが均等に分割される保証がないため、負荷が連鎖的に隣接拠点へ波及するカスケード障害のリスクが増す(西・中央・東の3拠点でキャパシティ50%の状態から東が落ちると中央が66%、さらに西が100%まで負荷を受ける、という具体例が示される)。データセンタ数を2から3以上に増やす本当の理由は性能であり、ユーザに近い拠点を増やすほどページ読み込みが速くなる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]] §17.4) ## 単一ベンダー依存のリスク 多くの顧客を抱える第三者ベンダーに依存すべきではない。他の顧客が攻撃されれば、自社に非がなくてもサイトが道連れで落ちる。2006年に Blue Security がスパマー対策サービスを開始した際、スパマーの反撃を受けた DNS プロバイダ UltraDNS への大規模 DDoS 攻撃が、無関係な Tucows や Six Apart を巻き添えにした事例(2009年には Amazon・Salesforce.com にも同種の被害)が挙げられる。共有リソースを使う場合は特に、複数ベンダーを併用すべきである。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]] §17.6) ## フェイルオーバーのテスト BCP は単なる計画であり、実行に移して初めて意味を持つ。フェイルオーバーは緊急時以外にも定期的にテストしなければ、実際に必要になったときに機能するかどうかわからない。優れたリリースの仕組みがあれば、1つのデータセンタのトラフィックを遮断してソフトウェアのアップグレード・QA テストを行い、トラフィックを戻すという手順を他のデータセンタでも繰り返せる。これによりアップグレード中の問題がユーザに影響しなくなるだけでなく、予備のルータ交換や UPS のテストといった保守作業自体のリスク回避にもフェイルオーバーの仕組みを使える。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]] §17.7) ## 横断的知見 - **「9 の数で語らずRTO/RPOで分析する」という実務的処方は、[[可用性]] concept が集約する形式的な可用性モデルとは異なる軸から同じ問題(可用性目標をどう定めるか)に答える**: [[可用性]] は O'Connor & Kleyner(2012)・Laprie & Kanoun(1996)に基づき、固有可用性・達成可用性・運用可用性という3尺度と、信頼性成長下での不可用性の時間発展(P1-P6)という**形式的・定量的なモデル**を集約する。これに対し本ページのソース(ch.17, 2011)は、経営層への説明という**実務的な意思決定の場面**で「9の数」という単一指標が機能しない理由(コスト・パフォーマンスとのトレードオフが見えない)を指摘し、代わりに RTO(復旧時間)/RPO(データ損失許容量)という**2次元かつ用途固有**の指標を提案する。両者は「可用性を単一の数値に潰さない」という点で問題意識を共有しながら、[[可用性]] が測定対象の**時間的・空間的な粒度**(考慮する停止要因の範囲、信頼性成長の時間発展)を精緻化する方向に進むのに対し、本ページは**目的別の2軸(いつまでに直すか、どこまで失ってよいか)への分解**という、より実務者向けの単純化を選ぶ。同じ「単一の可用性数値は不十分」という診断から、学術的な精緻化と実務的な次元分解という異なる処方箋が導かれている。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]] §17.2, [[@2012__Wiley__Practical Reliability Engineering - Chapter 16 Maintainability, Maintenance and Availability]] §16.2) - **RTO/RPOは「サイト・データセンタ単位」と「個々のデータ資産単位」という異なる粒度で使われる**: 本ページが集約するch.17は、RTO・RPOを「9の数で語らない実務的な可用性指標」として、データセンタ全体・フェイルオーバーアーキテクチャ(ホット/ホット、ホット/ウォームなど)の文脈で扱う。これに対し[[データ保護]]が集約する[[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]]は、同じRTO・RPOという指標を、データ資産の棚卸表の1行(特定のデータベース・NASアプライアンスなど)に対して個別に設定するものとして扱う。前者はデータセンタ・アプリケーション全体を落とすかどうかの意思決定に、後者は特定のストレージシステムのバックアップ頻度という運用判断に、それぞれRTO・RPOを接続しており、同じ指標が異なる抽象度の意思決定に使われることを示す。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]] §17.2, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.1) - **非同期レプリケーションの「フェイルオーバー時の未複製データ」問題は、サイト層とデータ層の双方から独立に報告される**: ホット/ウォーム構成の「致命的な読み取り」(最新版が到達する前に他拠点から読み取ってしまう)は本ページのch.17が指摘する問題だが、[[データ保護]]が集約するch.14のロンドン-ダブリン間の事例(冷却カスケード障害でロンドンが停止し、非同期複製の遅延分のデータがダブリンに未到達のままフェイルオーバーを迫られた)は、同じ「レプリケーション遅延がフェイルオーバー時のデータ整合性を脅かす」問題を、ストレージ運用者の視点から具体的に裏づける。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]] §17.1, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] §14.2) ## 未解決の問い - RTO/RPO という2軸の分析は、[[可用性]] が集約する固有可用性・達成可用性・運用可用性という3尺度のどれに対応するのか、あるいは別の独立した次元なのか。本ページのソースだけでは両者の形式的な対応関係を確認できない。 - データセンタ数を「可用性は要因に入らない、コスト・複雑さ・性能で決める」とする本章の主張は、[[データセンター信頼性]] が集約する相関障害の実証研究(同一データセンタ内でハードウェア障害が時間・空間的に相関する)とどこまで整合するか。相関障害の強さによっては、2拠点でも十分な可用性が得られない場合があるのではないか。 - GSLB の TTL 由来の遅延(1〜5分、実務上はもっと長い)は、[[可用性]] の RTO 概念とどう対応づけられるか。GSLB 自体が RTO の下限を規定する構造的要因になっているのではないか。 - ホット/ウォーム構成の「致命的な読み取り」は、分散システムの一貫性モデル(強一貫性・結果整合性など)の語彙とどう対応するか。本ページのソースは実務的な現象として述べるにとどまり、形式的な一貫性モデルとの接続は示していない。 ## 関連 - 概念: [[可用性]] / [[データセンター信頼性]] / [[グレイ障害]] / [[継続的ベリフィケーション]] / [[障害注入]] / [[システム信頼性モデル]] / [[負荷分散]] / [[データ保護]](RTO/RPOをデータ資産単位で論じる) - 実体: [[Mike Christian]] / [[Yahoo!]] / [[Anoop Nagwani]] - ソース: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 14 ストレージ]] - 書籍: [[ウェブオペレーション ―サイト運用管理の実践テクニック]] ## 出典 - マイク・クリスチャン, 「夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）」, John Allspaw・Jesse Robbins 編, 角 征典 訳, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, 17 章. - アヌープ・ナグワニ, 「ストレージ」, John Allspaw・Jesse Robbins 編, 角 征典 訳, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, 14 章, §14.1, §14.2.