AWSの新しいロードバランシング（負荷分散）サービス「Application Load Balancer（ALB）」の代表的な機能は、パケットの内容に応じたコンテントベースのルーティングだ。詳しくは後述するが、これはレイヤー7（L7）スイッチが備える機能。ALBは、L7スイッチ相当のロードバランシングサービスといえる。

　従来、AWSのロードバランシングサービスには「Elastic Load Balancing（ELB）」が存在したが、機能は限定的だった。コンテントベースのルーティングを行うには、サードパーティーのソフトを仮想マシンのEC2に導入して利用する必要があった。

　ALBの登場により、標準サービスとしてコンテントベースのルーティングが可能になったほか、それ以外の機能強化も行われた。料金体系が異なることから、システムの要件によって、従来のロードバランシングサービスと新しいALBの使い分けが必要になる。

　そこでこの記事では、従来のロードバランシングサービスと比較してALBの機能を紹介する。さらに新しいALBについて性能検証を行う。

　本題に入る前に、サービス名称についての説明が必要だ。ALBの一般提供に伴い、従来のロードバランシングサービスELBは「Classic Load Balancer（CLB）」という名称に変更された。ELBは、新しいALBと従来のCLBを合わせたロードバランシングサービスの総称として用いられる。

コンテントベースのルーティング

　新しいALBの代表的な機能であるコンテントベースのルーティングとは何か。まずは、クライアント（Webブラウザー）－ALB－Webサーバーという単純なシステム構成で説明しよう。

　クライアントは「http://xxxx.yyyy.co.jp/○○○/」といったURLを使って、ALBを経由してWebサーバーにアクセスする。その際、コンテントベースのルーティングでは、ALBがURL末尾の「○○○」という部分に基づいて、異なるWebサーバーにリクエストを振り分ける。

　例えば「http://xxxx.yyyy.co.jp/AAA/」というリクエストはAサーバーに、「http://xxxx.yyyy.co.jp/BBB/」というリクエストはBサーバーに振り分ける。

　そのメリットを説明するために、複数のサブシステムから成る人事システムを取り上げる（図1）。給与計算サブシステムが2台の仮想マシン上で稼働しており、「http://xxxx.yyyy.co.jp/kyuyo/」というURLあてのリクエストをALBによって負荷分散している。そこに、勤怠管理サブシステムを稼働させる2台の仮想マシンを追加する。

図1　コンテントベースルーティングの仕組み
図1　コンテントベースルーティングの仕組み
[画像のクリックで拡大表示]

　勤怠管理サブシステムのリリース作業では、2台の仮想マシンを新規作成する。そのうえで、「http://xxxx.yyyy.co.jp/kintai/」というパスのリクエストが届いたら、勤怠管理サブシステムの2台の仮想マシンに順に割り振るよう、ALBのルーティング設定を変更する。

　その際、既存の給与計算サブシステムについては、特に変更は必要ない。クライアントでアクセスする際のパスを指定するだけで、給与計算サブシステムにも勤怠管理サブシステムにもアクセスできる。

　このようなコンテントベースのルーティングをするメリットは、新規サブシステムをリリースする際に、既存サブシステムの変更が必要ないことだ。停止時間を短くできる。

　しかもALBは従来のCLBと同じく、振り分け処理の負荷に応じて自動的に性能が向上する。そのため、サブシステム単位や機能単位での順次リリースがしやすい。

　スモールスタートで新システムを使い始めたい場合、新サブシステムのリリース時に既存サブシステムの停止時間を短くしたい場合、システム全体をどれだけ拡張するかが決まっていない場合などに向く。