本連載ではこれから数回にわたって、ロードバランサ製品のデファクトスタンダード「BIG-IP」の概要を紹介していくが、第1回となる今回はBIG-IPそのものの前に、まずは「ロードバランサ」という製品ジャンルについて、あらためて簡単におさらいしておこう。

「ロードバランサ」とはその名の通り、主にWebシステムにかかる負荷（load：ロード）を複数のサーバに分散させ、処理のバランスを調整するための装置だ。日本語では一般的に「負荷分散装置」などと呼ばれる。

Webシステム、特にインターネットにサービスを公開しているシステムは、いつどれだけの数のユーザーからアクセスを受けるかわからない。公開当初はさほどアクセスがないサイトでも、何かのきっかけで急に人気が出てアクセスが集中することも多い。そうした場合に備え、ユーザーからのアクセスをさばくWebサーバを複数台用意しておき、システムの処理能力が不足してきた場合には、サーバの台数を増やして処理性能を維持できるようにしておくのが一般的だ。

負荷分散装置（ロードバランサ）の価値

このようなシステム構成をうまく機能させるには、これら複数台のWebサーバを束ねて、処理を効率的に割り振る仕組みが不可欠だ。この役割を担うのが、ロードバランサだ。ユーザーからのWebアクセスをまずはロードバランサ上に設定する仮想IP(バーチャルIPと呼ばれる)が一手に受け付け、NAPT（Network Address and Port Translation）の機構を通じて配下の適切なWebサーバに割り振る。このIPアドレスとポート番号を対象とした、最も基本的なロードバランス処理は、レイヤー4ロードバランシングなどと呼ばれている。

ただし、単にWebアクセスの負荷を分散させるだけであれば、DNSラウンドロビン（DNSサーバの設定を工夫し、一つのホスト名への名前解決に複数のIPアドレスで応答することでWebサーバへのアクセスを分散）という方法もある。つまり、わざわざ高価なロードバランサ装置を導入する必要はない。にもかかわらず、これだけロードバランサが普及している最大の理由は、サービスダウンを回避する仕組みがあるからだ。ロードバランサは、配下にあるWebサーバが正常に稼働しているか否かを常にチェックしており（ヘルスチェック）、異常があると判断したWebサーバに対しては処理を割り振らず、別の正常なサーバに割り振る。こうした仕組みによって、たとえある特定のWebサーバに障害が発生したとしても、ユーザーからのアクセスは、正常稼働するWebサーバで処理を継続できるので、サービスは無停止として運用可能だ。

ロードバランサの特徴／動作概要

ちなみに、ロードバランサが複数のWebサーバに処理を分散させる際のアルゴリズムにもさまざまなものがあり、それらをうまく使い分けることで、Webシステム全体のパフォーマンスや可用性を向上させることができる。あとの回で詳しく紹介するが、BIG-IPは数あるロードバランサ製品の中でも、数多くのアルゴリズムをサポートすることで知られている。

ここだけは押さえておきたい
ロードバランサのあの機能

ここまで説明してきた内容は、おそらくほとんどの方がすでに理解しているかと思う。しかし、ロードバランサのより具体的な機能レベルの話となると、意外と重要なポイントが抜け落ちていることが多い。そこで、ロードバランサ製品を選定する上でも、あるいはすでに導入済みの製品をよりうまく使いこなすためにも、ぜひ押さえておきたいポイントをいくつか挙げてみたいと思う。

アプリケーションレベルのチェック

先ほど、ロードバランサはWebサーバの死活監視を常に行っていると説明したが、製品によってはネットワーク接続が有効かどうかのチェックしか行わないものもあるので注意が必要だ。そのため、ネットワークは生きているものの、アプリケーションがダウンしているような障害は検知できない。

しかし、BIG-IPを含むいくつかの製品では、アプリケーションが正常稼働しているかどうかを、アプリケーションサービスのレベルで細かくチェックできる。この機能を活用すれば、予期せぬアプリケーション障害によるサービスダウンを厳密に防げる。

サーバメンテナンス時のトラフィック切り離し

ロードバランサの運用が始まると、最も頻度の高い作業は、サーバOS／アプリケーションのパッチ適用やバージョンアップなどに伴い、サーバをロードバランス対象から切り離す作業だ。その際に、ユーザーからのアクセス処理を継続しているサーバを、いきなり切り離してしまうとそのユーザーの処理が停止され、サービス障害となる。その障害を防ぐためには、アプリケーションに対するユーザーセッションが一つ残らず使われていないかをチェックする機能が必要となる。このような機能を備えているのはBIG-IPのみである。

BIG-IPの概要：TMOSと各種モジュール群

冗長化

サービスダウン回避のためには、ロードバランサ自体の冗長化も欠かせない。ロードバランサは、ユーザーからのWebアクセスを一手に引き受けるため、その機能停止はサービス全体のダウンに直結してしまう。こうした事態を防ぐため、通常は2台のロードバランサ機器で冗長化構成を組むのが一般的だ。

しかし、各製品の仕様を詳しく調べてみると、障害発生時の待機系へ処理の引継ぎ（フェールオーバー）に要する時間（一般的には数秒～数十秒)や、もともと本番系で処理していたコネクションやユーザーセッションをどれだけ引き継げるか（コネクションおよびセッションミラー処理）といった点に、意外と違いがあることがわかる。これらの違いは、そのままサービスダウンの時間を如何に短縮できるかに繋がるので、重点的にチェックする必要がある。ロードバランサ製品を選ぶ際には、これらの点にもぜひ留意したい。

パーシステンス

「パーシステンス」も、ロードバランサを扱う上ではぜひ理解しておきたい機能だ。これは、Webアプリケーションのトランザクションの整合性を維持するために、特定のユーザーからのWebアクセスを、ある特定のサーバに割り振り続ける機能のことを言う。

ちなみに、現在、最も多く使われているパーシステンスの仕組みが、Cookie情報を利用した「Cookie パーシステンス」という技術だ。これはもともと、BIG-IPの開発元であるF5ネットワークスが2002年に取得した特許技術だったが、現在ではほとんどのロードバランサベンダーがF5ネットワークスとクロスライセンス契約を締結することによって広く採用されている。

レイヤー7 トラフィック処理（URIスイッチなど）

さらに高度な負荷分散の方法として、「レイヤー7 トラフィック処理」というものがある。「URIスイッチ」とも呼ばれる処理が広く使われているが、URIの内容に応じて、リクエストを特定のサーバ群に割り振るというものだ。

Webサイトでは通常、コンテンツやサービスごとに開発・運用を担当する部門が異なる。そこで、個々のコンテンツ／サービスごとにあらかじめ異なるURIを指定しておき、その内容を基にユーザーからのリクエストを適切なサーバ群に自動的に割り振ることで、開発や運用体制の独立性を高め効率的なサイト運用をすることができるのだ。 このURIスイッチを実施するためには、先述のL4ロードバランシングとは異なり、クライアントからのTCPコネクションをサーバの代理として終端し、HTTP GETリクエストヘッダのメッセージを解析して処理する必要がある。レイヤー4とレイヤー7の処理によるロードバランサの処理動作の違いも、ぜひ 理解しておきたいポイントだ。

SSLオフロード

SSLによりインターネット通信経路の暗号化とWebサイト運営事業者の確実な認証を行う際にも、ロードバランサの機能が大いに役立つ。複数のWebサーバを運用する場合、それぞれで個別にSSL証明書を入手・管理・更新する必要があり、往々にして煩雑な作業が生じるが、これをロードバランサ上で集中管理できるのだ。

また、暗号化された形で届いたデータの復号化処理は、WebサーバのCPUに少なからぬ処理負荷を与える。また、2010年頃からSSL暗号化の鍵長を1024ビットから2048ビットへ切り換えて暗号強度を高めることが普及したため、SSL処理の負荷が以前と比較して5倍に跳ね上がった。これをすべてロードバランサ上で集中処理することで、Webサーバの処理負荷を大幅に軽減できる。ロードバランサ製品には、SSLの暗復号化処理専用チップを搭載したものも多い。

こうして、あらためてロードバランサの基本機能を整理してみると、わかっていたつもりでも意外と抜け落ちていたポイントがあったのではないだろうか。さて次回は、ここ最近におけるロードバランサの急速な技術進化やトレンドなどについて紹介してみたい。

[PR]提供：F5ネットワークス