Service Bus の障害および災害に対するアプリケーションの保護のベスト プラクティス
ミッション クリティカルなアプリケーションは、予期しない障害や災害が発生した場合でも継続して稼働する必要があります。 この記事では、発生する可能性がある Service Bus の障害や災害からアプリケーションを保護するために使用できる手法について説明します。
障害とは、Azure Service Bus が一時的に利用できなくなることです。 障害によって、メッセージング ストアなどの Service Bus の一部のコンポーネント、さらにはデータセンター全体に影響が及ぶ場合があります。 問題が解決されると、Service Bus は再び利用可能になります。 通常、故障によってメッセージなどのデータが失われることはありません。 コンポーネントのエラーの例としては、特定のメッセージング ストアが利用できなくなることが挙げられます。 データセンター全体の障害の例としては、データセンターの電源障害や、データセンターのネットワーク スイッチの障害などがあります。 障害は、数分間から数日間続く場合があります。
災害とは、Service Bus のスケール ユニットまたはデータセンターが永続的に失われることです。 データセンターは、再び利用可能になる場合とならない場合があります。 通常、災害によってメッセージなどのデータの一部またはすべてが失われます。 災害の例としては、火災、洪水、地震があります。
停止または災害に対する保護 - Premium レベル
Azure Service Bus Premium レベルには、高可用性とディザスター リカバリーという概念が組み込まれています。これらは、同じリージョン (Availability Zones 利用) にも異なるリージョン (geo ディザスター リカバリー利用) にも適用されます。
geo ディザスター リカバリー
Service Bus Premium レベルでは、名前空間のレベルで geo ディザスター リカバリーがサポートされています。 詳細については、「Azure Service Bus の geo ディザスター リカバリー」を参照してください。 Premium SKU でのみ利用できるディザスター リカバリー機能は、メタデータのディザスター リカバリーを実装しており、プライマリとセカンダリの名前空間を利用しています。 geo ディザスター リカバリーでは、エンティティのメタデータのみが、プライマリとセカンダリの名前空間の間でレプリケートされます。
可用性ゾーン
Service Bus Premium レベルは、同じ Azure リージョン内に障害から分離された場所を提供する可用性ゾーンをサポートしています。 Service Bus は、メッセージング ストアの 3つのコピー (1つのプライマリと 2つのセカンダリ) を管理します。 Service Bus では、データ操作および管理操作のために 3 つのコピーをすべて同期します。 プライマリ コピーがフェイルした場合には、セカンダリ コピーの 1つをプライマリに昇格させ、ダウンタイムを発生させません。 アプリケーションが Service Bus からの一時的な切断を認識した場合、SDK の再試行ロジックによって Service Bus に自動的に再接続します。
可用性ゾーンを使うと、メタデータとデータ (メッセージ) の両方が、可用性ゾーン内のデータ センター間でレプリケートされます。
注意
Premium レベルの可用性ゾーンのサポートは、可用性ゾーンが存在する Azure リージョンでのみ利用できます。
ポータルを使って Premium レベルの名前空間を作成すると、可用性ゾーンのサポートが名前空間で自動的に有効になります (選んだリージョンで使用できる場合)。 Azure Resource Manager/Bicep テンプレート、CLI、PowerShell など、他の方法を使って Premium レベルの名前空間を作成するときに、可用性ゾーンを有効にするには、プロパティ zoneRedundant を true に明示的に設定する必要があります (選んだリージョンで使用できる場合)。 この機能を使うための追加コストはなく、名前空間を作成した後でこの機能を無効または有効にすることはできません。
停止または災害に対する保護 - Standard レベル
Standard メッセージング価格レベルでデータセンターの停止に対する回復性を実現するには、アクティブなまたはパッシブ レプリケーションを使用できます。 どちらの方法でも、データセンターの障害時に特定のキューまたはトピックにアクセスできる状態を維持する必要がある場合は、両方の名前空間にそのキューまたはトピックを作成します。 両方のエンティティに同じ名前を付けることができます。 たとえば、プライマリ キューは contosoPrimary.servicebus.windows.net/myQueue を使用してアクセスでき、セカンダリ側は contosoSecondary.servicebus.windows.net/myQueue を使用してアクセスできます。
注意
アクティブ レプリケーションとパッシブ レプリケーションのセットアップは汎用ソリューションであり、Service Bus の固有の機能ではありません。 レプリケーション ロジック (2 つの異なる名前空間への送信) は送信側アプリケーションにあるため、受信側では、重複を検出するためのカスタム ロジックを用意する必要があります。
アプリケーションが、送信側から受信側への永続的な通信を必要としない場合、アプリケーションで永続的なクライアント側キューを実装することで、メッセージの消失を防止し、送信側を一時的な Service Bus エラーから保護できます。
アクティブ レプリケーション
アクティブ レプリケーションでは、すべての操作で両方の名前空間のエンティティを使用します。 メッセージを送信するクライアントはすべて、同じメッセージのコピーを 2 つ送信します。 1 つ目のコピーがプライマリ エンティティ (たとえば contosoPrimary.servicebus.windows.net/sales) に送信され、そのメッセージの 2 つ目のコピーはセカンダリ エンティティ (たとえば contosoSecondary.servicebus.windows.net/sales) に送信されます。
クライアントは両方のキューからメッセージを受信します。 受信側はメッセージの 1 つ目のコピーを処理し、2 つ目のコピーは抑制されます。 重複したメッセージを抑制するには、送信側が各メッセージに一意の識別子のタグを付ける必要があります。 メッセージのコピーには、両方とも同じ識別子のタグを付ける必要があります。 ServiceBusMessage.MessageId または ServiceBusMessage.Subject プロパティを使用するか、カスタム プロパティを使用してメッセージにタグを付けることができます。 受信側は、既に受信したメッセージの一覧を保持する必要があります。
[Service Bus Standard レベルでの geo レプリケーション][Service Bus Standard レベルでの geo レプリケーション] サンプルでは、メッセージング エンティティのアクティブなレプリケーションを示します。
Note
アクティブ レプリケーションの手法では操作の数が 2 倍になるので、この手法はコストの増加につながる可能性があります。
パッシブ レプリケーション
障害のない場合は、パッシブ レプリケーションは 2 つのメッセージング エンティティのうち 1 つのみを使用します。 クライアントは、アクティブなエンティティにメッセージを送信します。 アクティブなエンティティでの操作が失敗し、アクティブなエンティティをホストしているデータセンターが使用できない可能性があることを示すエラー コードが表示された場合、クライアントはメッセージのコピーをバックアップ エンティティに送信します。 この時点で、アクティブなエンティティとバックアップ エンティティの役割が切り替わります。 送信側クライアントは、前のアクティブなエンティティを新しいバックアップ エンティティと見なし、前のバックアップ エンティティを新しいアクティブなエンティティと見なします。 両方の送信操作が失敗した場合、2 つのエンティティの役割は変更されず、エラーが返されます。
クライアントは両方のキューからメッセージを受信します。 受信側は同じメッセージのコピーを 2 つ受信する可能性があるので、受信側では重複したメッセージを抑制する必要があります。 アクティブ レプリケーションの説明と同じ方法で重複を抑制することができます。
一般的に、パッシブ レプリケーションではほとんどの場合に操作が 1 つだけ実行されるので、アクティブ レプリケーションよりも経済的です。 遅延、スループット、および金銭的コストは、レプリケーションなしのシナリオと同じです。
パッシブ レプリケーションを使用する場合、次のシナリオではメッセージを喪失するか、2 回受信する可能性があります。
- メッセージの遅延または喪失:送信側からメッセージ m1 がプライマリ キューに正常に送信されてから、受信側で m1 を受信する前にプライマリ キューが使用不可になったとします。 送信側が後続のメッセージ m2 をセカンダリ キューに送信します。 プライマリ キューが一時的に使用できない場合、受信側はキューが再び使用可能になった後で m1 を受信します。 障害が発生した場合、受信側は m1 を受け取らない可能性があります。
- 重複した受信:送信側がメッセージ m をプライマリ キューに送信するとします。 Service Bus により m が適切に処理されますが、応答の送信に失敗します。 送信操作がタイムアウトになった後で、送信側が m の同一のコピーをセカンダリ キューに送信します。 プライマリ キューが使用不可になる前に受信側が m の 1 つ目のコピーを受信できる場合、受信側は m の両方のコピーをほぼ同時に受信します。 プライマリ キューが使用不可になる前に受信側が m の 1 つ目のコピーを受信できない場合、受信側は m の 2 つ目のコピーのみを最初に受信しますが、プライマリ キューが使用可能になったときに m の 1 つ目のコピーを受信します。
.NET Core を使用した Azure メッセージング レプリケーション タスク のサンプルでは、名前空間間のメッセージのレプリケーションを示します。
次のステップ
ディザスター リカバリーの詳細については、次の記事を参照してください。