ロードバランサの活用(2) ロードバランサからADCへ

03_S_02

前回の「ロードバランサの活用でシステム構成をうまく機能させる方法」に続いて、今回は「ロードバランサからADCへの転換点」を紹介します。

ロードバランサの基本機能である「負荷分散」備えたロードバランサ製品が登場したのは、今から17年ほど前、1996年頃のことです。
その後間もなく、1990年代後半に入ると、「ドットコムカンパニー」と呼ばれる
インターネットをビジネスの中心に据えたスタートアップ企業が米国を発端に全世界的に相次いで登場します。
この頃から、Eコマースサイトなどに、負荷分散装置を導入するケースが目立つようになり、日本でも多くの企業がWeb技術をベースとしたポータルサイトやEコマースサイトなどを立ち上げました。

ロードバランサからADCへ

2004年頃から、従来の設計と一線を画した製品が登場します。
あるベンダーで「アプリケーション・フルプロキシ」と呼ばれる、このまったく新たなアーキテクチャは、アプリケーショントラフィックの終端装置として、L4~7のプロトコル処理、およびアプリケーションデータすべてへの介入を可能にしました。
このアーキテクチャは、アプリケーショントラフィックをよりきめ細かく、かつ、積極的に制御可能にし、ロードバランサが負荷分散以外の機能を担う道を切り拓きます。
このブレイクスルーこそが、ロードバランサのADC(Application Delivery Controller)への転換点となりました。

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

ロードバランサからADCへ進化したことによって、ADCによるWebアプリケーションのセキュリティ対策が可能になります。

例えば、クライアントとWebアプリケーション間のセッション(cookieを利用することが一般的)の妥当性をチェックしてセッションハイジャックを防止したり、クライアントから送信されるパラメータデータの妥当性をチェックすることで不正なデータがWebアプリケーションに送信されることを防止します。

Webアプリケーションの完全なセキュアコーディングはかなり困難で、脆弱性が潜んでしまうと言われています。
その脆弱性をいわゆる「WAF(Webアプリケーション・ファイアウォール)」で対策しますが、WAFはアプリケーションフルプロキシ・アーキテクチャがあってこそ実現された技術です。

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

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