Skip to main content

本ページの製品は2024年4月1日より、エフサステクノロジーズ株式会社に統合となり、順次、切り替えを実施してまいります。一部、富士通表記が混在することがありますので、ご了承ください。

Japan

負荷分散入門

本連載では、信頼性の高いシステムを構築する上で欠かせない要素となってきた負荷分散技術と負荷分散装置(ロードバランサ)について解説します。

掲載日：2004年11月23日
更新日：2006年12月19日

これまでの連載

第6回 セッション維持機能

第2回でも説明したように、 セッション維持機能は、付加価値の高いサービスを提供する上で欠かせない機能です。

利用者がWebサイトにアクセスしているとき、Webブラウザは比較的短い時間で接続を切ってしまいます。つまり、クライアントとサーバが常時接続されている訳ではありません。
負荷分散システムでは、クライアントからのリクエストが複数のサーバに振り分けられるため、Webブラウザは、実際には毎回同じサーバにアクセスするは限らないという事になります。 これでも、情報を表示するだけの情報公開サイトなどであれば何の問題もありません。

しかし、クライアントからのリクエストが、前と異なるサーバに送られると困る場合があります。 たとえは、ショッピングサイトでは、ショッピングを始めてから決済がすむまで、利用者が選んだ商品のリストを管理しています。 しかし、リクエストが別々のサーバに送られると、各サーバが別々に異なった商品のリストを持つことになってしまいます。

このような問題の解決策の一つは、各サーバのアプリケーションが、サーバ間で通信をするなどして情報を共有することです。しかし、この様な機能をサーバのアプリケーションに付加しようとすると、アプリケーションの開発が大変になってしまいます。

もう一つの解決策は、負荷分散装置のセッション維持機能を利用することです。
セッション維持機能を利用すると、ある利用者のリクエストは必ずひとつのサーバに振り分けられるため、利用者とサーバの両方にとって矛盾のない通信が保証されます。 サーバのアプリケーションは、他のサーバの存在を意識する必要がなくなります。

6-1.gif

図 1. セッション維持機能

セッション維持機能は、セッションを識別する情報により二つに大別されます。

  • ネットワーク・プロトコルの情報を参照してセッションを識別する
  • アプリケーション・プロトコルの情報を参照してセッションを識別する

前者では、IP、TCP、UDPといった基本的なネットワーク・プロトコルの情報によって、セッションを識別します。 この方法は、アプリケーション・プロトコルに依存しないため、サーバのサービスの種類に関わりなく使用可能です。

後者では、より上位のアプリケーション・プロトコルの情報によってセッションを識別します。 アプリケーションが管理する情報に基づいてセッションを識別するため、きめ細かい制御が可能になります。 この方法は、アプリケーション・プロトコルに依存するため、サービスの種類に合わせてセッション維持の方式を選択します。

IPCOMでは、セッション維持機能として次の機能を提供しています。

全てのサービスで使用できる機能
  • ノード単位の分散
HTTP (Web)プロトコルのセッション維持機能
  • cookieオプション
  • URLリライト・オプション
  • HTTP認証ヘッダー・オプション
SSLプロトコルのセッション維持機能
  • SSLセッションID・オプション

今回は、これらのセッション維持機能について説明します。

  1. ノード単位の分散
  2. HTTPプロトコルのセッション維持方式
  3. SSLプロトコルのセッション維持方式

ページの先頭へ topofpage

blue_dot.gifノード単位の分散

「 ノード単位の分散」は、クライアント（利用者）を1つの単位とし、同じクライアントからのすべてのリクエストを同じ分散対象サーバに振り分ける方式です。
この方式は、クライアントを送信元IPアドレスに基づいて識別し、同じ送信元IPアドレスを持つすべてのリクエストを同じサーバに振り分けます。 これにより、1 つのクライアントからのすべてのリクエストは、同じサーバに振り分けられることが保証されます。

6-2.gif

図 2. 送信元IPアドレスによるセッション維持

ページの先頭へ topofpage

blue_dot.gifHTTP (Web)プロトコルのセッション維持方式

HTTPプロトコルに対しては、複数のセッション維持方式が用意されています。
Webブラウザの条件によって利用可能な方式が異なるため、対象となるクライアントやWebブラウザに合わせて、セッション維持方式を選択します。

cookieオプション
cookie(クッキー)は、Webベースのアプリケーションを利用中に発生した利用者固有の情報を、サーバ側でなく、Webブラウザ側に記憶させる仕掛けです。
サーバは、応答データに Set-Cookieヘッダーを追加することで、記憶させたい情報とその有効期限を、Webブラウザに指示することができます。 Webブラウザは、有効期間内に同じサーバにアクセスするとき、リクエストに Cookieヘッダーを追加して、記憶していた情報をWebサーバに送ります。
「 cookieオプション」は、この機能を利用して、クライアントからのリクエストを同じサーバに振り分ける方式です。

セッション維持のために cookieオプションが設定された場合、IPCOMは、クライアントからのリクエストと、サーバからの応答の両方を監視します。
クライアントが初めてサーバにアクセスしたときには、IPCOMは設定された分散方式に基づき、最適なサーバにリクエストを振り分けます。 このとき、サーバはセッションIDをcookieとして応答データに挿入します。 Webブラウザは、このcookieを記憶しておき、次にアクセスするときにリクエストに挿入します。
サーバからの応答にセッションIDを含むcookieが含まれていたら、IPCOMはそのセッションIDとアクセス先のサーバのテーブルを作成します。 そのあと、クライアントからのリクエストにセッションIDを含むcookieが含まれていたら、IPCOMはそのセッションIDを発行したサーバを探し、そのサーバにリクエストを振り分けます。

パソコン用のWebブラウザのほとんどでcookieは利用可能であるため、cookieオプションはよく利用される方式です。

6-3.gif

図 3. cookieによるセッション維持

URLリライト・オプション
パソコン用のWebブラウザでは、ほとんどcookieを利用可能ですが、セキュリティ上の理由でcookieを利用しない設定になっていることがあります。 また、携帯電話のブラウザでは、はじめからcookieを利用できません。
このため、cookieオプション以外のセッション維持方式も必要となります。

「 URLリライト・オプション」は、WebベースのアプリケーションがURLのパス情報の中に埋め込むセッションIDに基づいて、クライアントからのリクエストを同じサーバに振り分ける方式です。

セッションIDが埋め込まれたURLの例

  https://www.fujitsu.com/jp/products/network/security-bandwidth-control-load-balancer/ipcom/?jsessionid=ExU08oXaz=

セッション維持のために URLリライト・オプションが設定された場合、IPCOMは、クライアントからのリクエストとサーバからの応答の両方を監視します。
クライアントが初めてサーバにアクセスしたときには、IPCOMは設定された分散方式に基づき、最適なサーバにリクエストを振り分けます。 このとき、WebサーバはセッションIDを埋め込んだURLを生成して、Webブラウザに通知します。
そのあと、Webブラウザは、このセッションIDが埋め込まれたURLでサーバにアクセスします。
サーバからの応答にセッションIDが埋め込まれたURLが含まれていたら、IPCOMはそのセッションIDとアクセス先サーバのテーブルを作成します。 そのあと、クライアントからのリクエストにセッションIDが埋め込まれたURLが含まれていたら、IPCOMはそのセッションIDを発行したサーバを探し、そのサーバにリクエストを振り分けます。

URLリライト・オプションを使用することにより、cookieが利用できない端末でもセッション維持が可能となります。

6-4.gif

図 4. URLによるセッション維持

HTTP認証ヘッダー・オプション
Webブラウザは、Webサーバのアクセス制限のある領域にアクセスするとき、ユーザIDやパスワードの情報から生成された文字列 ( 認証情報) を、 HTTP認証ヘッダー( Authorizationヘッダー) としてリクエストに挿入します。
「 HTTP認証ヘッダー・オプション」は、この認証情報を基に、リクエストを認証処理を実行したサーバと同じサーバに振り分ける方式です。

セッション維持のために HTTP認証ヘッダー・オプションが設定された場合、IPCOMは、クライアントからのリクエストとサーバからの応答の両方を監視します。
クライアントからのリクエストにHTTP認証ヘッダーが含まれていたら、IPCOMはその認証情報とアクセス先サーバのテーブルを作成します。 そのあと、クライアントからのリクエストに記憶している認証情報と同じ認証情報が含まれていたら、IPCOMはそのリクエストを以前アクセスしたサーバと同じサーバに振り分けます。

6-5.gif

図 5. HTTP認証ヘッダーによるセッション維持

ページの先頭へ topofpage

blue_dot.gifSSLプロトコルのセッション維持方式

SSLプロトコルは、サーバとクライアントの間で鍵の生成、通信データの暗号化/復号化を行うプロトコルです。
SSLプロトコルは、単体で使われる事はなく、HTTPやFTPといった他のアプリケーション・プロトコルと組み合わせて利用されます。 これにより、暗号化されていないアプリケーション・プロトコルとそのデータを保護します。
SSLとHTTPの組み合わせ(HTTPS)は、良く利用されます。

SSLセッションIDオプション
SSLプロトコルでは、一つのクライアントとサーバの組み合わせに対して一つの SSLセッションIDが付与されます。 「 SSLセッションIDオプション」は、このSSLセッションIDでクライアントを識別し、同じSSLセッションIDを持つリクエストを、同じサーバに振り分ける機能です。

6-6.gif

図 6. SSLセッションIDによるセッション維持

なお、負荷分散するサービスがHTTPS (HTTP+SSL)プロトコルの場合には、以下の点にご注意ください。
現在、パソコンで使用されているWebブラウザのほとんどは、SSLセッションIDを短時間で切り替える仕様になっています。 このため、SSLセッションIDオプションでは、HTTPS(HTTP+SSL)通信のセッション維持機能が期待通りに機能しません。
HTTPS通信のセッション維持を行うには、次に説明する「 SSLアクセラレーターを利用したセッション維持」をご利用ください。

SSLアクセラレーターを利用したセッション維持
SSLプロトコルで保護された通信のセッション維持を行う方法は、もう一つあります。 それは、負荷分散装置に SSLアクセラレーターを内蔵し、通信データの復号化と負荷分散処理を同時に実施する方法です。

HTTPSプロトコルの通信データはSSLにより暗号化されているため、そのままではURLやcookieの情報を用いたセッション維持機能は利用できません。SSLアクセラレーターで暗号化された通信データを復号化することにより、cookieオプション、URLリライト・オプション、HTTP認証ヘッダー・オプションが利用可能になりなます。
また、SSLプロトコルの処理はサーバにとって負荷が大きいため、これを専用のハードウェアで処理することにより、Webサーバの持つ能力を最大限に発揮させることができます。

IPCOMでは、SSLアクセラレーターを内蔵したモデルも提供しています。

【参考資料】
SSLアクセラレーターの導入効果について解説しています。

6-7.gif

図 7. SSLアクセラレーターを利用したセッション維持

ページの先頭へ topofpage

これまでの連載

ページの先頭へ topofpage

負荷分散装置(IPCOM)のラインナップ

負荷分散装置 IPCOMシリーズは、システムに合わせて搭載機能を追加し、段階的な統合を可能にすることにより、常にシステムに最適なネットワーク環境を実現します。

lineup_moreinfo.gif

ページの先頭へtop fo page