自己修復と自己保存に関する推奨事項

  • [アーティクル]

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

RE:07 自己保存と自己復旧の対策を実装することで、ワークロードの回復性と回復性を強化します。 インフラストラクチャ ベースの信頼性パターンとソフトウェアベースの設計パターンを使用して、コンポーネントの障害や一時的なエラーを処理することで、ソリューションに機能を組み込みます。 ソリューション コンポーネントの障害を検出し、ワークロードが引き続き完全または縮小された機能で動作している間に、修正アクションを自動的に開始する機能をシステムに組み込みます。

関連ガイド:バックグラウンドジョブ | 一時的な障害

このガイドでは、信頼性を最適化するために、アプリケーション アーキテクチャに自己復旧機能と自己保持機能を構築するための推奨事項について説明します。

自己保存機能により、ワークロードに回復性が追加されます。 これにより、完全な停止の可能性が減り、障害が発生したコンポーネントが復旧されている間にワークロードが低下した状態で動作できるようになります。 自己復旧機能は、障害検出と自動修正アクションを組み込んでさまざまな障害の種類に対応することで、ダウンタイムを回避するのに役立ちます。

このガイドでは、自己保存と自己修復に焦点を当てた設計パターンについて説明します。 それらをワークロードに組み込んで、回復性と回復性を強化します。 パターンを実装しないと、避けられない問題が発生したときにアプリが失敗するリスクがあります。

定義

期間 定義
自己復旧 影響を受けるコンポーネントを復旧し、必要に応じて冗長インフラストラクチャにフェールオーバーすることで、ワークロードが問題を自動的に解決する機能。
自己 潜在的な問題に対して回復性を持つワークロードの機能。

主要な設計戦略

自己保存ガイダンス

自己保存のためにワークロードを設計するには、インフラストラクチャとアプリケーション アーキテクチャの設計パターンに従って、ワークロードの回復性を最適化します。 アプリケーションの完全停止が発生する可能性を最小限に抑えるには、単一障害点を排除し、障害の爆発半径を最小限に抑えることで、ソリューションの回復性を高めます。 この記事の設計アプローチでは、ワークロードの回復性を強化し、ワークロードの定義された 信頼性目標を満たすいくつかのオプションを提供します。

インフラストラクチャ設計のガイダンスとパターン

インフラストラクチャ レベルでは、 冗長アーキテクチャ設計 では、 可用性ゾーン または リージョン間にデプロイされたリソースを使用して、重要なフローをサポートする必要があります。 可能 な場合は自動スケーリングを実装します 。 自動スケーリングは、予期しないアクティビティのバーストからワークロードを保護し、インフラストラクチャをさらに強化するのに役立ちます。

問題が発生したときに爆発半径を最小限に抑えるには、デプロイ スタンプ パターンまたは Bulkhead パターンを使用します。 これらのパターンは、個々のコンポーネントが使用できない場合にワークロードを使用可能に保つのに役立ちます。 自動スケーリング戦略と組み合わせて、次のアプリケーション設計パターンを使用します。

  • デプロイ スタンプ パターン: 複数のワークロードまたはテナントをホストおよび運用するためのさまざまなリソース グループをプロビジョニング、管理、監視します。 個々のコピーはスタンプと呼ばれ、サービス ユニット、スケール ユニット、またはセルと呼ばれる場合もあります。

  • バルクヘッド パターン: コンシューマーの負荷と可用性の要件に基づいて、サービス インスタンスを プールと呼ばれる異なるグループにパーティション分割します。 この設計は、障害を分離するのに役立ち、障害発生時でも一部のコンシューマーのサービス機能を維持できます。

アプリケーション設計のガイダンスとパターン

アプリケーション設計でモノリシック アプリケーションを構築しないでください。 適切に定義された標準を介して相互に通信する疎結合サービスまたはマイクロサービスを使用して、1 つのコンポーネントに誤動作が発生した場合の広範な問題のリスクを軽減します。 たとえば、すべての非同期通信を処理するサービス バスの使用を標準化できます。 通信プロトコルを標準化することで、アプリケーションの設計が一貫して簡素化されるため、誤動作が発生したときにワークロードの信頼性が高くなり、トラブルシューティングが容易になります。 実用的な場合は、配信不能などのタイムアウトの問題を最小限に抑えるために、同期通信よりもコンポーネント間の非同期通信を優先します。 次の設計パターンは、ワークロードを整理し、ビジネス要件に最適な方法でコンポーネント間の通信を定義するのに役立ちます。

  • アンバサダー パターン: ビジネス ロジックをネットワーク コードと回復性ロジックから分離します。 コンシューマー サービスまたはアプリケーションの代わりにネットワーク要求を送信するヘルパー サービスを作成します。 このパターンを使用して、再試行メカニズムまたは回線切断を実装できます。

  • 非同期 Request-Reply パターン: バックエンド処理を非同期にする必要があるが、フロントエンドに明確な応答が必要な場合は、フロントエンド ホストからバックエンド処理を切り離します。

  • キャッシュアサイド パターン: データ ストアからキャッシュにオンデマンドでデータを読み込みます。 このパターンにより、パフォーマンスが向上し、キャッシュに保持されているデータと基になるデータ ストア内のデータの一貫性を維持するのに役立ちます。

  • サーキット ブレーカー パターン: サーキット ブレーカーを使用して、操作の続行を許可するか、最近の障害の数に基づいて例外を返すかを事前に判断します。

  • 要求チェック パターン: 大きなメッセージを要求チェックとペイロードに分割します。 要求チェックをメッセージング プラットフォームに送信し、ペイロードを外部サービスに格納します。 このパターンを使用すると、メッセージ バスを保護し、クライアントが過負荷や速度低下を防ぎながら、大きなメッセージを処理できます。

  • 競合コンシューマー パターン: 複数の同時コンシューマーが、同じメッセージング チャネルで受信したメッセージを処理できるようにします。 システムは複数のメッセージを同時に処理できるため、スループットが最適化され、スケーラビリティと可用性が向上し、ワークロードのバランスが取られます。

  • 要求タイムアウトの構成: サービスまたはデータベースへの呼び出しの要求タイムアウトを構成します。 通常、データベース接続のタイムアウトは 30 秒に設定されます。

  • ゲートキーパー パターン: 専用のホスト インスタンスを使用して、クライアントとアプリケーションまたはサービス間の要求を仲介することで、アプリケーションとサービスを保護します。 ブローカーは要求を検証してサニタイズし、システムの攻撃対象領域を制限するための追加のセキュリティ層を提供できます。

  • キューベースの負荷平準化パターン: 各タスクを非同期的に実行できるように、それらの間のキューを使用して、ソリューション内のサービスからタスクを切り離します。 タスクと呼び出すサービスの間のバッファーとしてキューを使用すると、サービスが失敗したり、タスクがタイムアウトしたりする可能性のある断続的な負荷をスムーズにすることができます。このパターンは、タスクとサービスの可用性と応答性に対する需要のピークの影響を最小限に抑えるのに役立ちます。

  • 調整パターン: アプリケーション、個々のテナント、またはサービス全体のインスタンスによって使用されるリソースの消費量を制御します。 このパターンにより、需要の増加がリソースに極端な負荷をかけている場合でも、システムは引き続き機能し、サービス レベル アグリーメント (SLA) を満たすことができます。

  • 一時的な障害処理パターンと再試行パターン: ワークロードの回復性を提供するために、一時的な障害を処理する戦略を実装します。 一時的な障害は、クラウド環境で通常発生し、予期される発生です。 一時的な障害の一般的な原因としては、ネットワーク接続の一時的な損失、データベース接続の切断、サービスがビジー状態の場合のタイムアウトなどがあります。 再試行戦略の開発の詳細については、このシリーズ の一時的な障害処理ガイド を参照してください。

バックグラウンド ジョブ

バックグラウンド ジョブは、タスクをユーザー インターフェイス (UI) から切り離すことで、システムの信頼性を向上させる効果的な方法です。 ユーザー入力やフィードバックが不要で、UI の応答性に影響しない場合は、タスクをバックグラウンド ジョブとして実装します。

バックグラウンド ジョブの一般的な例を次に示します。

  • 複雑な計算の実行や構造モデルの分析など、CPU 負荷の高いジョブ。
  • 複数のストレージ操作の実行や大きなファイルのインデックス作成など、I/O 負荷の高いジョブ。
  • データを定期的に更新したり、特定の時刻にタスクを処理したりするバッチ ジョブ。
  • 注文の完了やサービスとシステムのプロビジョニングなど、実行時間の長いワークフロー。

詳細については、「 バックグラウンド ジョブの推奨事項」を参照してください。

自己復旧ガイダンス

自己復旧用にワークロードを設計するには、自動応答がトリガーされ、クリティカル フローが正常に復旧されるように、障害検出を実装します。 ログ記録を有効にして、障害の性質と回復の成功に関する運用上の分析情報を提供します。 クリティカル フローの自己復旧を実現するために行う方法は、そのフローに対して定義されている 信頼性ターゲット と、フローのコンポーネントと依存関係によって異なります。

インフラストラクチャ設計ガイダンス

インフラストラクチャ レベルでは、重要なフローは、それをサポートするコンポーネントに対して自動フェールオーバーが有効になっている 冗長アーキテクチャ設計 でサポートされている必要があります。 次の種類のサービスに対して自動フェールオーバーを有効にすることができます。

  • コンピューティング リソース: Azure Virtual Machine Scale Setsとほとんどのサービスとしてのプラットフォーム (PaaS) コンピューティング サービスは、自動フェールオーバー用に構成できます。

  • データベース: リレーショナル データベースは、Azure SQL フェールオーバー クラスター、Always On可用性グループ、PaaS サービスを使用した組み込み機能などのソリューションを使用して、自動フェールオーバー用に構成できます。 NoSQL データベースには、同様のクラスタリング機能と PaaS サービス用の組み込み機能があります。

  • ストレージ: 自動フェールオーバーで 冗長ストレージ オプション を使用します。

アプリケーション設計のガイダンスとパターン

  • 不適切なアクターをブロックする: クライアントを調整しても、クライアントが悪意のある動作をしていたという意味にはなりません。 クライアントがサービス クォータを超えた可能性があります。 ただし、クライアントが常にクォータを超えている場合や、動作が悪い場合は、それらをブロックする可能性があります。 クライアントがブロック解除を要求するための帯域外プロセスを定義します。

  • サーキット ブレーカー パターン: 再試行メカニズムが開始された後も障害が続く場合は、呼び出しのバックログの増加に起因する連鎖障害のリスクがあります。 再試行メカニズムを操作するように設計されたサーキット ブレーカーは、失敗する可能性がある操作をアプリが繰り返し実行することを防ぐことで、障害が連鎖するリスクを制限します。

  • 補正トランザクション パターン: 一連の手順で構成される最終的に一貫性のある操作を使用する場合は、補正トランザクション パターンを実装します。 1 つ以上のステップが失敗した場合は、このパターンを使用して、ステップが実行した作業を元に戻すことができます。

  • 正常に低下する: 問題を回避できない場合がありますが、機能を減らすことができます。 書籍のカタログを表示するアプリケーションを例に説明します。 そのアプリケーションが表紙のサムネイル画像を取得できない場合は、プレース ホルダー イメージを表示することができます。 サブシステム全体が、アプリケーションにとって重要でない場合もあります。 たとえば、eコマース Web サイトの場合、製品の推奨事項を表示することは、注文の処理よりも重要度が低い可能性があります。 正常な低下には、自動フェールオーバー操作も含まれます。 プライマリ インスタンスの問題が原因でデータベースがレプリカに自動的にフェールオーバーされると、パフォーマンスが短時間低下します。

  • リーダー選択パターン: タスクを調整する必要がある場合は、リーダーの選択を使用してコーディネーターを選択し、1 つのコーディネーターが単一障害点でないようにします。 コーディネーターが失敗すると、新しいコーディネーターが選択されます。 リーダー選択アルゴリズムをゼロから実装するのではなく、 ZooKeeper などの既製のソリューションを検討してください。

  • テスト パターン: 標準のテスト手順の一部として実装するパターンのテストを含めます。

  • 実行時間の長いトランザクションにチェックポイントを使用する: チェックポイントは、実行時間の長い操作が失敗した場合に回復性を提供できます。 操作が再起動すると (たとえば、別の仮想マシンによって取得された場合)、最後のチェックポイントから再開できます。 タスクに関する状態情報を一定の間隔で記録するメカニズムを実装することを検討してください。 タスクを実行しているプロセスの任意のインスタンスからアクセスできる永続ストレージにこの状態を保存します。 プロセスがシャットダウンされている場合は、別のインスタンスを使用して、実行していた作業を最後のチェックポイントから再開できます。 NServiceBus や MassTransit など、この機能を備えたライブラリがあります。 これにより、間隔が Azure Service Bus 内のキューからのメッセージの処理と一致する状態が透過的に保持されます。

自動自己復旧アクション

自己復旧のもう 1 つのアプローチは、事前に決定された正常性状態の変化が検出されたときに監視ソリューションによってトリガーされる自動アクションの使用です。 たとえば、Web アプリが要求に応答していないことが監視で検出された場合は、PowerShell スクリプトを使用して自動化を構築し、アプリ サービスを再起動できます。 チームのスキル セットと推奨される開発テクノロジに応じて、Webhook または関数を使用して、より複雑な自動化アクションを構築します。 関数を使用してデータベースの調整に応答する例については、 イベント ベースのクラウド オートメーション 参照アーキテクチャに関するページを参照してください。 自動化されたアクションを使用すると、迅速に回復し、人間の介入の必要性を最小限に抑えることができます。

Azure ファシリテーション

ほとんどの Azure サービスとクライアント SDK には、再試行メカニズムが組み込まれています。 ただし、各サービスの特性と要件が異なるため、各再試行メカニズムは特定のサービスに合わせて調整されるため、異なります。 詳細については、「 一時的な障害処理に関する推奨事項」を参照してください。

電子メール、音声、SMS などの通知に Azure Monitor アクション グループ を使用し、自動アクションをトリガーします。 エラーが通知されたら、Azure Automation Runbook、Azure Event Hubs、Azure 関数、ロジック アプリ、または Webhook をトリガーして、自動復旧アクションを実行します。

考慮事項

各パターンの考慮事項について理解します。 実装する前に、パターンがワークロードとビジネス要件に適していることを確認します。

例

一部のパターンのユース ケースの例については、 .NET の信頼性の高い Web アプリ パターンに関するページを参照してください。 参照実装をデプロイするには、次の手順に従います。

信頼性チェックリスト

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

信頼性チェックリスト