AWSのロードバランサーといえばELBです。これはEC2をバックエンドに置いたときの負荷分散として多くで採用されることが多いものです。
しかし従来のELBはGoogle LoadBalancerと比べてもいろいろできなくてもんにょりします。これはGoogle LoadBalancerが優れているのもありますが、ここ数年細かな設定サポート追加はあったものの、目立った機能改善がなかったこともあります。
さて、2016年8月12日AWS Application Load Balancerが発表されました。全リージョンですぐに利用可能です。
https://aws.amazon.com/jp/blogs/aws/new-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からバックエンド振り分けが可能になります。ただしそれぞれがパスに対応した入口を持っている必要があります。
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に分かれています。
https://aws.amazon.com/elasticloadbalancing/classicloadbalancer/pricing/
https://aws.amazon.com/jp/elasticloadbalancing/applicationloadbalancer/pricing/?nc1=h_ls
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でリリースされています。すぐに試すことができます。
https://www.nuget.org/packages/AWSSDK.ElasticLoadBalancingV2/
早速、Amazon Certificate Managerで用意した証明書を使ったHTTPSをHTTPに流すELBを作成してみましょう。適当に必要なnugetパッケージを取得しておいてください。
https://www.nuget.org/packages/AWSSDK.EC2
https://www.nuget.org/packages/AWSSDK.ElasticLoadBalancingV2/
ザックリこんな感じです。
https://gist.github.com/guitarrapc/a853cc9444d17993d4b7c047bc5b8976
作成直後は、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は、ヘルスチェックを/に対して/で行います。(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なら.... げふ。
