キューに置かれた通信のベスト プラクティス
ここでは、Windows Communication Foundation (WCF) のキューに置かれた通信で推奨されるベスト プラクティスについて説明します。 以下の各セクションでは、シナリオの観点から推奨されるベスト プラクティスについて説明します。
キューに置かれたベストエフォート方式の高速メッセージング
キューに置かれたメッセージングによってもたらされる分離と、ベストエフォート保証による高パフォーマンスの高速メッセージングを必要とするシナリオでは、非トランザクション キューを使用し、ExactlyOnce プロパティを false に設定します。
また、Durable プロパティを false に設定して、ディスク書き込みの負荷がかからないようにすることもできます。
セキュリティは、パフォーマンスに影響を及ぼします。 詳細については、「パフォーマンスに関する考慮事項」を参照してください。
キューに置かれた信頼性のあるエンド ツー エンドのメッセージング
以下のセクションでは、エンドツーエンドで信頼できるメッセージングが必要なシナリオで推奨されるベスト プラクティスについて説明します。
基本的で信頼できる転送
エンド ツー エンドの信頼性を実現するには、ExactlyOnce プロパティを true に設定して、確実に転送できるようにします。 Durable プロパティは、要件に応じて true に設定することも、false に設定することもできます (既定値は true です)。 通常、エンド ツー エンドの信頼性の一環として、Durable プロパティは true に設定されています。 これはパフォーマンス コストに影響しますが、これによりメッセージが永続的になるため、キュー マネージャーがクラッシュした場合でもメッセージが失われなくなります。
トランザクションの使用
エンド ツー エンドの信頼性を確保するには、トランザクションを使用する必要があります。 ExactlyOnce の保証によって保証されるのは、メッセージがターゲット キューに配信されることだけです。 メッセージを確実に受信するには、トランザクションを使用します。 トランザクションを使用しないと、サービスがクラッシュした場合に、配信中であるが、実際にはアプリケーションに配信されるメッセージは失われます。
配信不能キューの使用
配信不能キューを使用すると、メッセージがターゲット キューに配信されなかった場合に、必ず通知されます。 システム指定の配信不能キューまたはカスタムの配信不能キューを使用できます。 アプリケーションごとに専用の配信不能キューに配信不能メッセージを送信できるため、一般にカスタムの配信不能キューを使用することをお勧めします。 カスタムの配信不能キューを使用しない場合は、システムで実行されているすべてのアプリケーションで発生するすべての配信不能メッセージが 1 つのキューに配信されます。 この場合、各アプリケーションは配信不能キュー全体を検索して、それぞれのアプリケーションに関連する配信不能メッセージを見つける必要があります。 MSMQ 3.0 を使用する場合など、カスタムの配信不能キューを使用できないこともあります。
エンド ツー エンドの信頼性が必要な通信では、配信不能キューを無効にすることはお勧めしません。
詳細については、「配信不能キューを使用したメッセージ転送エラー処理」を参照してください。
有害メッセージ処理の使用
有害メッセージ処理は、メッセージ処理のエラーから回復する機能を提供します。
有害メッセージ処理機能を使用する場合は、ReceiveErrorHandling プロパティが適切な値に設定されていることを確認します。 このプロパティを Drop に設定すると、データが失われることになります。 一方、Fault に設定すると、有害メッセージが検出されたときにサービス ホストでエラーが発生します。 MSMQ 3.0 を使用する場合、データの損失を防ぎ、有害メッセージを取り除くための最適なオプションは Fault です。 MSMQ 4.0 を使用する場合は、Move が推奨されます。 Move に設定すると有害メッセージがキューから取り除かれるため、サービスは新しいメッセージの処理を続行できます。 有害メッセージ サービスは、取り除かれた有害メッセージを別個に処理できます。
詳細については、「有害メッセージ処理」を参照してください。
高スループットの実現
単一のエンドポイントで高スループットを実現するには、以下を使用します。
トランザクション バッチ。 トランザクション バッチでは、1 回のトランザクションで多くのメッセージを読み取ることができます。 これにより、トランザクションのコミットが最適化され、全体的なパフォーマンスが向上します。 バッチ処理の難点は、バッチ内の 1 つのメッセージでエラーが発生した場合に、バッチ全体をロールバックし、再び安全にバッチ処理できるようになるまで、メッセージを 1 つずつ処理する必要があることです。 ほとんどの場合、有害メッセージはまれであるため、特にトランザクションに他のリソース マネージャーが参加している場合は、バッチ処理がシステム パフォーマンスを向上させる方法として推奨されます。 詳細については、「トランザクションに含まれるメッセージのバッチ処理」を参照してください。
コンカレンシー。 コンカレンシーによりスループットが向上します。ただし、コンカレンシーは共有リソースの競合に影響します。 詳細については、「コンカレンシー」を参照してください。
調整。 最適なパフォーマンスを実現するために、ディスパッチャー パイプラインのメッセージの数を調整します。 この操作を行う方法の例については、「調整」を参照してください。
バッチ処理を使用する場合は、コンカレンシーと調整はコンカレント バッチに変換されることに気をつけてください。
スループットと可用性を高めるには、キューから読み取る WCF サービスのファームを使用します。 この場合、ファームのすべてのサービスが同じエンドポイントで同じコントラクトを公開している必要があります。 ファームを使用すると、多数のサービスがすべて同じキューから読み取ることができるため、この方法はメッセージの生成率が高いアプリケーションで最も効果を発揮します。
ファームを使用する場合、MSMQ 3.0 ではリモート トランザクション読み取りがサポートされていないので注意してください。 MSMQ 4.0 は、リモート トランザクション読み取りをサポートしています。
詳細については、「トランザクションに含まれるメッセージのバッチ処理」を参照してください。
作業単位のセマンティクスによるキュー処理
キューにある一連のメッセージが関連している可能性があるため、これらのメッセージの順序付けが重要となるシナリオがあります。 このようなシナリオでは、関連するメッセージのグループを 1 つの単位としてまとめて処理します。つまり、すべてのメッセージが正常に処理されるか、どのメッセージも処理されないかのいずれかになります。 このような動作を実装するには、キューでセッションを使用します。
詳細については、「セッションでキューに置かれたメッセージのグループ化」を参照してください。
要求/応答メッセージの関連付け
通常、キューは一方向ですが、シナリオによっては、受信した応答を以前に送信した要求に関連付けることが必要になる場合があります。 このような関連付けが必要な場合、関連付け情報を含む独自の SOAP メッセージ ヘッダーをメッセージに追加することをお勧めします。 通常、送信側がこのヘッダーをメッセージに添付すると、受信側は、このメッセージを処理して応答キューにある新しいメッセージで応答するときに、関連付け情報を含む送信側のメッセージ ヘッダーを添付します。これにより、送信側は要求メッセージを使用して応答メッセージを識別できます。
非 WCF アプリケーションとの統合
WCF サービスまたはクライアントを非 WCF サービスまたはクライアントと統合するときには、MsmqIntegrationBinding を使用します。 非 WCF アプリケーションには、System.Messaging、COM+、Visual Basic、または C++ を使用して作成された MSMQ アプリケーションなどがあります。
MsmqIntegrationBinding を使用するときは、以下の点に注意してください。
WCF メッセージの本文は、MSMQ メッセージの本文と同じではありません。 キューに置かれたバインディングを使用して WCF メッセージを送信する場合は、WCF メッセージの本文が MSMQ メッセージの内部に配置されます。 MSMQ インフラストラクチャは、この追加情報を認識しません。認識するのは、MSMQ メッセージだけです。
MsmqIntegrationBindingでは、よく使用されるシリアル化型をサポートしています。 ジェネリック メッセージである MsmqMessage<T> の本文の型は、シリアル化型に基づいてさまざまな型パラメーターを受け取ります。 たとえば、ByteArray にはMsmqMessage\<byte[]>が必要であり、Stream にはMsmqMessage<Stream>が必要です。XML シリアル化では、<behavior> 要素の
KnownTypes属性を使用して既知の型を指定できます。この型は、後で XML メッセージを逆シリアル化する方法を確認する際に使用されます。