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

非同期型メッセージング パターンと高可用性

更新日: 2014年9月

非同期メッセージングはさまざまな方法で実装できます。キュー、トピック、サブスクリプション (まとめてメッセージング エンティティと呼ばれます) に関して、Microsoft Azure の Service Bus はストア経由の非同時性と転送メカニズムをサポートしています。通常の (同期的) 操作では、メッセージをキューとトピックに送信し、キューとサブスクリプションからメッセージを受信します。ユーザーが作成するアプリケーションは、これらのエンティティが常に利用可能であることに依存します。さまざまな状況下でエンティティの正常性が変化した場合、ニーズを満たすために機能を低下させたエンティティを提供する手段が必要になります。

通常、アプリケーションは非同期メッセージング パターンを使用して多くの通信シナリオを可能にします。ユーザーは、サービスが実行していない時でもクライアントがメッセージをサービスに送信できるアプリケーションを構築できます。アプリケーションで通信の集中が起こった場合、キューは通信をバッファーする場所を提供することで負荷の一定化を助けることができます。そして、シンプルかつ効果的なロード バランサーを入手して複数のコンピューター間でメッセージを配信することも可能です。

これらのエンティティの可用性を維持するため、永続的なメッセージング システムでエンティティが利用不可と表示されるさまざまなパターンを考慮してください。一般的には、エンティティがアプリケーションで利用不可となる場合、次のような方法で表示されます。

  1. メッセージを送信できません。

  2. メッセージを受信できません。

  3. エンティティを処理できません (エンティティの作成、取得、更新、削除)。

  4. サービスと通信できません。

これらの各エラーには、アプリケーションが制限された機能レベルでの操作を引き続き実行できるエラー モードがそれぞれにあります。たとえば、メッセージを送信できるが受信できないというシステムでは、顧客からの注文を受信はできるが、注文の処理を行えないという状況になります。このトピックでは発生する可能性のある潜在的な問題と、それらの問題を軽減する方法について説明します。Service Bus ではユーザーが使用を選択できる軽減策が多数用意されており、このトピックではこれらの軽減策の使用に関するルールについても説明します。

メッセージやエンティティの問題にはさまざまな対処方法があり、それらの軽減策の適切な使用を管理するためのガイドラインが存在します。ガイドラインを理解するには、まず Service Bus で起こりうるエラーを理解しておく必要があります。Windows Azure システムの設計上、これらの問題は長続きはしません。大まかに言えば、利用不可となる原因には次のようなものがあります。

  • Service Bus が依存する外部システムからのスロットル。スロットルはストレージとコンピューター リソースとの相互作用から発生します。

  • Service Bus が依存するシステム上の問題。たとえば、指定した部分のストレージで問題が発生した場合など。

  • 1 つのサブシステム上の Service Bus のエラー。この場合、計算ノードが不整合な状態になり再起動が必要になるため、すべてのエンティティが他のノードに負荷分散することになります。これにより、一時的にメッセージの処理速度が低下することになります。

  • Windows Azure データ センター内の Service Bus のエラー。これは、システムが数十分または数時間アクセス不可になるという致命的なエラーです。

noteメモ
ストレージという単語は Windows Azure ストレージおよび SQL Azure の両方が当てはまります。

Service Bus には上記の問題に対する軽減策が多数備わっています。次のシナリオでは、それぞれの問題とそれに対する軽減策について説明します。

Service Bus では、スロットルによるメッセージ レートの共同管理が可能です。各 Service Bus ノードには多数のエンティティがあります。各エンティティはシステムに対して CPU、メモリ、記憶域、他のファセットに関する要求を行います。いずれかのファセットが定義されたしきい値を超えた使用を検出すると、Service Bus はその要求を拒否できます。呼び出し元は ServerBusyException を受信し、10 秒後に再試行します。

軽減策として、コードがエラーを読み取り、メッセージの再試行を 10 秒以上中断する必要があります。エラーはユーザーのアプリケーションのピース全体で発生する可能性があるため、各ピースがそれぞれ再試行ロジックを実行することが予期されます。キューやトピックでのパーティション化を有効にすることで、コードはスロットルの発生率を低下させることができます。

Windows Azure の他のコンポーネントでもサービスの問題が発生する場合があります。たとえば、Service Bus が使用するシステムがアップグレードされた場合、システムの機能が一時的に制限されている可能性があります。この種類の問題を回避するため、Service Bus は定期的に調査を行い、軽減策を実施します。ただし、これらの軽減策の副作用もあります。たとえば、ストレージの一時的な問題に対処するため、Service Bus はメッセージの送信操作が可能なシステムを実装して動作の一貫性を維持します。軽減策の性質により、送信されたメッセージが影響を受けるキューやサブスクリプションに表示され、受信操作が可能になるまで最大 15 分かかる場合があります。一般的には、ほとんどのエンティティでこのような問題は発生しません。ただし、Windows Azure 内の Service Bus のエンティティの数を考慮すると、これは一部の Service Bus ユーザーにとって必要な軽減策です。

どのアプリケーションでも、状況によって Service Bus の内部コンポーネントに矛盾が生じる場合があります。Service Bus がそれを検出した場合、アプリケーションからデータを収集して発生状況の診断に役立てます。データを収集すると、一貫した状態に復帰するため、アプリケーションが再開されます。このプロセスは非常に素早く実行され、エンティティが利用不可になるのは最大でも数分のため、ダウンタイムは非常に短い時間になります。

この場合、クライアント アプリケーションが TimeoutException または MessagingException の例外を生成します。Service Bus .NET SDK にはこの問題に対する軽減策が自動化されたクライアント再試行ロジックの形で含まれています。再試行の期間が過ぎてもメッセージが配信されない場合は、組み合わせ名前空間などの他の機能を試すことができます。組み合わせ名前空間には本書で後述するその他の注意事項があります。

Azure データ センターで起こるエラーでまず考えられる原因は、Service Bus または依存システムのアップグレードの展開の失敗です。プラットフォームの成熟化に伴い、この種類のエラーが発生する確率は減少しています。また、データ センターのエラーは次のような原因で発生する場合があります。

  • 停電 (電力供給および発電の停止)。

  • 接続の問題 (クライアントと Windows Azure 間のインターネット接続の切断)。

両方のケースとも、自然災害または人災による問題です。この問題を回避し、継続してメッセージを送信できるようにするため、組み合わせ名前空間を使用してプライマリの場所が正常に戻るまでの間、第 2 の場所にメッセージを送信するようにできます。

組み合わせ名前空間 の機能では、Service Bus エンティティやデータ センター内の展開が利用不可になった場合のシナリオをサポートします。このイベントはまれにしか起こりませんが、最悪のシナリオに対処できるよう分散システムの準備は不可欠です。通常、このイベントは Service Bus が依存する一部のエレメントで一時的な問題が発生している場合に起こります。障害の発生中もアプリケーションの可用性を維持するため、Service Bus ユーザーは 2 つの異なる名前空間 (できれば別のデータ センター内) を使用してメッセージング エンティティをホストできます。このセクションの後半では次の用語を使用します。

  • プライマリ名前空間:アプリケーションが送受信操作で対話する名前空間。

  • セカンダリ名前空間:プライマリ名前空間のバックアップの機能を果たす名前空間。アプリケーション ロジックはこの名前空間とは対話しません。

  • フェールオーバー間隔:アプリケーションがプライマリ名前空間からセカンダリ名前空間に切り替える前に通常のエラーを受け入れる時間。

組み合わせ名前空間は送信の可用性をサポートします。送信の可用性はメッセージの送信機能を維持することに重点を置いています。送信の可用性を使用するには、アプリケーションが次の要件を満たしている必要があります。

  1. メッセージをプライマリ名前空間からのみ受信する。

  2. 指定したキュー/トピックへ送信されたメッセージが順序どおり届かない場合がある。

  3. アプリケーションでセッションを使用している場合。

    1. セッション内のメッセージが順序どおり届かない場合がある。これはセッションの通常機能の中断です。これは、アプリケーションがセッションを使用してメッセージを論理的にまとめていることを意味します。

    2. セッション状態はプライマリ名前空間でのみ維持されている。

  4. セカンダリ キューがすべてのメッセージをプライマリ キューに配信する前にプライマリ キューがオンラインになり、メッセージの受信を開始できる。

このセクションでは API とその実装方法、および機能を使用するサンプル コードについて説明します。この機能は課金に影響を与える場合がありますのでご注意ください。

組み合わせ名前空間の機能では、MessagingFactory クラスに次の新しいメソッドを導入します。

public Task PairNamespaceAsync(PairedNamespaceOptions options)

タスクが完了すると名前空間の組み合わせも完了し、MessagingFactory で作成したすべての MessageReceiverQueueClientTopicClient で動作可能になります。PairedNamespaceOptions は異なる種類の組み合わせの基本クラスで、MessagingFactory で利用可能です。現在、唯一の派生クラスは SendAvailabilityPairedNamespaceOptions という名前で、送信の可用性の要件を満たすものです。SendAvailabilityPairedNamespaceOptions にはコンストラクターのセットがあり、すべて互いの上にビルドしています。最もパラメーターの多いコンストラクターを見ると、他のコンストラクターの動作を理解できます。

public SendAvailabilityPairedNamespaceOptions(
    NamespaceManager secondaryNamespaceManager,
    MessagingFactory messagingFactory,
    int backlogQueueCount,
    TimeSpan failoverInterval,
    bool enableSyphon)

これらのパラメーターには次の意味があります。

  • secondaryNamespaceManager: PairNamespaceAsync メソッドがセカンダリ名前空間のセットアップに使用できる、セカンダリ名前空間用の初期化された NamespaceManager インスタンス。名前空間のキューの一覧の入手にはマネージャーが使用され、必要なバックログ キューが存在することを確認します。それらのキューが存在しない場合は、作成されます。NamespaceManager では Manage 要求付きのトークンを作成する機能が必要です。

  • messagingFactory: セカンダリ名前空間の MessagingFactory インスタンス。MessagingFactory は送信に使用され、EnableSyphon プロパティが true に設定されている場合はバックログ キューからのメッセージの受信に使用されます。

  • backlogQueueCount: 作成するバックログ キューの数。この値は少なくとも 1 である必要があります。バックログへメッセージを送信する際にこれらのキューの中から 1 つがランダムに選択されます。値を 1 に設定した場合は、使用されるのは 1 つのキューのみです。この動作が発生し、1 つのバックログ キューでエラーが生成された場合、クライアントは別のバックログ キューで再試行することはできず、メッセージの送信に失敗する場合があります。この値は少し大きな数値に設定し、既定値を 10 にすることをお勧めします。これは、アプリケーションが 1 日に送信するデータ量に応じてより高いまたは低い値に変更できます。各バックログ キューは最大 5 GB までのメッセージを格納できます。

  • failoverInterval: 1 つのエンティティをセカンダリ名前空間に切り替える前に、プライマリ名前空間でエラーを受け入れる時間。フェールオーバーはエンティティごとに発生します。1 つの名前空間内のエンティティは Service Bus の異なるノードにある場合が多々あります。1 つのエンティティのエラーが、他のエンティティのエラーを意味することはありません。この値を Zero に設定すると、一時的でないエラーが初めて発生した場合すぐにセカンダリにフェールオーバーできます。フェールオーバー タイマーのトリガーとなるエラーは MessagingException で、IsTransient プロパティが False または TimeoutException の場合です。UnauthorizedAccessException などのその他の例外では、クライアントが正しく構成されていないことを示すため、フェールオーバーは発生しません。ServerBusyException では 10 秒待機してから再度メッセージを送信することが正しいパターンであるため、フェールオーバーは発生しません。

  • enableSyphon: この特定の組み合わせではセカンダリ名前空間からプライマリ名前空間へメッセージをサイホンする必要があることを示します。一般的には、メッセージを送信するアプリケーションではこの値を false に、メッセージを受信するアプリケーションでは true に設定します。これは、ほとんどの場合メッセージの送信者よりも受信者の方が数が少ないためです。受信者の数に応じて、1 つのアプリケーション インスタンスでサイホン処理を行うよう選択できます。多くの受信者を使用すると、各バックログ キューの課金に影響を与える場合があります。

コードを使用するには、プライマリ MessagingFactory インスタンス、セカンダリ MessagingFactory インスタンス、セカンダリ NamespaceManager インスタンス、SendAvailabilityPairedNamespaceOptions インスタンスを作成します。呼び出しは次のようにシンプルです。

SendAvailabilityPairedNamespaceOptions sendAvailabilityOptions =
    new SendAvailabilityPairedNamespaceOptions(secondaryNamespaceManager, secondary);
primary.PairNamespaceAsync(sendAvailabilityOptions).Wait();

PairNamespaceAsync メソッドから返されたタスクが完了すると、すべてがセットアップされて使用準備が整います。タスクが返される前に、組み合わせが正常に動作するために必要なすべてのバックグラウンド作業を完了していない場合は、タスクが返されるまでメッセージの送信を開始しないでください。資格情報の間違いやバックログ キューの作成に失敗するなどのエラーが発生した場合、タスクが完了した時点でそれらの例外がスローされます。タスクが返されたら、SendAvailabilityPairedNamespaceOptions インスタンスの BacklogQueueCount プロパティでキューが見つかった、または作成されたかどうかを確認します。前のコードでは、この操作は次のように表示されます。

if (sendAvailabilityOptions.BacklogQueueCount < 1)
{
    // Handle case where no queues were created. 
}

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