コラム

サーバーロードバランス(SLB)の歴史

第2回:SLB界隈における2010年から2020年の間に見られた変化について

更新
サーバーロードバランス(SLB)の歴史

2010年から2020年の間におけるSLB機器の担う役割の変化や拡大について紹介します。

LBから ADCへ進化、動作する環境の変化

第1回目で焦点を当てた1990年から2000年代において、サーバ負荷分散を行う機器はLB(Load balancer)という略称で呼ばれていました。そのような役割のネットワーク製品がADC(Application Delivery Controller)と呼ばれるようになり、その機能が比較的安定して動作するようになったのが 2010年から2020年の間だったと記憶しています。

それまでローカル、グローバルでのサーバ分散をメインの役割としていたところから、サーバを防御するための WAF(Web Application Firewall)やDDoS対策の機能、HTTPSによる通信の暗号化/復号化やそれを応用したトンネリング(SSL-VPN)、モバイル端末やIoTデバイスの普及に対応するIPv4/IPv6変換機能などが広く使われるようになりました。

図:様々な機能が実装されたADCのイメージ

図:様々な機能が実装されたADCのイメージ

また機器が動作する環境がオンプレ環境だけだったものから、クラウド環境やオンプレ環境+クラウド環境のハイブリット環境に変化したのもこの時期でした。利用される環境が広がったことで利用目的も変わり、さらなる機能強化がされることとなります。

Webベースサービスの一般的な利用の定着

2010年代から2020年代における利用者目線での変化としては、高度な機能を持つモバイル端末(所謂スマートフォンなど)が一般で使用されるようになり、Webベースでサービスにアクセスする機会が増加したことがあります。

Webブラウザ自体の機能やサーバで動作するソフトウェアが進化したことにより、アクセス元に特別なソフトウェアを入れることなく、様々なサービス(文書作成や動画視聴、コミュニケーションなど)を受けることが可能となりました。

そのようなサービスが一般化することによって生じた課題が、いかにしてWebベースのサービスを安全に使用できるようにするか、どうやって攻撃から守るかということになります。これらの課題に対しLBに実装されたのがWAFやDDoS対策といった機能です。

WAFやDDoS対策機能による防御

様々なものがWebブラウザベースで閲覧/操作できる一方で、そこが弱点となる場合があります。ローカルにあるものであれば特定の場所や機器からのみアクセスを許可することである程度のセキュリティを担保できますが、世界中のだれからでもアクセスできるようにしているWebアプリケーションではアクセスの内容に応じた防御が必要となります。

Webアプリケーションへのアクセス内容やレスポンス内容を見て攻撃や情報漏洩を防ぐものとしてWAF(Web Application Firewall)があります。もともとLBにはHTTPでやり取りされるパケットのデータ部分を見てその内容に応じて分散するサーバを変えるL7ロードバランシングという機能が実装されており、WAFとの相性が良いネットワーク機器と言えます。

またWAFに加えて過剰なトラフィックからサーバを防御するDDoS対策機能もLBに付加することで、サーバの防御をADCで一元的に行うことができるようになります。

図:WAF機能、DDoS対策機能が実装されたADCによる防御のイメージ

図:WAF機能、DDoS対策機能が実装されたADCによる防御のイメージ

HTTPS の爆発的な普及、ADCによる復号化の必要性

Webアプリケーションが広く一般的に使われるものとなった一方で、ネットワーク上でやり取りされるWeb関連の通信の暗号化(HTTPS)化が一気に進みました。以前はユーザー情報やクレジットカード番号の入力などセキュリティを高めたい部分のみHTTPSでやり取りするというWebサイト、サービスが多くありましたが、現在では一般的に利用されるほとんどのサイトが全ての通信をHTTPSで暗号化するようになっています。

HTTPS通信が普及することによる生じる課題として、通信の中身を見て精査することが難しくなることと、HTTPS通信を復号化するためCPUリソースを必要とすること、複数サーバで証明書を管理するとその更新作業などが煩雑になることなどがありますが、ADC製品を使うことでこれらは解決できます。

第1回目の中でも触れていますが、LB/ADC製品には古くからH/WベースのSSLアクセラレーション機能が実装されており、サーバの前段にADC製品を置くことで、クライアントとの通信はHTTPSで通信を暗号化しつつ、HTTPSの復号化を行ってやり取りされている中身(データ)を精査し攻撃から防御するといったことが可能です。

ADCで復号化し内容が精査された通信の多くはそのまま平文でサーバに送られます。このようにADCで暗号化を解き、ADCとサーバ間は平文でやり取りすることにより、サーバの負荷を上げることなくクライアントとの通信のHTTPS化を行い、なおかつ証明書の管理もADCで一元的に行うことができるようになります。

忘れてはいけない脆弱性対策

最後になりますが、ADC自身についての脆弱性対策について記しておこうと思います。

LBと呼ばれていたころはOSやその中で動作するアプリケーション、CPUなどを自社開発していましたが、現在ではADC機能のコアの部分は自社開発するものの、それを動かす環境は汎用的なCPU、汎用的なOS/ソフトウェアを採用しているという状況が見受けられます。

このような開発の変化により、ADC自体の脆弱性対策に気を配る必要が生じました。ApacheやOpenSSL、BINDなどADCのサービスで直接使用されていないOSSのアプリケーションの脆弱性やCPUの持つ脆弱性をアタッカーに利用されることで、ADCとしてサービスが提供できなくなることや不正侵入を許してしまう場合があります。

図:CVE(脆弱性)登録件数の推移

図:CVE(脆弱性)登録件数の推移

ベンダーなどが提供する脆弱性情報に気を配り、脆弱性が見つかった場合には早急に対処を行うことが運用において重要となったのも2010年から2020年代に見られた変化と言えます。

次回のコラムではこれより2020年以降のトレンドなどを紹介したいと思います。

著者

CTCテクノロジー株式会社 テクニカルサポート本部 テクニカルサポート第3部 森岡 延史

CTCテクノロジー株式会社
テクニカルサポート本部
テクニカルサポート第3部
森岡 延史

2003年CTCテクノロジー株式会社に入社。
ネットワークエンジニア一筋でL1~L7までのテクニカルサポートを20年以上実施している。
F5,A10の最上位資格保有。

  • このページについてツイッターでツイート(新しいウィンドウで開く)
  • このページをフェイスブックでシェア(新しいウィンドウで開く)

このコラムに関するお問い合わせはこちら

※記載内容は掲載当時のものであり、変更されている場合がございます。