Service Broker のスケーラビリティ
Service Broker は、スケール アップまたはスケール アウトのどちらの場合でも、データベース アプリケーションの適切なスケール変更を支援するようにデザインされています。このトピックでは、Service Broker を利用するアプリケーションをデザインするための一般的なガイドラインを示します。
Service Broker をアクティブ化すると、それまでよりも処理能力を多く利用できるようになるので、アプリケーションを容易にスケール アップできます。メッセージ交換グループのロックによって、競合の最も一般的な原因をサービス プログラムで容易に回避できるようになります。
各 Service Broker アプリケーションは、独立して動作できる一連のタスクで構成されています。Service Broker のルーティングによって、Service Broker を使用するアプリケーションはサービスを別のインスタンスに移動することができます。アプリケーションではなく Service Broker がメッセージのルーティングを処理するので、アプリケーション コードを変更することなく、サービスを複数の異なるコンピュータに分散できます。
スケーラビリティを実現するために Service Broker アプリケーションをデザインする場合は、アプリケーション内のタスク間の相互関係を入念に検討してください。一般に、タスク間を明確に区別して構築されたサービスは、スケール アップとスケール アウトの両方のシナリオで成果を挙げることができます。通常、タスクをサービスに分割するときには、タスクの遂行に必要なデータを考慮します。関連する 2 つのタスクが同じデータを変更しない場合は、これらのタスクを異なるサービスとして構成することを検討してください。たとえば、顧客管理アプリケーションと出荷アプリケーションはどちらも顧客の住所にアクセスしますが、住所を変更するのは顧客管理アプリケーションだけであるとします。この場合、出荷アプリケーションへのメッセージには、注文品を出荷するために必要な住所情報が含まれている可能性があります。出荷アプリケーションと顧客アプリケーションが同じテーブルにアクセスする必要はないため、これらのタスクは別々のサービスに分けることができます。