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

ロードバランサは別名「負荷分散装置」とも呼ばれるが、その名の通り、基本的な機能はサーバ(Web、メール、DNSサーバなど)に掛かるトラフィックの負荷を分散させ、サイト全体の可用性や安定性を保つことにある。前回はそうしたロードバランサの基本的な役割について簡単に解説したが、実は今日のロードバランサ製品は、負荷分散という基本機能にとどまらず、実にさまざまな機能を備えた製品が販売されている。そのような多機能な製品は、Application Delivery Controller(以下、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のプロトコル処理、およびアプリケーションデータすべてに介入できるようになったことで、ネットワーク機器からアプリケーショントラフィックをよりきめ細かく、かつ積極的に制御することが可能になったのだ。

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

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

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

また、この時期は同時に、多くの企業がそれまで自社内で運用していた業務システムを次々とデータセンターに移行させ、システムの集約を進めていた時期とも重なる。システム集約は、その運用管理コストを効率化する上では大きな効果があったが、その半面、クライアントとサーバとの間の物理的な距離が伸びたことで遅延が増加し、アプリケーションのスループット低下という副作用も生むことになった。

さらにビジネスのグローバル化が進む中で、海外拠点から日本国内の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アプリケーション・ファイアウォール)」であり、アプリケーションフルプロキシ・アーキテクチャがあってこそ実現された技術だ。

特に2005年頃から、SQLインジェクション攻撃といったアプリケーションの脆弱性を突いたセキュリティ攻撃が増すにつれ、セキュリティ機器としてのADCの役割も年々高まっている。

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

次回は、BIG-IPが備えるセキュリティ関連の機能について、もう少し深堀りして解説してみよう。