エクスポート (0) 印刷
すべて展開

Azure のキュー ベースのメッセージング ソリューションのスケーラビリティとコスト効果を最大限に高めるためのベスト プラクティス

更新日: 2015年2月

執筆者: Amit Srivastava

校閲者: Brad Calder、Sidney Higa、Christian Martinez、Steve Marx、Curt Peterson、Paolo Salvatori、Trace Young

この記事では、Azure プラットフォームでスケーラビリティ、効率、およびコスト効果が高いキュー ベースのメッセージング ソリューションを構築するための手順とベスト プラクティスを示します。この記事は、Azure プラットフォームのキュー ストレージ サービスを利用したクラウドベースのソリューションを設計および実装するソリューション設計者や開発者を対象としています。

従来のキュー ベースのメッセージング ソリューションでは、メッセージ キューと呼ばれるメッセージの格納場所の概念を利用します。これは、参加者の間で通常は非同期の通信メカニズムを利用して送受信されるデータのリポジトリです。

この記事の目的は、コスト効果が高い最適化されたキュー ベースのメッセージング ソリューションを構築するために、Azure プラットフォームで提供される機能と組み合わせて利用できるデザイン パターンを調べることです。ここでは、Azure ソリューションでキュー ベースの操作を実装する一般的なアプローチについて詳しく説明し、パフォーマンスの向上、スケーラビリティの強化、および運用コストの削減に役立つ推奨事項を示します。

基本的な説明に加え、関連するベスト プラクティス、ヒント、推奨事項がある場合はそれらも紹介します。実際の顧客のプロジェクトに基づくシナリオに従って、技術的な実装について説明していきます。

メッセージ キューを使用して分散コンポーネント間でデータを交換する一般的なメッセージング ソリューションには、メッセージをキューに格納するパブリッシャーと、それらのメッセージを受信する側のサブスクライバーが含まれます。キュー リスナーとも呼ばれるサブスクライバーは、ほとんどの場合、シングルスレッドまたはマルチスレッドのプロセスとして実装されます。このプロセスは、継続して実行される場合と、スケジュールのパターンに従って要求時に開始される場合があります。

キューに格納されたメッセージをキュー リスナーで受信できるようにするために使用されるディスパッチ メカニズムは、大きく分けて 2 種類あります。

  • ポーリング (プル ベース モデル): リスナーでキューを監視し、一定の間隔で新しいメッセージがないかどうかを確認します。キューが空のときもポーリングを継続し、定期的にスリープ状態にしてバックオフします。

  • トリガー (プッシュ ベース モデル): メッセージがキューに到着するとトリガーされるイベントをリスナーでサブスクライブします (イベントのトリガーはパブリッシャー自体またはキュー サービス マネージャーで行われます)。到着したメッセージから順番に処理を開始できるため、新しい作業があるかどうかを確認するためにキューをポーリングする必要はありません。

どちらのメカニズムにも、これ以外にも異なる特性があることに注意してください。たとえば、ポーリングにはブロッキングと非ブロッキングの 2 種類があります。ブロッキングではキューに新しいメッセージが格納されるまで (またはタイムアウトするまで) 要求を保持し、非ブロッキングではキューが空の場合はすぐに要求が完了します。また、トリガー モデルでは、新しいメッセージが追加されるたび、空のキューに最初のメッセージが到着したときのみ、キューの深さが一定のレベルに達したときのいずれかのタイミングでキュー リスナーに通知をプッシュできます。

noteメモ
Azure キュー サービス API でサポートされるデキュー操作は非ブロッキング操作です。つまり、GetMessageGetMessages などの API メソッドは、キューにメッセージがないとすぐに制御が戻ります。これに対し、Azure Service Bus のキューの受信操作はブロッキング操作です。そのため、メッセージがキューに到着するか、指定したタイムアウト時間が経過するまで、呼び出し側のスレッドがブロックされます。

今日の Azure ソリューションでキュー リスナーを実装する最も一般的なアプローチをまとめると次のようになります。

  1. リスナーは、ワーカー ロール インスタンスの一部としてインスタンス化されて実行されるアプリケーション コンポーネントとして実装されます。

  2. キュー リスナー コンポーネントのライフサイクルは、多くの場合、ホスト側のロール インスタンスの実行時間に依存します。

  3. メインの処理ロジックは、デキューとディスパッチを行ってメッセージを処理するループで構成されます。

  4. メッセージを受信しない状態が続くと、リッスン スレッドはスリープ状態になります。この時間は、通常はアプリケーション固有のバックオフ アルゴリズムで決まります。

  5. 受信ループの実行とキューのポーリングは、ループを終了するようにリスナーに通知されるまで継続されます。

次のフローチャートの図は、Azure アプリケーションのポーリング メカニズムを使用してキュー リスナーを実装する場合の一般的なロジックを示しています。

Best-Practices-Messaging-Solutions-Azure2
noteメモ
この記事では、一元化されたキュー マネージャー (ブローカー) を使用する必要があるような複雑なデザイン パターンは使用しません。

Azure キューを使用する場合は、ポーリング メカニズムを使用した従来のキュー リスナーは適さない場合もあります。Azure の料金モデルでは、キューが空であるかどうかに関係なく、キューに対して実行されるアプリケーション要求の単位でストレージ トランザクションが計算されるためです。この後のセクションでは、Azure プラットフォームのキュー ベースのメッセージング ソリューションのパフォーマンスを最大限に高めると同時にコストを最小限に抑える方法をいくつか紹介します。

ここでは、パフォーマンス、スケーラビリティ、およびコスト効果を高めるための関連するデザインの改善点について検証します。

実装パターンが "効率的なソリューション" であると見なされる際に最も重視されるのは、おそらく、デザインによって次の目的を達成できるかどうかです。

  • 有用な結果が得られないストレージ トランザクションの多くを排除して運用コストを削減する

  • 新しいメッセージがあるかどうかを確認する際のポーリング間隔による過剰な待機時間をなくす

  • 変化する作業量に応じて処理能力を割り当てることで動的にスケールアップ/スケールダウンする

ただし、これらの目的を達成できても、そのメリットを上回るほど実装パターンが複雑になっては意味がありません。

Azure プラットフォームに配置されるソリューションの総保有コスト (TCO) および投資回収率 (ROI) を評価する際、TCO の式の主な変数の 1 つにストレージ トランザクションの量があります。Azure キューに対するトランザクションの数を減らすと、Azure でのソリューションの実行に関連する運用コストが少なくなります。

Azure キューに関連付けられたストレージ領域のコストは、次のように計算できます。

キュー領域: 24 バイト + Len(QueueName) * 2 +  For-Each Metadata(4 バイト + Len(QueueName) * 2 バイト + Len(Value) * 2 バイト)

メッセージ領域: 12 バイト + Len(Message)

キュー ベースのメッセージング ソリューションの場合、次の方法を組み合わせて使用することで、ストレージ トランザクションのボリュームを減らすことができます。

  1. キューにメッセージを格納するときは、1 つの大きなバッチに関連するメッセージをまとめます。圧縮したイメージを BLOB ストレージに格納し、実際のデータを保持する BLOB への参照をキューで保持します。この方法は、トランザクションのコストとストレージ領域のコストを最適化するのに役立ちます。

  2. キューからメッセージを取得するときは、1 つのストレージ トランザクションに複数のメッセージをまとめます。キュー サービス API の GetMessages メソッドを使用すると、指定した数のメッセージを 1 つのトランザクションでデキューできます (この後の注意事項を参照)。

  3. キューに作業項目があるかどうかを確認するときは、空の状態が続いた場合に頻繁にポーリングを行わないように、ポーリング要求の間隔を長くするバックオフ遅延を実装します

  4. キュー リスナーの数を少なくします。プル ベース モデルを使用する場合、キューが空のときは、ロール インスタンスごとのキュー リスナーの数を 1 つだけにします。ロール インスタンスごとのキュー リスナーの数をさらに少なくして 0 にするには、通知メカニズムを使用して、キューが作業項目を受け取ったときにキュー リスナーをインスタンス化します。

  5. ほぼ常にキューが空の状態になる場合は、ロール インスタンスの数を自動的にスケールダウンします。関連するシステム メトリックを継続的に監視することで、ワークロードの増加に対応するためにインスタンスの数をスケールアップする必要がないかどうかを確認します。

  6. 有害メッセージを除去するメカニズムを実装します。有害メッセージとは通常、アプリケーションが処理できない不適切な形式のメッセージを指します。未処理のままにすると、そのようなメッセージが蓄積し、トランザクションおよび処理に必要なコストが繰り返し発生する可能性があります。単純な実装メカニズムは、しきい値の期間を過ぎたメッセージをキューから削除し、アーカイブ システムに書き込んだ後にさらに評価するというものです。

  7. 予期されるタイムアウト エラーを減らします。サービスに要求を送信する際に、独自のタイムアウトを指定して、SLA タイムアウトより小さい値に設定することができます。この場合、要求がタイムアウトすると、予期されるタイムアウトとして分類され、課金可能なトランザクション数のカウントに含められます。

これらの推奨事項のほとんどは、メッセージ バッチを処理し、基になるキュー/BLOB ストレージおよびスレッド管理操作の多くをカプセル化する汎用的な実装で実現できます。この方法については後ほど説明します。

Important重要
GetMessages メソッドを使用してメッセージを取得する場合にキュー サービス API でサポートされる最大バッチ サイズは、デキュー操作あたり 32 個までです。

一般に、Azure キューのトランザクションのコストは、ロール インスタンスの数をスケールアップしたときやデキュー スレッドの数を増やしたときなど、キュー サービス クライアントの数に比例して増加します。これらの推奨事項に従っていないソリューション デザインによるコストへの影響について説明するために、次に具体的な数値に基づく例を示します。

前に示した請求システムのアーキテクチャを構築する際に、ソリューション設計者が関連する最適化について考慮しなかった場合、Azure プラットフォームにソリューションを配置して実行したときに運用コストが必要以上に増大する可能性があります。ここでは、コストが必要以上に高くなる原因について説明します。

シナリオの定義で示したように、ビジネス トランザクション データを一定の間隔で受け取っています。ただし、処理ワークロードが集中する時間は、8 時間の営業時間のうちの 25% に過ぎないとします。この場合、6 時間 (8 時間 * 75%) は、システムからトランザクションを受け取らない可能性がある "アイドル時間" になります。さらに、毎日 16 時間は、営業時間外のためデータをまったく受け取りません。

合計 22 時間のアイドル状態の間も、ソリューションでは新しいデータをいつ受け取るか明確に認識できないため、作業のデキューを試行し続けることになります。ポーリング間隔が既定の 1 秒であるとすると、この間に入力キューに対して各デキュー スレッドで実行されるトランザクションの数は、最大で 79,200 (22 時間 * 60 分 * 60 トランザクション/分) になります。

既に説明したように、Azure プラットフォームの料金モデルは、"ストレージ トランザクション" の数に基づいています。ストレージ トランザクションは、ストレージ データの追加、読み取り、更新、削除を行うためのユーザー アプリケーションによる要求です。このホワイトペーパーの作成時点のストレージ トランザクションの料金は、10,000 トランザクションあたり 0.01 ドルです (キャンペーン プランや特別な料金の取り決めについては加味していません)。

Important重要
キューのトランザクション数の計算について注意が必要なのは、キューに 1 つのメッセージを格納する操作は 1 つのトランザクションとしてカウントされますが、メッセージを使用する操作は、多くの場合、メッセージを取得する操作とその後にメッセージをキューから削除する操作から成る 2 段階のプロセスになるということです。そのため、デキュー操作に成功した場合、ストレージ トランザクションは 2 つになります。デキュー要求でデータが取得されなかった場合でも課金対象のトランザクションとしてカウントされることに注意してください。

このシナリオでは、1 つのデキュー スレッドで生成されるストレージ トランザクションにより、月額料金が約 2.38 ドル (79,200 / 10,000 * 0.01 ドル * 30 日) 多くなります。たとえば、デキュー スレッドが 200 個であれば (デキュー スレッドを 1 つ実行するワーカー ロール インスタンスが 200 個ある場合も同じ)、1 か月のコストは 457.20 ドル増えます。ソリューションでまったく計算を実行していない間に、キューに作業項目があるかどうかを確認するだけで、これだけのコストがかかることになります。この例は理論上のものであり、実際にこの方法でサービスを実装することはありません。このようにならないために、次に説明する最適化を行うことが重要になります。

キュー ベースの Azure メッセージング ソリューションのパフォーマンスを最適化するためのアプローチの 1 つとして、ここでは、Azure Service Bus のパブリッシュ/サブスクライブ メッセージング レイヤーを使用する方法を説明します。

このアプローチでは、ポーリングとリアルタイムのプッシュ ベースの通知を組み合わせて使用する必要があります。具体的には、新しいワークロードがキューに格納されたことを示すために特定の条件で発生する通知イベント (トリガー) をリスナーでサブスクライブできるようにします。このアプローチでは、通知のディスパッチにパブリッシュ/サブスクライブ メッセージング レイヤーを使用することで従来のキュー ポーリング ループを強化します。

複雑な分散システムでは、このアプローチを実現するために、疎結合方式で 1 つ以上のサブスクライバーに通知が確実に配信されるように "メッセージ バス" または "メッセージ指向のミドルウェア" を使用する必要があります。Azure やオンプレミスで実行される疎結合分散アプリケーション サービス間のメッセージングの要件に対処するには、Azure Service Bus が適しています。これは、キュー ベースの通信にかかわるプロセス間での通知の交換を可能にする "メッセージ バス" のアーキテクチャとも適合します。

キュー ベースのメッセージ交換にかかわるプロセスでは、次のようなパターンが使用されます。

Best-Practices-Messaging-Solutions-Azure3

特にキュー サービスのパブリッシャーとサブスクライバーの間のやり取りについては、Azure ロール インスタンス間の通信に適用される同じ原則に従うことで、プッシュ ベースの通知メッセージ交換の要件についても大半は満たすことができます。

Important重要
Azure Service Bus の使用には、Service Bus のキューやトピックなどのメッセージング エンティティに対するメッセージング操作の量に応じて料金がかかります。

したがって、費用便益分析を実行して、アーキテクチャごとに Service Bus を導入する利点と欠点を評価することが重要です。それを踏まえ、投資および必要な開発作業に見合うだけのコスト削減を実際に達成できるかどうかを評価したうえで、Service Bus に基づく通知ディスパッチ レイヤーを導入するかどうかを検討する必要があります。

Service Bus の料金モデルの詳細については、「Azure FAQ」で関連する項目を参照してください。

待機時間に対する影響についてはパブリッシュ/サブスクライブ メッセージング モデルで比較的簡単に対処できますが、コストをさらに削減するには、次のセクションで説明する動的 (柔軟) なスケーリングを使用します。

Azure Storage では、アカウント全体のレベルとパーティション レベル単位でスケーラビリティ ターゲットを定義します。Azure のキューは独自の単一パーティションであるため、1 秒間に最大 2000 メッセージを処理できます。メッセージ数がこのクォータを超えると、ストレージ サービスは HTTP 503 (サーバーがビジー状態) メッセージで応答します。このメッセージは、プラットフォームでキューが調整中であることを示します。アプリケーション デザイナーは、適切な数のキューでアプリケーションの要求レートを維持できるようにキャパシティ プランニングを実行する必要があります。1 つのキューでアプリケーションの要求レートを処理できない場合は、複数のキューでパーティション キュー アーキテクチャを設計し、スケーラビリティを確保します。

1 つのアプリケーションで、異なるメッセージの種類に対して複数の異なるキューを利用することもできます。これにより、1 つのキューだけを圧迫せずに複数のキューを共存させることができ、アプリケーションのスケーラビリティが確保されます。また、異なるキューに保存されているメッセージの秘密度や優先度に基づいて、キューの処理を個別に制御できるようになります。優先度の高いキューに、優先度が低いキューよりも多くの専用ワーカーを割り当てることができます。

Azure プラットフォームでは、これまで以上にすばやく簡単にスケールアップとスケールダウンを行えるようになっています。変化するワークロードやトラフィックに対応できることは、クラウド プラットフォームならではの価値の 1 つです。これは、IT においては "スケーラビリティ" はもはや高価なものではなく、優れたクラウド ソリューションであれば要求時にプログラムですぐに利用できる機能であることを意味します。

動的スケーリングは、作業能力や処理能力を実行時に増減することで変動するワークロードに対応するための特定のソリューションの技術的な機能です。Azure プラットフォームでは、コンピューティング時間を必要に応じて購入できる分散コンピューティング インフラストラクチャのプロビジョニングを通じて、動的スケーリングをネイティブでサポートしています。

Azure プラットフォームでは、次の 2 種類の動的スケーリングを区別することが重要です。

  • ロール インスタンスのスケーリングは、特定の時点のワークロードを処理するために Web ロールまたはワーカー ロールのインスタンスを追加および削除することを指します。通常は、サービス構成のインスタンス数を変更する操作がこれに該当します。インスタンス数を増やすと Azure ランタイムで新しいインスタンスが開始され、インスタンス数を減らすと実行中のインスタンスが停止されます。

  • プロセス (スレッド) のスケーリングは、現在のワークロードに応じてスレッドを増減することによって特定のロール インスタンスの処理スレッドの能力を確保することを指します。

キュー ベースのメッセージング ソリューションの動的スケーリングでは、次の一般的な推奨事項を組み合わせて使用します。

  1. CPU 使用率、キューの深さ、応答時間、メッセージ処理の待機時間など、パフォーマンスに関する主な指標を監視します

  2. 予測可能であるかどうかに関係なく、ワークロードの急増に対処できるように、ロール インスタンスの数を動的に増減します

  3. 特定のロール インスタンスで処理する負荷の状態の変化に対応できるように、処理スレッドの数をプログラムで増減します

  4. .NET Framework 4 のタスク並列ライブラリを使用して、ワークロードを細かく分割して同時に処理します

  5. ワークロードの変動が大きいソリューションでは、追加のインスタンスを設定するオーバーヘッドなしでワークロードの急増に対応できるように、十分な能力を確保します

サービス管理 API を使用すると、Azure ホステッド サービスで、実行時に配置構成を変更することで実行中のロール インスタンスの数を変更することができます。

noteメモ
一般的なサブスクリプションにおける Azure の小さいコンピューティング インスタンスの最大数 (他のサイズのコンピューティング インスタンスではコアの数に相当) は、既定では 20 個までに制限されます。このクォータを増やすときは、Azure のサポート チームにお問い合わせください。詳細については、「Azure FAQ」を参照してください。

Azure Auto Scalingを導入すると、プラットフォームで、キュー メッセージの深さに基づいてインスタンス数を増加または減少させることができます。この方法は、動的スケーリングに非常によく適合します。また、Azure プラットフォームがアプリケーションのタスクを監視してスケーリングを実行するという利点もあります。

ロール インスタンス数の動的スケーリングは、負荷の急増に対応する方法として常に適切であるとは限りません。たとえば、新しいロール インスタンスのスピンアップには数秒かかることがありますが、現在の SLA にはスピンアップ時間に関するメトリックはありません。代わりに、ワーカー スレッドの数を増やすだけでワークロードの増加に対処できる場合もあります。この場合、ワークロードの処理中に、ソリューションで関連する負荷メトリックを監視し、ワーカー プロセスの数を動的に増減する必要があるかどうかを確認します。

Important重要
現在、1 つの Azure キューのスケーラビリティ ターゲットは 2000 トランザクション/秒に制限されています。たとえば数百のデキュー スレッドを実行している複数のロール インスタンスからキュー操作を実行するなど、このターゲットを超える処理を実行しようとすると、ストレージ サービスから HTTP 503 (サーバーがビジー状態) 応答が返されることがあります。この場合、アプリケーションで、指数関数的なバックオフ遅延アルゴリズムを使用する再試行メカニズムを実装する必要があります。ただし、HTTP 503 エラーが繰り返し発生する場合は、複数のキューを使用し、複数のキューでスケーリングを行うパーティション分割に基づく方法を実装することをお勧めします。

ほとんどの場合、ワーカー プロセスの自動スケーリングは個々のロール インスタンスで行います。これに対して、ロール インスタンスのスケーリングでは、多くの場合、ソリューション アーキテクチャの要素で一元的にパフォーマンス メトリックを監視して適切なスケーリング処理を行う必要があります。次の図は、負荷メトリックを収集して分析し、新しいインスタンスのプロビジョニングやアイドル状態のインスタンスの停止が必要かどうかを判断する動的スケーリング エージェントというサービス コンポーネントを示しています。

Best-Practices-Messaging-Solutions-Azure4

このスケーリング エージェント サービスは、Azure で実行されるワーカー ロールとしてもオンプレミスのサービスとしても配置できます。つまり、配置トポロジに関係なく Azure キューにアクセスすることができます。

動的スケーリング機能を実装するときは、Azure で実行されるソリューションでの自動スケーリングを有効にする Microsoft Enterprise Library の Autoscaling Application Block を使用することを検討してください。Autoscaling Application Block には、Azure アプリケーションで自動スケーリングを定義および監視するために必要なすべての機能が用意されています。

noteメモ
動的スケーリングを手動で実行する代わりに、Azure で組み込みの自動スケーリング機能を使用することを検討してください。

ここまでで、待機時間による影響、ストレージ トランザクションのコスト、および動的スケーリングの要件について説明しました。次は、これらの推奨事項を踏まえ、技術的な実装について見ていきましょう。

具体的な例として、ここでは、次のような実際の顧客のシナリオを想定しています。

SaaS ソリューション プロバイダーは、顧客のトランザクション処理の規模に関するビジネス ニーズに対応するために、Azure アプリケーションとして実装された新しい請求システムを導入しました。ソリューションの前提として特に重視しているのは、大量の計算を伴うワークロードをクラウドに移し、Azure インフラストラクチャの柔軟性を利用して計算量が多い作業を実行することです。

エンド ツー エンドのアーキテクチャのオンプレミスの要素により、1 日を通して定期的に、大量のトランザクションがまとめて Azure ホステッド サービスにディスパッチされます。1 回に送信されるトランザクションの量は数千から数十万で、1 日の合計では数百万に上ります。さらに、このソリューションでは、最大処理待機時間に対する SLA で保証された要件も満たす必要があります。

ソリューションのアーキテクチャは、分散型の map-reduce デザイン パターンに基づき、作業ディスパッチに Azure キュー ストレージを使用する複数インスタンス ワーカー ロール ベースのクラウド層で構成されます。トランザクション バッチは、プロセス イニシエーター ワーカー ロール インスタンスで受け取られた後、小さい作業項目に分解 (バッチ解除) され、負荷分散のために Azure キューのコレクションにエンキューされます。

ワークロード処理は、キューから作業項目をフェッチして計算処理に渡す処理ワーカー ロールの複数のインスタンスによって処理されます。処理インスタンスでは、最適なパフォーマンスが得られるように、マルチスレッドのキュー リスナーを使用して並列データ処理を実装します。

処理対象の作業項目は専用のキューにルーティングされた後、そのキューからプロセス コントローラー ワーカー ロール インスタンスによってデキューされ、データ マイニング、レポート、および分析用に集約されてデータ ストアに格納されます。

このソリューションのアーキテクチャを表した図を次に示します。

AzureGuidance_MaxScale

この図のアーキテクチャは、大規模または複雑な計算ワークロードをスケールアウトする場合の一般的なアーキテクチャと言えます。このアーキテクチャで採用されているキュー ベースのメッセージ交換パターンもごく一般的なものであり、キューを介して相互に通信する必要がある Azure の多くのアプリケーションやサービスで採用されています。そのため、キュー ベースのメッセージ交換に関連する基本的な各コンポーネントについて、標準的なアプローチで調べることができます。

Azure プラットフォームで実行されるキュー ベースのメッセージング ソリューションの効率性とコスト効果を最大化するために、ソリューション設計者および開発者は次の推奨事項を検討してください。

ソリューション設計者は、次を実行する必要があります。

  • クラウドベースのソリューションまたはハイブリッド ソリューションで階層とサービス間の大規模な非同期通信に Azure キュー ストレージ サービスを使用するキュー ベースのメッセージング アーキテクチャをプロビジョニングします。

  • 1 秒あたり 2000 を超えるメッセージをスケーリングする場合はパーティション キューイング アーキテクチャをお勧めします。

  • Azure の料金モデルの基礎を理解し、一連のベスト プラクティスとデザイン パターンを通じてトランザクション コストを下げるようにソリューションを最適化します。

  • 揮発性の変動ワークロードに適応するアーキテクチャをプロビジョニングして動的スケーリング要件を考慮します。

  • 計算能力を柔軟に拡張および縮小して運用費をさらに最適化するための適切な自動スケーリング手法とアプローチを使用します。

  • Azure Auto Scaling を評価し、アプリケーションの動的スケーリングに対する必要性に適合するかどうかを確認します

  • リアルタイムのプッシュ ベースの通知ディスパッチで Azure Service Bus への依存性を利用して待機時間を短縮した場合の費用便益比を評価します。

開発者は、次を実行する必要があります。

  • Azure キューからデータを格納および取得するときにバッチ処理を使用するメッセージング ソリューションを設計します。

  • Azure Auto Scaling を評価し、アプリケーションの動的スケーリングに対する必要性に適合するかどうかを確認します

  • 効率的なキュー リスナー サービスを実装し、キューが空のときに 1 つのデキュー スレッドのみによってポーリングされるようにします。

  • キューが長時間にわたって空である場合はワーカー ロール インスタンスの数を動的にスケールダウンします

  • アプリケーション固有のランダム指数バックオフ アルゴリズムを実装して、ストレージのトランザクション コストにおけるアイドル状態のキュー ポーリングの影響を軽減します。

  • 高度にマルチスレッド化されたマルチインスタンス キューのパブリッシャーとコンシューマーを実装するときに 1 つのキューのスケーラビリティ ターゲットを超えないようにするための適切な手法を採用します。

  • Azure キューからのデータをパブリッシュおよび使用するときに多様な一時的状況に対処できる堅牢な再試行ポリシーを使用します。

  • 待機時間を短縮し、キュー ベースのメッセージング ソリューションのパフォーマンスを向上させるために、Azure Service Bus で提供されている、プッシュ ベースの通知をサポートする一方向のイベント機能を使用します

  • 並列処理の次数を最大化し、同時実行性を向上させ、複数のマルチスレッド サービスのデザインを簡素化する TPL、PLINQ、オブザーバー パターンなどの .NET Framework 4 の新機能を探索します。

付随するサンプル コードは、MSDN Code Gallery からダウンロードできます。サンプル コードには、前のコード スニペットで提供されていない Azure キュー サービスの汎用対応抽象化レイヤーなど、必要なすべてのインフラストラクチャ コンポーネントが含まれています。対応する免責事項で説明されているとおり、すべてのソース コード ファイルは Microsoft Public License によって管理されることに注意してください。

このホワイト ペーパーで説明しているトピックの詳細については、以下を参照してください。

表示:
© 2015 Microsoft