信頼性テスト戦略を設計するためのアーキテクチャ戦略

この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。

信頼性テストでは、障害が発生する前にアーキテクチャの弱点をキャッチします。 障害シナリオに対する意図的なテストを行わないと、回復性パターンが実際に機能するかどうか、または定義されたターゲット内でワークロードが回復するかどうかはわかりません。

可用性に影響するセキュリティ リスク、システムを使用できなくなるパフォーマンスの問題、インシデント対応を制限する運用上のギャップをテストするときに、ワークロードの信頼性を強化します。 この記事の戦略を使用して、障害モードに対してワークロードを定期的に検証するテスト周期を確立します。 アーキテクチャの変化とインシデントによって新しい弱点が明らかになるように、テストを進化させます。 ワークロードが障害に耐え、需要に応じてスケールし、RTO と RPO の目標内で復旧できるという確信を得るとともに、継続的に信頼性体制を強化するフィードバックループを構築します。

この記事の重要な戦略は、 OE:09 のテストのためのアーキテクチャ戦略で説明されている基本的なテスト プラクティスに基づいて構築されています。 最初にその記事を確認します。 このガイドの推奨事項は、信頼性を対象としており、障害に耐え、ターゲット内で復旧するワークロードの能力に対する信頼度の達成に重点を置きます。

次の表では、この記事全体で使用される主要な信頼性用語を定義します。

定義

サービスの種類に基づいて信頼性テストスコープを定義する

信頼性テストのスコープを定義する場合は、使用するサービスの共同責任モデルを検討してください。 各サービスの種類 (IaaS、PaaS、SaaS) には、さまざまな信頼性の保証と、障害処理に対するさまざまなレベルの制御が用意されています。 自分が所有する信頼性の側面にテストを集中します。

• テストの深さは、自分の責任範囲に応じて決めましょう。 インフラストラクチャ サービス (IaaS) の場合、チームはほとんどの信頼性の決定を所有しているため、カオス エンジニアリングとフォールト インジェクションを通じて徹底的な検証に投資します。 プラットフォーム (PaaS) サービスとソフトウェア (SaaS) サービスの場合、プロバイダーは基になる信頼性の多くを管理します。 PaaS でのインフラストラクチャ フェールオーバーの処理方法、調整、サービスの低下、負荷パターンの変更など、ワークロードがそれらのサービスとどのようにやり取りするかに重点を置きます。

• 混合サービス ワークロードを考慮します。 ワークロードが複数のサービスの種類にまたがる場合、テストの責任はコンポーネントによって異なります。 可用性ゾーンの停止中に VM ベースのインフラストラクチャ コンポーネントのフェールオーバーをテストすることもできますが、高可用性のために設計された PaaS データベースのプロバイダーの保証に依存します。 これらの境界がどこにあるかを特定し、テストがそれらの間のギャップをカバーしていることを確認します。

信頼性のターゲットに対してエンド ツー エンドでテストする

SLO、RTO、RPO などの信頼性ターゲットは、障害条件下でのワークロードの動作を定義します。 個々のコンポーネントだけでなく、完全な重要なフロー全体で合格基準と不合格条件として使用します。

• 完全なフロー全体の復旧を検証します。 1 つのコンポーネントが RTO 内で復元される可能性がありますが、ダウンストリームの依存関係も復元する必要がある場合、全体的な復旧時間が目標を超える可能性があります。 問題を検出して対応する時間を含め、フロー全体の合計復旧時間を考慮します。

• SLO とエラー予算を使用してテスト スコープを定義します。 エラー予算は、フォールトインジェクションにどれだけ投じられるかを示します。 混乱テストを SLO 内に留まるように制限し、フロー復旧ターゲットを使用して各テストの境界を定義します。

重要なフローと障害モードから信頼性シナリオを構築する

ワークロード内の重要なフローと、それらに影響を与える可能性がある障害モードから始めます。 障害モード分析を使用して、最も影響の大きい障害シナリオを特定し、回復性と回復戦略を検証するテストを構築します。

影響と可能性によって優先順位を付けます。 すべての障害モードで同じテスト投資が保証されるわけではありません。 まず、ユーザーへの影響の可能性が最も高く、発生する可能性が最も高いシナリオに焦点を当てます。 障害モードの分析によって、この優先順位付けが促進されます。

フォールト トレランスと復旧メカニズムを検証する

ダウンタイムを引き起こしたり、ユーザー エクスペリエンスを低下させたりする可能性が最も高いシナリオに焦点を当てます。 このセクションの戦略を使用して、障害を処理して効果的に復旧するワークロードの能力を検証するテストを構築します。

バックアップと復元

バックアップと復元のテストでは、データ保護アプローチが復旧目標を満たしていることを検証する必要があります。

• テスト周期を確立します。 バックアップ構成、データ スキーマ、またはインフラストラクチャの変更頻度に基づいて、復元をテストする必要がある頻度を決定します。 変更の頻度が高いほど、復元テストの頻度が高くなります。

• 復旧ターゲットを設定します。 RPO と RTO のターゲットに対して実際の復元時間を測定し、バックアップ戦略が復旧目標を満たしていることを確認します。

• バックアップの完全性を想定しないでください。 データのサブセットのみをキャプチャするようにバックアップが正しく構成されていない可能性があります。 復元操作が成功したかどうかだけでなく、データの整合性と完全性を検証します。

• 分離してテストします。 運用環境とは別の環境で復元を検証し、ライブ ワークロードを中断することなく完全なチェックを実行できるようにします。

一時的な障害

一時的なネットワークの中断、短時間のサービス利用不可、接続タイムアウトなどの一時的な障害は、一般的な信頼性リスクです。 ワークロードがユーザーに影響を与えずにこれらのエラーを処理することを検証します。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。

• 所有している内容に焦点を当てます。 SDK またはプラットフォーム サービスが再試行と回線切断を自動的に処理する場合は、すべての再試行が失敗したときやサーキット ブレーカーが開いた場合など、組み込みのメカニズムが使い果たされたときに何が起こるかをテストします。

• エラー処理の構成を検証します。 ワークロードの障害処理構成を評価します。 現実的な障害条件下で、再試行ポリシー、サーキット ブレーカーのしきい値、およびタイムアウト値が想定どおりに動作することを確認します。

• 一時的な障害と永続的な障害の境界をテストします。 障害が想定されたしきい値を超えて継続する場合に、ワークロードが再試行動作からフォールバックまたは縮退へ円滑に移行することを検証します。

• 回復性機能からの一時的な障害を考慮します。 ゾーン冗長と同様の設計では、通常のフェールオーバー操作中に一時的な障害が発生することがよくあります。 たとえば、ゾーン冗長データベースでは、障害発生時にトラフィックが正常なゾーンに移行すると、一時的な接続エラーが発生する可能性があります。 ワークロードが、ユーザーに大きな影響を与えることなく、これらの予期される一時的な障害を処理できるかどうかをテストします。

ロードとスケーリングへの対応

需要の変化時にワークロードが信頼性を維持していることを検証します。急激な急増と緩やかな増加の両方です。 詳細については、 スケーリング戦略を参照してください。 ロード テストとストレス テストのガイダンスについては、「 テストの推奨事項」を参照してください。

• スケールアウトとスケールインの両方をテストします。 新しいキャパシティが十分迅速に利用可能になることと、スケールインによってリクエストが失われたり孤立したリソースが残ったりしないことを確認します。

• スケーリングの遅延を考慮してください。 スケーリングをトリガーする条件を満たすのと、新しい容量を準備するまでには、常に遅延があります。 そのギャップの間にワークロードが需要を処理できるかどうか、または追加の容量を事前にプロビジョニングする必要があるかどうかを判断します。

依存関係エラー

ワークロードは、サードパーティの API、マネージド プラットフォーム サービス、共有内部サービスなど、直接制御されていないサービスに依存している可能性があります。 ワークロードが、ユーザーに重大な中断を与えることなく、これらの依存関係のエラーを処理することを検証します。

• 依存関係を重要度別に分類します。 すべての依存関係で同じテスト投資が保証されるわけではありません。 重要なフローにあり、組み込みの冗長性またはフォールバック パスがない依存関係のテストに優先順位を付けます。

• 依存関係ごとにフォールバック動作をテストします。 依存関係が使用できなくなった場合、ワークロードは完全に失敗するのではなく、別のパスまたは動作にフォールバックする必要があります。 各フォールバックが正しくアクティブ化され、関連のない機能が引き続き機能することを確認します。

• 部分的および連鎖的な障害を考慮します。 依存関係がバイナリ形式で失敗することはめったにありません。 全面停止だけをテストしてはいけません。 待機時間の増加、断続的なエラー、データの一部の可用性をカバーします。

• 分離と障害影響範囲の封じ込めを検証する。 1 つの依存関係エラーが関連のない機能に連鎖していないことを確認します。

自己保存と回復

完全復旧が直ちに行われていない場合に、ワークロードが削減された容量で動作し続けることができるかどうかなど、 自己復旧と自己保存の設計 が誤動作にどのように応答するかを検証します。

• 自動復旧をエンドツーエンドでテストします。 ヘルス モデルを評価し、適切なチェックが含まれていることを確認します。 これらのチェックでエラーが正確に検出され、想定どおりに自動修復がトリガーされ、許容される期間内にシステムが正常な状態に戻されることを確認します。

• 手動復旧ランブックを検証します。 自動復旧では、すべてのシナリオがカバーされるわけではありません。 現実的な条件下で手動のランブックをテストし、プレッシャーのかかる状況でも、オペレーターが目標復旧時間内にそれを実行できることを確認してください。

• グレースフルデグラデーションの動作を検証します。 コンポーネントに障害が発生した場合、ワークロードは完全に停止するのではなく、機能を一部制限しながら動作を継続できるようにする必要があります。 手動レビューの要求をキューに入れるなど、縮小モードで動作できること、および低下したエクスペリエンスがユーザーに許容されることをテストします。 チームがこの状態でワークロードを運用する方法と、完全な機能を復元する方法を理解していることを確認します。

インシデントとディザスター リカバリー (DR)

インシデントや災害が発生した場合、それを迅速に検出し、効果的に対応する能力が重要です。 計画とプロセスをテストして、致命的な障害や重大なインシデントに対処していることを確認します。 運用ワークロードに影響を与えないように、DR テスト専用の環境を使用します。 詳細については、 ディザスター リカバリー計画を参照してください。

• インシデント検出メカニズムを検証します。 インシデントをシミュレートして、監視ログが必要な情報をキャプチャし、アラートが適切にトリガーされることを確認します。 たとえば、要求の失敗率がどれだけ速く検出されるか、監視データをサンプリングする頻度をテストします。

• インシデント管理プロセスをテストします。 チームがインシデント対応手順に効果的に従うことができることを確認します。 詳細については、「 インシデント対応」を参照してください。

• 完全なフェールオーバーとフェールバックをテストします。 個々の部分を分離してテストすると、実際の切り替え中にのみ発生する調整エラーを見逃す可能性があります。 DNS の切り替え、バックアップとデータ レプリケーションの整合性の復元、クライアントの再接続など、完全なフェールオーバー シーケンスを検証します。 また、プライマリ デプロイへのフェールバックもテストします。これは、多くの場合、最初の切り替えよりも複雑です。

• フェールオーバー環境で容量を検証します。 フェールオーバー環境に、負荷の下で折りたたまずにフェールオーバーの直後にトラフィックを処理できる十分な事前プロビジョニング容量があることを確認します。 スケーリング メカニズムがアクティブ化され、スケーリング アプローチが検証されている間、環境が操作を維持できることをテストします。 詳細については、「 読み込みとスケーリングの応答」を参照してください。

• 目標値に照らして測定します。 DR テストが RTO または RPO を満たしていない場合は、ギャップを分析し、それに応じて DR 計画を更新します。

• ユーザーとプロセスを検証します。 DR テストでは、通信チャネルを検証し、復旧手順を実行するために必要なアクセス権とアクセス許可をオペレーターが持っていることを確認し、DR 固有の Runbook を迅速に検出できることを確認する必要があります。

テーブルトップ演習を使用して計画をテストして評価する

Tabletop 演習は、実際のインシデントが公開される前に信頼性テストのギャップを見つけるのに役立ちます。 チームで障害シナリオをシミュレートすることで、未テストの条件を特定し、応答手順が期待どおりに動作することを検証できます。

• 現実的なインシデントをシミュレートします。 リージョンの停止やデプロイの破損などの障害シナリオについて説明し、チームに、検出、対応、復旧に必要な手順を説明します。 これらの議論では、テストによって検証されていないシステムの動作に関する前提がよく明らかになります。

• 結果をテスト ケースに変換します。 演習の中で明らかになったギャップや未知の点を活用して、新しい信頼性テストを作成します。 特定の依存関係が失敗したときにワークロードがどのように動作するかを誰も知らないとチームが検出した場合、それはテスト戦略に追加するシナリオです。

計画および計画外の停止を活用する

計画メンテナンスまたは計画外の停止によってワークロードがオフラインになっている場合には、テストを実行し、ワークロードの理解を深める、またとない機会があります。

計画的なメンテナンス

更新プログラムまたはパッチのメンテナンス期間中は、メンテナンス作業に関係のないコンポーネントとフローをテストします。 ワークロードを予期せず低下させたり、オフラインにしたりするリスクなしにテストを実行できます。 十分な時間がある場合は、作業完了後にメンテナンスに関連するコンポーネントもテストします。

計画外の停止

計画外のすべての停止は、信頼性テスト戦略を強化する機会です。 サービスを復元し、インシデントの事後レビューを完了したら、結果を使用してテストを改善します。

• 軽減策をテストします。 回避策または一時的な修正プログラムを適用した場合は、永続的な修正が実施される前に、予想される負荷を処理できることを検証します。

• 同様の弱点をスキャンします。 停止の原因になったのと同じ構成または設計パターンについて、他のコンポーネントを確認します。 同じように失敗する前に、これらのコンポーネントのテストを追加します。

さまざまな種類のテストを組み合わせる

さまざまな種類のテストを一緒に実行すると、各テストが単独で実行されるときに表示されない信頼性の問題を明らかにできます。 ワークロードは通常の条件下で特定の負荷を処理する可能性がありますが、障害が発生すると、同じ負荷によってエラーが発生します。

• 既存のテスト インフラストラクチャを再利用する。 ロード テスト用のインフラストラクチャとテスト ハーネスが既にある場合は、それを使用して混乱テストを同時に実行します。 同じテスト実行で負荷と障害の挿入を組み合わせると、需要と障害が同時に発生する現実的な条件下でワークロードがどのように動作するかを示します。

• 非運用環境で開始します。 障害モードを安全に調査できるリスクの低い環境で信頼性テストを開始します。 運用環境以外の環境から分析情報を使い果たし、ブラスト半径を制限し、迅速にロールバックするためのセーフガードを設定した後にのみ、運用テストに移行します。

フォールトインジェクションとカオスエンジニアリングを活用する

障害の挿入とカオス エンジニアリングは、意図的に障害を導入し、応答を観察することで、ワークロードの回復性に対する信頼度を高めるのに役立ちます。 実験を実行する前に、軽減策が実施されていることを確認します。

• カオス実験を定期的に実行します。 テスト スコープを評価します。 信頼できると想定しているコンポーネントやフローに障害を注入します。 アーキテクチャが変更されると、新しい障害モードが発生し、以前の想定が保持されなくなる可能性があります。 定期的に実験を実行して回帰をキャッチし、新しい依存関係を検証し、最近の変更で弱点が発生していないことを確認します。

• 失敗モード分析を使用して実験に集中します。 各実験では、特定の障害または一連の障害を対象とし、特定のコンポーネントの損失に耐える特定のフローの能力をテストするなど、明確な仮説を持つ必要があります。 実験で新しい障害モードまたは検出されていない依存関係が明らかになったら、障害モード分析を更新して最新の状態に保ちます。

• 実験中は影響範囲を抑えます。 ターゲット コンポーネントを迅速に回復し、各障害注入の影響に関する十分な情報に基づいた期待値を設定できます。 実験が範囲を超えた場合、または予期しない結果が生成された場合は、それを停止します。 意味のあるデータの収集と、ユーザーへの影響を最小限に抑えるバランスを取る。

• ベースラインに対して測定します。 各実験のフローとコンポーネントの一貫した信頼性とパフォーマンス メトリックを確立します。 低下状態メトリックをこれらのベースラインと比較して、障害の完全な影響を理解し、回復性設計がその目標を満たしているかどうかを判断します。

• 結果をテスト戦略に反映させます。 実験の結果を使用して、新しいテストの推進、復旧計画の更新、修復バックログ項目の通知を行います。 予期しない動作が発生した場合は、それらの動作の対象となるテストを作成し、修復戦略を設計します。

トレードオフ: 本番環境でのフォールトインジェクションテストは支障を来す可能性があり、ダウンタイムを引き起こす可能性もあります。 この可能性について関係者と透明性を保つ。 実験を停止して迅速にロールバックできるようにセーフガードを配置し、機密性の高い期間中にテストを実行するタイミングや回避するタイミングに関する柔軟性を維持します。 意図しない障害から保護するには、十分な 冗長性 を計画し、関係者がコストのトレードオフを理解していることを確認します。

リスク： 信頼性テストでは、さまざまな障害モードでカバレッジを拡大できますが、意味のある値が提供されなくなったら停止する必要があります。 既知の信頼性の問題のバックログが既にある場合は、テストを追加するのではなく、これらの問題の修正に優先順位を付けます。

Azureファシリテーション

Azure Test Plans は、計画的な手動テスト、ユーザー受け入れテスト、探索的テスト、利害関係者からのフィードバックの収集に必要なすべての機能を提供する、ブラウザーベースのテスト管理ソリューションです。

Azure Chaos Studio は、カオス テストを使用して、クラウド アプリケーションとサービスの回復性の測定、理解、改善に役立つマネージド サービスです。

Azure App Testing は、Azure Load Testingを使用して劇作家のワークスペースおよびパフォーマンス テストで機能テストを実行し、アプリケーションの問題を特定できるようにするサービスです。

Azure Service Health には、Azure ポータルの専用セクションである計画メンテナンス ウィンドウがあり、今後のメンテナンス アクティビティについて通知を受け取ることができます。 Azure リソースに影響する可能性があるイベントが強調表示され、事前に準備するのに役立ちます。

接続モニター は 、Azure Network Watcher の機能であり、Azure 環境とハイブリッド環境の両方にわたるネットワーク接続の合成監視とリアルタイム テストに使用できます。 カオス エンジニアリング シナリオでは、接続モニターを使用して、ターゲットネットワーク コンポーネントに障害を挿入し、待機時間やパケット損失などの主要なメトリックを継続的に測定できます。 この機能を使用すると、個々のフロー コンポーネントとエンドツーエンドのネットワーク パスの両方で、中断がネットワークの信頼性にどのように影響するかをチームが観察できます。 障害の影響を評価し、改善のための領域を特定するには、接続モニターテレメトリとベースライン メトリックを比較します。

関連リンク

• Azure アプリケーションのバックアップとディザスター リカバリー
• 信頼性テストのチェックリスト
• アプリケーションの可用性と回復性をテストする

信頼性チェックリスト

推奨事項の完全なセットを参照してください。