信頼性テスト戦略を設計するための推奨事項

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

このガイドでは、ワークロードの信頼性を検証して最適化するための信頼性テスト戦略を設計するための推奨事項について説明します。 信頼性テストでは、ワークロードの回復性と可用性、特にソリューションの設計時に特定する重要なフローに焦点を当てています。 このガイドでは、障害の挿入とカオス エンジニアリングに固有の一般的なテスト ガイダンスとガイダンスを提供します。

定義

主要な設計戦略

一般的なテスト ガイダンス

• 既存のしきい値、ターゲット、前提条件を検証するためのテストを定期的に実行します。 ワークロードで大きな変更が発生した場合は、定期的なテストを実行します。 テスト環境とステージング環境でほとんどのテストを実行します。 運用システムに対してテストのサブセットを実行することも有益です。 運用環境で主要なテスト環境の 1 対 1 のパリティを計画します。

• テストを自動化して、一貫したテスト カバレッジと再現性を確保します。 頻繁に行うテスト タスクは自動化し、そのテストをビルド プロセスに統合します。 ソフトウェアを手動でテストするのは面倒で、エラーの影響を受けやすくなりますが、手動探索的テストを行うことができます。 自動テストを開発する必要がある場合は、手動テストを使用して、開発するテストの範囲を決定します。

• 開発サイクルの早い段階で回復性と可用性のテストを実行するには、シフトレフト テスト アプローチを採用します。

• 簡単なドキュメント形式を調整して、すべての通常のテストのプロセスと結果を誰もが簡単に理解できるようにします。

• 運用チーム、テクノロジ リーダー、ビジネス関係者、ディザスター リカバリーの利害関係者など、文書化された結果を適切なチームと共有します。 結果は、サービス レベル目標 (SLO)、サービス レベル アグリーメント (SLA)、復旧時間目標 (RTO)、回復ポイント目標 (RPO) などの信頼性目標の絞り込みを通知する必要があります。

• バックアップの定期的なテスト周期を作成します。 分離システムにデータを復元して、バックアップが有効であり、復元が機能していることを確認します。

• 復旧時間のメトリックを文書化し、ディザスター リカバリー関係者と共有して、復旧に対する期待が適切であることを確認します。

• 業界標準の デプロイ テスト手順 を使用して、自動化された予測可能で効率的なデプロイ プロセスを確実に行うことができます。

• 一時的な障害に耐えるワークロードの機能をテストします。 詳細については、「 一時的な障害を処理するための推奨事項」を参照してください。

• 負荷パターンの変化と使用量の急増に対応するワークロードの機能をテストします。 この情報は、 スケーリング戦略のテストに役立ちます。 ロード テストとストレス テストの詳細については、「テスト の推奨事項」を参照してください。

• 障害挿入を使用して、ワークロードが依存サービスまたはその他の依存関係の障害を処理する方法をテストします。

• 自己修復および自己保存設計が誤動作にどのように応答するかをテストして検証します。 自動および手動の復旧操作をテストします。

• 致命的な障害やその他の重大なインシデントに対応するために、 ディザスター リカバリー計画 をテストします。

• 障害の挿入を使用して、ワークロードの機能を適切に低下させ、コンポーネントの誤動作の爆発半径を最小限に抑える能力をテストします。

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

計画メンテナンスや計画外の停止が原因でワークロードがオフラインになっている場合は、テストを実行し、ワークロードの理解を向上させる独自の機会があります。 次のセクションでは、各シナリオに関する推奨事項を示します。

Azure の計画メンテナンス

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

計画外の停止

すべての停止インシデントを、ワークロードの詳細を確認し、優先順位に従って次の手順に従って回復性を向上させる機会として使用します。

• 顧客のためにワークロードをオンラインに戻します。 これを行うには、問題の回避策を実行するか、問題を解決するか、復旧プロセスを開始します。

• 停止の根本原因を特定し、対処します。 調査の一環として根本原因を修正できる場合は、根本原因とその修正にかかった対策を文書化します。 問題が後で追加のメンテナンス期間を取る必要がある場合は、十分にテストすることで、軽減策で予想される負荷を処理できることを確認します。 軽減策をカバーするための十分な監視が設定されていることを確認します。

• 該当する場合は、ワークロード内のすべてのコンポーネントで、同様の問題の影響を受ける可能性がある同じ問題または構成の弱点を探します。 この機会を利用して、これらのコンポーネントに事前に対処します。 インシデント履歴を調べ、ワークロード全体で同様の問題のパターンを検出します。

• 結果を使用してテスト戦略を改善します。 同じエラーを直接テストして、根本原因と同様の問題に正常に対処したことを確認します。

フォールト インジェクションとカオス エンジニアリングのガイダンス

フォールト インジェクション テストは、コンポーネントの障害に対応するワークロードの能力を強調することで、カオス エンジニアリングの原則に従います。 実稼働前環境と運用環境でフォールト インジェクション テストを実行します。 インフラストラクチャ層とアプリケーション 層にテストを適用する。 エラー モード分析を実行するための推奨事項について学習した情報を適用して、優先順位を付けた障害のみをテストし、障害に対処する軽減戦略があることを確認します。 カオス エンジニアリングの主なガイドラインは次のとおりです。

• プロアクティブに行う。 エラーが発生するのを待つ必要はありません。 運用環境に影響を与える前に、カオス実験を行って問題を検出して修正することで、障害を予測してみてください。

• 障害に対応する。 システムで発生したエラーを受け入れて学習します。 障害を複雑なシステムの自然な部分として見て、システムの信頼性を学習して向上させる機会として使用します。

• システムを中断する。 システムに障害やストレスを意図的に挿入して、回復性をテストします。 実際の障害や中断をシミュレートして、ワークロードの回復機能をテストして改善します。

• 単一障害点を早期に特定して対処する。 テスト中に、 エラー モード分析 を参照して更新し、ドキュメントのエラーを検証して対処します。 冗長性やセグメント化などの信頼性アプローチを適用して、ワークロードの可用性を向上させ、ダウンタイムを最小限に抑えます。

• ガードレールとグレースフルな軽減策を導入する。 可用性を向上させるために、サーキット ブレーカー パターンや調整パターンなどの安全対策を実装します。 障害発生時のビジネス継続性を可能にする適切な劣化アプローチを実装します。

• 爆発半径を最小限に抑える。 障害が発生した場合でも、そのスコープが制限されるように、障害分離戦略を実装します。 システムは、顧客への影響を最小限に抑えて引き続き機能します。

• 免疫を作る。 カオス エンジニアリング実験を使用して、障害を防ぎ、障害から回復するワークロードの能力を向上させます。

カオス エンジニアリングは、ワークロード チームカルチャの不可欠な部分であり、継続的なプラクティスであり、単一の停止に対応する短期的な戦術的な取り組みではありません。 カオス実験を設計するときは、次の標準的な方法に従います。

1. 仮説から始めます。 各実験には、特定のコンポーネントの損失に耐える特定のフローの能力をテストするなどの明確な目標が必要です。
2. ベースラインの動作を測定します。 実験の実行時に低下状態と比較するために、特定の実験に関連するフローとコンポーネントの信頼性とパフォーマンスのメトリックが一貫していることを確認します。
3. 1 つまたは複数の障害を挿入します。 実験では、迅速に回復できる特定のコンポーネントを意図的にターゲットにする必要があります。また、障害の注入によって実験の爆発半径を制御するのに役立つ影響について、情報に基づいた期待を持っている必要があります。
4. 結果として発生する動作を監視します。 個々のフロー コンポーネントと、障害の影響を適切に理解するために実験がターゲットとするエンドツーエンドのフロー動作に関するテレメトリを収集します。 収集したメトリックとベースライン メトリックを比較して、障害の挿入結果の全体像を確認します。
5. プロセスと観測された内容を文書化します。 実験の詳細な記録を保持すると、ワークロード設計に関する将来の決定が通知され、時間の経過とともに明らかになったギャップに確実に対処できます。
6. 結果を特定し、対応します。 改善としてワークロード バックログに追加できる修復手順を計画します。 他のデプロイと同じプロセスに従って、非運用環境で設計改善計画がレビューおよびテストされていることを確認します。

プロセス、アーキテクチャの選択、コードを定期的に検証して、技術的負債をすばやく検出し、新しいテクノロジを統合し、変化する要件に適応します。

フォールト インジェクション実験を行う場合、次の手順を実行します。

• 監視が実施され、アラートが設定されていることを確認します。
• インシデントの所有権を取得するために直接責任のある個人 (DRI) を割り当てるプロセスを検証します。
• ドキュメントと調査プロセスが最新であることを確認します。

次の推奨事項と考慮事項を統合して、カオス テスト戦略を最適化します。

• システムの想定に挑戦する。 テストでは、ワークロードの回復性とワークロード設計戦略を改善しようとします。 過去のエクスペリエンスに基づいて信頼性が高いコンポーネントとフローに障害を挿入する機会を探します。 新しいワークロードでは信頼できない可能性があります。

• トポロジ、プラットフォーム、リソースなどの変更を検証します。 フォールト インジェクション テストを含む徹底的なテストを行わないと、変更が行われた後にワークロードの不完全な画像が表示される可能性があります。 たとえば、すぐには明らかではない方法で、誤って新しい依存関係を導入したり、既存の依存関係を壊したりする可能性があります。

• SLA バッファーを使用します。 混乱テストを制限して SLA 内に留まり、停止による潜在的な評判や財務上の影響を回避します。 フローとコンポーネントの復旧ターゲットは、テストのスコープを定義するのに役立ちます。

• カオスとフォールト挿入への投資としてエラー バジェットを設定します。 エラー予算は、SLO の 100% を達成することと、合意された SLO を達成することの違いです。

• スコープを超えた場合は、実験を停止します。 不明な結果が、カオス実験の予想される結果です。 影響を受ける運用ユーザー数を可能な限り抑えながら実質的な結果データを収集できるようにうまく調整します。

• 開発チームと緊密に連携して、挿入された障害の関連性を確認します。 過去のインシデントまたは問題をガイドとして使用します。 依存関係を確認し、それらの依存関係を削除するときに結果を評価します。

• カオス テストによって明らかにされたワークロード内のさまざまなコンポーネント間で、以前に検出されなかった依存関係を特定して文書化します。

• カオス テスト中に検出された依存関係を考慮して、必要に応じて復旧計画を調整します。

• 実験とテストの結果を、新しい実験とテストの基礎として使用します。 予期しない動作が発生すると、新しいテストでこれらの動作が直接ターゲットになり、修復戦略を設計する機会が得られます。

トレードオフ: 運用環境でのフォールト インジェクション テストは中断する可能性があり、ダウンタイムを引き起こす可能性があります。 この可能性について関係者に対して透明性を保ち、実験を終了し、計画をロールバックして、導入した障害を迅速に取り消すための保護措置を講じてください。 運用環境での意図しない停止から保護するには、十分な 冗長性 を計画し、利害関係者がコストのトレードオフを理解していることを確認します。

Azure ファシリテーション

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

Azure Chaos Studio は、カオス エンジニアリングを使って、クラウド アプリケーションとサービスの回復性を測定、把握、改善するのに役立つマネージド サービスです。 Azure Chaos Studio は Ignite 2023 で一般提供に達し、Azure インフラストラクチャを使用してアプリケーションのフォールト インジェクションと回復性テストを開始するのに役立つ多くの機能を備えています。

関連リンク

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

信頼性チェックリスト

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