Service Broker 開発計画
Service Broker アプリケーションを設計する際は、以下を確認してください。
アプリケーションからの発生が予測される入出力の種類とボリュームに関する基準
提案するアプリケーションの要件
これらの項目について理解している場合は、ビジネス目標を達成するシステムを開発できます。
チェックリストの立案
アプリケーションの計画に際しては、次の問題点を検討します。
アプリケーションでは Service Broker がどのような役割を果たしますか。
この質問に対する答えを基に、アプリケーションが使用するメッセージ型、アプリケーションの構造、アプリケーションが必要とするストレージや処理の要件がどのようになるかを計画できます。
たとえば、アプリケーションは Service Broker を使用すると、リソースが使用可能になるまでメッセージをキューに格納しておくことによって、受信メッセージの急増に対処できます。この場合、アプリケーションが使用するメッセージ型は、既存のアプリケーションの入出力ときわめて近いものとなります。既存のワークロードに基づいて、アプリケーションのストレージ要件と処理要件を見積もることができます。
逆に、新しいアプリケーションをデザインする場合は、どの操作が Service Broker の利点を最大限活かせるかを慎重に検討します。Service Broker を使用する場合は、トレードオフが発生することが多くあります。一番問題のないケースでは、信頼性を確保できる予想可能な範囲の処理時間になります。また、従来のアプリケーションが完全に機能しなくなる場合もあります。
たとえば、オンライン受注アプリケーションは、発注時点では、注文を完全に処理し、最終確認を行わなくてもかまいません。代わりに、注文をサービスに送信し、サービスが注文を処理して、電子メールで最終確認を行うことができます。このようなデザインであれば、受注アプリケーションでネットワークの問題のために注文を確認できない場合でも、継続して注文を受け付けることができます。ネットワークの問題が解決された時点で、注文が処理されます。この場合、アプリケーションのストレージ要件と処理要件は、予想される注文数、各注文メッセージのサイズ、および各注文の処理にかかる時間によって決まります。
目的の作業を完了するために、メッセージ交換で必要になる情報は何ですか。また、この情報を相互に提供するためにエンドポイントが交換するメッセージのスキーマは何ですか。
ほとんどのサービスは、半構造化されたデータを交換するため、XML エンコードが適しています。バイナリ エンコードは、画像などのバイナリ ファイルを交換する場合に有用です。メッセージが到着したという事実だけがメッセージによって伝達される場合は、空のメッセージを使用します。
正しいメッセージ型を選択すると、アプリケーションを後で更新する必要が生じる可能性は低くなります。メッセージ型のエンコードによっては、XML スキーマ ファイルの更新から、アプリケーションのコードの大幅な変更に至るまで、更新の内容はさまざまです。現在は必要なくても、将来必要になると思われるデータ項目がある場合は、これを含めておきます。これらの要素を最初にスキーマで定義しておけば、要素をサポートするようになったときに、スキーマを変更する必要はありません。
メッセージ処理ロジックが実行されるのはどこですか。
Service Broker によってアクティブ化されるストアド プロシージャ、バックグラウンド サービス、定期的なイベント、または外部アプリケーションとしてアプリケーションをデザインできます。最終的な判断は、Service Broker が果たす役割によって決まります。たとえば、アプリケーションが予測可能なペースで絶え間なく到着するメッセージを処理する場合は、バックグラウンド サービスを使用できます。到着するメッセージの数に応じて動的にアプリケーションのスケールを変換する必要がある場合は、キューによりアクティブ化されるストアド プロシージャを使用できます。キューにメッセージを保持し、すべてのメッセージを決められた時間に処理する場合は、アプリケーションを起動する定期的なイベントを使用できます。
プログラムが Web ページやファイルなどデータベース外のリソースにアクセスする必要がある場合は、外部アプリケーションを使用できます。外部アプリケーションを使用すると、アプリケーションのスケーラビリティが向上します。これは、処理がデータベース サーバーではなく、中間層サーバーで行われるためです。Service Broker ではキューへのリモート トランザクション アクセスが提供されるので、Service Broker を使用するアプリケーションは容易にスケール アウトできます。データベースに Transact-SQL コマンドを送信し、結果を処理できるアプリケーションであれば、Service Broker を使用できます。
各外部プログラムは、キューを使用する他のプログラムとは分離されます。したがって、外部プログラムは、キューへのアクセスを管理するための特別な事前処理を必要としません。また、アプリケーションがメッセージを処理している最中に切断された場合、トランザクションはロールバックされ、Service Broker がメッセージをキューに戻します。ネットワーク障害が発生した場合でも、メッセージが失われることはありません。
アプリケーションの実装には、どのようなテクノロジを使用しますか。
SQL Server でデータベースに接続し、Transact-SQL ステートメントを実行できる任意のテクノロジを使用すると、外部アプリケーションを実装できます。ただし、アプリケーションは通常 .NET Framework 対応の言語や ADO.NET を使用して開発されます。ストアド プロシージャは、Transact-SQL または .NET Framework 対応の言語の 1 つを使用して実装できます。データベース エンジンの処理パフォーマンスは、Transact-SQL を使用した方が優れていますが、CLR 準拠の言語は柔軟性が高く、より細かいプログラム フローの制御が可能で、プロセッサを集中的に使用するアプリケーションのパフォーマンスを向上させるほか、.NET Framework に直接アクセスできます。
アプリケーションが最も集中的に使用するサーバー コンポーネントはどれですか。
システム管理者の協力を仰ぎ、最高のアプリケーション パフォーマンスを実現するために必要なリソースを確保します。どのコンポーネントを最も頻繁に使用するかを把握します。たとえば、アプリケーションがキューを使用して処理ワークロードを均等にする場合、またはメッセージの保有オプションを有効にする場合は、キューが拡張しても問題ないだけのディスク領域を確保します。逆に、メッセージの量は多くても、キューの待ち時間は少ないアプリケーションの場合は、より多くのネットワーク帯域幅を必要としますが、使用するディスク領域は少なくなります。
メッセージには異なる優先度が割り当てられますか。
負荷の高いシステムでは、Service Broker のメッセージ交換の優先度を使用すると、重要度の低い大量の作業によって重要度の高い作業がブロックされるのを防ぐことができます。メッセージ交換の優先度によって、設計でさまざまなレベルのサービスをサポートすることも可能になります。