LVSによるLinuxロードバランサと市販製品を比較する


LVSによるLinuxロードバランサはOSIモデル第4層(トランスポート層)の情報でスイッチングを行うL4スイッチです。市販製品もL4スイッチをベースとしたものが主流ですが、多くの製品でL4スイッチの機能に加えて第7層(アプリケーション層)の情報を取り扱う機能がオプションとして提供されています。LVSと市販製品の比較で実用上注目しなければならない相違点です。実用上、この違いが意味のある差異となるのかどうか検討してみましょう。

市販製品のL7スイッチ機能

市販製品の第7層機能は、概ね、以下のようなアプリケーション層のセッション維持を目的としたものです。

  • アプリケーション・セッション維持機能 (例:「スティッキーセッション」、「ポリシールーティング」)
  • SSL session-ID付加機能 (SSLアクセラレータを装備したものもある)

アプリケーション層のセッション維持が必要となる典型的な例は、WEB ECサイトのショッピングカートです。同じユーザのリクエストが異なるサーバに無作為に割り当てられた場合、サーバによってカートの中身が違うという事態に陥ります。この課題には2系統の異なるアプローチが存在します。

  • サーバで対応 (サーバのクラスタリング機能でセッション管理)
  • ロードバランサーで対応 (セッションを識別し、固定的にサーバを割り当てる)

ロードバランサーのセッション維持機能は後者を前提としたものです。L4スイッチには、このような課題に対応するために、クライアントのIPアドレスを元に特定のサーバを固定的に振り当てる機能が備えられています。「永続性機能」「パーシスタンス」などと呼ばれるこの機能はLVSも市販製品も同様に提供しています。市販製品では、これに加えて、以下のようなアプリケーション層(L7)の処理によるセッション維持機能が提供されています。実際の応用環境で、このようなL7機能に大きな意味があるのかどうかを考えて見ましょう。

  • 強制的にセッションCookieやURLパラメータを生成し追跡
  • アプリケーションが使用しているセッション情報(Cookie, URLパラメータ)を追跡
  • アプリケーション層の情報を解析し追跡 (ハイエンド製品)

目的アプリケーションとセッション管理

WEBサーバの場合

HTTPサーバやアプリケーションサーバやがクラスタリング機能を備えている場合、ロードバランサーでセッション維持を負担する必然性がありません。Tomcat、JBossなどのJava EEアプリケーションサーバや、CMSサーバであるZopeなどがこの例です。また、HTTPサーバソフトウェアの代表であるApacheはVers2.xからクラスタリング機能を提供しています。ECサイトなど一般的なWEBサーバに関する限り、ロードバランサーのスティッキーセッション機能は、現実には不要と言って過言ではありません。Perl、 PHP等によるCGIを含んでいる場合は、ロードバランサーのスティッキーセッション機能があれば、クラスタリングへの対応が簡単になりますが、PHPで作成されたECサイトなどの場合、クライアントの特定など、多くの場合、アプリケーション側でセッション管理が必要であり、手段も提供されています。

DBサーバの場合

ロードバランサーを経由することは相応の遅延を生じます。セッション管理のような高コストな処理を伴った場合はなおさらです。DBサーバではこのような遅延の累積は著しい性能低下を生じます。DBサーバもWEBサーバ同様、DBソフトウェアや接続ミドルウェアがクラスタリングの機能を提供している場合、ロードバランサーでセッション維持を管理する必要はありません。DBサーバの場合はDBソフトウェアあるいは接続ミドルウェアによる解決が汎用のロードバランサーを使用するよりも有益です。

メールサーバの場合

SMTP、 POP、IMAPなどのプロトコルは、WEBサーバなどとちがい、基本的にステートフルなサービスです。したがって、ロードバランサーによるセッション管理は基本的に不要です。なんらかの理由で、特定のクラスターノードにクライアントを固定したい場合、パーシスタンス機能が利用できます。