次の方法で共有

負荷分散

  • [アーティクル]

Windows Communication Foundation (WCF) アプリケーションの処理能力を高める方法の 1 つは、アプリケーションを負荷分散されたサーバー ファームに配置することでスケール アウトすることです。 WCF アプリケーションは、ハードウェア ベースの負荷分散アプリケーションのほか、Windows Network Load Balancing のようなソフトウェアによる負荷分散も含む、標準的な負荷分散手法を使用して負荷分散できます。

以降のセクションでは、システム指定の各種のバインディングを使用して構築された WCF アプリケーションを負荷分散するときの考慮事項について説明します。

基本 HTTP バインディングによる負荷分散

負荷分散の面から見た場合、BasicHttpBinding を使用して通信を行う WCF アプリケーションと、他の一般的なタイプの HTTP ネットワーク トラフィック (静的な HTML コンテンツ、ASP.NET ページ、ASMX Web サービス) との相違はありません。 このバインディングを使用する WCF チャネルは本質的にステートレスで、チャネルが閉じると接続を終了します。 したがって、BasicHttpBinding には既存の HTTP 負荷分散の手法で十分に対応できます。

既定では、BasicHttpBinding は、メッセージの接続 HTTP ヘッダーで Keep-Alive 値を送信することで、サポートするサービスにクライアントが永続的な接続を確立できるようにします。 この構成では、以前に確立した接続を再使用して同じサーバーへの後続するメッセージを送信できるため、スループットが向上します。 ただし、接続を再使用すると、クライアントが負荷分散ファーム内の特定サーバーと強く関連付けられてしまうため、ラウンドロビン方式の負荷分散の効果を損ねることがあります。 これを回避するには、Keep-Alive またはユーザー定義の KeepAliveEnabled で CustomBinding プロパティを使用して、サーバーの HTTP Binding を無効にできます。 構成を使用してこれを行う例を次に示します。

<?xml version="1.0" encoding="utf-8" ?>  
<configuration>  
  
 <system.serviceModel>  
  <services>  
   <service
     name="Microsoft.ServiceModel.Samples.CalculatorService"  
     behaviorConfiguration="CalculatorServiceBehavior">  
     <host>  
      <baseAddresses>  
       <add baseAddress="http://localhost:8000/servicemodelsamples/service"/>  
      </baseAddresses>  
     </host>  
    <!-- configure http endpoint, use base address provided by host  
         And the customBinding -->  
     <endpoint address=""  
           binding="customBinding"  
           bindingConfiguration="HttpBinding"
           contract="Microsoft.ServiceModel.Samples.ICalculator" />  
   </service>  
  </services>  
  
  <bindings>  
    <customBinding>  
  
    <!-- Configure a CustomBinding that disables keepAliveEnabled-->  
      <binding name="HttpBinding" keepAliveEnabled="False"/>  
  
    </customBinding>  
  </bindings>  
 </system.serviceModel>  
</configuration>

.NET Framework 4 で導入された簡略化された構成を使用すると、次の簡略化された構成で同じ動作を実現できます。

<?xml version="1.0" encoding="utf-8" ?>  
<configuration>  
 <system.serviceModel>  
    <protocolMapping>  
      <add scheme="http" binding="customBinding" />  
    </protocolMapping>  
    <bindings>  
      <customBinding>  
  
      <!-- Configure a CustomBinding that disables keepAliveEnabled-->  
        <binding keepAliveEnabled="False"/>  
  
      </customBinding>  
    </bindings>  
 </system.serviceModel>  
</configuration>

既定のエンドポイントについては、「Simplified Configuration」 (簡易構成) と「Simplified Configuration for WCF Services」 (WCF サービスの簡易構成) を参照してください。

WSHttp バインディングおよび WSDualHttp バインディングによる負荷分散

WSHttpBinding と WSDualHttpBinding はどちらも、既定のバインド構成をいくつか変更すれば、HTTP の負荷分散手法を使用して負荷分散できます。

  • セキュリティ コンテキストの確立を無効にするか、ステートフルなセキュリティ セッションを使用します。 セキュリティ コンテキストの確立を無効にするには、WSHttpBinding の EstablishSecurityContext プロパティを false に設定します。 WSDualHttpBinding を使用しているか、セキュリティ セッションが必要な場合は、「セキュリティで保護されたセッション」で説明されているステートフルなセキュリティ セッションを使用することができます。 ステートフルなセキュリティ セッションでは、セキュリティ セッションのすべての状態 (ステート) が保護セキュリティ トークンの一部として要求ごとに転送されるため、サービスをステートレスな状態に保つことができます。 ステートフルなセキュリティ セッションを有効にする場合、システム指定の WSHttpBinding と WSDualHttpBinding では必要な構成設定が公開されないため、CustomBinding またはユーザー定義の Binding を使用する必要があります。

  • セキュリティ コンテキストの確立を無効にした場合は、サービス資格情報のネゴシエーションも無効にする必要もあります。 これを無効にするには、WSHttpBinding の NegotiateServiceCredential プロパティを false に設定します。 サービス資格情報のネゴシエーションを無効にするには、クライアント上でエンドポイント ID を明示的に指定することが必要になる場合があります。

  • 信頼できるセッションを使用しないでください。 この機能は既定では無効です。

Net.TCP バインディングの負荷分散

NetTcpBinding は、IP レイヤー負荷分散の手法を使用して負荷分散できます。 ただし、NetTcpBinding は接続の待ち時間を減らすために、既定で TCP 接続のプールを作成します。 この最適化は、負荷分散の基本的なメカニズムに干渉します。 NetTcpBinding を最適化するための主な構成値はリース タイムアウトで、これは接続プール設定の一部です。 接続プールによって、クライアントの接続がファーム内の特定サーバーと関連付けられます。 このような接続の有効期間 (これはリース タイムアウトの設定で制御される要素です) が長くなるにつれて、ファーム内の各サーバーの負荷分散がうまくいかなくなります。 その結果、平均呼び出し時間が増加します。 したがって、NetTcpBinding を負荷分散シナリオで使用する場合は、バインディングによって使用される既定のリース タイムアウトを少なくすることを検討してください。 負荷分散のシナリオでは、30 秒のリース タイムアウトから始めるのが合理的ですが、最適値はアプリケーションによって異なります。 チャネル リース タイムアウトおよびその他のトランスポート クォータの詳細については、「トランスポート クォータ」を参照してください。

負荷分散のシナリオで最適なパフォーマンスを実現するには、NetTcpSecurity (Transport または TransportWithMessageCredential) を使用することを検討してください。

関連項目