ロードバランサ基本講座

ロードバランサの歴史を紐解けばわかる、Web を支える BIG-IP の進化2

ロードバランサの基本的な役割についてあらためておさらい1

CONTENTS

ロードバランサ基本講座

「ロードバランサ」とはその名の通り、主に Web システムにかかる負荷（load：ロード）を複数のサーバに分散させ、処理のバランスを調整するための装置だ。日本語では一般的に「負荷分散装置」などと呼ばれる。　Web システム、特にインターネットにサービスを公開しているシステムは、いつどれだけの数のユーザーからアクセスを受けるかわからない。公開当初はさほどアクセスがないサイトでも、何かのきっかけで急に人気が出てアクセスが集中することも多い。そうした場合に備え、ユーザーからのアクセスをさばく Web サーバを複数台用意しておき、システムの処理能力が不足してきた場合には、サーバの台数を増やして処理性能を維持できるようにしておくのが一般的だ。 図 1

　このようなシステム構成をうまく機能させるには、これら複数台の Web サーバを束ねて、処理を効率的に割り振る仕組みが不可欠だ。この役割を担うのが、ロードバランサだ。ユーザーからの Web アクセスをまずはロードバランサ上に設定する仮想IP（バーチャル IP と呼ばれる）が一手に受け 付 け、NAPT（Network Address and Port Translation）の機構を通じて配下の適切な Web サーバに割り振る。この IP アドレスとポート番号を対象とした、最も基本的なロードバランス処理は、レイヤー 4ロードバランシングなどと呼ばれている。　ただし、単に Web アクセスの負荷を分散させるだけであれば、DNS ラウンドロビン（DNS サーバの設定を工夫し、一つのホスト名への名前解決に複数の IP アドレスで応答することで Web サーバへのアクセスを分散）という方法もある。つまり、わざわざ高価なロードバランサ装置を導入する必要はない。にもかかわらず、これだけロードバランサが普及している最大の理由は、サービスダウンを回避する仕組みがあるからだ。ロードバランサは、配下にある Webサーバが正常に稼働しているか否かを常にチェックしており（ヘルスチェック）、異常があると判断した Web サーバに対しては処理を割り振らず、別の正常なサーバに割り振る。こうした仕組みによって、たとえある特定の Web サーバに障害が発生したとしても、ユーザーからのアクセスは、正

常稼働する Web サーバで処理を継続できるので、サービスは無停止として運用可能だ。 図 2

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

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

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

と思う。

■アプリケーションレベルのチェック　先ほど、ロードバランサは Web サーバの死活監視を常に行っていると説明したが、製品によってはネットワーク接続が有効かどうかのチェックしか行わないものもあるので注意が必要だ。そのため、ネットワークは生きているものの、アプリケーションがダウンしているような障害は検知できない。　しかし、BIG-IP を含むいくつかの製品では、アプリケーションが正常稼働しているかどうかを、アプリケーションサービスのレベルで細かくチェックできる。この機能を活用すれば、予期せぬアプリケーション障害によるサービスダウンを厳密に防げる。

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

　ロードバランサの運用が始まると、最も頻度の高い作業は、サーバ OS ／アプリケーションのパッチ適用やバージョンアップなどに伴い、サーバをロードバランス対象から切り離す作業だ。その際に、ユーザーか

ロードバランサの基本的な役割についてあらためておさらい1

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

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

図1

図2

2

ロードバランサ基本講座

らのアクセス処理を継続しているサーバを、いきなり切り離してしまうとそのユーザーの処理が停止され、サービス障害となる。その障害を防ぐためには、アプリケーションに対するユーザーセッションが一つ残らず使われていないかをチェックする機能が必要となる。このような機能を備えているのは BIG-IP のみである。

■冗長化　サービスダウン回避のためには、ロードバランサ自体の冗長化も欠かせない。ロードバランサは、ユーザーからの 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 の暗復号化処理専用チップを搭載したものも多い。

　こうして、あらためてロードバランサの基本機能を整理してみると、わかっていたつもりでも意外と抜け落ちていたポイントがあったのではないだろうか。 図 3

　ロードバランサは別名「負荷分散装置」とも呼ばれるが、その名の通り、基本的な機能はサーバ（Web、メール、DNS サーバなど）に掛かるトラフィックの負荷を分

散させ、サイト全体の可用性や安定性を保つことにある。前述ではそうしたロードバランサの基本的な役割について簡単に解説したが、実は今日のロードバランサ製品は、

負荷分散という基本機能にとどまらず、実にさまざまな機能を備えた製品が販売されて い る。 そ の よ う な 多 機 能 な 製 品 は、Application Delivery Controller（ 以 下、

ロードバランサの歴史を紐解けばわかる、Web を支える BIG-IP の進化2

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

3

ロードバランサ基本講座

ADC）と呼ばれている。そこで今回は、ロードバランサの歴史やここ 10 年ほどの間に起こったロードバランサの進化の歴史をざっと振り返りながら、ADC と呼ばれるに至った背景や役割について、改めて確認してみたい。

ロードバランサから ADC へと 進化を遂げた転換点

　負荷分散という基本機能を備えたロードバランサ製品が初めて世に登場したのは、今から 17 年ほど前（1996 年頃）のことだ。その後、間もなくして 1990 年代後半には、米国でいわゆるドットコムカンパニーと呼ばれるインターネットをビジネスの中心に据えたスタートアップ企業が相次いで登場し、E コマースサイトなどに負荷分散装置を導入するケースが目立つようになった。ドットコムブームは時を同じくして日本にも飛び火し、米国と同じくインターネットビジネスブームが起きた結果、多くの企業が Web 技術をベースとしたポータルサイトや E コマースサイトなどを立ち上げた。　こうして「ビジネスインフラとしてのWeb」が初めてクローズアップされるに伴い、サイトの可用性やスケーラビリティを確保するための技術として、ロードバランサが一気にクローズアップされることとなった。「BIG-IP」を筆頭とするロードバランサ製品が世の注目を集めるようになったのは、まさにこの時期だ。　以降、ロードバランサはミッションクリティカルな Web システムにおいて、なくてはならない技術となったが、2004 年に、テクノロジーのブレークスルーが起こる。それまでのロードバランサは、BIG-IP を含めて、流れていくパケットの IP アドレス /ポート番号 /HTTP などのデータを抽出・解析し、トラフィック振り分けなどの処理を行うものだった。ロードバランサを介して通信はするものの、クライアントからすると基本的にはオリジナルのサーバと通信している状況として動作しており、Packet by Packet の処理を前提とした設計だった。逆に言えば、ロードバランサ自身がプロトコルの終端装置として、TCP/IP や HTTPの処理を実行するものではなかった。　しかし、2004 年に F5 ネットワークスがリリースした「BIG-IP Ver.9 TMOS」は以前の Packet by Packet の処理を前提とした設計を覆し、クライアントとサーバの間でプロトコルの終端装置として動作し、ク

ライアントから BIG-IP、および BIG-IP からサーバの通信を完全に独立させ、すべてのプロトコルをフルスタックで理解できる「フルプロキシ」として設計され、世に登場したのだ。つまり、クライアントとサーバの間のパケットを単に中継するのではなく、サーバの「代理」としてクライアントと通信し、一方でサーバとの間にまったく別のTCP コネクションを確立し、この双方のTCP コネクションを BIG-IP がつなぎ合わせる（クライアントからすると BIG-IP がサーバ、サーバからすると BIG-IP がクライアントとして通信している）という、まったく新たなアーキテクチャを確立したのだ。　F5 ネットワークスが「アプリケーション・フルプロキシ」と呼ぶ、この新たなアーキテクチャは、ロードバランサ製品の可能性を大きく押し広げることになった。従来のように単にパケットを中継するだけでなく、アプリケーショントラフィックの終端装置として L4 〜 7 のプロトコル処理、およびアプリケーションデータすべてに介入できるようになったことで、ネットワーク機器からアプリケーショントラフィックをよりきめ細かく、かつ積極的に制御することが可能になったのだ。 図 4

　このブレークスルーにより、BIG-IP は従来のロードバランサ製品とは比べ物にならないほど大きな進化を遂げた。リクエストとレスポンスの双方向トラフィックのプロトコルヘッダやアプリケーションペイロードを対象とした、よりきめ細かな処理が可能となり、負荷分散処理の自由度は劇的に向上した。しかしそれ以上に大きかったのが、ロードバランサが負荷分散以外の機能を担う道を切り拓いたことだった。

Web アプリケーション高速化の 機能を新たに搭載

　そうした機能の 1 つが「Web アプリケーションの高速化」だ。BIG-IP がアプリケーション・フルプロキシを導入した 2004 年からの数年間は、インターネットビジネスが日本で根付いてきた時期と重なる。Webサイトを通じて大きな売り上げを稼ぐ企業が増加した結果、サイトのレスポンスタイムがそのまま売上額の多寡に直結するようになってきた。つまり、Webアプリケーションのパフォーマンスが、より一層、重要視されるようになってきたのだ。 図 5

　また、この時期は同時に、多くの企業が

プラグイン化されている F5 BIG-IP 製品群

F5 ならではの「アプリケーションフルプロキシ・アーキテクチャ」図4

図5

4

ロードバランサ基本講座

それまで自社内で運用していた業務システムを次々とデータセンターに移行させ、システムの集約を進めていた時期とも重なる。システム集約は、その運用管理コストを効率化する上では大きな効果があったが、その半面、クライアントとサーバとの間の物理的な距離が伸びたことで遅延が増加し、アプリケーションのスループット低下という副作用も生むことになった。　さらにビジネスのグローバル化が進む中で、海外拠点から日本国内の Web アプリケーションに遠隔からアクセスしたいというニーズも一般化している。この場合、アプリケーションのスループット低下はさらに深刻な問題となる。　こうした課題を解決するために考え出されたのが、アプリケーション・フルプロキシを活用して Web アプリケーションのパフォーマンスを高速化する技術だった。BIG-IP は前述のアーキテクチャ変更により、アプリケーションレベルできめ細かく制御する術をすでに手に入れていた。そこでこの強みを生かして、例えば Web のコンテンツを BIG-IP で圧縮（HTTP 圧縮と呼ばれる）、さらにそのデータをキャッシュ（HTTPキャッシュと呼ばれる）したり、あるいはBIG-IP が TCP の終端ポイントになることで、回線のパケットロスや遅延により引き起こされる TCP データ転送のパフォーマンス劣化を解消する技術（TCP プロトコル最適化と呼ばれる）、近年ではビデオコンテンツの解像度を回線環境にあわせて変更といったさまざまな方法を駆使して、Webアプリケーションの高速化を実現したのだ。

セキュリティ機器としての ニーズの高まり

　こうした機能は、もはやロードバランサ本来の役目である負荷分散を大きく越えたものだ。事実、この頃から IT のリサーチ・

アドバイザリ・サービスを提供している第三者機関のガートナー社は、BIG-IP の事をロードバランサとは呼ばず「Application Delivery Controller（ADC）」という新たなカテゴリの製品として呼ぶようになる。その名の通り、ネットワークを経由してアプリケーションを配信する際の制御をするためのデバイスとして、新たに位置付けられたのだ。　この過程で、アプリケーション高速化と並んで新たに加わったのが、セキュリティ関連の機能だ。この背景には、やはり先ほど挙げた 2004 年のアーキテクチャ変更がある。アプリケーション・フルプロキシの採用で、プロトコル処理の自由度が大幅に増し、Web アプリケーションの中身をより細かく精査できるようになった結果、これまでにはない新たなセキュリティ対策の実装が可能になったのだ。　もう少し具体的に言えば、ADC への進化によって、「Web アプリケーションの脆弱性」に対するセキュリティ対策が可能になった。例えば、クライアントと Web アプリケーション間のセッション（cookie を利用することが一般的）の妥当性をチェックすることで、セッションハイジャックを防止したり、クライアントから送信されるパラ

メータデータの妥当性をチェックすることで不正なデータが Web アプリケーションに送信されることを防止する。Web アプリケーションが完全にセキュアコーディングされていれば良いのだが、実情はかなり困難であり脆弱性が潜んでしまう。その脆弱性を BIG-IP の機能で対策できる。この機能は、いわゆる「WAF（Web アプリケーション・ファイアウォール）」であり、アプリケーションフルプロキシ・アーキテクチャがあってこそ実現された技術だ。 図 6

　特に 2005 年頃から、SQL インジェクション攻撃といったアプリケーションの脆弱性を突いたセキュリティ攻撃が増すにつれ、セキュリティ機器としての ADC の役割も年々高まっている。　最近では ADC を負荷分散装置としてではなく、セキュリティ機器としてとらえる風潮も強まっている。ADC はアプリケーションの手前に配置されるケースが多く、アプリケーションサーバへのトラフィックの出入り口としてセキュリティ機能を実装するというコンセプトは、システム構成上、とても理にかなったアプローチと言える。技術革新を常にリードしてきた BIG-IP も、ここ数年の間でセキュリティ関連の機能を急速に強化しつつある。

F5 ネットワークスジャパン株式会社 URL http://www.f5networks.co.jp/inquiry/

お問い合わせ先

Web アプリケーション・ファイアウォール（BIG-IP ASM：Application Security Manager）

図6

※本書中の登録商標および商標は所有者に帰属します。本書は下部息会社マイナビが運営する「マイナビニュース」に掲載された記事を再編集したものです。©マイナビ 2014

5