セールス: 1-800-867-1380

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

更新日: 2015年7月

ミッション クリティカルなアプリケーションは、計画外の障害や災害が発生した場合でも継続的に稼働する必要があります。このトピックでは、発生する可能性がある Service Bus の障害や災害からアプリケーションを保護するために使用できる手法について説明します。

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

災害とは、Service Bus のスケール ユニットまたはデータセンターが永続的に失われることです。データセンターは、再び利用可能になる場合も、ならない場合もあります。一般的に、災害によってメッセージなどのデータの一部またはすべてが失われます。災害の例としては、火災、洪水、地震があります。

Service Bus では、複数のメッセージング ストアを使用し、キューやトピックに送信されたメッセージを格納します。パーティション分割されていないキューやトピックは 1 つのメッセージング ストアに割り当てられます。メッセージング ストアが利用できない場合、そのキューやトピックに対するすべての操作が失敗します。

Service Bus のメッセージング エンティティ (キュー、トピック、リレー) はすべて、データセンターと連携する 1 つのサービスの名前空間に存在します。Service Bus では、データの自動 geo レプリケーションを有効にすることや、サービスの名前空間が複数のデータ センターにまたがることは許可されません。

ACS の資格情報を使用している場合に ACS を使用できなくなると、クライアントはトークンを取得できなくできます。ACS が停止した時点でトークンを取得しているクライアントは、トークンの期限が切れるまで引き続き Service Bus を使用できます。トークンの既定の有効期間は 3 時間です。

ACS の障害への対処として、Shared Access Signature (SAS) トークンを使用します。この場合、クライアントはシークレット キー付きの自主生成したトークンに署名することで Service Bus に対して直接認証します。ACS への呼び出しは必要ありません。SAS トークンの詳細情報については、「Service Bus 認証」を参照してください。

パーティション分割されていないキューやトピックは 1 つのメッセージング ストアに割り当てられます。メッセージング ストアが利用できない場合、そのキューやトピックに対するすべての操作が失敗します。一方、パーティション分割されたキューは複数のフラグメントで構成されます。各フラグメントは異なるメッセージング ストアに格納されます。パーティション分割されたキューまたはトピックにメッセージが送信されると、Service Bus はそのメッセージをフラグメントのいずれかに割り当てます。対応するメッセージング ストアが利用できない場合、可能であれば Service Bus はメッセージを別のフラグメントに書き込みます。パーティション分割されたエンティティの詳細情報については、「メッセージング エンティティのパーティション分割」を参照してください。

2 つのデータセンター間でのフェールオーバーを可能にするために、各データセンターに 1 つの Service Bus サービスの名前空間を作成することができます。たとえば、Service Bus サービスの名前空間 contosoPrimary.servicebus.windows.net を米国 (北/中央) 地域に置き、contosoSecondary.servicebus.windows.net を米国 (南部/中央) 地域に置くことができます。データセンターの障害発生時にも Service Bus メッセージング エンティティがアクセス可能な状態を維持する必要がある場合、両方のサービスの名前空間内にエンティティを作成します。

詳細については、TechNet の「については、「非同期メッセージング パターンと高可用性」の「Azure データセンター内の Service Bus のエラー」のセクションを参照してください。

リレー エンドポイントの geo レプリケーションにより、Service Bus 障害発生時にリレー エンドポイントを公開するサービスにアクセスできるようになります。geo レプリケーションを実現するには、異なる名前空間内に 2 つのリレー エンドポイントを作成する必要があります。両方のサービスの名前空間が異なるデータセンターに存在し、両方のエンドポイントに異なる名前が付けられている必要があります。たとえば、プライマリ エンドポイントは contosoPrimary.servicebus.windows.net/myPrimaryService を使用してアクセスでき、セカンダリ側は contosoSecondary.servicebus.windows.net/mySecondaryService を使用してアクセスできます。

その後、サービスは、両方のエンドポイント上でリッスンし、クライアントはどちらかのエンドポイントを介してサービスを呼び出すことができます。クライアント アプリケーションは、いずれかのリレー エンドポイントをプライマリ エンドポイントとしてランダムに選択して、アクティブなエンドポイントに要求を送信します。操作が失敗してエラー コードが表示された場合、このエラーは、リレー エンドポイントが使用できないことを示します。アプリケーションは、バックアップ エンドポイントへのチャネルを開き、要求を再び発行します。この時点で、アクティブなエンドポイントとバックアップ エンドポイントの役割が切り替わります。クライアント アプリケーションは、前のアクティブなエンドポイントを新しいバックアップ エンドポイントと見なし、前のバックアップ エンドポイントを新しいアクティブなエンドポイントと見なします。両方の送信操作が失敗した場合、2 つのエンティティの役割は変更されず、エラーが返されます。

Service Bus リレー メッセージを使用した geo レプリケーションのサンプルでは、リレーをレプリケートする方法を説明しています。

仲介型メッセージングを使用する際、データセンターの障害から復元できるように、Service Bus では、アクティブ レプリケーションとパッシブ レプリケーションの 2 つの方法がサポートされています。どちらの方法でも、データ センターの障害発生時に特定のキューまたはトピックにアクセス可能な状態を維持する必要がある場合は、両方の名前空間にそのキューまたはトピックを作成します。両方のエンティティに同じ名前を付けることができます。たとえば、プライマリ キューは contosoPrimary.servicebus.windows.net/myQueue を使用してアクセスでき、セカンダリ側は contosoSecondary.servicebus.windows.net/myQueue を使用してアクセスできます。

アプリケーションが、送信側から受信側への永続的な通信を必要としない場合、アプリケーションで永続的なクライアント側キューを実装することで、メッセージの消失を防止し、送信側を一時的な Service Bus エラーから保護できます。

アクティブ レプリケーションでは、すべての操作で両方のサービスの名前空間のエンティティを使用します。メッセージを送信するクライアントはすべて、同じメッセージのコピーを 2 つ送信します。最初のコピーがプライマリ エンティティ (たとえば contosoPrimary.servicebus.windows.net/sales) に送信され、メッセージの 2 つ目のコピーはセカンダリ エンティティ (たとえば contosoSecondary.servicebus.windows.net/sales) に送信されます。

クライアントは両方のキューからメッセージを受信します。受信側はメッセージの最初のコピーを処理し、2 つ目のコピーは抑制されます。重複したメッセージを抑制するには、送信側が各メッセージに一意の識別子のタグを付ける必要があります。メッセージのコピーは両方とも同じ識別子でタグ付けする必要があります。Microsoft.ServiceBus.Messaging.BrokeredMessage.MessageId プロパティ、Microsoft.ServiceBus.Messaging.BrokeredMessage.Label プロパティ、またはカスタム プロパティを使用して、メッセージにタグを付けることができます。受信側は、既に受信したメッセージの一覧を保持する必要があります。

Service Bus の仲介型メッセージを使用した geo レプリケーションのサンプルでは、メッセージング エンティティのアクティブ レプリケーションについて説明しています。

noteメモ
アクティブ レプリケーションの手法では操作の数が 2 倍になるので、この手法はコストの増加につながる可能性があります。

障害のないケースでは、パッシブ レプリケーションは 2 つのメッセージング エンティティのうち 1 つのみを使用します。クライアントは、アクティブなエンティティにメッセージを送信します。アクティブなエンティティでの操作が失敗し、アクティブなエンティティをホストしているデータセンターが使用できない可能性があることを示すエラー コードが表示された場合、クライアントはメッセージのコピーをバックアップ エンティティに送信します。この時点で、アクティブなエンティティとバックアップ エンティティの役割が切り替わります。送信側クライアントは、前のアクティブなエンティティを新しいバックアップ エンティティと見なし、前のバックアップ エンティティを新しいアクティブなエンティティと見なします。両方の送信操作が失敗した場合、2 つのエンティティの役割は変更されず、エラーが返されます。

クライアントは両方のキューからメッセージを受信します。受信側は同じメッセージのコピーを 2 つ受信する可能性があるので、受信側では重複したメッセージを抑制する必要があります。アクティブ レプリケーションの説明と同じ方法で重複を抑制することができます。

一般的に、パッシブ レプリケーションではほとんどの場合に 1 つの操作のみが実行されるので、アクティブ レプリケーションよりも経済的です。遅延、スループット、および金銭的コストはレプリケーションなしのシナリオと同じです。

パッシブ レプリケーションを使用する場合、次のシナリオではメッセージが失われたり 2 回受信したりする可能性があります。

  • メッセージの遅延または喪失: 送信側からメッセージ m1 がプライマリ キューに正常に送信されてから、受信側で m1 を受信する前にプライマリ キューが使用不能になったとします。送信側が後続のメッセージ m2 をセカンダリ キューに送信します。プライマリ キューが一時的に使用できない場合、受信側はキューが再び使用可能になった後に m1 を受信します。災害の場合、受信側は m1 を受信できない可能性があります。

  • 重複した受信: 送信側がメッセージ m をプライマリ キューに送信するとします。Service Bus により m が適切に処理されますが、応答の送信に失敗します。送信操作がタイムアウトになった後に、送信側が m の同一のコピーをセカンダリ キューに送信します。プライマリ キューが使用不能になる前に受信側が m の最初のコピーを受信できる場合、受信側は m の両方のコピーをほぼ同時に受信します。プライマリ キューが使用不能になるまでに受信側が m の最初のコピーを受信できない場合、受信側は m の 2 つ目のコピーのみを最初に受信しますが、プライマリ キューが使用可能になったときに m の 2 つ目のコピーを受信します。

Service Bus の仲介型メッセージを使用した geo レプリケーションのサンプルでは、メッセージング エンティティのパッシブ レプリケーションについて説明しています。

アプリケーションで Service Bus エンティティが使用不能になっても許容できるが、メッセージを失うことは許容できない場合、送信側で Service Bus に送信できないすべてのメッセージをローカルに格納する永続的なクライアント側キューを使用できます。Service Bus エンティティが再び使用可能になると、バッファー内のすべてのメッセージがそのエンティティに送信されます。永続的なメッセージ送信元のサンプルでは、MSMQ を利用してこのようなキューを実装しています。代わりに、メッセージをローカル ディスクに書き込むこともできます。

永続的なクライアント側キューではメッセージの順序が保存され、クライアント アプリケーションを Service Bus エンティティが使用できない場合の例外から保護します。永続的なクライアント側キューは、単純なトランザクションや分散トランザクションと共に使用できます。

関連項目

この情報は役に立ちましたか。
(残り 1500 文字)
フィードバックをいただき、ありがとうございました
表示:
© 2015 Microsoft