ロードバランスクラスタの実装：Linuxクラスタリングへの招待（4）

» 2001年06月09日 00時00分公開

　第3回までは、フェイルオーバクラスタの有効性、仕組みについてLinuxではどのように実現されているのかを解説しました。最終回となる今回は、停止しないWebサービス環境を構築するためのロードバランスクラスタ（負荷分散）技術について説明します。

　負荷分散は数年前からホットな話題となり、大規模サイトはもちろんのこと、現在では中小規模のサイトにおいてもその可用性の高さが注目され、導入するユーザーが増えてきています。インターネットでのチケット、限定品の販売などで急激なアクセス増加が見込まれる場合でも、ロードバランスクラスタ構成にしておくことでサービスのダウンは防止できるのです。

　なお、ロードバランスクラスタの概要については、連載第1回の「ロードバランスクラスタ」を参照してください。

負荷分散の実現方法

　負荷分散の実現方法は2つあります。

■マルチポイント方式

　これは、分散ノードであるサーバが同じ仮想IPアドレスを持ち、要求はすべてのノードが受け付けます。各ノード間ではネゴシエーションを行っており、次にどのノードが処理するかを決めます。処理を行うノード以外はその要求を破棄します。ノード間のネゴシエーションのオーバヘッドが大きくなりますが、クライアントへダイレクトにレスポンスを返すことにより、スループットを高めています（次に説明するコーディネータ方式では、レスポンスも負荷分散装置を経由するものが多い）。

　この方式のメリットは、コーディネータ方式のように専用装置を必要とせず、既存のサーバに組み込むことで負荷分散環境を構築できることです。また、分散ノードが並列なためSPOF（Single Point of Failure）になりません。

　MicrosoftのWindows 2000 Advanced Serverに搭載されているNLB（Network Load Balance）がこの方式を採用しています（Windows NTではWLBSと呼ばれてます）。

図1　マルチポイント方式

■コーディネータ方式

　一般的に負荷分散装置（専用ハードウェアあるいはソフトウェア実装）で実現している方法で、クライアントからのすべての要求をいったん装置で受け、配下のノードに対して分散させます。

　専用ハードウェアではASICによる分散エンジンにより非常に高速な転送が可能です。

　最近ではレイヤ4スイッチに負荷分散機能を組み込んだ製品も多く見られます。しかし、装置自身がSPOFとなるため装置の二重化によるフェイルオーバークラスタ構成を組む必要があります。

　CiscoのLocal Director、F5 Networks社のBIG-IP（ともに専用ハードウェア）、TurbolinuxのTurbo Cluster、NECのCLUSTERPRO for Linux（ともにソフトウェア実装）などがこの方式を採用しています。

　Linuxでの負荷分散機構は、High-Availability Linux Projectと協力する形でLVS（Linux Virtual Server）がコーディネータ方式の分散エンジンをGPLで提供しています。

参考：
http://www.linux-ha.org/
http://www.linuxvirtualserver.org/
http://jlvs.infoscience.co.jp/

図2　コーディネータ方式

分散アルゴリズム

　次に負荷分散のアルゴリズムについて説明します。

　古くはDNSラウンドロビンが使われましたが、現在ではアプリケーションやサーバ環境に合わせたよりきめ細かな分散制御ができるよう、さまざまなアルゴリズムが利用されています。

　代表的なものを幾つか紹介します。

ラウンドロビン（Round Robin）
配下の分散ノードに対して、要求を順番に割り振ります
最小コネクション（Least Connection）
コネクション数が一番少ないノードに割り振ります
最速応答（Fastest）
一番応答が速いノードに割り振ります
CPU負荷分散（CPU Load）
CPU負荷が一番軽いノードに割り振ります

　上記の方式は、いずれも重み付け（Weight値設定）ができます。

　例えばCPUパワーの異なるノードにおいて、ラウンドロビンで順番に分散させたのでは、CPUパワーの低いサーバはすべての要求を処理しきれず、逆にCPUパワーの高いサーバは処理を完了し、次の要求までアイドル状態になることも考えられます。そこでWeight値をセットすることで分散比率を変え、クライアントからの要求を効率よく分散して全体のスループットを向上させます。

　実装製品は少ないのですが、各ノードのCPU使用率をモニタしてCPUが空いているノードに動的に分散させる方式は、より効率のよい分散が可能といえます。

　これまで述べたことは、負荷分散として最もベーシックな機能部分です。これらに加えてより強力なロードバランス環境を提供する上で、幾つかの重要な機能が必要となります。

セッション維持

　負荷分散環境の構築により、サーバ負荷の軽減やユーザーへのスループット向上を実現できます。参照系のサイトであれば、同一クライアントからの要求をセッションごとにどのサーバに割り振っても特に問題にはなりません（もちろん、各ノード内のコンテンツの同期が取れていることが前提です）。

　しかし、ショッピングサイトで買い物中に同一クライアントからのセッションが異なるサーバに分散されたのでは、せっかく買おうと思ってショッピングカートに詰め込んだ商品が消失してしまうことにもなりかねません。

　そこで、「セッションの維持」が必要となります。同一クライアントからの要求は同一サーバに固定的に割り振り、同一サーバを使ってセッションを維持するということです。

　セッション維持の方法には幾つかありますが、昨今のブラウザ環境の多様化に伴い、新しい維持方法（Sticky）も必要となってきています。ここではそれらも含めて説明します。

■ソースIPアドレスによるSticky

　各クライアントはIPアドレスが異なるため、そのIPアドレスをキーにして分散ノードを固定します。

図3　ソースIPアドレスによるSticky

　しかし、この方法はある大きな問題を抱えています。プロキシサーバを経由してロードバランサに到達した場合です。プロキシサーバを経由してアクセスしてくる要求は、プロキシサーバのIPアドレスがソースIPアドレスとなるため、分散先が特定のノードに集中し、分散効果がまったく得られないことになります。

　この問題の解決方法として代表的なものが、次に紹介するhttp Cookieによるクライアントの特定とセッション維持の確立方法です。

■http CookieによるSticky

　プロキシ経由では同じソースIPアドレスになってしまうため、ロードバランス装置の中でクライアントごとに異なるCookieを生成します。そのCookieをクライアントに送ることでクライアントを識別し、ノードに分散させると同時にセッション維持のためのキーとして利用します。しかし、クライアントがCookieを無効にしたり、SSLでの接続（Cookieも暗号化される）の場合は有効ではありません。

図4　http CookieによるSticky

■SSL Session IDによるSticky

　SSL（ポート番号443番）を使った接続の際、SSLセッションIDをキーとして接続ノードを固定化します。分散ノードに対するHTTPコネクションの確立時に、HTTPヘッダにSSL情報を追加する方法が考えられます。

　実装としては、サーバが返してきたセッションIDとサーバとの対応テーブルを構築し、そのテーブルで分散サーバとの対応付けを行うのも1つの方法です。

図5　SSL Session IDによるSticky

　しかし、プロキシ経由の場合は特定のサーバに固定化されるため分散効果が得られない場合があります。

■URLによるSticky

　HTTPヘッダ内のURLにより分散先を固定化します。

　複数サーバがそれぞれ異なるコンテンツを持つホスティングサービスを提供する場合に、URLにより分散先を切り替えます。

図6　URLによるSticky

■携帯電話へのSticky

　NTTドコモのiモードのような携帯端末は、上記のCookieやSSL（iアプリ機など、一部の機種ではサポート）を利用できるブラウザではありません。NTTドコモのゲートウェイを経由する際に、ソースIPアドレスが1つとは限らず、ソースIPアドレスによるセッション維持は利用できないことになります。また、ゲートウェイが1つだとすると、プロキシ経由の問題を引き起こしてしまいます。

　このようなケースでは、サーバからのレスポンスHTML中にサーバを特定する情報を追加してクライアントへ返信し、クライアントが次にアクセスした際に、そのサーバ情報で分散先サーバを特定します。

　なお、SSLの場合はHTMLの解析ができないため、この方法は有効ではありません。