信頼性テスト戦略を設計するための推奨事項
この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。
| RE:08 | テスト環境と運用環境でカオス エンジニアリングの原則を適用して、回復性と可用性のシナリオをテストします。 テストを使用し、意図的な誤作動とシミュレートされたロード テストを実行することで、グレースフル デグラデーションの実装とスケーリング戦略が効果的なことを確認します。 |
|---|
このガイドでは、ワークロードの信頼性を検証して最適化する、信頼性テスト戦略を設計するための推奨事項について説明します。 信頼性テストでは、ワークロードの回復性と可用性、特にソリューションの設計時に特定する重要なフローに焦点を当てます。 このガイドでは、一般的なテスト ガイダンスと、フォールト挿入およびカオス エンジニアリングに固有のガイダンスを提供します。
定義
| 相談 | 定義 |
|---|---|
| 可用性 | アプリケーション ワークロードが重大なダウンタイムなしで、正常な状態において実行される時間。 |
| カオス エンジニアリング | アプリケーションとサービスを、実際のストレスと障害にさらすプラクティス。 カオス エンジニアリングのゴールは、信頼性の低い条件と不足している依存関係に対する回復性を構築して検証することです。 |
| フォールト挿入 | システムの回復性をテストするために、システムにエラーを導入する行為。 |
| 回復性 | 回復性の同意語。 |
| 回復性 | 障害モードに耐えて復旧する、アプリケーション ワークロードの能力。 |
主要な設計戦略
信頼性の準備状況をテストする
テストを定期的に実行して、既存のしきい値、ターゲット、前提条件を検証します。 ワークロードで大きな変更が発生した場合は、定期的なテストを実行します。 テスト環境とステージング環境でほとんどのテストを実行します。 運用システムに対してテストのサブセットを実行することも有益です。 主要なテスト環境と運用環境との 1 対 1 のパリティを計画します。
テストを自動化して、一貫したテスト カバレッジと再現性を確保します。 頻繁に行うテスト タスクは自動化し、そのテストをビルド プロセスに統合します。 ソフトウェアを手動でテストするのは面倒で、エラーの影響を受けやすくなりますが、手動の探索的テストは実施しても構いません。 自動テストを開発する必要がある場合は、手動テストを使用して、開発するテストの範囲を決定します。
シフト レフトのテスト アプローチを採用して、開発サイクルにおける早い段階で回復性と可用性のテストを実行します。
簡単なドキュメント形式を適応させて、すべてのユーザーがすべての定期的なテストのプロセスと結果を簡単に理解できるようにします。
文書化された結果を、運用チーム、テクノロジ リーダーシップ、ビジネスの利害関係者、ディザスター リカバリーの利害関係者など、適切なチームと共有します。 その結果は、サービス レベル目標 (SLO)、サービス レベル アグリーメント (SLA)、目標復旧時間 (RTO)、目標復旧時点 (RPO) など、信頼性目標の改善に反映させる必要があります。
バックアップの定期的なテスト頻度を作成します。 バックアップが有効であり、復元が機能していることを確認するために、分離されたシステムにデータを復元します。
復旧時間のメトリックを文書化し、ディザスター リカバリーの利害関係者と共有して、復旧に対する期待値が適切であることを確認します。
業界標準のデプロイ テスト手順を使用して、自動化された、予測可能で、効率的なデプロイ プロセスを確保します。
一時的な障害に耐えるワークロードの能力をテストします。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
負荷パターンにおける変化と、使用量におけるスパイクに対応するワークロードの能力をテストします。 この情報を使用して、スケーリング戦略をテストするのに役立てます。 ロードおよびストレス テストの詳細については、テストに関する推奨事項を参照してください。
フォールト挿入を使用して、依存サービスまたはその他の依存関係内のエラーをワークロードで処理する方法をテストします。
自己修復および自己保存の設計が、誤動作にどのように対応するかをテストして検証します。 自動および手動の復旧操作をテストします。
致命的な障害やその他の重大なインシデントに対応するためにディザスター リカバリー計画をテストします。
フォールト挿入を使用して、段階的に機能を低下させ、コンポーネント誤動作の影響範囲を最小限に抑えるワークロードの能力をテストします。
計画および計画外の停止を活用する
計画メンテナンスまたは計画外の停止によってワークロードがオフラインになっている場合には、テストを実行し、ワークロードの理解を深める、またとない機会があります。 次のセクションでは、各シナリオに関する推奨事項を示します。
定期的なメンテナンス
更新プログラムまたはパッチの計画メンテナンス期間がある場合、そのメンテナンス作業に関係のないコンポーネントとフローをテストできます。 ワークロードが予期せず機能低下したり、完全にオフラインになったりする潜在的なリスクを負わずにテストを実行します。 メンテナンス期間中に十分な時間がある場合は、メンテナンス作業の完了後に、メンテナンスに関係するコンポーネントとフローもテストできます。
計画外の停止
すべての停止インシデントを、ワークロードの詳細を確認し、優先順位と次の手順に従って、その回復性を向上させる機会として使用します。
顧客のためにワークロードをオンラインに戻します。 これを行うには、問題の回避策を実行する、問題を解決する、または復旧プロセスを開始する場合があります。
停止の根本原因を特定し、それに対処します。 調査の一環として根本原因を修正できる場合は、その根本原因と、それを修正するために行った対策を文書化します。 その問題に、後で追加のメンテナンス期間が必要な場合は、綿密にテストすることで、その軽減策が予想される負荷を処理できることを確認します。 軽減策を扱うのに十分な監視が設定されていることを確認します。
該当する場合は、ワークロード内のすべてのコンポーネントにわたって、同じ問題、または同様の問題により影響を受ける可能性がある構成の弱点を探します。 この機会を利用し、事前対策的にそれらのコンポーネントに対処します。 インシデント履歴を調べて、ワークロード全体で同様の問題のパターンを検出します。
調査結果を使用して、テスト戦略を改善します。 同じ障害を直接テストして、根本原因と同様の問題に正常に対処したことを確認します。
フォールト挿入とカオス エンジニアリングを使用する
フォールト挿入テストは、コンポーネントの障害に対応するワークロードの能力を強調することで、カオス エンジニアリングの原則に従います。 運用前および運用環境内で、フォールト挿入テストを実行します。 テストはインフラストラクチャおよびアプリケーションのレイヤーに適用されます。 「障害モード分析を実行するための推奨事項」で学習した情報を適用して、優先順位を付けた障害のみをテストし、障害に対処する軽減戦略があることを確認します。 カオス エンジニアリングの主なガイドラインは次のとおりです。
プロアクティブに行う。 障害が発生するまで待つ必要はありません。 カオス実験を実施して障害を予測し、運用環境に影響を与える前に問題を検出して修正します。
障害に対応する。 システム内で発生した障害を受け入れて、そこから学びます。 障害を複雑なシステムの自然な部分とみなし、それをシステムの信頼性を学習して向上させる機会として使用します。
システムを中断する。 システム内に意図的に障害またはストレスを挿入して、その回復性をテストします。 実際の障害や中断をシミュレートし、ワークロードの復旧機能をテストして改善します。
単一障害点を早期に特定して対処する。 テストする際に、障害モード分析を調べて更新し、ドキュメント内の障害を検証して対処します。 冗長性やセグメント化などの信頼性アプローチを適用し、ワークロードの可用性を向上させて、ダウンタイムを最小限に抑えます。
ガードレールとグレースフルな軽減策を導入する。 サーキット ブレーカー パターンまたは調整パターンなどの安全対策を実装して、可用性を高めます。 障害発生中にビジネス継続性を実現できるようにする、グレースフル デグラデーションのアプローチを実装します。
爆発半径を最小限に抑える。 障害分離戦略を実装して、たとえ障害が発生した場合でも、その範囲が制限されることを確認します。 システムは、顧客に対する影響を最小限に抑えながら、引き続き機能します。
免疫を作る。 カオス エンジニアリング実験を使用して、障害を防ぎ、障害から復旧するワークロードの能力を向上させます。
カオス エンジニアリングは、一度の停止に対応する短期の戦術的な取り組みではなく、ワークロード チームの文化と継続的なプラクティスの不可欠な部分です。 カオス実験を設計する際は、次の標準的な方法に従います。
- 仮説から始めます。 各実験には、特定のコンポーネントの損失に耐える特定のフローの能力をテストする、などの明確なゴールが必要です。
- ベースラインの動作を測定します。 実験の実行時に機能低下状態と比較するために、特定の実験に関係するフローとコンポーネントの、信頼性およびパフォーマンスのメトリックが一貫していることを確認します。
- 1 つまたは複数の障害を挿入します。 この実験では、迅速に回復できる固有のコンポーネントを意図的にターゲットにする必要があり、実験の影響範囲の制御に役立つ、フォールト挿入によって引き起こされる影響について、十分な情報に基づいて予測する必要があります。
- 結果として発生する動作を監視します。 個々のフロー コンポーネントと、実験がターゲットとするエンドツーエンドのフロー動作に関するテレメトリを収集して、障害の影響を適切に理解します。 収集したメトリックをベースライン メトリックと比較して、フォールト挿入結果の全体像を確認します。
- プロセスと観測された内容を文書化します。 実験の詳細な記録を保持することで、ワークロードの設計に関する将来の決定に反映させ、時間の経過と共に明らかになったギャップに確実に対処します。
- 結果を特定し、対応します。 改善点として、ワークロードのバックログに追加できる修復手順を計画します。 他のデプロイと同じプロセスに従って、非運用環境内で設計改善計画がレビューおよびテストされていることを確認します。
プロセス、アーキテクチャの選択、コードを定期的に検証し、技術的負債をすばやく検出して、新しいテクノロジを統合し、変化する要件に適応します。
フォールト挿入実験を実施する場合は、次の手順を実行します。
- 監視が実施され、アラートが設定されていることを確認します。
- インシデントの所有権を取得する直接責任者 (DRI) を割り当てるプロセスを検証します。
- ドキュメントおよび調査プロセスが最新であることを確認します。
次の推奨事項と考慮事項を統合して、カオス テスト戦略を最適化します。
システムの想定に挑戦する。 テストでは、ワークロードの回復性とワークロード設計戦略を改善しようとします。 過去の経験に基づいて、信頼性が高いと推測されるコンポーネントとフローの中に障害を挿入する機会を探します。 新しいワークロードでは信頼できない可能性があります。
トポロジ、プラットフォーム、リソースなどの変更を検証します。 フォールト挿入テストを含む綿密なテストを行わないと、変更が加えられた後にワークロードが不完全な状態になる場合があります。 たとえば、すぐにはわからない方法で、誤って新しい依存関係を導入してしまう、または既存の依存関係を壊してしまう場合があります。
SLA バッファーを使用します。 カオス テストを制限して SLA 内に留まるようにし、停止による評判や財務上への潜在的な影響を回避します。 フローとコンポーネントの復旧目標は、テストの範囲を定義するのに役立ちます。
カオスとフォールト挿入への投資としてエラー バジェットを設定します。 エラー バジェットは、100% の SLO を達成する場合と、合意された SLO を達成する場合の差です。
範囲を超えた場合は実験を停止します。 不明な結果が、カオス実験の予想される結果です。 影響を受ける運用ユーザー数を可能な限り抑えながら実質的な結果データを収集できるようにうまく調整します。
開発チームと緊密に連携して、挿入された障害の関連性を確認します。 過去のインシデントまたは問題をガイドとして使用します。 依存関係を調べて、それらの依存関係を削除する際に結果を評価します。
カオス テストによって明らかにされたワークロード内のさまざまなコンポーネント間で、以前に検出されなかった依存関係を特定して文書化します。
カオス テスト中に検出された依存関係を考慮して、必要に応じて復旧計画を調整します。
実験とテストの結果を、新しい実験とテストの基礎として使用します。 予期しない動作が発生すると、新しいテストでそれらの動作を直接ターゲットとし、それらの修復戦略を設計する機会を得られる場合があります。
トレードオフ: 運用環境内でのフォールト挿入テストは中断を招き、ダウンタイムを発生させる可能性があります。 この可能性について、利害関係者に対して透明性を保ち、実験を終了するためのセーフガードが講じられていること、および導入した障害を迅速に元に戻すためのロールバック計画があることを確認します。 運用環境内での意図しない停止を防ぐには、十分な冗長性を計画すること、および利害関係者がトレードオフのコストを理解することを確認します。
Azure ファシリテーション
Azure Test Plans は、計画的な手動テスト、ユーザー受け入れテスト、探索的テスト、利害関係者からのフィードバックの収集に必要なすべての機能を提供する、使いやすいブラウザーベースのテスト管理ソリューションです。
Azure Chaos Studio は、カオス エンジニアリングを使って、クラウド アプリケーションとサービスの回復性を測定、把握、改善するのに役立つマネージド サービスです。 Azure Chaos Studio は Ignite 2023 で一般提供され、Azure インフラストラクチャを使用してアプリケーションのフォールト挿入と回復性テストを開始するのに役立つ多くの機能を備えています。
関連リンク
信頼性チェックリスト
レコメンデーションの完全なセットを参照してください。