信頼性成熟度モデル

最適化タスクに時間を費やすのではなく、ワークロードインフラストラクチャと運用における回復性の確かな基礎を確立します。

成熟度モデルのレベル 1 は、ワークロード チームがシステムの信頼性のための強力な基盤を構築できるように設計されています。 ブートストラップに焦点を当てています。これは、将来の信頼性の決定のための基本を設定するプロセスです。 この段階では、ほとんどの場合、現在のプラクティスに対するマイナーな拡張機能を使用した機能実装が含まれます。

このステージには、システムの調査、分析情報の取得、およびインベントリの作成が含まれます。 また、すぐに改善するためにゾーンの冗長性を有効にするような、Azure の組み込みの信頼性機能も使用します。

これらの基本を確立することで、信頼性成熟度モデルのレベルを進め、システムの回復性とパフォーマンスを段階的に強化するようにチームを準備できます。

主な戦略

✓ 運用責任を軽減する機会を評価する

この戦略は、基本的に ビルド と 購入または依存 のアプローチです。 この決定は、将来の開発をサポートしながら、この段階でどの程度の責任を管理できるかによって異なります。 ワークロードに関連するリソースを使用する必要がありますが、メンテナンスをオフロードする機会を常に検討する必要があります。 このアプローチを適用する従来のユース ケースをいくつか次に示します。

• サービスとしてのプラットフォーム (PaaS) ソリューションを選択して、クラウド プラットフォームに責任をオフロードします。 レプリケーション、フェールオーバー、バックアップ ストアなど、一般的な回復性のニーズに対応する既製のソリューションを提供します。 このアプローチを使用すると、クラウド プロバイダーがホスティング、メンテナンス、回復性の向上を処理します。

  たとえば、クラウド プロバイダーは複数のコンピューティング ノードにデータをレプリケートし、レプリカを可用性ゾーンに分散します。 仮想マシン (VM) 上に独自のソリューションを構築する場合は、これらの側面を自分で管理する必要があります。これには時間がかかり、複雑になる可能性があります。

• ワークロードのビジネス目標に直接関連付けられていない操作の責任をオフロードします。 データベース管理やセキュリティなど、一部の特殊な操作は、ワークロードの信頼性に影響する可能性があります。 経験豊富なチーム、テクノロジ、またはその両方がこれらのタスクを処理する可能性を探ります。

  たとえば、チームにデータベースの専門知識がない場合は、マネージド サービスを使用して、プロバイダーに責任を移します。 このアプローチは、チームがワークロードの機能に集中できるため、最初に役立ちます。 多くの企業は、一元管理されたサービスを共有しています。 プラットフォーム チームが使用可能な場合は、それらを使用してこれらの操作を処理します。 ただし、このアプローチでは、依存関係と組織の複雑さが増す可能性があります。

  または、チームが適切な専門知識を持っている場合は、スキルを使用し、管理機能を含まないサービスを選択することを明示的に決定できます。

• Microsoft 以外のベンダーに責任をオフロードします。 出発点として既製の製品を選択します。 ワークロードのビジネス価値に貢献する場合にのみ、カスタマイズされたソリューションを構築します。

リスク：購入または依存オプションが要件を部分的に満たしている場合は、カスタム拡張機能の実装が必要になる場合があります。 この方法では、更新と最新化が実用的でなくなる "カスタマイズ ロックイン" 状況が発生する可能性があります。 要件を定期的に確認し、ソリューションの機能と比較します。 2 つの間に有意な偏差がある場合の出口戦略を作成します。

逆のシナリオもリスクです。 最初は 購入または依存 オプションの方が簡単に見えるかもしれませんが、PaaS サービス、ベンダー ソリューション、またはプラットフォーム所有のリソースの制限がワークロードに必要な粒度またはレベルの自律性を満たしていない場合は、後で再評価と再設計が必要になる場合があります。

✓ 重要なユーザーフローとシステムフローを特定する

この段階では、ワークロードをフローに分割することが重要です。 ユーザー フローとシステム フローに焦点を当てます。 ユーザー フローはユーザーの操作を決定し、システム フローはユーザー タスクに直接関連付けられていないワークロード コンポーネント間の通信を決定します。

たとえば、eコマース アプリケーションでは、顧客は閲覧や注文などのフロントエンド アクティビティを実行します。 一方、バックエンド トランザクションとシステムによってトリガーされるプロセスは、ユーザー要求を満たし、他のタスクを処理します。 これらの個別のフローは同じシステムの一部ですが、異なるコンポーネントを含み、さまざまな目的に対応します。

この段階でフローのカタログの作成を開始します。 ユーザーの操作とコンポーネントの通信を観察します。 フローを一覧表示して分類し、その始点と終点を定義し、依存関係をメモします。 わかりやすくするために、図を使用して結果と例外を文書化します。 このカタログは、ビジネス利害関係者との最初の会話の重要なツールとして機能し、最も重要な側面をその観点から特定できます。 この会話は、優先順位付けの第 1 レベルを通知できます。

主要なビジネス アクティビティに対するリスクと影響を評価して、フローをクリティカルとして分類します。 停止が予想される場合、グレースフル デグラデーションでは、これらの重要なフローを維持することに重点が置かれます。 eコマースの例では、重要なフローには、製品検索、カートへの項目の追加、およびチェックアウトが含まれます。これらのタスクはビジネスに不可欠であるためです。 製品データの更新や製品イメージの保守など、他のプロセスはそれほど重要ではありません。 ユーザーが製品を検索し続け、カートに項目を追加できるようにすることで、収益の損失を防ぐために、停止中も重要なフローが動作し続けられるようにします。

詳細については、「 Azure Well-Architected Framework: フローを使用してワークロード設計を最適化する」を参照してください。

✓ 適切な設計モデル、リソース、機能を選択する

この戦略は、次のレベルで適用する必要があります。

• 建築： ワークロード設計では、さまざまなインフラストラクチャ レイヤーでの信頼性の期待を考慮する必要があります。 最初の決定は、アプリケーションをホストするためのコンテナー化と PaaS のどちらを選択するかです。 または、ハブアンドスポークや単一の仮想ネットワークなどのネットワーク設定を検討することもできます。

  機能に基づいてセグメント化を作成する境界も設定する必要があります。 たとえば、単一ゾーンの仮想ディスクを使用して 1 つの VM 上のすべてをホストする代わりに、コンピューティングとデータ ストレージを分割し、専用サービスを使用することを検討してください。

  注意事項

  移行シナリオでは、新しい機会を確認せずにリフト アンド シフト アプローチを採用すると、メリットと非効率性が見逃される可能性があります。 変更が困難なセットアップに行き詰まらないようにし、より優れたオプションと改善点を活用するために、最新化を早期に調査することが重要です。

• Azure サービス: デシジョン ツリーを使用すると、設計に適したサービスを選択するのに役立ちます。 ワークロードの進化とより多くの機能の要求に応じてサービスを切り替えることができるように、現在のニーズを満たすが柔軟性を維持するコンポーネントを選択します。

• Azure サービス内の SKU または階層: 各 SKU の機能を確認し、プラットフォームの可用性の保証を理解します。 サービスレベル アグリーメントを評価して、公開されたパーセンタイルに関連する対象範囲を理解します。

• 信頼性をサポートする機能: コードを変更せずに単純な構成を使用して可用性を強化するには、クラウドネイティブ サービスを選択します。 オプションを理解し、ゾーンの冗長性を高めたり、セカンダリ リージョンにデータをレプリケートしたりするなどの構成を意図的に選択することが重要です。

✓ 基本レベルの冗長性を使用してデプロイする

ソリューションの各部分内で、単一インスタンスなどの単一障害点を回避します。 代わりに、冗長性のために複数のインスタンスを作成します。 Azure サービスは、多くの場合、冗長性を処理します。特に PaaS サービスでは、通常は既定でローカルの冗長性とアップグレードのオプションが含まれます。 ゾーン冗長を使用して、これらのインスタンスを複数の Azure データセンターに分散することをお勧めします。 そうでない場合は、少なくともローカルの冗長性を確保しますが、この方法ではリスクが高くなります。 今後のレベルでは、geo 冗長コンポーネントを使用してソリューションを拡張することで、信頼性要件が満たされる可能性があるかどうかを評価します。

トレードオフ： 重要なトレードオフの 1 つは、冗長性のコストの増加です。 また、クロスゾーン通信では待機時間が発生する可能性があります。 待機時間を最小限に抑える必要があるレガシ アプリケーションの場合、冗長性によってパフォーマンスが低下する可能性があります。

リスク： アプリケーションが複数インスタンス環境用に設計されていない場合は、複数のアクティブなインスタンスで問題が発生し、データが不整合になる可能性があります。 また、待機時間が短いオンプレミスのセットアップ用にアプリケーションが構築されている場合、可用性ゾーンを使用すると、パフォーマンスが低下する可能性があります。

✓ メトリック、ログ、トレースを有効にしてフローを監視する

メトリック、ログ、トレースの可視性を確保するために、Azure Monitor などのプラットフォームネイティブ ツールを選択します。 組み込みの機能を使用して、潜在的な問題のアラートを設定します。 通知を送信してアラートを取得するには、基本的なアラートが設定されている必要があります。 次のようなサービスの正常性状態の変化を示す Azure プラットフォーム機能を利用します。

• プラットフォームの正常性を確認するためのAzure Service Health。

• リソース レベルの正常性状態を確認する Azure Resource Health。

インフラストラクチャとアプリケーションの両方に 対して Azure Monitor アクション グループ を設定します。

トレードオフ： より多くのログを収集するときは、増加するボリュームを管理する必要があります。これは、これらのログのストレージ関連のコストに影響します。 データ保持ポリシーを使用してデータの量を管理します。 Azure Monitor を使用して、ワークスペースに日次上限を設定します。 詳細については、「信頼性の 構成に関する推奨事項」を参照してください。

次のレイヤーで可観測性の構築を開始します。

インフラストラクチャ

まず、診断ログを有効にし、分析のためにプラットフォーム コンポーネントからネイティブ メトリックを収集します。 CPU、メモリ、入力/出力、ネットワーク アクティビティなど、リソースの使用状況に関する情報を収集します。

アプリケーション

メモリ消費量や要求の待機時間などのアプリケーション レベルのメトリックを収集し、アプリケーション アクティビティをログに記録します。 メイン アプリケーション スレッドとは別のスレッドまたはプロセスでログ記録操作を実行します。 この方法では、ログ記録によってアプリケーションのプライマリ タスクの速度が低下することはありません。

また、Application Insights の 基本的な可用性テスト も確認してください。

データ

データベースを基本的なレベルで監視するには、データベース リソースが出力する主要なメトリックを収集します。 インフラストラクチャ コンポーネントと同様に、ネットワーク メトリックなど、データ ストアのコンテキストでリソースの使用状況を追跡します。 接続がプールされる方法に関するデータを収集することは、後の段階で効率性を高めるためには重要です。

信頼性を確保するには、アクティブな接続や失敗した接続の監視などの接続メトリックを追跡することが重要です。 たとえば、Azure Cosmos DB では、要求の数が割り当てられた要求ユニットを超え、接続が失敗し始めると、429 状態コードが返されます。

✓ 障害軽減プレイブックの構築を開始する

障害の範囲は、断続的なものから、わずかに拡張された一時的な障害や致命的な停止までです。

レベル 1 では、プラットフォームの障害に焦点を当てます。 これらは制御できない場合でも、それらを処理するための戦略を持っている必要があります。 たとえば、可用性ゾーンを使用してゾーンの停止に対処します。 プラットフォーム レベルで一時的な障害を予測し、ワークロードで処理します。

これらのエラーを処理するプロセスは、複雑さによって異なります。 プラットフォーム レベルの潜在的な障害、関連するリスク、軽減戦略の文書化を開始します。 この演習は主に理論的であり、後のレベルで自動化で成熟します。

エラーの可能性、影響、軽減戦略などの要因を文書化する必要があります。 ワークロードの目標に合った重要度スケールを使用します。 スケールには、次のようなものが含まれるかもしれません。

• 高。 システムの完全な停止により、大幅な財務損失とユーザー信頼の低下が発生します。

• ミディアム ワークロードの一部に影響し、ユーザーの不便を引き起こす一時的な中断。

• 低。 アプリケーションの不要な機能に影響を与え、ユーザーのダウンタイムを最小限に抑える小さなソフトウェアの問題。

テンプレートの例を次に示します。

レベル 1 では、予期しない障害ケースが常に存在するため、完全性を追求しないでください。 予期しない停止が発生した場合は、原因と軽減策をプレイブックに文書化します。 この資産は、時間の経過に伴って更新する生きたドキュメントとして扱います。

✓一時的な障害から回復するためのメカニズムを追加

クラウド環境では、一時的な障害が一般的です。 これは、再試行が通常数秒以内に解決できる短期的な問題を示します。

組み込みの SDK と構成を使用してこれらの障害を処理し、システムをアクティブに保ちます。 多くの場合、組み込みの構成が既定の設定であるため、実装を検証するためにテストが必要になる場合があります。 また、アーキテクチャの一時的な障害を処理するように設計されたパターンを実装します。 詳細については、「信頼性を サポートするアーキテクチャ設計パターン」を参照してください。

永続的な問題は、一時的ではない障害または停止の開始を示している可能性があります。 このシナリオでは、アプリケーション内のローカライズされた問題を修正するだけではありません。 これには、システムの重要なユーザーとシステムのフローを調べ、自己保存手法と回復作業を追加することが含まれます。 これらのメソッドは、レベル 2 で説明されている成熟したプラクティスです。

✓ 基本的なテストを実行する

ソフトウェア開発ライフサイクルの初期段階で基本的な信頼性テストを統合します。 単体テストから始めて、機能と構成を検証するテストを行う機会を探します。

また、リスク軽減プレイブックで特定した問題の簡単なテスト ケースを開発します。 影響が大きく、作業の軽減策が少なくなるように重点を置く。 たとえば、ネットワークの停止や断続的な接続の問題をシミュレートして、再試行ロジックによって中断がどのように解決されるかを確認します。

リスク： テストでは、多くの場合、開発サイクルに摩擦が発生します。 このリスクを軽減するには、開発タスクと共に信頼性テストを追跡できるようにします。

特徴開発が優先され、テストによって開発サイクルに摩擦が生じる可能性があります。 機能開発が完了する前に、テストを開始する方が簡単です。 最初にアプリケーションの非機能的な側面を設計すると、後で対処するために問題のバックログを構築するのではなく、機能機能を追加するときにそれらを拡張できます。 このアプローチでは、最初はより多くの労力を必要としますが、管理しやすく、後で大きな問題を回避できます。

自己保存機能を組み込み、障害を管理するための基本的な復旧計画を用意することで、システムが機能し、安定していることを確認します。

クラウドでの障害は避けられません。 回復性戦略は、すべての条件下でシステムの機能を維持するように努める必要があります。 レベル 1 では、一時的な障害に対処するための方法が導入されています。 レベル 2 では、長期的な障害を防ぎ、検出し、回復するための自己保存戦略を組み込むことに重点を置いています。 未解決のままにすると、これらの問題が完全な停止に変わる可能性があります。

レベル 1 で識別した重要なフローが優先されます。 アプリケーション、サービス、データベースを含むすべてのコンポーネントに対して、回復性と回復の取り組みを強化する必要があります。 信頼性のリスクを軽減するために、初期プロビジョニング サイズ、インスタンス数、自動スケール ポリシーを調整する必要があります。

このレベルでは、監視とテストのプラクティスについて意図的に行ってください。 技術的なニーズに合わせ、開発チームを対象とする高度な監視手法を使用します。 単純なプレイブックを展開して、アプリケーション コードなど、開発および所有するアーキテクチャ コンポーネントについて説明します。

主な戦略

✓ 障害から保護するために回復性の現在の状態を評価する

• 冗長性のレベルは、障害に耐えられるほど十分ですか? 維持する冗長リソースの数を指定する冗長性戦略を定義します。 これらのリソースを配置する場所 (ローカル、複数のゾーン、地理的に分散した場所) を決定します。 クラウド プラットフォームの設定を評価し、ビジネス ニーズと許容できるトレードオフを満たすレベルを選択します。

• ワークロード コンポーネントは、障害を抑制するのに十分に区切られていますか? Bulkhead パターンのようなパターンは、回復性と障害の分離を構築するのに役立ちます。 バルクヘッド パターンは、障害がシステムの他の部分にカスケードされないように、システムを分離されたコンポーネント ( バルクヘッドと呼ばれます) に分割します。

• クリティカル パス上のコンポーネントは非同期的に通信しますか? そうでない場合は、キューなどの通信方法を使用します。 この方法では、ダウンストリーム コンポーネントで障害が発生した場合でも、システムの動作が維持されます。 また、システムが不確定な状態になるのを防ぎます。 キュー用の Azure Service Bus やイベント ストリーム用の Azure Event Hubs など、Azure のオプションについて説明します。

  トレードオフ： 非同期通信は、プロセスを切り離すことで連鎖的な障害を防ぐのに役立ちます。 ただし、通信パスに待機時間が追加されるため、重要なコンポーネントに問題が発生する可能性があります。 デザイン パターンを変更する前に、パフォーマンスへの影響を評価します。

• 操作は一貫性のために設計されていますか? アプリケーション シークレットや証明書などの資産の有効期限が切れ、定期的な更新が必要になる場合があります。 定期的な更新の不整合により、信頼性の問題が発生する可能性があります。

  エラーが発生しやすく、信頼性リスクを引き起こす不整合を引き起こす可能性があるため、進行中の人間が操作するタスクを特定して排除するのが理想的です。 可能な限り多くの運用タスクをクラウド プロバイダーにオフロードします。 たとえば、Microsoft Entra ID が提供するマネージド ID と、Azure Front Door が管理するトランスポート層セキュリティ (TLS) 証明書を使用します。

  証明書の有効期限の追跡や通知の受信など、プロアクティブな対策を行う場合は、監視が必要です。 アプリケーションは、有効期限が近い TLS 証明書などの重要なイベントをログに記録する必要があります。 複数の方法を使用して潜在的なエラーを確認すると、必要なアクションが確実に実行されます。

✓ 監視システムに技術的な機能を追加する

レベル 1 では、インフラストラクチャに重点を置き、ワークロード コンポーネントから監視データを収集しました。 基本的な分析が完了し、基本的なアラートが設定されます。 このセットアップは、ワークロード コンポーネントのベースライン パフォーマンスを理解し、異常な動作を特定するために不可欠です。

レベル 2 では、高度な監視機能をワークロード リソースに追加し、監視データを分析するためのより構造化されたアプローチを採用することで、監視をさらに一歩進めます。 クラウド サービスが提供する分析ツールを活用します。 たとえば、VM 分析情報やネットワーク分析情報などの Azure Monitor 分析情報ツールは、依存関係全体の正常性とパフォーマンスの視覚化を提供します。

次のレイヤーで監視機能を計画します。

アプリケーション

• ヘルスステータスプローブに応答します。 アプリケーションがプローブからの正常性チェック要求に応答できるようにします。 アプリケーションには、正常性チェック用の専用エンドポイントが必要です。これにより、 正常性 や 異常などの状態情報が少なくとも提供されます。 このアプローチにより、監視システムは、アプリケーションが正常に機能していて、要求を処理できるかどうか、または対処する必要がある問題があるかどうかを評価できます。

  Azure Front Door、Azure Traffic Manager、Azure Application Gateway、Azure Load Balancer などの Azure 負荷分散サービスは、正常性プローブをサポートします。 ヘルスプローブは、健康チェック要求をアプリケーションに送信します。

• セマンティック ログに進みます。 イベントとアクションに関する構造化された情報をアプリケーションに含めます。 構造化ログでは、明確に定義されたスキーマを使用してログ データが一貫した形式で記録されます。 このスキーマを使用すると、後の段階で自動化、検索、分析を簡単に作成できます。 タイムスタンプやエラー コードなどの特定のフィールドを含め、問題をすばやく特定してトラブルシューティングします。

• 分散トレースを実装します。 要求がシステムのさまざまなコンポーネントを通過する場合は、境界を越えてトレース データをキャプチャすることが重要です。 このデータは、アプリケーションの動作に関する分析情報を取得し、パフォーマンスのボトルネック、エラー、待機時間の問題を特定するのに役立ちます。 Azure Monitor では、Application Insights を使用した OpenTelemetry ベースのデータ収集がサポートされています。

データ

• クエリ期間、失敗したクエリ、およびその他の関連メトリックを追跡します。 実行時間の長いクエリは、リソースの制約を示す可能性があり、場合によってはスキーマ設計を調整する必要があります。

  この段階では、データベースはしばらくの間動作しています。 データの増加率に注意してください。特に、予期せず急速に増加するテーブルでは注意してください。 この情報は、将来のストレージ ニーズを計画し、パフォーマンスの問題に早期に対処するために重要です。

• データベース管理システムが提供するツールとダッシュボードを使用して、データベース レプリケーションの状態を監視します。 たとえば、Azure Cosmos DB を使用する場合は、Azure Cosmos DB の分析情報を使用します。 Azure SQL Database または Azure SQL Managed Instance の場合は、データベース ウォッチャーを使用して、データベースに関する診断の詳細を取得することを検討してください。

  データベースが大きくなると、スキーマの問題が明らかになり、パフォーマンスに影響を与える可能性があります。 クエリの効率を最適化するには、インデックスを追加するか、スキーマを変更することを検討してください。これらの変更は信頼性に影響を与える可能性があるためです。

オペレーション

レベル 1 は、上記のレイヤーに重点を置いています。 レベル 2 では、監視システムを中心に運用を開始します。

• 分析情報を得るのに十分な時間、ログを保持します。 信頼性の観点から、障害パターンを検出し、問題のトラブルシューティングを行い、根本原因分析を実行するのに十分なデータを収集できるように、リテンション期間を構成します。

• バックアップと回復のプロセスを監視します。 バックアップが計画された場所に正常に格納され、ワークロード データが妥当な期間内に復旧されることを確認します。 これらのプロセスの監視は、後のレベルで目標復旧ポイント (RPO) メトリックのベースラインを設定するために重要です。

✓ 障害軽減プレイブックを拡張する

レベル 1 では、予想されるプラットフォームの障害に重点を置いています。 レベル 2 では、独自のワークロード内のコンポーネントと操作の障害ポイントに対処します。 コードがプラットフォーム上で実行されると、プラットフォームとアプリケーションの間の相互作用ポイントが増加します。 コード内のバグ、デプロイの失敗、およびヒューマン エラーによるエラーが予想されます。 自己保存または回復の戦術を使用して、これらの問題を軽減します。

バグやデプロイの問題を含むように、障害軽減プレイブックを拡張します。 次の表は、レベル 1 のテンプレートに基づいています。

この演習は、考えられるすべての失敗を考慮しようとすると、圧倒的になる可能性があります。 簡単にするために、重要なユーザー フローの一部であるコンポーネントに注目します。 この生きているドキュメントは、ワークロードが成熟するにつれて拡大し続けます。

✓ 基本的な復旧計画を策定する

障害軽減プレイブックは、基本的な復旧計画を作成するための基礎です。 軽減戦略には、設計パターンの実装、プラットフォーム構成の調整、ライブ サイト インシデント管理、自動テスト、およびコード レビュー中に問題を検出するためのトレーニング担当者を含めることができます。

まず、システムの一部が正常に動作しない場合の一時的な修正を含む、グレースフルな低下戦略から始めます。 目標は、非作業部分を無効にし、ユーザー エクスペリエンスを調整することで、障害が発生してもユーザーにサービスを提供し続けることでした。 たとえば、データベースがダウンしている場合、アプリケーションは影響を受ける機能を無効にし、HTTP 状態コードを使用してサービスが一時的に使用できないことをクライアントに通知できます。

段階的劣化を機能させるには、システムコンポーネントを分離し、影響を受けた部分だけが問題を経験し、残りのコンポーネントが引き続き機能するようにします。 バルクヘッド パターンを使用して、障害の分離を実現します。

この機会に、復旧が遅くなる可能性がある設計の選択を見直してください。 たとえば、ドメイン ネーム システム (DNS) レコードを Azure App Service 上のアプリケーションに直接ポイントすると、DNS 伝達のために復旧中に遅延が発生する可能性があります。 復旧手順中の再構成を容易にするために、イングレス ポイントとして Azure Front Door などの専用サービスを使用します。

この基本計画は、より成熟したレベルで完全なディザスター リカバリー計画に進化することを期待してください。

✓ テスト計画を作成する

リスク軽減プレイブックで特定された停止と問題をシミュレートして、テスト 計画を作成します。 単純なテスト ケースでこれらの軽減策を補完し、期待どおりに動作し、実行可能であることを確認します。 これらの機能が正しく動作することを確認し、特定のコンポーネントが失敗したときにシステムがどのように動作するかを確認するために、劣化テストを実施します。 テストが失敗するか成功するかを確認して、結果をシンプルに保ちます。

フレームワークのモック作成などのテスト ツールを使用して HTTP 要求にエラーを挿入します。これは、再試行ポリシーをより明示的にテストするのに役立ちます。 Azure Chaos Studio には、コンポーネントの停止やその他の問題をシミュレートするための包括的なテスト スイートが用意されているため、探索に役立つ貴重なサービスになります。 Chaos Studio の機能に慣れるにつれて、徐々に Chaos Studio を導入できます。

✓ スケーリング操作が信頼性に与える影響を評価する

負荷の急増に対処するには、重要なコンポーネントが効率的にスケールアウトまたはスケールアップできる必要があります。 Azure で提供される自動スケール機能を利用します。 これらの機能は、定義済みの構成に基づいてサービスの容量制限を調整します。 この調整により、必要に応じてサービスをスケールアップまたはスケールダウンできます。

• 潜在的なボトルネックを特定し、発生する可能性があるリスクを理解します。 たとえば、高スループットではフローが中断されないようにする必要があります。

• 読み込みパターンを理解する。 静的な使用パターンによってボトルネックの重要度が低下する可能性がありますが、使用量と消費のダイナミクスの変化によってリスクが悪化する可能性があります。

  注

  モノリシック データベースやレガシ アプリケーションなど、スケールアウトできないコンポーネントが存在する可能性があります。 必要に応じて再設計できるように、負荷曲線を事前に監視します。

• パフォーマンスと信頼性の要件に基づいて妥当なスケーリング制限を決定します。 パフォーマンスに関する問題の場合は、徐々にスケールアップすることが最も一般的です。 ただし、重要なフローの信頼性の問題では、停止を回避するために、より迅速なスケーリングが必要になる場合があります。 どちらの場合も、無限スケーリングを避けてください。

リスク： パフォーマンス関連の問題に対処する場合、スケーリングは便利な軽減戦略になる可能性があります。 ただし、スケーリングは一時的な修正であり、ソリューションではありません。 メモリ リークやランナウェイ プロセスなど、基になる問題を調査して解決します。 それ以外の場合は、別の転換点で同じ軽減策をもう一度適用し、不要なリソースに対する支払いを行うリスクがあります。 根本原因に対処することで、長期的な安定性とコスト効率を確保できます。

信頼性の目標と目標を設定して、チームが復旧手順に責任を持つようにします。

初期のレベルでは、チームは簡単な勝利と基本的な機能に焦点を当てています。 小規模な改善から始まり、Azure の信頼性機能にほとんど依存しながら、強力な基盤を構築するための単純な問題を解決します。 チームの成長に合わせて、チームは自身の資産とプロセスに関連する技術的な課題に対処します。

レベル 3 では、チームは復旧計画のためにビジネスの分析情報と技術的スキルを統合する必要があります。 高度な監視を使用して目標を設定し、復旧プロセスを計画します。 このアプローチは、サイト信頼性エンジニア (SRE) が信頼性目標を迅速に満たすのに役立ちます。

主な戦略

✓ 信頼性機能を目標として形式化する

信頼性の目標は、ワークロード チームのアカウンタビリティを設定するのに役立ちます。 復旧時間とコストについて話し合い、ビジネス目標に合った妥協を行うために、ビジネス関係者と共同作業を行うことが重要です。 関係者を集め、ワークショップとしてこの議論を行います。 ワークショップの議題については、次の点を考慮してください。

• 目標の背後にあるメトリックについて説明します。 まず、サービス レベルの目標、目標復旧時間 (RTO)、目標復旧時点 (RPO) などの目標を定義するために使用される主要なメトリックについて説明します。 これらのメトリックがビジネス目標とどのように一致しているかを示します。 重要なユーザー フローに焦点を当てます。 たとえば、eコマース アプリケーションでは、メール設定を更新するための RTO は、ユーザーがショッピング カートをチェックアウトするよりも重要ではありません。

• トレードオフを伝えます。 多くの場合、利害関係者は達成できる以上のものを期待します。 スコープの拡張が予算、運用要件、およびパフォーマンスにどのように影響するかを説明します。

• 目標を提案する。 アーキテクチャエクスペリエンスとワークロード設計に基づいて、RPO と RTO を 4 時間に設定して、99.9% アップタイムなどのターゲットを推奨します。 利害関係者がフィードバックを提供し、調整を行うためにディスカッションを容易にします。 ビジネス利害関係者と技術関係者の両方が、非現実的な期待に対する保護を確実に行います。 共同作業の考え方でディスカッションに取り組む。

• 合意または決定に達する。 コンセンサスを目指しますが、それが不可能な場合は、意思決定者に目標を最終決定し、進行状況を確保してください。

✓あなたの健康モデルを使用して積極的に監視

レベル 1 では、監視データは、プラットフォーム サービスやアプリケーションを含むワークロード コンポーネントから収集されます。 基本的な分析とアラートは、ベースライン のパフォーマンスを確立し、異常を特定するように設定されています。 レベル 2 では、アプリケーション コードなどのワークロード コンポーネントから監視データを取得することにフォーカスが移ります。

レベル 3 では、ビジネス コンテキストを重要なフローに追加し、正常性モデリングを通じて 正常、 異常、 および低下した 状態を定義することで、監視を強化します。 利害関係者契約は、許容されるユーザー エクスペリエンスの侵害を判断するために必要であり、正常性状態を定義するための入力として使用する必要があります。

正常性モデリングには、運用の成熟度と監視ツールの専門知識が必要です。 チームは生データ、パフォーマンス レベル、ログを確認して、フローの正常性状態を定義するカスタム メトリックとしきい値を作成します。 これらの値がシステムの全体的な正常性にどのように関連しているかを理解する必要があります。 明確な定義としきい値を利害関係者に伝えます。

ダッシュボードで正常性モデルを視覚化し、SRE が異常なフローや低下したフローに焦点を当てることで、問題をすばやく特定できるようにします。

正常性モデルは、アプリケーションの状態と重要なフローを定義します。 緑は、すべての重要なフローが想定どおりに動作していることを示します。 赤は失敗を示します。 黄色は問題に対する傾向を示します。 正常性モデルのバージョンを反復処理すると、信頼性と精度が確保されますが、大規模なアプリケーションには多大な労力が必要です。

正常性状態の変更は、アラートとして構成する必要があります。 ただし、アラートを意図的に保持するには、コンポーネントの重要度を考慮する必要があります。

詳細については、「 Well-Architected フレームワーク: 正常性モデリング」を参照してください。

✓ アクション可能なアラートを設定する

応答効率を向上させるには、アラートを明確に定義し、迅速なアクションのための十分な情報を提供します。 詳細なアラートの名前と説明は、トラブルシューティング中の時間と労力を節約するのに役立ちます。 重大度レベルに特に注意して、重大度、名前、および説明を慎重に構成します。 すべてのイベントが緊急時であるわけではありません。 重大度レベルを慎重に評価し、80% から 90% への CPU スパイクが緊急時として適格かどうかなど、各レベルの基準を確立します。 適切なしきい値を設定して、アラートが効果的に定義されるようにします。

効果的なアラート管理により、アラートは適切なユーザーに適切なタイミングで通知されます。 頻繁で破壊的なアラートは調整の必要性を示し、無視されると逆効果になる可能性があります。 適切なしきい値を設定して誤ったアラームを除外することで、不要な通知を減らします。 自動化によって運用手順をトリガーできる機会を特定します。

アラートを効率的にトラブルシューティングするために必要な情報を含む 1 つのランディング ページを作成します。 この方法では、Azure portal にログインしてメトリックを検索する場合と比べて、時間が節約されます。 Azure Monitor の組み込み機能がニーズを完全に満たしていない場合は、カスタム ダッシュボードの開発を検討してください。

✓ 障害モード分析を実施する

以前のレベルでは、個々のコンポーネントに対して単純な障害軽減プレイブックを作成しました。 このレベルでは、そのプレイブックを正式な故障モード分析 (FMA) 演習に進化させます。 この演習の目的は、潜在的な障害モードを事前に特定することにあります。

FMA では、ワークロード内の潜在的な障害点を特定し、自己復旧やディザスター リカバリー (DR) などの軽減アクションを計画する必要があります。 まず、エラー率の増加を監視し、重要なフローへの影響を検出します。 過去のエクスペリエンスとテスト データを使用して、潜在的な故障を特定し、その爆発半径を評価します。 リージョン全体の停止などの主要な問題に優先順位を付けます。

アクションを 予防的 または反応性として分類することが重要 です。 予防措置は、障害が発生する前にリスクを特定し、リスクの可能性や重大度を低下させます。 問題に対処するためのリアクティブアクションは、健康状態の劣化または停止を軽減します。

eコマースのサンプル アプリケーションでは、ワークロード チームは FMA を実行して主要なイベントに備えたいと考えています。 主要なユーザー フローの 1 つは、カートに項目を追加することです。 フローの一部であるコンポーネントは、フロントエンド、CartAPI、ProductCatalogAPI、UserProfileAPI、PricingAPI、Azure Cosmos DB、Azure Event Hubs です。

FMA は複雑であり、時間がかかる可能性があるため、時間の経過と同時に徐々に分析を構築します。 このプロセスは反復的であり、後の段階で進化し続けています。

詳細については、「 FMA を実行するための RE:03 推奨事項」を参照してください。

✓ DR プランを準備する

レベル 2 では、システム機能を復元するための技術的な制御に重点を置いた復旧計画を作成しました。 ただし、災害では、致命的な損失や障害のために、より広範なアプローチが必要です。 DR プランはプロセス ベースです。 通信、詳細な復旧手順に対応しており、スクリプトなどの技術的な成果物が含まれる可能性があります。

まず、リージョンの停止、Azure 全体の障害、インフラストラクチャの中断、データベースの破損、ランサムウェア攻撃など、計画する災害の種類を特定します。 次に、各シナリオの復旧戦略を策定し、操作を復元するためのメカニズムが整っていることを確認します。 ビジネス要件、RTO、および RPO が DR プランをガイドする必要があります。 RTO と RPO が低い場合は明示的な自動化プロセスが必要ですが、RTO と RPO が高いほど、より簡単な回復方法と手動分析が可能になります。

DR には主に次のアクションが含まれます。

• 責任者に通知します。 誰をいつ関与させるかを明確にすることが重要です。 チームが適切なプロセスを使用し、適切なアクセス許可を持ち、回復における役割を理解していることを確認します。 CEO が市場に報告したり、規制要件を処理したりするなどの一部の責任は、早期に特定する必要があります。

  理想的には、回復とコミュニケーションの役割を個別に持ち、各ロールに異なるユーザーを割り当てる必要があります。 最初は、問題を検出した IT 運用担当者が両方の役割を処理する可能性があります。 しかし、状況がエスカレートするにつれて、ビジネス担当者が通信を管理している間、上級職員が技術的回復を処理する可能性があります。

• ビジネス上の意思決定を行います。 災害発生時には、ストレス レベルが高くなる可能性があり、明確な意思決定が不可欠になります。 適切に構造化された DR 計画では、暫定的な意思決定オプションを定義するために、技術チームとビジネス利害関係者の間で継続的な議論が必要です。 たとえば、ワークロード リソースを別のリージョンのバックアップがある Azure リージョンで実行するか、フェールオーバー中に新しいリソースを作成したり、バックアップから復元したりするために IaC 資産を事前に準備しておく必要があるかを検討します。

  DR 計画に従って実行されるアクションは、破壊的であるか、重大な副作用を持つ可能性があります。 オプションを理解し、長所と短所を比較検討し、それらを適用する適切なタイミングを決定することが不可欠です。 たとえば、プライマリ リージョンが許容可能な期間内に動作することが予想される場合に、別のリージョンへの復旧が必要かどうかを評価します。

• システム操作を復元します。 障害発生時には、原因の特定ではなく、操作の復元に重点を置く必要があります。 技術的な復旧 (特にリージョン のフェールオーバー) では、アクティブ/アクティブ、アクティブ/パッシブ、ウォーム スタンバイ、コールド スタンバイなどのアプローチを事前に決定します。

  選択した方法に基づいて、特定の復旧手順を準備します。 操作を復元する手順の具体的な一覧から始めます。 プロセスが成熟するにつれて、手動操作を最小限に抑えたスクリプトとして DR プランを定義することを目指します。 バージョン管理を使用し、スクリプトを安全に保存して簡単にアクセスできます。 このアプローチでは、より事前の作業が必要ですが、実際のインシデント時のストレスは最小限に抑えられます。

  詳細については、 DR のアクティブ/パッシブでのデプロイを参照してください。

• インシデント後の分析を実施する。 インシデントの原因を特定し、将来それを防ぐ方法を見つけます。 復旧プロセスを改善するために変更を加えます。 この演習では、新しい戦略を明らかにすることもできます。 たとえば、システムがセカンダリ環境に切り替えた場合は、プライマリ環境がまだ必要かどうか、およびフェールバック プロセスを決定します。

DR プランは、ワークロードの変化に適応する生きたドキュメントです。 新しいコンポーネントとリスクが発生したら、DR 計画を更新します。 DR オペレーターから現実的な情報を収集することで、訓練や実際の災害から得られた分析情報に基づいて計画を絞り込みます。

技術的および運用上の変更に起因するリスクを制御し、インシデント管理に優先順位を付けます。

前のレベルでは、ワークロード チームは機能の構築とシステムの運用に重点を置いています。 レベル 4 では、運用環境でシステムの信頼性を維持することにフォーカスが移ります。 インシデント管理は、導入された変更が十分にテストされ、システムが不安定にならないように安全にデプロイされるようにすることが重要になります。

このプロセスでは、信頼性インシデントを管理するための専用チームへの投資など、運用管理の改善が必要です。 また、以前のレベルで強化された重要なコンポーネントを超えてシステムの信頼性を高めるために、技術的な制御も必要です。 システムが運用環境で引き続き実行されるため、データの増加には、信頼性の高いアクセスとメンテナンスを確保するために、パーティション分割などの再設計が必要になる場合があります。

主な戦略

✓ 信頼性の高い変更管理

最大の信頼性リスクは、ソフトウェアの更新、構成の調整、プロセスの変更など、変更中に発生します。 これらのイベントは、信頼性の観点から重要です。 目標は、問題、停止、ダウンタイム、またはデータ損失の可能性を最小限に抑することです。 変更の種類ごとに、固有のリスクを効果的に管理するために特定のアクティビティが必要です。

レベル 4 では、信頼性は、変更を管理するときに安定した環境を維持する上で、オペレーショナル エクセレンスで説明されている安全なデプロイ プラクティスと交差します。 信頼性の高い変更管理は、ワークロードの安定性を実現するための要件です。 次の重要な側面について考えてみましょう。

• プラットフォームの更新に対応します。 Azure サービスには、サービスを更新するためのさまざまなメカニズムがあります。

  • メンテナンス プロセスを理解し、使用する各サービスのポリシーを更新します。 サービスが自動アップグレードと手動アップグレードのどちらをサポートしているか、および手動更新の時間枠を理解します。

  • 更新プログラムが計画されているサービスの場合は、影響の少ない時間帯にスケジュールすることで、これらの更新プログラムを効果的に管理します。 自動更新を回避し、リスクを評価するまで延期します。 一部のサービスではタイミングを制御できますが、他のサービスでは猶予期間が提供されます。 たとえば、Azure Kubernetes Service (AKS) では、更新プログラムが自動になる前に 90 日間オプトインできます。 本番環境を模した非本番環境クラスターで更新プログラムをテストし、回帰を防ぎます。

    更新プログラムを段階的に適用します。 テストで更新プログラムが安全であることが示されている場合でも、すべてのインスタンスに同時に適用すると危険な場合があります。 代わりに、一度にいくつかのインスタンスを更新し、各セットの間で待機します。

  • アクティビティ ログやその他のサービス固有のチャネルで使用できる可能性がある更新に関する通知を定期的に確認します。

  • 更新プログラムが適用された後の突然または段階的な変更を監視します。 理想的には、ヘルスモデルがこれらの変更を通知するべきです。

• 自動化による徹底的なテスト。 変更をロールアウトするときに、より多くのテストをビルドおよびデプロイ パイプラインに統合します。 手動プロセスをパイプラインの自動化された部分に変換する機会を探します。

  さまざまな段階でさまざまな種類のテストを組み合わせて包括的なテストを行い、変更が期待どおりに動作し、アプリケーションの他の部分に影響しないことを確認します。 たとえば、肯定的なテストでは、システムが期待どおりに動作することを確認できます。 エラーがなく、トラフィックが正しく流れているかどうかを検証する必要があります。

  更新プログラムを計画するときは、テスト ゲートと適用するテストの種類を特定します。 ほとんどのテストはデプロイ前の段階で行う必要がありますが、更新時には各環境でスモーク テストも実行する必要があります。

• 安全なデプロイプラクティスに従います。 検証ウィンドウと安全な展開プラクティスを含む展開トポロジを使用します。 柔軟性と信頼性を高めるために、カナリアデプロイやブルーグリーンデプロイなどの安全なデプロイパターンを実装します。

  たとえば、カナリアデプロイでは、少数のユーザーが最初に新しいバージョンを受け取ります。 このプロセスにより、ユーザー ベース全体にデプロイする前の監視と検証が可能になります。 機能フラグやダーク 起動などの手法は、すべてのユーザーに変更をリリースする前に、運用環境でのテストを容易にします。

• DR プランを更新します。 DR プランを定期的に更新して、関連性と効果を維持します。 古い手順は避けてください。 この方法により、運用環境にデプロイされ、ユーザーが依存しているシステムの現在の状態が計画に反映されます。 訓練と実際のインシデントから学んだ教訓を組み込みます。

詳細については、「オペレーショナル エクセレンス レベル 4」を参照してください。

✓ インシデントを処理するための専用チームに投資する

最初は、開発チームがインシデントの間に関与する可能性があります。 レベル 4 では、インシデント管理のためにサイト信頼性エンジニアリング (SRE) に投資します。 SRE は生産の問題に特化しており、効率性、変更管理、監視、緊急対応、容量管理の専門家です。 熟練した SRE チームは、エンジニアリング チームへの依存関係を大幅に削減できます。

インシデントを個別に処理するために必要なツール、情報、知識を SRE に提供します。 この準備により、エンジニアリング チームへの依存が軽減されます。 一般的なパターンをすばやく認識し、軽減プロセスを開始するには、プレイブックと以前のレベルで開発されたワークロード正常性モデルで SRE をトレーニングする必要があります。

エンジニアリング チームには、毎回個別に対処するのではなく、繰り返し発生する問題を反映し、長期的な戦略を策定する時間が必要です。

✓ 自己復旧プロセスを自動化する

前のレベルでは、自己復旧戦略は冗長性と設計パターンを使用して設計されています。 チームが実際の使用経験を持つようになったので、自動化を統合して一般的な障害パターンを軽減し、エンジニアリング チームへの依存を減らすことができます。

トレードオフ： 自動化には時間がかかり、セットアップにコストがかかる場合があります。 頻繁に発生するタスクや障害が発生する可能性があるタスクなど、最も影響の大きいタスクを最初に自動化することに重点を置く。

トリガーに基づいてアクションを構成し、時間の経過と同時に応答を自動化して、SRE の自動プレイブックを構築します。 1 つのアプローチは、軽減手順を実装するスクリプトを使用してプレイブックを強化することです。 Azure Monitor アクション グループの使用などの Azure ネイティブ オプションを調べて、さまざまなタスクを自動的に開始するトリガーを設定します。

✓ バック グラウンド タスクに回復性を拡張します。

ほとんどのワークロードには、ユーザー フローを直接サポートせず、アプリケーションのワークフロー全体で重要な役割を果たすコンポーネントが含まれます。 たとえば、eコマース システムでは、ユーザーが注文を行うと、メッセージがキューに追加されます。 このアクションにより、電子メールの確認、クレジット カードの請求の最終処理、ディスパッチ準備のための倉庫通知など、いくつかのバックグラウンド タスクがトリガーされます。 これらのタスクは、Web サイトでユーザー要求を処理する機能とは別に動作するため、負荷が軽減され、信頼性が向上します。 システムは、データのクリーンアップ、定期的なメンテナンス、バックアップのバックグラウンド タスクにも依存します。

プライマリ ユーザー フローを評価して改善したら、バックグラウンド タスクを検討します。 既に導入されている手法とインフラストラクチャを使用し、バックグラウンド タスクの機能強化を追加します。

• チェックポイント処理を適用します。 チェックポイント処理は、プロセスまたはタスクの状態を特定のポイントに保存するための手法です。 チェックポイント処理は、ネットワーク障害やシステム クラッシュなどの予期しない問題が原因で中断される可能性がある、実行時間の長いタスクまたはプロセスに特に役立ちます。 プロセスが再起動すると、最後に保存されたチェックポイントから取得できるため、中断の影響を最小限に抑えることができます。

• プロセスのべき等性を維持します。 タスクが失敗した場合に別のインスタンスがタスクを選択し、問題なく処理を続行できるように、バックグラウンド プロセスでべき等性を確保します。

• 一貫性を確保します。 バックグラウンド タスクが処理中に停止した場合に、システムが不整合な状態にならないようにします。 チェックポイント処理とタスク レベルのべき等性はどちらも、バックグラウンド タスク操作全体で一貫性を高める手法です。 各タスクをアトミック トランザクションとして実行します。 複数のデータストアまたはサービスにまたがるタスクの場合、タスクレベルの冪等性もしくは補償トランザクションを使用して、完了することを保証します。

• バックグラウンド タスクを監視システムとテストプラクティスに統合します。 障害を検出し、機能的および非機能的な結果をもたらす可能性のある気付かれていない中断を防ぎます。 監視システムでは、これらのコンポーネントからデータをキャプチャし、中断のアラートを設定し、トリガーを使用してプロセスを自動的に再試行または再開する必要があります。 これらの資産をワークロードの一部として扱い、重要なコンポーネントに対して行うのと同じ方法で自動テストを実施します。

Azure には、Azure Functions や Azure App Service WebJobs など、バックグラウンド ジョブ用のいくつかのサービスと機能が用意されています。 信頼性に重点を置くフローを実装する場合は、ベスト プラクティスと制限を確認します。

ワークロード アーキテクチャの進化に応じて回復力を維持します。これにより、システムは新しい予期しないリスクに耐えることができます。

レベル 5 では、ソリューションの信頼性を向上させるという焦点は、技術的な制御の実装から離れています。 インフラストラクチャ、アプリケーション、および操作は、障害に対する回復力を備え、目標復旧時間内に復旧できる十分な信頼性を備える必要があります。

データと将来のビジネス目標を使用して、ビジネスをさらに進める必要がある場合は、アーキテクチャの変更が必要になる可能性があることを確認します。 ワークロードの進化と新機能の追加に伴い、既存の機能の停止をさらに減らしながら、それらの機能に関連する停止を最小限に抑えるように努めます。

主な戦略

✓ 信頼性の分析情報を使用してアーキテクチャの進化をガイドする

このレベルでは、ビジネス利害関係者と協力して意思決定を行います。 次の要因について検討します。

• システムが期間内に信頼性のしきい値を超えた回数と、それが許容されるかどうかを示すメトリックを分析します。 たとえば、1 年間に 5 つの大規模な停止が発生すると、システムの設計と運用のプラクティスが再評価される可能性があります。

• システムのビジネス上の重要度を評価します。 たとえば、ミッション クリティカルなワークフローをサポートするサービスでは、コストや複雑さが増した場合でも、ダウンタイムなしのデプロイとインスタント フェールオーバーの再設計が必要になる場合があります。 逆に、使用を減らしたサービスは、より緩やかなサービス レベルの目標の恩恵を受ける可能性があります。

• 他の柱の変更が信頼性に与える影響を評価します。 たとえば、セキュリティ対策を強化するには、追加のセキュリティ ホップに対する信頼性の軽減が必要になる場合があります。これにより、潜在的な障害点が発生する可能性があります。

• 信頼性を維持するための運用コストを評価します。 これらのコストが予算の制約を超える場合は、支出を最適化および制御するためのアーキテクチャの変更を検討してください。

利害関係者、エンジニア、製品マネージャーが十分な情報に基づいた意思決定を行えるようにするには、上記のデータ ポイントと追加の分析情報を視覚化することを検討してください。 この方法では、信頼性の全体像を示します。

✓ 運用環境で制御されたテストを実行する

このレベルでは、ワークロードで最も高い回復性の保証が必要な場合にのみ、運用環境で制御された実験を検討してください。 これらのテスト プラクティスは、 カオス エンジニアリングと呼ばれます。 テストでは、システムが正常に回復し、有害な条件下で機能し続けることができることを検証します。

次のユース ケースの例を考えてみましょう。

• 依存関係フロー分析: 一般的なユース ケースは、マイクロサービスとして設計されたアプリケーションのテストです。 ランダム マイクロサービス インスタンスをオフにして、エラーがユーザー エクスペリエンスを連鎖または中断しないようにすることができます。 このアプローチをシステム フローに拡張するには、特定のコンポーネントを無効にして、ダウンストリーム システムの反応を分析します。 目標は、緊密な結合または非表示の依存関係を特定し、システム冗長プランのパフォーマンスをテストすることです。

• グレースフルデグレードテスト: 障害発生時に機能を縮小した状態でシステムがどのように動作するかを評価します。 たとえば、レコメンデーション エンジンが失敗した場合は、重要ではない機能を非表示にすることができます。

• サードパーティの障害シミュレーション: 外部 API の呼び出しを無効または調整して、システムの動作と、フォールバックまたは再試行が正しく実装されているかどうかを確認します。

カオス エンジニアリングは、回復性をテストするためのゴールド スタンダードです。 ただし、このプラクティスは成熟したシステムとワークロードチーム専用にしてください。 爆発半径を制限し、ユーザーへの影響を防ぐためのセーフガードが設定されていることを確認します。

• ゲームの日を実行することで備えます。 代理トランザクションを使用したリスクの低いセットアップで、実運用を想定した非運用環境から開始します。 このアプローチは、プロセスのギャップ、ヒューマン エラー パス、アーキテクチャ上の欠陥を特定するのに役立ちます。

  非運用環境のテストが貴重な分析情報を得なくなると、自信がある場合は運用環境に移行する時期になる可能性があります。 移行する前に、すべての懸念事項を一覧表示し、回復性を評価し、問題に対処してください。

• 実験の範囲を制限します。 たとえば、シャットダウンできるインスタンスは 1 つだけです。 テストの目的を明確に定義します。 テスト対象とその理由を理解します。

これらのテストは、定義済みの制限とエラー予算内で動作することにより、サービス レベルアグリーメントに従う必要があります。 これらの実験に適した期間を選択します。 通常、稼働中にそれらを実行すると、チームに完全なスタッフが配置され、発生する可能性のあるインシデントに対応するための十分なリソースが確保されます。

✓ ディザスター リカバリー訓練を実施する

カオス エンジニアリングは、技術コントロールの回復性をテストします。 ディザスター リカバリー (DR) 訓練では、プロセス制御の回復性を評価します。 DR 訓練の目的は、システムが大きな障害や災害から復旧したときの手順、調整、および人間の行動の有効性を検証することです。

規制ワークロードの場合、コンプライアンス要件によって DR 訓練の頻度が決まります。これにより、作業の記録が確実に得られます。 他のワークロードの場合は、これらの訓練を定期的に実施することをお勧めします。 6 か月間隔では、ワークロードの変更をキャプチャし、それに応じて DR 手順を更新する良い機会が得られます。

DR 訓練は、日常的な演習以上のものでなければなりません。 DR 訓練は、適切に実施されると、新しいチーム メンバーをトレーニングし、ツール、コミュニケーション、その他のドリル関連タスクのギャップを特定するのに役立ちます。 また、見過ごされる可能性のある新しい視点を強調表示することもできます。

DR 訓練を実施するための次の主要な方法を検討してください。それぞれリスクと実用的性が異なります。

• 完全にシミュレート: これらの演習は完全にホワイトボードベースであり、システムに影響を与えずに手順のチュートリアルが含まれています。 トレーニングと初期検証に適しています。 ただし、実際のインシデントに関する分析情報は提供されません。

• 非運用環境での実際の訓練: これらのドリルを使用すると、自動化、スクリプト、プロセスをビジネス リスクなしで検証できます。

• 運用環境での実際のドリル: これらのドリルは、最高レベルの信頼度とリアリズムを提供します。 これらのドリルは、前の 2 つの方法をテストした後にのみ実行します。 リスクを最小限に抑えるには、徹底的な計画とロールバック戦略が不可欠です。 停止を引き起こす可能性がある場合は、続行しないでください。

DR ドリルの種類に関係なく、ワークロード回復シナリオを明確に定義します。 実際のインシデントであるかのように訓練を実施します。 このアプローチにより、チームは十分に理解されたチェックリストに従うことができます。 継続的な改善を促進するために、結果を文書化して分類します。 DR の準備には、次のプロセスが含まれる場合があります。

• インシデント管理システムを理解し、チームがエスカレーション パスでトレーニングされていることを確認します。

• プライマリ システムが影響を受けた場合の代替手段を含む、コラボレーションと状態の更新のためのコミュニケーション ツールを一覧表示します。

• ワークロードに関連するテスト シナリオに関するスキル資料を提供します。

• 不一致を追跡して、実装中に発生した問題をキャプチャします。

トレードオフ： 通常、これらのドリルは中断を伴いませんが、時間がかかります。 その効果を最大限に高めるために、重要な側面に重点を置き、不要なタスクを回避します。 バックログでは、このプラクティスに時間を割り当てるようにしてください。

DR 計画を作成する場合や DR 訓練を実施する場合は、特に最初のいくつかの訓練に特化した専門知識を含める必要があります。 マルチリージョンの設計、フェールオーバーとフェールバックの戦略、サービスまたはツールに関する入力は非常に重要です。 組織にクラウド センター オブ エクセレンス チームがある場合は、計画プロセスに含めるようにしてください。

✓ 必要に応じてデータ モデルとセグメントを評価する

データは動的であり、絶えず進化しています。 アーキテクチャ内の他のコンポーネントとは異なり、通常、ユーザーがシステムとやり取りするにつれてデータが増加します。 時間の経過に伴うデータ パターンの監視と、アーキテクチャの他の部分への影響の評価は不可欠です。 このレベルでは、全体的な信頼性を高めるために、データ管理を簡素化し、パフォーマンスを向上させる手法を検討します。 パーティション分割は、これらの結果を達成するための重要な戦略です。

アクセス パターンに基づいてデータを分割し、個別に格納するホットコールド パーティション分割などの手法について説明します。 アクセスの頻度や関連性などの条件を使用して、パーティション分割する対象を決定します。

ホットコールド パーティション分割はシャーディングと組み合わせることができます。これは、大規模なデータベースをシャードと呼ばれる小さな単位に分割 するプロセスです。 各シャードはデータの一部を保持し、一緒に完全なデータセットを形成します。 この方法により、独立したデータ管理が可能になります。

トレードオフ： シャードのバランスを取るには、運用プロセスでその分配を評価し、確認する必要があります。 この方法は、1 つのパーティションが過剰に使用されるホット パーティションを回避するのに役立ちます。 ただし、バランスを維持するために継続的な労力とリソースも必要です。

パーティション分割手法を選択する場合は、次の信頼性の利点を考慮してください。

• パフォーマンスの向上: 複数のパーティションに要求を分散することで、個々のストアの負荷を軽減できます。 シャーディングを効果的に実装すると、システムは 1 日に何百万もの書き込み要求を処理できます。 この戦略により、パフォーマンスが向上し、待機時間が最小限に抑えられます。

  パーティション分割を使用すると、水平方向のスケーリングを簡略化できます。 たとえば、シャーディングでは、ユーザーまたは顧客をほぼ等しいサイズのバケットに分割できます。

• 改善されたデータ管理: ホットコールド パーティション分割を使用すると、各ストレージ層に異なるレベルのデータ管理を適用できます。 たとえば、アーカイブ データを別のストアに移動すると、操作やバックアップの速度低下を防ぐことができます。 同様に、すべてのログ データをリレーショナル データベースに格納する必要はありません。 アクティブなワークロード データがリレーショナルのままである間は、別のデータ ストアに格納できます。

• カスタマイズされた信頼性ポリシー: さまざまな信頼性ポリシーを適用して、各パーティションに適切なレベルの回復性を確保し、単一ストアがボトルネックにならないようにすることができます。 ホット パーティションは、ゾーン冗長や geo 冗長性を含め、完全冗長にすることができますが、コールド パーティションはバックアップに依存します。 さらに信頼性の利点は、一部の種類の故障の爆発半径を減らすことです。 たとえば、障害が 1 つのシャードに影響を与える場合、他のシャードには影響しない可能性があります。

トレードオフ： 異なるデータ パーティション間の相互依存関係が強いため、パーティションの保守や変更が困難な場合があります。 これらの変更は、特に単一のデータ ストアと比較した場合に、データの整合性と整合性を検証する機能に影響する可能性があります。 パーティションの数が増えるにつれて、データの整合性を維持するための堅牢なプロセスの必要性がより重要になります。 これらの対策がないと、信頼性が損なわれる可能性があります。