10月14日、Pragmatic Engineerが「Building resilient AI-powered software, and planning for when things go wrong」と題した記事を公開した。この記事では、AIを組み込んだシステムの耐障害性設計と、大規模障害時のディザスタリカバリ（DR）戦略について詳しく紹介されている。
本記事は、Sam Newmanが執筆したO'Reillyの新刊『Building Resilient Distributed Systems』からの抜粋をベースにしている。Newmanは『Building Microservices』の著者としても広く知られるソフトウェアアーキテクチャの第一人者であり、マイクロサービス設計における信頼性の文脈で長年発言を続けてきた人物だ。今回の新刊の執筆には当初2年を見込んでいたが、AI関連の変化を随所に反映するために3年かけて完成させたという。AIエージェントがコードを大量に生成し、デプロイ頻度が上がるにつれ本番インシデントも増加している今、DR設計の重要性は高まる一方だ。
RPOとRTO：DR設計の出発点
DR戦略の議論で必ず登場するのが、RPO（Recovery Point Objective：目標復旧時点） と RTO（Recovery Time Objective：目標復旧時間） の2指標だ。
- RPO：「最後にバックアップした時点からどれだけのデータ損失を許容できるか」の上限時間。1時間ごとにバックアップしているなら、RPOは1時間になる。
- RTO：「障害発生後、どれだけの停止時間を許容できるか」。データ復元、インフラ再構築、トラフィック切り替えまで含めた全体の時間だ。
理想を言えばどちらもゼロにしたいが、RPO・RTOを下げるほどコストと複雑性は劇的に増加する。技術的にもゼロを保証することは不可能である。
実務上の重要な視点として、Newmanはシステムの部位ごとに異なるRPO/RTOを設定することを推奨している。銀行を例に挙げると、決済データは低RPO・低RTOが必須だが、新規口座申込機能は多少の停止を許容できる。ステークホルダーと「どこまでの停止・損失が事業的に許容できるか」を費用対効果の観点で議論することが先決だ。
また、RPO/RTOはSLO（Service Level Objective：サービスレベル目標、システムが満たすべき信頼性の目標値）には馴染まないとも指摘している。SLOの達成可否はSLI（Service Level Indicator：サービスレベル指標、エラーレートやレイテンシなどSLOを評価するために実測する指標値）の継続的な収集で判断するが、災害はそう頻繁に起きないためSLIを集めようがない。定期的なDRテストで代替するしかない、というのが現実的な結論だ。
4つのDRパターン：コストと復旧速度のトレードオフ
Newmanは4つのDRパターンを、複雑性とRTO/RPOの改善度が上がる順に整理している。
1. バックアップ＆リストア（最もシンプル）
定期的にデータをバックアップし、障害時に別サイトへインフラを立ち上げてデータを復元する。手順はシンプルで以下の4ステップだ。
- データを定期バックアップ（別サイトに保存）
- フェイルオーバーサイトにインフラをプロビジョニング（自動化推奨）
- バックアップからデータをリストア
- トラフィックをプライマリからフェイルオーバーへ切り替え
コストを抑えたい場合の第一選択肢だが、RTOは最長になる。データ量が多ければ復旧に数時間かかることもある。Newmanが強調するのは「定期的なテスト」の重要性で、負荷テストのタイミングに合わせてバックアップ＆リストアを実施する方法を実用的なアプローチとして挙げている。
プライマリとフェイルオーバーで同じTerraformスクリプト等を共有できる構成にしておくと、復旧手順の信頼性が大きく向上する。
2. パイロットライト
パイロットライトの本質は、データベースやコアサービスなど最も重要なコンポーネントを最小限の規模で常時稼働させておく点にある。バックアップ＆リストアがすべてのインフラをゼロから起動するのに対し、パイロットライトではコアとなる火種（ライト）が常に灯っているイメージだ。障害発生時はその周辺インフラをスケールアウトしてトラフィックを受け入れる構成になる。クロスサイトのデータレプリケーションをコアコンポーネントに対して常時行っておくため、バックアップ＆リストアと比べてRPOを大きく改善できる。一方で、常時稼働分のコストとデータレプリケーション基盤の維持が必要になる。
3. ウォームフェイルオーバー
フェイルオーバーサイトに本番と同等かそれに近い規模のインフラを常時稼働させておく。障害発生時はトラフィックを切り替えるだけでほぼ即座に復旧できるため、RTOはパイロットライトより大幅に短縮される。データはリアルタイムでレプリケーションされているため、RPOも非常に低く抑えられる。トレードオフは待機系インフラのコストで、本番相当の環境を常時維持する分だけ運用費が増加する。部分的なトラフィックをフェイルオーバーサイトで処理することでコストを一部回収するアプローチも取られることがある。
4. マルチサイトアクティブ-アクティブ（最も高コスト）
複数のサイトが同時に本番トラフィックを処理する構成だ。どのサイトで障害が発生しても、残るサイトがそのままトラフィックを引き受けるため、RTOは理論上ゼロに近い。RPOについても、アクティブなサイト間でデータが常時同期されているため最小化できる。ただし、コストと運用複雑性は4パターン中最大であり、複数サイト間のデータ整合性の担保が技術的に最大の難所となる。Newmanは、すべてのコンポーネントにこのパターンを適用する必要はなく、システムの部位ごとに異なるパターンを組み合わせることが現実的な選択肢だと指摘している。
AIシステム固有の課題：モデルが変わり、ベンダーが変わる
本書がAI時代向けに加筆した部分として、Newmanはモデルプロバイダーへの依存に特有のリスクを論じている。
GPUとCPUの供給不足は、DR計画に直接影響する。「障害時にインフラを確保できる」という前提が崩れる可能性があるため、ベンダーの制約を事前に把握し、クリティカルなサービスを優先する計画が必要になる。
さらに、AIモデルは知らないうちに変更されるという問題がある。同じAPIを叩いていても、モデルの挙動が変わっていれば出力は変わる。これはトラディショナルなサービス障害とは異なる種類の不確実性だ。Newmanが挙げる対策は以下だ。
- マルチモデル・マルチベンダー構成：特定のモデルやプロバイダーへの依存を分散させる
- コストの可視化：AIコンポーネントのコストを透明にし、ベンダー乗り換えの判断材料にする
- オブザーバビリティの確保：モデルの出力品質を継続的に監視し、劣化を検知できる仕組みを作る
- ベンダーの定期的な再評価：市場の変化が速いため、定期的にベンダーの状況を分析する
AIを組み込んだシステムにおけるインシデント事例や障害の傾向については、AI Incident Databaseでも実例が継続的に収集・公開されており、DR設計の参考になる。
AIがコードを書き、デプロイ頻度が上がり、インシデントも増える。その中でDR設計を「いつかやる課題」として放置するコストは、以前より高くなっている。
詳細はBuilding resilient AI-powered software, and planning for when things go wrongを参照していただきたい。
