Google Cloud Well-Architected Framework: 信頼性

Last reviewed 2025-02-14 UTC

Google Cloud Well-Architected Framework の信頼性の柱では、 Google Cloudで信頼性の高いワークロードを設計、デプロイ、管理するための原則と推奨事項について説明します。

このドキュメントは、クラウド アーキテクト、デベロッパー、プラットフォーム エンジニア、管理者、サイト信頼性エンジニアを対象としています。

信頼性とは、定義された条件内で意図した機能を一貫して実行し、サービスを中断することなく維持するシステムの能力です。信頼性に関するベスト プラクティスには、冗長性、フォールト トレラントな設計、モニタリング、自動復旧プロセスなどがあります。

信頼性の一部である復元力とは、パフォーマンスを維持しながら、障害や予期しない中断に耐えて復旧するシステムの能力です。マルチリージョン デプロイ、自動バックアップ、障害復旧ソリューションなどの機能は、システムの復元力を高めるのに役立ちます。Google Cloud

信頼性は、次のような多くの理由からクラウド戦略にとって重要です。

  • 最小限のダウンタイム: ダウンタイムは、収益の損失、生産性の低下、評判の低下を招く可能性があります。復元力のあるアーキテクチャは、障害発生中にシステムが機能し続けるようにしたり、障害から効率的に復旧できるようにしたりするのに役立ちます。
  • ユーザー エクスペリエンスの向上: ユーザーはテクノロジーとシームレスにやり取りすることを期待しています。復元力のあるシステムは、一貫したパフォーマンスと可用性を維持し、需要の急増や予期しない問題が発生しても信頼性の高いサービスを提供できます。
  • データの整合性: 障害が発生すると、データの損失やデータの破損が発生する可能性があります。復元力のあるシステムでは、バックアップ、冗長性、レプリケーションなどのメカニズムを実装してデータを保護し、正確でアクセス可能な状態を維持します。
  • ビジネスの継続性: ビジネスの重要なオペレーションにテクノロジーを依存している。レジリエントなアーキテクチャは、致命的な障害が発生した後の継続性を保証するのに役立ちます。これにより、ビジネス機能が大幅な中断なく継続され、迅速な復旧をサポートできます。
  • コンプライアンス: 多くの業界には、システムの可用性とデータ保護に関する規制要件があります。レジリエント アーキテクチャは、システムの運用とセキュリティを維持することで、これらの標準を満たすのに役立ちます。
  • 長期的な費用の削減: 復元力のあるアーキテクチャには初期投資が必要ですが、復元力により、費用のかかるダウンタイムを回避し、事後対応の修正を回避し、リソースをより効率的に使用できるため、長期的には費用を削減できます。

組織の考え方

システムの信頼性を高めるには、計画と確立された戦略が必要です。この戦略には、他のイニシアチブとともに信頼性を優先する教育と権限が含まれている必要があります。

開発、プロダクト管理、運用、プラットフォーム エンジニアリング、サイト信頼性エンジニアリング（SRE）など、組織全体が信頼性に対して責任を負うことを明確にします。マーケティングやセールスなど、ビジネス重視のグループでも信頼性に影響する可能性があります。

すべてのチームは、アプリケーションの信頼性目標とリスクを理解する必要があります。チームはこれらの要件に責任を負う必要があります。信頼性と通常のプロダクト機能開発との間に生じる競合については、優先度を上げて対応し、適切にエスカレーションする必要があります。

すべての機能とチーム全体で信頼性を包括的に計画、管理します。信頼性に関する柱を含む Cloud Center of Excellence（CCoE）の設定を検討してください。詳細については、Cloud Center of Excellence を使用して組織のクラウド ジャーニーを最適化するをご覧ください。

信頼性の重点分野

信頼性の高いシステムを設計、デプロイ、管理するために行うアクティビティは、次の重点分野に分類できます。このピラーの信頼性に関する原則と推奨事項は、これらの重点分野のいずれかに関連しています。

  • スコープ設定: システムを理解するために、アーキテクチャの詳細な分析を行います。コンポーネント、コンポーネントの動作と相互作用、データとアクションがシステムをどのように流れるか、問題が発生する可能性のあることを理解する必要があります。潜在的な障害、ボトルネック、リスクを特定して、それらの問題を軽減するための対策を講じることができます。
  • オブザーバビリティ: システム障害を防ぐために、包括的で継続的なオブザーバビリティとモニタリングを実装します。この観察により、傾向を把握し、潜在的な問題を事前に特定できます。
  • レスポンス: 障害の影響を軽減するには、適切に対応して効率的に復旧します。自動化されたレスポンスは、障害の影響を軽減することもできます。計画と管理を行っても、障害が発生する可能性があります。
  • 学習: 障害の再発を防ぐため、各経験から学び、適切な措置を講じます。

基本原則

Well-Architected フレームワークの信頼性の柱の推奨事項は、次のコア原則にマッピングされています。

寄稿者

著者:

  • Laura Hyatt | エンタープライズ クラウド アーキテクト
  • Jose Andrade | エンタープライズ インフラストラクチャ カスタマー エンジニア
  • Gino Pelliccia | プリンシパル アーキテクト

その他の寄稿者:

ユーザー エクスペリエンスの目標に基づいて信頼性を定義する

Google Cloud Well-Architected Framework の信頼性の柱にあるこの原則は、ユーザー エクスペリエンスを評価し、検出結果を信頼性の目標と指標にマッピングするのに役立ちます。

この原則は、信頼性のスコープ設定の重点領域に関連しています。

原則の概要

オブザーバビリティ ツールは大量のデータを提供するが、そのデータのすべてがユーザーへの影響に直接関連しているわけではない。たとえば、CPU 使用率が高い、サーバー処理が遅い、タスクがクラッシュするなどの問題が発生する可能性があります。ただし、これらの問題がユーザー エクスペリエンスに影響しない場合は、サービス停止とは見なされません。

ユーザー エクスペリエンスを測定するには、内部システムの動作とユーザー向けの問題を区別する必要があります。ユーザー リクエストの成功率などの指標に重点を置きます。CPU 使用率などのサーバー中心の指標にのみ依存しないでください。サービス信頼性に関する誤った結論につながる可能性があります。真の信頼性とは、ユーザーがアプリケーションやサービスを一貫して効果的に使用できることを意味します。

推奨事項

ユーザー エクスペリエンスを効果的に測定するには、次のセクションの推奨事項を検討してください。

ユーザー エクスペリエンスを測定する

サービスの信頼性を正確に把握するには、ユーザーの実際の使用状況を反映する指標を優先します。たとえば、ユーザーのクエリ成功率、アプリケーションのレイテンシ、エラー率を測定します。

理想的には、このデータをユーザーのデバイスまたはブラウザから直接収集します。直接データ収集が不可能な場合は、システム内の測定ポイントをユーザーから徐々に遠ざけます。たとえば、ロードバランサまたはフロントエンド サービスを測定ポイントとして使用できます。このアプローチでは、問題がユーザーに大きな影響を与える前に問題を特定して対処できます。

ユーザー ジャーニーを分析する

ユーザーがシステムをどのように操作しているかを把握するには、Cloud Trace などのトレース ツールを使用します。アプリでのユーザーの操作をトレースすることで、ユーザー エクスペリエンスの低下につながるボトルネックやレイテンシの問題を見つけることができます。Cloud Trace は、サービス アーキテクチャの各ホップの詳細なパフォーマンス データをキャプチャします。このデータは、パフォーマンスの問題をより効率的に特定して対処するのに役立ち、信頼性が高く満足度の高いユーザー エクスペリエンスを実現できます。

信頼性の現実的な目標を設定する

Google Cloud Well-Architected Framework の信頼性に関する原則は、 Google Cloudのワークロードで技術的に実現可能な信頼性目標を定義するのに役立ちます。

この原則は、信頼性のスコープ設定の重点領域に関連しています。

原則の概要

ユーザーが満足できるほど十分に信頼できるシステムを設計します。直感に反するように思えますが、信頼性を 100% にするという目標は、多くの場合、最も効果的な戦略ではありません。信頼性を高めると、金銭的投資とイノベーションの制限の両面で、大幅な費用増加につながる可能性があります。ユーザーが現在のサービスレベルにすでに満足している場合、満足度をさらに高めるための取り組みは費用対効果が低くなる可能性があります。代わりに、リソースを他の場所に費やした方がよいでしょう。

ユーザーが満足できる信頼性のレベルを決定し、改善の費用がメリットを上回り始めるポイントを決定する必要があります。このレベルの十分な信頼性が確保されたら、リソースを戦略的に割り当て、ユーザーにより多くの価値をもたらす機能や改善に集中できます。

推奨事項

現実的な信頼性の目標を設定するには、次のサブセクションの推奨事項を検討してください。

一部の障害を許容し、コンポーネントに優先順位を付ける

稼働率 99.99% などの高可用性を目標としますが、稼働率 100% を目標に設定しないでください。失敗は避けられないことを認識する。

100% の稼働時間と 99.99% の目標値の差は、障害の許容範囲です。この差は、エラー バジェットと呼ばれます。エラー バジェットは、リスクを負ってイノベーションを起こすのに役立ちます。これは、競争力を維持するためにあらゆるビジネスにとって不可欠な要素です。

システムで最も重要なコンポーネントの信頼性を優先します。重要度の低いコンポーネントには、障害に対する許容度が高いことを受け入れる。

信頼性と費用のバランスを取る

システムの最適な信頼性レベルを決定するには、費用対効果を徹底的に分析します。

システム要件、障害の結果、特定のアプリケーションに対する組織のリスク許容度などの要素を考慮してください。目標復旧時間（RTO）や目標復旧時点（RPO）などの障害復旧指標を考慮してください。予算やその他の制約内で許容できる信頼性のレベルを決定します。

重要な信頼性機能に妥協することなく、効率を改善して費用を削減する方法を探します。

リソースの冗長性により高可用性システムを構築する

Google Cloud Well-Architected Framework の信頼性の柱にあるこの原則では、障害を回避するためにリソースの冗長性を計画、構築、管理するための推奨事項が示されています。

この原則は、信頼性のスコープ設定の重点領域に関連しています。

原則の概要

必要な信頼性のレベルを決定したら、単一障害点を回避するようにシステムを設計する必要があります。システム内のすべての重要なコンポーネントは、複数のマシン、ゾーン、リージョンにレプリケートする必要があります。たとえば、重要なデータベースを 1 つのリージョンにのみ配置することはできません。また、メタデータ サーバーを 1 つのゾーンまたはリージョンにのみデプロイすることはできません。これらの例では、単一のゾーンまたはリージョンが停止すると、システム全体が停止します。

推奨事項

冗長システムを構築するには、次のサブセクションの推奨事項を検討してください。

障害ドメインを特定してサービスを複製する

個々の VM からリージョンまで、システムの障害ドメインをマッピングし、障害ドメイン全体で冗長性を考慮して設計します。

高可用性を実現するには、サービスとアプリケーションを複数のゾーンとリージョンに分散して複製します。ゾーンまたはリージョンが停止した場合にサービスとアプリケーションが引き続き使用できるように、自動フェイルオーバー用にシステムを構成します。

マルチゾーン アーキテクチャとマルチリージョン アーキテクチャの例については、Google Cloud のワークロードに適した信頼性の高いインフラストラクチャを設計する Google Cloudをご覧ください。

問題を迅速に検出して対処する

障害ドメインのステータスを継続的に追跡して、問題を迅速に検出して対処します。

Google Cloud Service Health ダッシュボードを使用すると、すべてのリージョンのサービスの現在のステータスをモニタリングできます。 Google Cloud また、Personalized Service Health を使用して、プロジェクトに関連するインシデントを参照することもできます。ロードバランサを使用してリソースの健全性を検出し、正常なバックエンドにトラフィックを自動的に転送できます。詳細については、ヘルスチェックの概要をご覧ください。

フェイルオーバー シナリオをテストする

消火訓練と同様に、障害を定期的にシミュレートして、レプリケーションとフェイルオーバー戦略の効果を確認します。

詳細については、リージョン MIG のゾーンの停止をシミュレートすると GKE リージョン クラスタでゾーン障害をシミュレートするをご覧ください。

水平方向のスケーラビリティを活用する

Google Cloud Well-Architected Framework の信頼性の柱にあるこの原則では、水平方向のスケーラビリティを使用する際の推奨事項が示されています。水平スケーラビリティを使用すると、Google Cloud のワークロードを効率的にスケーリングしてパフォーマンスを維持できます。

この原則は、信頼性のスコープ設定の重点領域に関連しています。

原則の概要

システムを水平アーキテクチャに再構築します。トラフィックやデータの増加に対応するには、リソースを追加します。使用していないリソースは削除することもできます。

水平方向のスケーリングの価値を理解するには、垂直方向のスケーリングの制限事項を考慮してください。

垂直スケーリングの一般的なシナリオは、重要なデータを含むプライマリ データベースとして MySQL データベースを使用することです。データベースの使用量が増えると、より多くの RAM と CPU が必要になります。最終的には、データベースがホストマシンのメモリ上限に達し、アップグレードが必要になります。このプロセスは複数回繰り返す必要がある場合があります。問題は、データベースの増加量にハードリミットがあることです。VM サイズに上限はありません。データベースにリソースを追加できなくなる場合があります。

リソースに制限がない場合でも、大規模な VM が単一障害点になる可能性があります。プライマリ データベース VM に問題があると、エラー レスポンスが返されたり、すべてのユーザーに影響するシステム全体の停止が発生したりする可能性があります。リソースの冗長性による高可用性システムの構築で説明されているように、単一障害点は避けてください。

これらのスケーリングの上限に加えて、垂直方向のスケーリングは費用が高くなる傾向があります。コンピューティング能力とメモリ容量の大きいマシンを取得すると、費用は指数関数的に増加する可能性があります。

一方、水平方向のスケーリングでは、費用を抑えることができます。スケーリングするように設計されたシステムでは、水平方向のスケーリングの可能性は事実上無限です。

推奨事項

単一の VM アーキテクチャから水平の複数マシン アーキテクチャに移行するには、慎重に計画し、適切なツールを使用する必要があります。水平方向のスケーリングを実現するには、次のサブセクションの推奨事項を検討してください。

マネージド サービスを使用する

マネージド サービスを使用すると、水平方向のスケーリングを手動で管理する必要がなくなります。たとえば、Compute Engine マネージド インスタンス グループ（MIG）を使用すると、VM を追加または削除してアプリケーションを水平方向にスケーリングできます。コンテナ化されたアプリケーションの場合、Cloud Run は、受信トラフィックに基づいてステートレス コンテナを自動的にスケーリングできるサーバーレス プラットフォームです。

モジュラー設計を推進する

モジュラー コンポーネントと明確なインターフェースにより、アプリケーション全体をスケーリングするのではなく、必要に応じて個々のコンポーネントをスケーリングできます。詳細については、パフォーマンス最適化の柱のモジュラー設計を推進するをご覧ください。

ステートレス設計を実装する

ローカルに保存されるデータがないように、アプリケーションをステートレスに設計します。これにより、データの整合性を気にすることなくインスタンスを追加または削除できます。

オブザーバビリティを使用して潜在的な障害を検出する

Google Cloud Well-Architected Framework の信頼性に関する原則では、エラーや障害が発生する可能性のある領域を事前に特定するための推奨事項が示されています。

この原則は、信頼性の観察 の焦点領域に関連しています。

原則の概要

Google Cloudでワークロードの信頼性を維持して向上させるには、指標、ログ、トレースを使用して効果的なオブザーバビリティを実装する必要があります。

  • 指標は、特定の時間間隔でアプリのトラッキング対象とするアクティビティの定量的な測定値です。たとえば、サービスレベル指標（SLI）として使用できるリクエスト レートやエラー率などの技術的な指標を追跡できます。注文や受け取った支払いなど、アプリケーション固有のビジネス指標をトラッキングすることも必要になる場合があります。
  • ログは、アプリケーションまたはシステム内で発生する個別のイベントのタイムスタンプ付きレコードです。イベントには、障害、エラー、状態の変化などがあります。ログには指標が含まれる場合があり、SLI にログを使用することもできます。
  • トレースとは、複数の個別のアプリケーションまたはアプリケーションのコンポーネントを通過する単一のユーザーまたはトランザクションのジャーニーを表します。たとえば、これらのコンポーネントはマイクロサービスです。トレースを使用すると、ジャーニーで使用されたコンポーネント、ボトルネックの場所、ジャーニーに要した時間を追跡できます。

指標、ログ、トレースは、システムを継続的にモニタリングするのに役立ちます。包括的なモニタリングにより、エラーが発生した場所と原因を特定できます。エラーが発生する前に潜在的な障害を検出することもできます。

推奨事項

潜在的な障害を効率的に検出するには、次のサブセクションの推奨事項を検討してください。

包括的な分析情報を取得する

レスポンス時間やエラー率などの主要な指標を追跡するには、Cloud Monitoring と Cloud Logging を使用します。また、これらのツールを使用すると、指標がワークロードのニーズを常に満たしていることを確認できます。

データドリブンな意思決定を行うには、デフォルトのサービス指標を分析して、コンポーネントの依存関係と、それらがワークロードの全体的なパフォーマンスに与える影響を把握します。

モニタリング戦略をカスタマイズするには、Google Cloud SDK を使用して独自の指標を作成して公開します。

事前トラブルシューティングを行う

堅牢なエラー処理を実装し、 Google Cloudでワークロードのすべてのコンポーネントでロギングを有効にします。Cloud Storage アクセス ログや VPC フローログなどのログを有効にします。

ロギングを構成する際は、関連する費用を考慮してください。ロギング費用を制御するには、ログシンクに除外フィルタを構成して、特定のログの保存を除外します。

リソース使用率を最適化する

CPU 使用量、ネットワーク I/O 指標、ディスク I/O 指標をモニタリングして、GKE、Compute Engine、Dataproc などのサービスでプロビジョニング不足またはプロビジョニング過剰のリソースを検出します。サポートされているサービスの一覧については、Cloud Monitoring の概要をご覧ください。

アラートの優先順位付け

アラートの場合は、重要な指標に焦点を当て、適切なしきい値を設定してアラート疲労を最小限に抑え、重大な問題にタイムリーに対応できるようにします。このターゲット アプローチにより、ワークロードの信頼性を事前に維持できます。詳細については、アラートの概要をご覧ください。

グレースフル デグラデーションに対応した設計

Google Cloud Well-Architected Framework の信頼性の柱にあるこの原則では、正常に失敗するようにワークロードを設計するための推奨事項が示されています。 Google Cloud

この原則は、信頼性のレスポンス の重点分野に関連しています。

原則の概要

グレースフル デグラデーションとは、負荷が高いシステムが機能し続け、パフォーマンスや精度が低下する可能性がある設計手法です。グレースフル デグラデーションにより、システムの処理が最適でない場合でも、システムの可用性が維持され、完全な障害を防ぐことができます。負荷が管理可能なレベルに戻ると、システムは完全な機能を再開します。

たとえば、負荷が高い期間中は、Google 検索はランキングの高いウェブページの検索結果を優先するため、精度が低下する可能性があります。負荷が低下すると、Google 検索は検索結果を再計算します。

推奨事項

正常な降格のためにシステムを設計するには、次のサブセクションの推奨事項を検討してください。

スロットリングを実装する

レプリカが過負荷を独立して処理し、トラフィックの多いシナリオで受信リクエストをスロットリングできるようにします。このアプローチにより、ゾーン間のトラフィックの過剰なシフトによって発生するカスケード障害を防ぐことができます。

Apigee などのツールを使用して、トラフィックの多い時間帯の API リクエストのレートを制御します。リクエストのスケールバック方法を反映するようにポリシー ルールを構成できます。

余分なリクエストを早期にドロップする

バックエンド コンポーネントを保護するために、フロントエンド レイヤで余分なリクエストを破棄するようにシステムを構成します。一部のリクエストをドロップすると、グローバルな障害を防ぎ、システムをより適切に復元できます。このアプローチでは、一部のユーザーにエラーが発生する可能性があります。ただし、過負荷時にトラフィックのすべてがドロップされる回線切断などのアプローチとは対照的に、停止の影響を最小限に抑えることができます。

部分的なエラーと再試行を処理する

部分的なエラーと再試行をシームレスに処理するようにアプリケーションをビルドします。この設計により、高負荷のシナリオでできるだけ多くのトラフィックが処理されるようになります。

過負荷シナリオをテストする

スロットルとリクエスト ドロップ メカニズムが効果的に機能することを確認するには、システムで過負荷状態を定期的にシミュレートします。テストを行うと、実際のトラフィックの急増に備えてシステムを準備できます。

トラフィックの急増をモニタリングする

分析ツールとモニタリング ツールを使用して、トラフィックの急増が過負荷にエスカレーションする前に予測し、対応します。早期の検出と対応により、需要のピーク時でもサービスの可用性を維持できます。

障害からの復旧テストを実施する

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 パイプラインを使用して信頼性テストを開発ライフサイクルに統合し、フェイルオーバー テストを自動化します。

ポストモーテムでは、関係者やエンドユーザーからのフィードバックを使用して、テストプロセスとシステムの復元力を改善します。

データ損失からの復旧テストを実施する

Google Cloud Well-Architected Framework の信頼性の柱にあるこの原則では、データ損失からの復元のためのテストを設計して実行するための推奨事項が示されています。

この原則は、信頼性の学習の重点分野に関連しています。

原則の概要

データが失われたり破損したりした場合にシステムが復元できるようにするには、そのようなシナリオのテストを行う必要があります。データ損失は、ソフトウェアのバグや自然災害によって発生する可能性があります。このようなイベントが発生した場合は、バックアップからデータを復元し、新しく復元したデータを使用してすべてのサービスを再び起動する必要があります。

このタイプの復元テストの成功または失敗を判断するには、データの完全性、目標復旧時間（RTO）、目標復旧時点（RPO）の 3 つの基準を使用することをおすすめします。RTO と RPO の指標の詳細については、DR 計画の基本をご覧ください。

データ復元テストの目的は、組織がビジネス継続性要件を継続的に満たすことができることを定期的に確認することです。データ復元テストでは、RTO と RPO の測定に加えて、復元されたデータを使用して、アプリケーション スタック全体とすべての重要なインフラストラクチャ サービスのテストを行う必要があります。これは、デプロイされたアプリケーション全体がテスト環境で正しく動作することを確認するために必要です。

推奨事項

データ損失からの復元のためのテストを設計して実行する場合は、次のサブセクションの推奨事項を検討してください。

バックアップの整合性を確認して復元プロセスをテストする

バックアップに、復元してアプリケーションをすぐに再び使用できるように、整合性があり使用可能なデータのスナップショットが含まれていることを確認する必要があります。データの整合性を検証するには、各バックアップの後に実行される自動整合性チェックを設定します。

バックアップをテストするには、非本番環境で復元します。バックアップを効率的に復元し、復元されたデータがアプリケーション要件を満たしていることを確認するには、データ復元シナリオを定期的にシミュレートします。データ復元の手順を文書化し、障害発生時に手順を効果的に実行できるようにチームをトレーニングします。

定期的なバックアップを頻繁にスケジュールする

復元中のデータ損失を最小限に抑え、RPO 目標を達成するには、定期的にバックアップをスケジュール設定することが不可欠です。RPO に合わせてバックアップの頻度を確立します。たとえば、RPO が 15 分の場合は、少なくとも 15 分ごとに実行されるようにバックアップをスケジュールします。バックアップ間隔を最適化して、データ損失のリスクを軽減します。

Google Cloud Cloud Storage、Cloud SQL 自動バックアップ、Spanner バックアップなどのツールを使用して、バックアップのスケジュール設定と管理を行います。重要なアプリケーションの場合は、Cloud SQL のポイントインタイム リカバリ（PITR）や大規模なデータセットの増分バックアップなど、ほぼ継続的なバックアップ ソリューションを使用してください。

RPO を定義してモニタリングする

ビジネスニーズに基づいて明確な RPO を設定し、RPO の遵守状況をモニタリングします。バックアップ間隔が定義された RPO を超える場合は、Cloud Monitoring を使用してアラートを設定します。

バックアップの健全性をモニタリングする

Google Cloud Backup and DR サービスなどのツールを使用して、バックアップの状態を追跡し、安全で信頼できる場所に保存されていることを確認します。復元性を高めるために、バックアップが複数のリージョンに複製されていることを確認します。

バックアップ以外のシナリオを計画する

バックアップをアクティブ / アクティブ フェイルオーバー設定やクロスリージョン レプリケーションなどの障害復旧戦略と組み合わせることで、極端なケースでの復旧時間を短縮できます。詳細については、障害復旧計画ガイドをご覧ください。

徹底した事後分析を行う

Google Cloud Well-Architected Framework の信頼性の柱にあるこの原則では、障害やインシデントの後に効果的なポストモーテムを実施するための推奨事項が示されています。

この原則は、信頼性の学習の重点分野に関連しています。

原則の概要

事後調査は、インシデント、その影響、インシデントの軽減または解決のためにとったアクション、根本原因、インシデントの再発を防ぐためのフォローアップ アクションに関する書面の記録です。事後分析の目的は、過失から学ぶことであり、責任を割り当てることではありません。

次の図は、ポストモーテムのワークフローを示しています。

事後分析のワークフロー。

ポストモーテムのワークフローには、次のステップが含まれます。

  • 事後調査を作成する
  • 事実を把握する
  • 根本原因を特定して分析する
  • 将来を見据えて計画を立てる
  • 計画を実行する

次のような重大なイベントや重大でないイベントの後に、事後分析を行います。

  • ユーザーに見えるダウンタイムやパフォーマンスの低下が一定のしきい値を超えた。
  • あらゆる種類のデータ損失。
  • オンコール エンジニアによる介入（リリースのロールバック、トラフィックの再ルーティングなど）。
  • 定義されたしきい値を超える解決時間。
  • モニタリングの失敗（通常、これはインシデントが手動で発見されたことを意味する）

推奨事項

インシデントが発生する前に事後調査の条件を定義して、事後調査が必要なタイミングを全員が把握できるようにします。

効果的な事後検証を行うには、次のサブセクションの推奨事項を検討してください。

責任転嫁のない事後分析を行う

効果的なポストモーテムは、プロセス、ツール、テクノロジーに焦点を当て、個人やチームに責任を負わせません。事後分析の目的は、誰が悪いかを見つけることではなく、技術と将来を改善することです。誰にでも間違いはあります。目標は、間違いを分析してそこから学ぶことです。

次の例は、責任を割り当てるフィードバックと責任を割り当てないフィードバックの違いを示しています。

  • 責任を帰属させるフィードバック: 「複雑なバックエンド システム全体を書き換える必要があります。この問題は過去 3 四半期にわたって毎週発生しており、断片的に修正することに疲れていることでしょう。本当に、あと 1 回呼び出されたら自分で書き直しますよ...」
  • 非難のないフィードバック: 「バックエンド システム全体を書き換えるアクション アイテムは、実際にはこれらのページの発生を防ぐことができます。このバージョンのメンテナンス マニュアルは非常に長く、完全にトレーニングするのは非常に困難です。今後オンコール エンジニアが感謝してくれるはずです。」

対象とするすべてのユーザーがポストモーテム レポートを読めるようにする

レポートに含める予定の情報について、その情報が重要で、視聴者が状況を把握するために必要かどうかを評価します。補足データと説明は、レポートの付録に移動できます。審査担当者が追加情報を必要とした場合、リクエストできます。

複雑なソリューションや過剰に設計されたソリューションは避ける

問題の解決策を検討する前に、問題の重要性と再発の可能性を評価します。再発する可能性の低い問題を解決するためにシステムの複雑さを増やすと、不安定性が高まる可能性があります。

事後調査を可能な限り広く共有する

問題が解決しないようにするには、ポストモーテムの結果を幅広いユーザーに公開し、経営陣からサポートを得てください。事後検証の価値は、事後検証後に得られる学習に比例します。より多くの人がインシデントから学ぶことで、同様の障害が再発する可能性を低減できます。