次の方法で共有

Service Bus の障害および災害に対するアプリケーションの保護のベスト プラクティス

  • [アーティクル]

ミッション クリティカルなアプリケーションは、予期しない障害や災害が発生した場合でも継続して稼働する必要があります。 データ処理リソースの大きな損害をもたらす停止に対する回復力は、多くの企業にとっての要件であり、業界の規制によって要求される場合もあります。 この記事では、発生する可能性がある Service Bus の障害や災害からアプリケーションを保護するために使用できる手法について説明します。

Azure Service Bus により、1 つのデータセンター内の複数の障害ドメインにまたがるクラスター間で、個々のマシンまたはラック全体の致命的な障害のリスクが既に分散されています。また、透過的な障害検出およびフェールオーバー メカニズムが実装されるため、通常はそのような障害発生時にも、顕著な中断なしに、保証されたサービス レベル内でサービスが動作し続けます。

さらに、物理的に分離された 3 つの施設間 (可用性ゾーン) で停止リスクがさらに分散されます。また、サービスには、データセンターの致命的な損失に瞬時に対処するための十分な容量が予約されています。 可用性ゾーンのサポートする、障害ドメイン内のオールアクティブ Azure Service Bus クラスター モデルは、致命的なハードウェア障害またはデータセンター機能全体の致命的な損失が発生した場合の回復性に関して、オンプレミスのメッセージ ブローカー製品よりも優れています。 それでも、広範囲の物理的な破壊によって、これらの手段によっても十分に防御できない致命的な状況が生じるおそれがあります。

Service Bus geo ディザスター リカバリーと geo レプリケーションの機能は、容易にこの大きさの災害から復旧し、アプリケーションの構成を変更することなく、障害が発生した Azure リージョンを完全に破棄できるように設計されています。

故障と災害

"故障" と "災害" の違いに注意してください。

故障とは、Azure Service Bus が一時的に使用不可能になっていることです。メッセージング ストアなどサービスの一部のコンポーネントや、場合によってはデータセンター全体に影響を与えることがあります。 しかし、問題が解決されると、Service Bus は再び使用可能になります。 通常、故障によってメッセージなどのデータが失われることはありません。 コンポーネントのエラーの例としては、特定のメッセージング ストアが利用できなくなることが挙げられます。 データセンター全体の障害の例としては、データセンターの電源障害や、データセンターのネットワーク スイッチの障害などがあります。 障害は、数分間から数日間続く場合があります。 一時的な問題やネットワークの問題によって、接続が短時間失われるだけの故障もあります。

"災害" は、Service Bus クラスター、Azure リージョン、またはデータ センターの永久または長期間損失として定義されています。 リージョンまたはデータセンターは、再び利用可能になる場合も、ならない場合もあり、数時間または数日停止する可能性もあります。 このような災害の例としては、火災、洪水、地震があります。 永続的な災害により、メッセージやイベントなどのデータが失われる可能性があります。 ただし、ほとんどの場合、データ センターが稼働状態に戻れば、データが失われることはなく、メッセージを復元できます。

停止または災害に対する保護

Premium レベルの Azure Service Bus では、geo ディザスター リカバリーを提供する機能が 2 つあります。 まず、メタデータ (エンティティ、構成、プロパティ) のレプリケーションを提供する geo ディザスター リカバリー (メタデータ DR) があります。 2 つ目は、現在パブリック プレビュー段階である geo レプリケーションです。メタデータとデータ (メッセージ データとメッセージ プロパティまたは状態の変更) 自体の両方のレプリケーションを提供します。 どちらの geo ディザスター リカバリー機能も、可用性ゾーンと混同しないでください。 メタデータ DR か geo レプリケーションかに関係なく、両方の geo リカバリー機能により、米国東部や米国西部などの Azure リージョン間の回復性を実現できます。

可用性ゾーンはすべての Service Bus レベルで使用できます。また、サポートにより、米国東部などの特定の地域内で回復性を実現できます。 Microsoft Azure でのディザスター リカバリーの詳細については、こちらの記事をご覧ください。

Azure Service Bus Premium レベルには、高可用性とディザスター リカバリーという概念が組み込まれています。これらは、同じリージョン (可用性ゾーンを利用) にも異なるリージョン (geo ディザスター リカバリーと geo レプリケーションを利用) にも適用されます。

geo ディザスター リカバリーのオプション

geo ディザスター リカバリー

Service Bus Premium レベルでは、名前空間のレベルで geo ディザスター リカバリーがサポートされています。 詳細については、「Azure Service Bus の geo ディザスター リカバリー」を参照してください。 Premium レベルでのみ利用できる geo ディザスター リカバリー機能は、メタデータのディザスター リカバリーを実装しており、プライマリとセカンダリの名前空間を利用しています。 geo ディザスター リカバリーでは、エンティティのメタデータのみが、プライマリとセカンダリの名前空間の間でレプリケートされます。

geo レプリケーション

Service Bus Premium レベルでは、名前空間レベルで geo レプリケーションもサポートされています。 詳細については、「Azure Service Bus geo レプリケーション (パブリック プレビュー)」を参照してください。 geo レプリケーション機能は、Premium レベルでのみ使用可能であり、現在はパブリック プレビュー段階です。また、メタデータとデータのディザスター リカバリーを実装し、プライマリとセカンダリのリージョンに依存しています。 geo レプリケーションを使用すると、エンティティのメタデータとデータの両方がプライマリとセカンダリのリージョン間でレプリケートされます。

機能の大まかな違い

geo ディザスター リカバリー (メタデータ DR) 機能を使うと、名前空間のメタデータをプライマリ名前空間からセカンダリ名前空間にレプリケートすることができます。 セカンダリ リージョンへの 1 回限りのフェールオーバーをサポートします。 お客様が開始したフェールオーバー中に、名前空間のエイリアス名がセカンダリ名前空間に再割り当てされ、ペアリングは解除されます。 メタデータ以外のデータはレプリケートされず、RBAC 割り当てもレプリケートされません。

geo レプリケーション機能を使うと、メタデータとすべてのデータをプライマリ リージョンから 1 つ以上のセカンダリ リージョンにレプリケートすることができます。 お客様がフェールオーバーを実行すると、選んだセカンダリがプライマリになり、前のプライマリがセカンダリになります。 ユーザーは、必要に応じて元のプライマリへのフェールオーバーを実行できます。

可用性ゾーン

すべての Service Bus レベルでは、同じ Azure リージョン内に障害から分離された場所を提供する可用性ゾーンがサポートされています。 Service Bus では、メッセージング ストアの 3 つのコピー (1 つのプライマリと 2 つのセカンダリ) を管理します。 Service Bus では、データ操作および管理操作のために 3 つのコピーをすべて同期します。 プライマリ コピーがフェイルした場合には、セカンダリ コピーの 1つをプライマリに昇格させ、ダウンタイムを発生させません。 アプリケーションが Service Bus からの一時的な切断を認識した場合、SDK の再試行ロジックによって Service Bus に自動的に再接続します。

可用性ゾーンを使うと、メタデータとデータ (メッセージ) の両方が、可用性ゾーン内のデータ センター間でレプリケートされます。

Note

可用性ゾーンのサポートは、可用性ゾーンが存在する Azure リージョンでのみ利用できます。

名前空間を作成すると、(選んだリージョンで使用可能な場合) 可用性ゾーンのサポートが名前空間に対して自動的に有効になります。 この機能を使うための追加コストはなく、名前空間を作成した後でこの機能を無効または有効にすることはできません。

Note

以前は、可用性ゾーンを有効にするにはプロパティ zoneRedundant を true に設定する必要がありましたが、この動作は既定で可用性ゾーンが有効になるように変更されました。 既存の名前空間も可用性ゾーンに移行され、プロパティ zoneRedundant は非推奨になっています。 可用性ゾーンが有効な場合でも、プロパティ zoneRedundant は false と表示される場合があります。

災害に対する保護 - Standard レベル

Service Bus 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 プロパティを使用するか、カスタム プロパティを使用してメッセージにタグを付けることができます。 受信側は、既に受信したメッセージの一覧を保持する必要があります。

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 メッセージング レプリケーション タスク のサンプルでは、名前空間間のメッセージのレプリケーションを示します。

次のステップ

ディザスター リカバリーの詳細については、次の記事を参照してください。