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