この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。
| RE:07 | 自己保存と自己復旧の手段を実装することで、ワークロードの回復性を強化します。 組み込みの機能と確立されたクラウド パターンを使用して、インシデント中のワークロードの機能とインシデントからの復旧を支援します。 |
|---|
このガイドでは、信頼性を最適化するために、アプリケーション アーキテクチャに自己保存機能と自己復旧機能を構築するための推奨事項について説明します。
自己保存機能により、ワークロードに回復性が追加されます。 完全な停止の可能性を減らし、障害が発生したときにワークロードを正常に動作させるか、または機能低下状態で動作できるようにします。 自己復旧機能は、障害検出を組み込むことでダウンタイムを回避し、障害に対応するための自動修正アクションを実現するのに役立ちます。
定義
| 任期 | Definition |
|---|---|
| 自己復旧 | 影響を受けるコンポーネントを復旧し、必要に応じて冗長インフラストラクチャにフェールオーバーすることで、ワークロードで問題を自動的に解決する機能。 |
| 自己防衛の本能 | 潜在的な問題に対する回復性を備えるワークロードの能力。 |
冗長性のための設計
ワークロードを誤動作から保護するための最も効果的な戦略の 1 つは、すべてのコンポーネントに冗長性を組み込み、単一障害点を回避することです。 コンポーネントまたはワークロード全体を冗長リソースにフェールオーバーできるため、システム内のほとんどの障害を効率的に処理できます。
さまざまなレベルで冗長性を構築し、コンピューティング、ネットワーク、ストレージなどの冗長インフラストラクチャ コンポーネントを検討し、ソリューションの複数のインスタンスをデプロイすることを検討します。 ビジネス要件に応じて、1 つのリージョン内またはリージョン間で冗長性を構築できます。 また、復旧要件を満たすためにアクティブ/アクティブまたはアクティブ/パッシブのどちらの設計が必要かを決定することもできます。 詳細については、「 冗長性を確保するためのアーキテクチャ戦略 」および「 可用性ゾーンとリージョンを使用するためのアーキテクチャ戦略」を参照してください。
自己保存のための設計
自己保持のためにワークロードを設計するには、インフラストラクチャとアプリケーション アーキテクチャの設計パターンに従って、ワークロードの回復性を最適化します。 アプリケーションの完全な停止が発生する可能性を最小限に抑えるには、単一障害点を排除し、障害の爆発半径を最小限に抑えることで、ソリューションの回復性を高めます。 この記事の設計アプローチでは、ワークロードの回復性を強化し、ワークロードの定義済みの 信頼性目標を満たすいくつかのオプションを提供します。
インフラストラクチャ設計のガイダンスとパターン
インフラストラクチャ レベルでは、 冗長アーキテクチャ設計 では、 可用性ゾーンまたはリージョン間にデプロイされたリソースを使用して、重要なフローをサポートする必要があります。 可能な場合 は自動スケールを実装します 。 自動スケールは、予期しないアクティビティのバーストからワークロードを保護し、インフラストラクチャをさらに強化するのに役立ちます。
デプロイ スタンプ パターンまたはバルクヘッド パターンを使用して、問題が発生した場合のブラスト半径を最小限に抑えます。 これらのパターンは、個々のコンポーネントが使用できない場合にワークロードを使用できるように保つのに役立ちます。 自動スケーリング戦略と組み合わせて、次のアプリケーション設計パターンを使用します。
デプロイ スタンプ パターン: 複数のワークロードまたはテナントをホストおよび運用するために、さまざまなリソース グループをプロビジョニング、管理、監視します。 個々のコピー はスタンプと呼ばれ、 サービス ユニット、 スケール ユニット、 セルと呼ばれることもあります。
バルクヘッド パターン: コンシューマーの負荷と可用性の要件に基 づいて、サービス インスタンスをプールと呼ばれる異なるグループにパーティション分割します。 この設計は、障害を分離するのに役立ち、障害発生時でも一部のコンシューマーのサービス機能を維持できます。
アプリケーション設計のガイダンスとパターン
アプリケーション設計でモノリシック アプリケーションを構築しないでください。 適切に定義された標準を介して相互に通信する疎結合のサービスまたはマイクロサービスを使用して、1 つのコンポーネントで誤動作が発生した場合の広範な問題のリスクを軽減します。 たとえば、すべての非同期通信を処理するサービス バスの使用を標準化できます。 通信プロトコルを標準化することで、アプリケーションの設計が一貫して簡素化され、障害が発生したときにワークロードの信頼性が高くなり、トラブルシューティングが容易になります。 実用的な場合は、配信不能などのタイムアウトの問題を最小限に抑えるために、同期通信よりもコンポーネント間の非同期通信を優先します。
業界で実証済みのパターンを使用して、設計標準を開発し、アーキテクチャの側面を簡素化します。 信頼性のサポートに役立つ設計パターンについては、 信頼性パターン に関する記事を参照してください。
自動修復機能の設計
ワークロードを自己復旧用に設計するには、エラー検出を実装して、自動応答がトリガーされ、重要なフローが正常に復旧されるようにします。 ログ記録を有効にして、障害の性質と復旧の成功に関する運用上の分析情報を提供します。 クリティカル フローの自己復旧を実現するために行う方法は、そのフローに対して定義されている 信頼性ターゲット と、フローのコンポーネントと依存関係によって異なります。
インフラストラクチャ設計ガイダンス
インフラストラクチャ レベルでは、重要なフローを冗長アーキテクチャ設計でサポートし、それをサポートするコンポーネントに対して自動フェールオーバーを有効にする必要があります。 次の種類のサービスに対して自動フェールオーバーを有効にすることができます。
コンピューティング リソース: Azure Virtual Machine Scale Sets とほとんどのサービスとしてのプラットフォーム (PaaS) コンピューティング サービスは、自動フェールオーバー用に構成できます。
データベース: リレーショナル データベースは、Azure SQL フェールオーバー クラスター、Always On 可用性グループ、PaaS サービスの組み込み機能などのソリューションを使用して、自動フェールオーバー用に構成できます。 NoSQL データベースには、同様のクラスタリング機能と PaaS サービス用の組み込み機能があります。
ストレージ: 自動フェールオーバーで 冗長ストレージ オプション を使用します。
アプリケーション設計ガイダンス
信頼性をサポートする 設計パターンの 使用に加えて、自己復旧メカニズムの開発に役立つその他の戦略は次のとおりです。
実行時間の長いトランザクションにチェックポイントを使用する: チェックポイントは、実行時間の長い操作が失敗した場合に回復性を提供できます。 操作が再起動すると (たとえば、別の仮想マシンによって取得された場合)、最後のチェックポイントから再開できます。 タスクに関する状態情報を一定の間隔で記録するメカニズムを実装することを検討してください。 タスクを実行しているプロセスの任意のインスタンスからアクセスできる永続的ストレージにこの状態を保存します。 プロセスがシャットダウンされた場合、実行していた作業は、別のインスタンスを使用して最後のチェックポイントから再開できます。 NServiceBus や MassTransit など、この機能を提供するライブラリがあります。 これらは透過的に永続化状態です。この間隔は、Azure Service Bus のキューからのメッセージの処理に合わせて調整されます。
自動自己復旧アクションを実装します。 事前に決定された正常性状態の変更が検出されたときに監視ソリューションによってトリガーされる自動アクションを使用します。 たとえば、Web アプリが要求に応答していないことを監視で検出した場合は、PowerShell スクリプトを使用して自動化を構築し、アプリ サービスを再起動できます。 チームのスキル セットと推奨される開発テクノロジに応じて、Webhook または関数を使用して、より複雑な自動化アクションを構築します。 関数を使用してデータベースの調整に応答する例については、 イベント ベースのクラウド 自動化 リファレンス アーキテクチャを参照してください。 自動化されたアクションを使用すると、迅速に回復し、人間の介入の必要性を最小限に抑えることができます。
グレースフルデ低下モードを実装する
自己保存と自己修復のメカニズムにもかかわらず、1 つ以上のコンポーネントが一定の時間使用できなくなるほど誤動作する状況が発生する可能性があります。 このような場合、ワークロードは、ビジネスが機能低下状態を継続するのに十分な機能を維持できるのが理想的です。 これが可能であることを確認するには、グレースフルな低下モードを設計して実装します。 これは、失敗したコンポーネントに反応して有効になっている個別のワークフローです。 設計と実装に関する考慮事項は次のとおりです。
- エラー検出と自動開始: 監視システムとアラート システムは、機能低下したコンポーネントと失敗したコンポーネントを検出する必要があるため、これらのシグナルを使用して、グレースフルデ低下モードに切り替える必要があるタイミングを決定するワークフローを構築します。 その後、ワークフローは、影響を受けるコンポーネントとの間の呼び出しを、別のコンポーネントまたはその他の同様のアクションに自動的に再ルーティングする必要があります。
- 低下したユーザー エクスペリエンスを実装します。 ユーザーが残っている機能と変更された機能を確実に把握できるように、グレースフルな低下モードのユーザー向けの通知メカニズムを含めます。 これは通常、たとえば、カートに項目を追加するときのポップアップなど、ワークロードのさまざまな機能に関連付けられているメッセージに反映されます。
- ワークロードの重要な機能を完了するための代替パスを構築 します。ワークロードの 重要なフロー を反映し、コア コンポーネントが使用できないときにそれらのフローを維持する方法を決定します。 たとえば、データベースがダウンしている場合、アプリケーションはキャッシュされたデータを使用して読み取り専用モードに切り替えることができます。 この例をさらに詳しく説明するために、支払いゲートウェイがダウンしている場合、キャッシュされたデータを使用すると、ユーザーがカートを保存し、後で購入を完了できる場合があります。
一時的な障害を処理するためのメカニズムを実装する
ネットワーク タイムアウトなどの一時的な障害はクラウド ワークロードの一般的な問題であるため、それらを処理するメカニズムを用意することで、運用環境でワークロードを運用する際のダウンタイムとトラブルシューティング作業を最小限に抑えることができます。 一時的な障害が原因で失敗するほとんどの操作は、操作を再試行する前に十分な時間が許されると成功するため、一時的な障害を処理するための最も一般的な方法は再試行メカニズムを使用することです。 再試行戦略を設計するときは、次の点を考慮してください。
推奨事項と考慮事項の完全なレビューについては、 一時的な障害 設計ガイドを参照してください。
バックグラウンド ジョブを実装する
バックグラウンド ジョブは、ユーザー インターフェイス (UI) からタスクを切り離すことで、システムの信頼性を高める効果的な方法です。 ユーザー入力やフィードバックが不要で、UI の応答性に影響しない場合は、タスクをバックグラウンド ジョブとして実装します。
バックグラウンド ジョブの一般的な例を次に示します。
- 複雑な計算の実行や構造モデルの分析など、CPU 負荷の高いジョブ。
- 複数のストレージ操作の実行や大きなファイルのインデックス作成など、I/O 負荷の高いジョブ。
- データを定期的に更新したり、特定の時刻にタスクを処理したりするなどのバッチ ジョブ。
- 注文の完了やサービスとシステムのプロビジョニングなど、実行時間の長いワークフロー。
推奨事項と考慮事項の完全なレビューについては、 バックグラウンド ジョブ の設計ガイドを参照してください。
Azure ファシリテーション
ほとんどの Azure サービスとクライアント SDK には、再試行メカニズムが含まれています。 ただし、各サービスの特性と要件が異なるため、各再試行メカニズムは特定のサービスに合わせて調整されるため、異なります。 詳細については、「 一時的な障害処理の推奨事項」を参照してください。
電子メール、音声、SMS などの通知に Azure Monitor アクション グループ を使用し、自動アクションをトリガーします。 エラーが通知されたら、Azure Automation Runbook、Azure Event Hubs、Azure 関数、ロジック アプリ、または Webhook をトリガーして、自動復旧アクションを実行します。
Example
一部のパターンのユース ケースの例については、 .NET 用の信頼性の高い Web アプリ パターンを参照してください。 参照実装をデプロイするには、次の手順に従います。
関連リンク
信頼性チェックリスト
推奨事項の完全なセットを参照してください。