はじめに:'0秒通知'災害に備えるデータセンターの現実

Netflixがライブストリーミング拡大において人、プロセス、インフラの三拍子を強調したように、Meta(Facebook)のデータセンター運用も同じ哲学を共有しています。ハリケーン、山火事、電力網障害など予告なしの災害はデータセンターインフラに致命的です。従来は数時間前の警告がある状況への対策は十分に整っていましたが、'0秒通知'災害(Instantaneous Power Loss) は全く異なるレベルの準備を要求します。

Metaはこの問題を解決するために Instant PowerLoss Storm という新しいテストパラダイムを導入しました。これは既存のDisaster Readiness (DR) Stormプログラムの最終防衛線として機能し、既知のリスクだけでなく予期せぬリスクにも対応できるよう設計されています。

参考: 本記事はMeta Engineering Blogの「Lights Out, Systems On: Validating Instant Power Loss Readiness」を基に再構成したインサイトです。原文はこちら

防御戦略:Defense-in-Depthの実践

Metaは瞬時的な電力喪失に耐える能力をデータセンタースタック全体にわたって「最初から」設計しました。機械・電気設備からサーバーラック、ストレージ、コンピュート、そして中核オーケストレーターである Twine まで、すべての層が電力喪失耐性を備えていました。

主要メカニズム

  1. バッテリーとPower Loss Siren (PLS): ラックの電源が切れた際にインメモリデータを保持する能力
  2. Unavailability Events (UE): Twineサービスのための非同期シグナルメカニズムで、リージョン全体に障害発生を伝播

しかし、単一DC内の単一障害ドメインでは検証されていたこれらの機能が、リージョン全体というシナリオでは新たな脆弱性を露呈しました。特にリージョンの規模が通常の障害ドメインの50~60倍に達し、レプリカ配置の問題と 自律ブートストラッピング 問題が核心的な課題でした。

ブートストラッピングの悪夢:循環依存と「ブーメラン」問題

MetaのTwineオーケストレーターには、Scheduler、Allocator、Broker、Zelos(コーディネーター)などのコントロールプレーンサービスが存在します。これらのサービスなしではリージョン内のいかなるサービスも実行できません。通常時は循環依存(Circular Dependency)のリスクは低いですが、リージョン全体をブートストラッピングする際には致命的な「鶏と卵」問題が発生します。

Metaはこの問題を Belljar というCI/CDパイプラインのテストを通じて解決しました。Belljarはコントロールプレーンサービス間の起動依存性を継続的に検出し除去します。また、万一に備えて Twine Recovery Kit (Twrko) という専用ツールを開発し、予期せぬ循環依存を強制的に断ち切れるようにしました。

もう一つの問題は 「ブーメラン」効果でした。障害復旧に使用されるUEシグナルが、コントロールプレーンサービス自身をシャットダウンしてしまう現象です。Metaはこの問題を、コントロールプレーンサービスが電力関連UEのシャットダウンシグナルを「無視」するというシンプルで持続可能なアプローチで解決しました。

トレードオフ:信頼性と成長速度のバランス

完全な耐性を構築することは可能ですが、インフラに過剰なエンジニアリングコストをもたらす可能性があります。Metaは以下のようなトレードオフを設定しました。

絶対に避けるべき影響許容可能なリスク
ストレージ/DBのデータ損失一時的なサービスエラー
DC設備(機械/電気)の恒久的損傷事前定義された閾値内のラック障害
単一リージョンを超える持続的影響サービスルーティングテーブルの制限された遅延

日本の開発現場での適用文脈: 国内のデータセンター運用では、特に「許容可能なリスク」の基準を明確に設定することが重要です。多くの企業が「無条件100%可用性」を目標としますが、これは不必要なコストと複雑性を招く可能性があります。Metaのアプローチのように「何を犠牲にできるか」を先に定義するのが賢明です。

検証:実際のプロダクションリージョンを停電させる

MetaはInstant PowerLoss Stormを検証するため、実際の大規模プロダクションリージョンの電源を遮断しました。これは相当なリスクを伴いましたが、体系的な段階的アプローチによりリスクを管理しました。

  1. 新規/プレプロダクションリージョンで自己完結的な問題を検証
  2. シャドウリージョン(プロダクション複製) でテスト
  3. 最小のプロダクションリージョンで限定的な爆発半径でテスト
  4. コアストレージ、AI、データウェアハウスワークロードをホストする大規模リージョンを停電

テストは実際の停電状況を再現するために事前措置を一切取らず、MTTR(平均復旧時間)も実際の障害シナリオと同一に設定しました。

まとめ:遅く進むことが結局は早い道

MetaのInstant PowerLoss Stormは単なるテスト以上のものです。これは インフラ全体にわたるアーキテクチャ改善 をもたらし、データセンター設計の革新と検証を可能にする基盤となりました。Metaは「信頼性と速度はコインの両面」という哲学のもと、急成長のための強固な基盤を築きました。

次のステップとしての学習方向:

  • データセンターの障害ドメイン(Fault Domain)設計パターンの学習
  • Kubernetesベースのオーケストレーターにおけるコントロールプレーンの冗長化戦略の研究
  • リージョン単位の災害復旧(DR)設計パターン(Active-Passive、Active-Active)

合わせて読みたい記事:

Meta data center server racks with power redundancy systems for Instant PowerLoss Storm testing Development Concept Image

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。