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