ニューヨークで行われたAmazonの顧客向けイベントで今朝（米国時間8/11）、AWSのCTO Werner Vogelsが新しいロードバランサーを発表した。それはコンテンツを複数のサーバーに分散する場合、もっときめの細かい分散の仕方をデベロッパーや管理者が指示できる、という負荷分散ツールだ。
それはAWS Application Load Balancerと呼ばれ、これまでの（2009年からある）Elastic Load Balancingツールのように、何をどこに置くかということをロードバランサーが自分のアルゴリズムで勝手に決めるのではなく、人間管理者が決められる。
この新たに加わった制御方式は、これまでのアプリケーションを動かしているだけのユーザーにはあまり関係ないかもしれないが、複数のコンテナに収めた現代的なタイプのアプリケーションを使っているユーザーには、プロセスに対するより強力なコントロール能力を与えるだろう。コンテナ化したアプリケーションは複数のマイクロサービスで構成されることが多いので、個々のマイクロサービスごとにトラフィックを制御できた方がありがたいのだ。
Vogelsはこう言う: “これにより、ユーザーのシステムの個々の部位ごとに、トラフィックの送り方を完全に制御できる”。
たとえば、APIコンテンツ（のリクエスト）はすべてそれ専用のサーバーへ行かせ、モバイルコンテンツは別の専用サーバーが担当する。この新しいツールを発表しているブログ記事は、こう述べている: “こうやってリクエストをルーティングしてやれば、複数のマイクロサービスから成るアプリケーションをそれぞれ個別に、独立的に動かし、またスケールできる”。
ユーザー（デベロッパーや管理者）にはElastic Load Balancing Consoleというコンソールが提供されるので、その上で新しいロードバランサーを使うのか、従来ので十分か、を決めて指示できる。
技術的には、新旧の違いは大きい。前のツールは“Layer 4”のロードバランサーといって、ネットワークプロトコルのレベルで動作し、ネットワークのパケットの内部で起きていることを表す詳細な情報にはアクセスできない。そこでこのツールは今後、Classic Load Balancerと呼ばれることになる。
そして新顔のApplication Load Balancerツールは“Layer 7”のロードバランサーと呼ばれる。それはパケットの内部を覗くことができ、より詳しい情報へのアクセスにより、より高度な仕事ができる。たとえば、パケットの性質に基づいて行き先を仕分けする、といったことも可能だ。
また新しい情報に伴う測度も、CloudWatchメトリクスをはじめ、新しいより詳しい測度だ。たとえばトラフィックはGBで表され、現在のアクティブコネクションの数や、毎時のコネクションレート（1時間あたりの接続数）なども分かる。
この新しいロードバランシングツールは、WebSocketとHTTP/2をサポートしている。これらはどちらも、ネットワークトラフィックを扱うためのより現代的な方法を提供しているから、一部のユーザーにとっては、ありがたいだろう。
Application Load Balancerは今すでに可利用であり、機能が増えているにも関わらず料金は従来品より10%安い。課金の単位は、使用した時間プラス、Load Balancer Capacity Unitsと呼ばれるややこしい測度で、それは毎秒の新しい接続の数や、アクティブコネクションの数、ユーザーが送信するデータの量、などをベースとする単位だ。
