Google Cloud Well-Architected Framework の信頼性の柱におけるこの原則では、障害発生時の復旧テストを設計して実行するうえで役立つ推奨事項が示されています。
この原則は、信頼性の学習 重点分野に関連しています。
原則の概要
システムが障害から復旧できることを確認するには、リージョン フェイルオーバー、リリースのロールバック、バックアップからのデータの復元を含むテストを定期的に実行する必要があります。
このテストは、リージョン全体の停止など、信頼性に大きなリスクをもたらすイベントに対する対応を練習するのに役立ちます。このテストは、中断中にシステムが意図したとおりに動作することを確認するのにも役立ちます。
リージョン全体が停止する可能性は低いですが、その場合はすべてのトラフィックを別のリージョンにフェイルオーバーする必要があります。ワークロードの通常のオペレーションでは、データが変更されたときに、プライマリ リージョンからフェイルオーバー リージョンに同期する必要があります。ユーザーがデータ損失やセッションの切断を経験しないように、レプリケートされたデータが常に最新であることを確認する必要があります。ロード バランシング システムは、サービスを中断することなく、いつでもフェイルオーバー リージョンにトラフィックを転送できる必要があります。リージョンで障害が発生した後のダウンタイムを最小限に抑えるには、運用エンジニアがユーザー トラフィックをリージョンから手動で効率的に移行できる必要があります。このオペレーションは、リージョンのドレインと呼ばれることもあります。これは、リージョンへのインバウンド トラフィックを停止し、すべてのトラフィックを別の場所に移動することを意味します。
推奨事項
障害復旧のテストを設計して実行する場合は、次のサブセクションの推奨事項を検討してください。
テストの目的と範囲を定義する
テストで達成したい目標を明確に定義します。たとえば、次のような目標を設定できます。
- 目標復旧時間（RTO）と目標復旧時点（RPO）を検証します。詳細については、DR 計画の基本をご覧ください。
- さまざまな障害シナリオでシステムの復元力とフォールト トレランスを評価します。
- 自動フェイルオーバー メカニズムの有効性をテストします。
テストの範囲に含めるコンポーネント、サービス、リージョンを決定します。スコープには、フロントエンド、バックエンド、データベースなどの特定のアプリケーション ティアを含めることができます。また、Cloud SQL インスタンスや GKE クラスタなどの特定の Google Cloud リソースを含めることもできます。スコープでは、サードパーティ API やクラウド相互接続などの外部依存関係も指定する必要があります。
テスト環境を準備する
適切な環境（本番環境のセットアップを複製するステージング環境またはサンドボックス環境が望ましい）を選択します。本番環境でテストを実施する場合は、自動モニタリングや手動ロールバック手順などの安全対策を準備してください。
バックアップ プランを作成します。テスト中にデータが失われないように、重要なデータベースとサービスのスナップショットまたはバックアップを作成します。自動フェイルオーバー メカニズムが失敗した場合に、チームが手動で介入できるように準備しておきます。
テストの中断を防ぐため、IAM ロール、ポリシー、フェイルオーバー構成が正しく設定されていることを確認してください。テストツールとスクリプトに必要な権限が設定されていることを確認します。
運用、DevOps、アプリケーション オーナーなどの関係者に、テストのスケジュール、範囲、潜在的な影響について通知します。関係者にテストの推定タイムラインとテスト中の想定される動作を提供します。
障害シナリオをシミュレートする
Chaos Monkey などのツールを使用して、障害を計画して実行します。カスタム スクリプトを使用して、マルチゾーン GKE クラスタのプライマリ ノードのシャットダウンや無効な Cloud SQL インスタンスなど、重要なサービスの障害をシミュレートできます。スクリプトを使用して、テストの範囲に基づいてファイアウォール ルールまたは API 制限を使用し、リージョン全体のネットワーク停止をシミュレートすることもできます。障害シナリオを段階的にエスカレーションして、さまざまな条件下でのシステム動作を観察します。
障害シナリオとともに負荷テストを導入して、停止中の実際の使用状況を再現します。バックエンド サービスが使用できない場合のフロントエンド システムの動作など、カスケード障害の影響をテストします。
構成の変更を検証し、人為的ミスに対するシステムの復元力を評価するには、構成ミスを含むテスト シナリオを使用します。たとえば、DNS フェイルオーバー設定が正しくない場合や、IAM 権限が正しくない場合にテストを実行します。
システム動作のモニタリング
ロードバランサ、ヘルスチェック、その他のメカニズムがトラフィックを再ルーティングする方法をモニタリングします。 Google Cloud Cloud Monitoring や Cloud Logging などのツールを使用して、テスト中に指標とイベントをキャプチャします。
障害シミュレーション中とシミュレーション後にレイテンシ、エラー率、スループットの変化を観察し、パフォーマンスへの全体的な影響をモニタリングします。ユーザー エクスペリエンスの低下や不整合を特定します。
サービス停止やフェイルオーバーなどの重要なイベントでログが生成され、アラートがトリガーされることを確認します。このデータを使用して、アラート システムとインシデント対応システムの有効性を検証します。
RTO と RPO に照らして復元を確認する
障害発生後にシステムが通常のオペレーションを再開するまでの時間を測定し、このデータを定義済みの RTO と比較して、ギャップを文書化します。
データの完全性と可用性が RPO と一致していることを確認します。データベースの整合性をテストするには、障害発生前後のデータベースのスナップショットまたはバックアップを比較します。
サービスの復元を評価し、ユーザーへの影響を最小限に抑えながら、すべてのサービスが機能状態に復元されていることを確認します。
結果を文書化して分析する
各テストステップ、失敗シナリオ、対応するシステム動作を文書化します。詳細な分析を行うため、タイムスタンプ、ログ、指標を含めます。
テスト中に確認されたボトルネック、単一障害点、予期しない動作をハイライトします。修正の優先順位付けに役立つよう、問題の重大度と影響度で分類します。
システム アーキテクチャ、フェイルオーバー メカニズム、モニタリング設定の改善を提案します。テストの結果に基づいて、関連するフェイルオーバー ポリシーとプレイブックを更新します。事後調査レポートを関係者に提示します。レポートには、結果、学んだこと、次のステップをまとめる必要があります。詳細については、徹底的な事後分析を実施するをご覧ください。
反復処理と改善
継続的な信頼性と復元力を検証するには、定期的なテスト（四半期ごとなど）を計画します。
インフラストラクチャの変更、ソフトウェアの更新、トラフィック負荷の増加など、さまざまなシナリオでテストを実行します。
CI/CD パイプラインを使用して信頼性テストを開発ライフサイクルに統合し、フェイルオーバー テストを自動化します。
事後分析では、関係者やエンドユーザーからのフィードバックを使用して、テストプロセスとシステムの復元力を改善します。