Google Cloud アーキテクチャ フレームワークの信頼性の柱にあるこの原則では、障害が発生した場合の復元テストの設計と実行に役立つ推奨事項が示されています。
この原則は、信頼性の学習の重点分野に関連しています。
原則の概要
システムが障害から復旧できることを確認するには、リージョン フェイルオーバー、リリースのロールバック、バックアップからの復元などを含むテストを定期的に実行する必要があります。
このテストは、リージョン全体の停止など、信頼性に大きなリスクをもたらすイベントへの対応を練習するのに役立ちます。このテストは、システムが中断中に意図したとおりに動作することを確認するのにも役立ちます。
リージョン全体が停止した場合は、すべてのトラフィックを別のリージョンにフェイルオーバーする必要があります。ワークロードの通常の運用中、データが変更された場合は、プライマリ リージョンからフェイルオーバー リージョンに同期する必要があります。ユーザーがデータの損失やセッションの破損を経験しないように、複製されたデータが常に最新のものであることを確認する必要があります。また、ロード バランシング システムは、サービスを中断することなく、いつでもフェイルオーバー リージョンにトラフィックをシフトできる必要があります。リージョンの停止後のダウンタイムを最小限に抑えるため、運用エンジニアは、できるだけ短い時間でユーザー トラフィックをリージョンから手動で効率的に移行できる必要があります。このオペレーションは、リージョンのドレインと呼ばれることもあります。これは、リージョンへのインバウンド トラフィックを停止し、すべてのトラフィックを別の場所に移動することを意味します。
推奨事項
障害復旧のテストを作成し、実行する際は、次のサブセクションの推奨事項を検討してください。
テストの目的と範囲を定義する
テストで達成したいことを明確に定義します。たとえば、目標には次のものがあります。
- 目標復旧時間(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 パイプラインを使用して信頼性テストを開発ライフサイクルに統合し、フェイルオーバー テストを自動化します。
ポストモーテムでは、関係者やエンドユーザーからのフィードバックを使用して、テストプロセスとシステムの復元力を改善します。