負荷分散／QoS制御 機能ガイド

2.1.1.7 セッション維持（一意性保証）

サイト負荷分散機能は、利用者からのリクエストをサーバファーム内のサーバに転送する際、分散の単位を設定することができます。分散の単位としてつぎのいずれかを設定できます。

• ノード単位の分散
  ノード、すなわちクライアント（利用者）を1つの単位として、同じノードからのリクエストはサーバファーム内の同じサーバに転送する方式です。1つのノードからのすべてのリクエストは同じサーバに転送されることが保証されます。
• コネクション単位の分散
  コネクション（TCPコネクションまたは、UDPフロー）を1つの単位として、コネクション単位にサーバファーム内の最適なサーバを選択して転送する方式です。ノード単位の分散と違い、同じノードであってもコネクションが異なれば、別の最適なサーバに転送されます。

負荷分散を行うアプリケーションの特性にもとづいて、上記のいずれかの方式を選択することができます。

「ノード単位の分散」は、クライアントの送信元IPアドレスにもとづいて、同じ送信元IPアドレスをもつすべてのリクエストを同じサーバに転送する制御を行っています。しかしながら、クライアントからのアクセスがプロキシやファイアウォールを経由する場合、一般的に、すべてのクライアントの送信元IPアドレスが1つまたは数個のIPアドレスに変換、または、コネクション単位に別のIPアドレスが割当てられます。この結果、1台または数台のサーバにトラフィックが集中したり、すべてのコネクションが同じサーバに転送されることを期待しているアプリケーションでは誤動作を起こす可能性があります。このような環境では「コネクション単位の分散」を使用します。しかし、WWWサーバ上のe−コマースアプリケーションなどでは、対話処理を行っている間、同じサーバにアクセスすることを期待するものがあります。このようなケースでは「コネクション単位の分散」だけではうまく動作しません。

Traffic Directorは、このようなアプリケーションの負荷分散をサポートするために、一定時間最初にアクセスしたサーバと同じサーバへのアクセスを保証する「セッション維持（アクセス先サーバの一意性保証）機能」を提供しています。

• Cookieオプション
  cookieオプションは、クライアントからのアクセスを負荷分散ポリシーで指定された時間(一意性保証時間)、サーバファーム内の特定のサーバに固定化するためのオプション機能です。このオプション機能は、HTTPプロトコルを使用した通信だけに使用することができます。また、このオプション機能を使用する際は、クライアント側でcookieを使用するように構成しておく必要があります。クライアントからのリクエストが到着すると、Traffic Director（サーバ）の負荷分散エンジンは、cookieが含まれているか否かを検査します。cookieが含まれていないリクエストは、新しいリクエストと見なして、指示されている「サーバ分散方式」にもとづいて最適なサーバに転送します。その後、負荷分散エンジンは、サーバからのレスポンスに対して、後で説明する2つの方式のいずれかの方式でcookieにクライアントIDを挿入、又はcookieに設定されているセッションIDを参照してアクセス先サーバとのマッピングテーブルを作成した後、クライアントにレスポンスを返します。一方、cookieが含まれているリクエストを受信すると、cookie内の情報を検査して、クライアントID又はセッションIDに対応するマッピングテーブルを使用して転送先サーバを決定し、最初に転送したサーバと同じサーバに転送します。無効なcookie情報をもつcookieを含むリクエストを受信した場合は、新しいリクエストと見なして、指示されている「サーバ分散方式」にもとづいて最適なサーバに転送します。
  Traffic Directorは、cookieオプションとして、つぎの2つの方式を提供しています。
  • クライアントID挿入方式
    Traffic Director（サーバ）自身がcookieにクライアントIDを挿入し、挿入したクライアントIDとアクセス先サーバをマッピングする方式です。
  • セッションID参照方式
    Interstage Application ServerやServer 2000のJava ServletがSet-Cookieで設定したセッションIDをTraffic Director（サーバ）が参照し、このセッションIDとアクセス先サーバをマッピングする方式です。
• SSLセッションIDオプション
  SSLセッションIDオプションは、同じSSLセッションIDをもつリクエストを負荷分散ポリシーで指定された時間(一意性保証時間)、同じサーバに転送するためのオプション機能です。このオプション機能は、SSL暗号通信を行うトランザクションだけに使用することができます。このオプション機能を使用する際は、サーバ側でSSL v3(バージョン3)がサポートされていなければなりません。
  Traffic Director（サーバ）の負荷分散エンジンは、SSL暗号通信に先立って行われるSSLハンドシェイク（新規要求に対しては、サーバとクライアント間のセキュリティ属性を折衝して、暗号アルゴリズムや圧縮アルゴリズムを決定し、SSLセッションIDが割当てられます。既存のセッションを再開する場合は、クライアントからサーバに対して、割当て済みのSSLセッションIDを提示します。）を監視しています。負荷分散エンジンがクライアントからの最初のリクエスト（SSLセッションIDなし）を受信した場合は、指示されている「サーバ分散方式」にもとづいて最適なサーバに転送し、その後、サーバからクライアントに対して通知されるSSLセッションIDを監視し、SSLセッションIDと転送先サーバのマッピングを行い、一意性を制御します。既存のセッションを再開する場合は、SSLハンドシェイク時にクライアントからSSLセッションIDが提示されますので、負荷分散エンジンが管理しているマッピングテーブルを検索し、該当するサーバにリクエストを転送します。マッピングテーブルが存在しないか、または、指定された一意性保持時間が満了している場合は、新しい要求と見なして、指示されている「サーバ分散方式」にもとづいて最適なサーバに転送します。
  SSLセッションIDオプションを使用することで、SSLハンドシェイク・プロセスを何度も行う必要がなく、サーバの負荷が下がり、快適なレスポンスを得ることができます。
• URLリライト・オプション
  Interstage Application ServerやServer 2000は、HTTPプロトコルを使用した一連の対話型の処理を管理するために、セッション管理と呼ばれる処理を行っています。セッション管理の手法として、上で説明したcookieを利用する方法とURLのパス情報の中にセッションIDを埋め込む（URLリライトまたはURL埋め込み）方法があります。Traffic Director（サーバ）は、HTTPレスポンスを監視し、URLリライトされたセッションIDとアクセス先サーバのマッピングテーブルを作成します。その後、クライアントからのHTTPリクエストを監視し、負荷分散ポリシーで指定された時間(一意性保証時間)、同じセッションIDを持つHTTPリクエストを以前アクセスしたサーバと同じサーバに転送します。
  （URLリライトの例：http://www.mybiz.com/catalog/index.html;jsessionid=セッションID）
  iモードなどのcookieが利用できないデバイスからのアクセスに対して、対話処理を行いつつ効果的なサーバ負荷分散が可能になります。
• URLリライト拡張オプション
  このオプション機能は、URLリライト・オプション機能を拡張したものです。URLリライト・オプション機能は、Interstage Application ServerやServer 2000がURLパス情報の中に埋め込むキー名（jsessionid等）を固定文字列として認識し、キー名に続くセッションIDにもとづいてセッション維持を制御していましたが、URLリライト拡張オプション機能は、URLパス情報内に埋め込まれた任意の文字列をキー名として認識し、キー名に続く情報にもとづいてセッション維持を制御します。つぎに示す例は、キー名として“$ServerID=”を負荷分散ポリシーとして定義した場合です。Traffic Director（サーバ）は、HTTPレスポンスを監視し、URLリライトされた“$ServerID=”に続く値（文字列）とアクセス先サーバのマッピングテーブルを作成します。その後、クライアントからのHTTPリクエストを監視し、負荷分散ポリシーで指定された時間(一意性保証時間)、同じ“$ServerID=値”を持つHTTPリクエストを以前アクセスしたサーバと同じサーバに転送します。
  （URLリライト拡張の例：http://www.mybiz.com/catalog/default.asp?$ServerID=0001;PW=xxxx）
  また、上記任意キーの参照を、URLパス情報だけでなく、Cookie内のキー名も任意の文字列として認識することが可能です。これにより、Cookieを使用可能な機器までも含めた柔軟なシステム構築が可能となります。
• HTTP認証ヘッダ・オプション
  WWWサーバがWeb認証を実行している場合、クライアントがアクセスする度に異なるサーバに転送されると、利用者は、その都度認証処理を行う必要があり、非常に使い勝手の悪いシステムとなってしまいます。1度認証処理を行うと、以降のアクセスに対して、認証処理を実行した同じサーバに転送されることが要求されます。HTTP認証ヘッダ・オプション機能は、HTTPリクエストヘッダ内のAuthorizationフィールド、またはProxy-Authorizationフィールドの値（認証情報）にもとづいてアクセス先サーバのマッピングテーブルを作成します。その後、クライアントからのHTTPリクエストを監視し、負荷分散ポリシーで指定された時間(一意性保証時間)、同じ認証情報を持つHTTPリクエストを以前アクセスしたサーバと同じサーバに転送します。
• HTTPトンネル・セッションIDオプション
  Interstage Application Serverは、クライアントとサーバ間の通信にHTTPトンネリングプロトコルと呼ばれる特別なプロトコルをサポートしています。クライアントとサーバ間でこのプロトコルが使用され、Interstage Application Serverがセッション管理を行う場合、一連の対話処理の間、アクセス先のサーバを固定化することが要求されます。Traffic Director（サーバ）は、HTTPレスポンスを監視し、HTTPのボディ部に埋め込まれたHTTPトンネリングプロトコルヘッダ内のセッションIDとアクセス先サーバのマッピングテーブルを作成します。その後、クライアントからのHTTPリクエストを監視し、負荷分散ポリシーで指定された時間(一意性保証時間)、同じセッションIDを持つHTTPリクエストを以前アクセスしたサーバと同じサーバに転送します。

上記の様々な一意性保証オプション機能は、「IPアドレス変換」方式と「MACアドレス変換」方式の両方の転送方式で利用できますが、Traffic Director（サーバ）を並列型配置する場合は、これらのセッション維持オプション機能は利用できません。

URLベース負荷分散機能と併用してセッション維持オプション機能を使用することで、より柔軟で拡張性の高い優れたパフォーマンスを発揮できるサーバファームを構築することができます。

なお、使用するネットワークの構成やクライアントにおけるセッション情報のキャッシュ時間等によりセッション維持（一意性保証）できない場合があります。

---

• コネクション単位の分散においてSSLセションID以外のオプションは、SSLで暗号化された通信には適用できません。
• Cookieオプションを使う場合は、アプリケーション作成上の注意事項があります。詳細は、「負荷分散/QoS制御 テクニカルガイド」を参照してください。
• Traffic Director(Solaris版)では、以下の注意事項があります。
  • JServletのセッションID参照方式において、JServletでセッションCookieを送らない機能を使用する設定を行なった場合、セッションIDがレスポンスデータの先頭から5360byte目までに含まれるようにアプリケーションを作成してください。
  • FTPの負荷分散において、パッシブ方式を使用する場合は、ノード単位の分散を選択してください。
  • コネクション単位の分散をおこなう場合、負荷分散対象サーバ上のWebサーバで設定するKeep Alive機能を無効にしてください。