次の方法で共有

self-healing と自己保存に関する推奨事項

  • [アーティクル]

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

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

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

このガイドでは、アプリケーション アーキテクチャに self-healing 機能と自己保存機能を組み込んで信頼性を最適化するための推奨事項について説明します。

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

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

定義

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

主要な設計戦略

自己保存のための設計

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

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

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

デプロイ スタンプ パターンまたはバルクヘッド パターンを使用して、問題が発生したときの影響範囲を最小限に抑えます。 これらのパターンは、個々のコンポーネントが使用できない場合にワークロードを使用できるように維持するのに役立ちます。 自動スケーリング戦略と組み合わせて、次のアプリケーション設計パターンを使用します。

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

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

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

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

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

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

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

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

  • クレーム チェック パターン: 大規模メッセージをクレーム チェックとペイロードに分割します。 クレーム チェックをメッセージング プラットフォームに送信し、ペイロードを外部サービスに保存します。 このパターンを使用すると、メッセージ バスを保護し、クライアントで大きな負荷や速度の低下が発生しないように維持しながら、大規模メッセージを処理できます。

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

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

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

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

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

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

バックグラウンド ジョブ

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

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

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

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

self-healing の設計

ワークロードを self-healing 用に設計するには、自動応答がトリガーされ、重要なフローが適切に回復するように障害検出を実装します。 ログ記録を有効にして、障害の性質と復旧の成功に関する運用上の分析情報を提供します。 重要なフローの self-healing を実現するために実施する方法は、そのフローに対して定義されている信頼性目標と、フローのコンポーネントおよび依存関係によって異なります。

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

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

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

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

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

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

  • 問題のあるユーザーをブロック: クライアントを制限しても、そのクライアントが悪意を持って操作していたことにはなりません。 そのクライアントがサービスのクォータを超えただけの場合もあります。 しかしクライアントが一貫してクォータを超えるか、不適切な動作をする場合は、ブロックすることも考えられます。 クライアントがブロック解除を要求できるように、定型外のプロセスを定義しておきます。

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

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

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

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

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

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

自動 self-healing アクション

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

Azure ファシリテーション

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

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

考慮事項

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

例

いくつかのパターンのユース ケースの例については、.NET に対して信頼性の高い Web アプリ パターンに関する記事を参照してください。 参照実装をデプロイするためのこれらの手順に従います。

信頼性チェックリスト

レコメンデーションの完全なセットを参照してください。

信頼性チェックリスト