Service Broker 開発計画
Service Broker アプリケーションの実装を開始する前に、アプリケーションで発生する入出力の種類や頻度を考慮することが重要です。これらの情報を十分に確認し、提案アプリケーションの要件を徹底的に分析することで、ビジネスの目標を首尾よく達成するシステムを開発できます。
チェックリストの立案
アプリケーションの計画に際しては、次の問題点を検討します。
- アプリケーションでは Service Broker がどのような役割を果たしますか。
この質問に対する答えを基に、アプリケーションが使用するメッセージ型、アプリケーションの構造、アプリケーションが必要とするストレージや処理の要件がどのようになるかを計画できます。
たとえば、メッセージ処理が行われるピーク時を回避するようにアプリケーションがデザインされれば、このアプリケーションが使用するメッセージ型は、既存のアプリケーションの入出力ときわめて近いものになります。既存のワークロードに基づいて、アプリケーションのストレージ域要件や処理要件を見積もることができます。
逆に、新しいアプリケーションをデザインする場合は、どの操作が Service Broker の利点を最大限活かせるかを慎重に検討します。Service Broker を使用する場合は、トレードオフが発生することが多くあります。一番問題のないケースでは、信頼性を確保できる予想可能な範囲の処理時間になります。また、従来のアプリケーションが完全に機能しなくなる場合もあります。
たとえば、オンライン受注アプリケーションは、発注時点では、注文を完全に処理し、最終確認を行わなくてもかまいません。代わりに、注文をサービスに送信し、サービスが注文を処理して、電子メールで最終確認を行うことができます。このようなデザインであれば、受注アプリケーションでネットワークの問題のために注文を確認できない場合でも、継続して注文を受け付けることができます。ネットワークの問題が解決された時点で、注文を無事に処理できます。この場合、アプリケーションのストレージ要件と処理要件は、予想される注文数、各注文メッセージのサイズ、および各注文の処理にかかる時間によって決まります。 - 目的の作業を完了するために、メッセージ交換の各ステップで必要になる情報は何ですか。また、この情報を相互に提供するためにエンドポイントが交換するメッセージのスキーマは何ですか。
サービスが交換する情報の種類を検討します。ほとんどのサービスは、半構造化されたデータを交換するため、XML エンコードが適しています。逆に、バイナリ エンコードは、画像などのバイナリ ファイルを交換する場合に有用です。メッセージで伝達される情報が、メッセージが到着したという事実を伝える情報だけの場合は、空のメッセージを使用します。
メッセージ型を適切に定義できれば、後でアプリケーションを更新する必要はありません。選択したメッセージ型のエンコードによっては、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 アプリケーションのインストール
Service Broker アプリケーションの管理