AWS のロードバランサーといえば ELB です。これはEC2 をバックエンドに置いたときの負荷分散として多くで採用されることが多いものです。
しかし従来の ELB は Google LoadBalancer と比べてもいろいろできなくてもんにょりします。これはGoogle LoadBalancer が優れているのもありますが、ここ数年細かな設定サポート追加はあったものの、目立った機能改善がなかったこともあります。
さて、2016年8月12日 AWS Application Load Balancer が発表されました。全リージョンですぐに利用可能です。
これはずいぶん前からGAを待っていたもので、ようやくGA としてプロダクションで使うことができます！早速見てみましょう。
目次
Application Load Balancer でできること
従来の ELBはレイヤー4 と レイヤー7 で動いていました。これは今後 Classic Load Balancer (CLB) と呼称されます。今回リリースされたのは レイヤー7 専用のロードバランサーで Application Load Balancer (ALB)と呼称されます。
ALBは従来に比べて多くのサポートが入りました。
- コンテンツベースルーティング
- WebSocket サポート
- HTTP/2 サポート
コンテンツベースルーティングサポートが入ったことで、自前API サーバーがある場合の制御がかなり楽になったと触りながら感じています。
例 : https://api.hoge.jp/api/v1/hoge と https://api.hoge.jp/api/v2/hoge など
あるいは、従来は Route53 で環境別にドメインを取得してバックエンドを振り分けていた場合、1つのELB からバックエンド振り分けが可能になります。ただしそれぞれがパスに対応した入口を持っている必要があります。
例 : https://hoge.jp/dev と https://hoge.jp/prod など
Classic Load Balancer の移行
Python製の移行ツールが公開されています。
以下の状況がサポートされていないようなので注意です。
- Classic load balancer has TCP or SSL listeners
- Classic load balancer is in EC2-Classic
- Classic load balancer has only one enabled subnet
- Classic load balancer has TCP or SSL health check configured
- Classic load balancer has an unsupported policy (please note that this utility does not currently support sticky sessions)
- Classic load balancer has more than 50 unique backend ports
- Classic load balancer has more than 10 listeners
価格
既存の Elastic Load Balancing の価格ページが Classic Load Balancer と Application Load Balancer に分かれています。
ELB 自体の価格は10% 既存より安くなっています。
The hourly rate for the use of an Application Load Balancer is 10% lower than the cost of a Classic Load Balancer.
東京の場合、現時点は以下のようです。
| ELB | 価格 |
|---|---|
| Classic Load Balancer | $0.027 per Elastic Load Balancer-hour (or partial hour) |
| Application Load Balancer | $0.0243 per Application Load Balancer-hour (or partial hour) |
一方でデータ処理に関しては従来と変わっています。
| ELB | 価格 |
|---|---|
| Classic Load Balancer | $0.008 per GB of data processed by an Elastic Load Balancer |
| Application Load Balancer | $0.008 per LCU-hour (or partial hour) |
LCU になってことで計算がずいぶん変わります。1LCU は以下です。
- Up to 25 new connections per second
- Up to 3,000 active connections per minute
- Up to 2.22 Mbps
試算例が載っています。
AWSSDK.NET の対応状況
すでに対応SDKが nuget でリリースされています。すぐに試すことができます。
早速、Amazon Certificate Manager で用意した証明書を使った HTTPS を HTTP に流す ELB を作成してみましょう。適当に必要な nuget パッケージを取得しておいてください。
ザックリこんな感じです。
作成直後は、provisioning というステータスですが数分で利用可能になります。
従来の CLB との違い
Listener と TargetGroups
まず作成時に気付くのが、Listener です。CLB では、IN-OUT(Instance) の Protocol / Port を Listener で設定していました。こんな感じですね。
ALB では IN を Load Balancer の Listener、OUT(Instance) を TargetGroup で設定することになります。例えば、上記コードで作成した段階では、HTTPS 443 で待ち受けなので以下のようになります。
そして Load Balancer がルーティングした先の TargetGroups を見てみると、作成したTestTargetGroups は、HTTP 80 で待ち受けます。もちろん stickness なども TargetGroups 単位で設定可能です。
TestTargetGroups は、ヘルスチェックを/ に対して HTTP : 80 で行います。(override port で別ポートも指定可能です)
TargetGroup は明らかにこれまでより良いやり方です。コンテンツベースでどこにルーティングするかを TargetGroup で指定することになります。そのため、インスタンスの紐づけも従来の Load Balancer 直接ではなく TargetGroup に変更となりました。
Rule 設定
コンテンツベースルーティングの設定は、Load Balancer の Listernersにある各リスナーに設定します。ここで、指定したパスのアクセスをどの TargetGroups にフォワードするか設定するだけです。非常に簡単です。
バックエンドインスタンスがない場合のエラー画面
これまでは真っ白画面でしたが、503 Service Temporarily Unavailable awselb/2.0 が帰ってきます。
Swagger UI
Stickness を有効にしても無効でも、ブラウザ上での Swagger UI でのAPIテストで content が空で返ってくるようなのでちょっと確認が必要のようです。
cUrl などでのAPIレスポンスは返ってきています。
ALB の削除防止
従来の CLB では削除防止がなく、事故で削除がありえました。が、ALB でようやく Deletion protection が設定可能鳴りました。
安心です。
Load Balancer の種別表記
従来のものが Classic、ALB が Application になりました。
まとめ
ようやく待ちに待った レイヤー7 ロードバランサーが誕生です。次は、できれば従来のL4ロードバランサーである Classic Load Balancer に Persistent TCP サポートを入れてほしいところです。Google Load Balancer なら.... げふ。
