【新機能】新しいロードバランサー Application Load Balancer（ALB）が発表されました
ウィスキー、シガー、パイプをこよなく愛する大栗です。
現在開催中のAWS Summit New York 2016のKeynoteの中で、新しいロードバランサ（Application Load Balancer）の発表がありましたのでまとめてみます。
New – AWS Application Load Balancer
古いELBから新しいALBへ移行する方法は、elastic-load-balancing-toolsを使ってELBをALBに移行してみたを御覧ください。
Application Load Balancer
新機能
これまでのELBでは、HTTP/HTTPS/TCP/SSLの4つのプロトコルに対応しており、L4とL7（Sticky Session）に対応していました。アプリケーションロードバランサーの名前の通りALBでは特にL7の機能が強化されています。ELBと比較して、以下のメリットが有ります。
- パスベースルーティング：URLのパスに基いてルーティングが可能です。
- 複数ポートの登録：1つのインスタンスに複数ポートを登録することが可能です。
- コンテナアプリケーションのサポート：ECSはタスクスケジュールので未使用のポートを使用してターゲットグループに登録する事ができます。
- ターゲットグループでのヘルスチェック：CloudWatchで多くのメトリクスをサポートしています。
- アクセスログの情報追加：アクセスログに情報が追加され、圧縮形式で保存されます。
- パフォーマンス改善：パフォーマンスが向上しています。
- HTTP/2サポート：HTTP/2のリクエストを受けられるようになりました。
- WebSocketサポート：WebSocketのリクエストを受けられるようになりました。
- 削除保護：EC2と同様に削除保護ができるようになりました。
ALBではロードバランサーにインスタンスを登録するのではなく、インスタンスをターゲットグループというグループでまとめてロードバランサに登録します。そしてターゲットグループに対してルーティングを行います。そのため可用性を確保するためにはターゲットグループ毎に複数インスタンス/複数AZでインスタンスを登録する必要があるということに注意して下さい。
なお、ALBの発表に伴い元々あったELBは標準ロードバランサ（Classic load balancer）という位置づけになっています。
価格
価格体系がELBと若干異なっています。以下の２つの料金の合算となっています。
- 1時間あたりの料金（ELBに較べて１０％引き）
- LCU時間あたりの料金
ALBを起動している時間に対する料金はELBより10％安くなっています。そして「LCU」という概念が追加されました。
LCUは「Load Balancer Capacity Units」の略でALBの使用量の単位です。LCUは以下の3つの尺度で決まります。
- 新規接続数：1秒辺りの新規にコネクションを確立する数
- アクティブ接続数：1分辺りのアクティブなコネクション数
- 帯域幅：
1LCUには、以下の内容が含まれます。
- 毎秒25までの新規接続
- 毎分3,000までのアクティブなコネクション
- 2.22Mbpまでの帯域
ALBではHTTP/2やWebSocketをサポートしていますので、コネクションがアクティブなまま接続し続けることになるのでLCUという単位で計測するようになったのではないかと推測しています。
2.22Mbpsは1時間で約1GBの転送量になります。転送量から帯域に変わっているため、ELBに較べて若干使用量が増加する可能性があります。しかし1時間あたりの起動時間に対する料金も下がっているので、使用料は大きく変動しないのではないかと推測しています。
ALBを作成してみる
ALBの設定は以下の流れになります。
- ターゲットグループを作成する
- ターゲットグループにインスタンスを登録する
- ALBを作成する
- ルールを作成してターゲットグループへのルーティングを設定する
構成は、以下の様に作成します。通常はtarget1へルーティングして、パスが/target/*の場合はtarget2へルーティングします。
ターゲットグループを作成する
ターゲットグループのtarget1とtarget2を作成します。
まずtarget1を作成します。
ターゲットグループ
| 設定項目 | 内容 |
|---|---|
| ターゲットグループ名 | target1 |
| プロトコル | HTTP |
| ポート | 80 |
| VPC | デフォルト VPC |
ヘルスチェックの設定
| 設定項目 | 内容 |
|---|---|
| プロトコル | HTTP |
| パス | /index.html |
target2の場合も同様に作成します。
ターゲットグループにインスタンスを登録する
作成したターゲットグループにEC2インスタンスを登録します。
ターゲットグループを選択してコンテキストメニューでインスタンスの登録と登録解除をクリックするか、ターゲットタブの編集をクリックします。
インスタンスtarget1-aとtarget1-cを登録します。
ALBにインスタンスが登録されます。ロードバランサに登録していないため状態はunusedとなります。
同様にtarget2にもインスタンスtarget2-aとtarget2-cを登録します。
ALBを作成する
ALBを作成します。アプリケーションロードバランサーを選択します。
ロードバランサの基本的な設定を行います。
プロトコルはHTTPとHTTPSのみとなっています。今回はHTTPSを選択します。
HTTPSを選択したのでSSL証明書を選択します。
ACMで証明書を作成していたので、それを選択します。セキュリティポリシーは「ELBSecurityPolicy-2015-05」しか選択できないようです。
セキュリティグループを選択します。
クライアントからHTTPSを許可し、EC2インスタンスへHTTPアクセスできるセキュリティグループを選択します。
ルーティングを設定します。
ターゲットグループはtarget1を選択します。ヘルスチェックはindex.htmlとしておきます。
ターゲットのEC2インスタンスを登録します。 ここではターゲットグループに登録されているインスタンスを確認します。
作成内容を確認して、作成をクリックします
この様にALBが作成されます。
ルールを作成してターゲットグループへのルーティングを設定する
target2へのルールを作成します。
作成したALBを選択して、リスナータブを選択します。
ALBを作成する時に登録したターゲットグループtarget1がデフォルトのルールとして登録されています。ここのルールを追加するをクリックします。
パスパターンに/target/*を入力して、ターゲットグループにtarget2を選択して保存します。
/target/以下のURLはtarget2へルーティングされて、それ以外はtarget1へルーティングされます。
対象ALBの説明タブで属性の編集をクリックします。
削除保護の有効化とアクセスログの有効化を行います。
動作を確認する
ルーティングの動作を確認します。
各インスタンスには/index.htmlと/target/index.htmlを用意しています。
まずはhttps://example.com/index.htmlを見ます。
target1を向いています。今回はtarget1-cへアクセスしています。
次にhttps://example.com/target/index.htmlを見ます。
target2を向いています。今回はtarget2-aへアクセスしています。
この様にURLのパスベースでルーティングをすることができます。
アクセスログを確認します。
ログファイルはgz圧縮されて保存されています。
アクセスログの中身を見ます。
先頭がh2となっています。これは先程はChromeを使用したのでHTTP/2でアクセスした事を表しています。WebサーバはデフォルトのApache2.2系を使用していたのですが、勝手にALBがHTTP/2で受けてくれるようです。アクセスログには対象のロードバランサやターゲットグループなどの情報も記載されています。
なお、WebSocketはws、WebSockets over SSL/TLSはwssとなります。
h2 2016-08-11T18:11:15.423647Z app/AppELB01/1234abcd5678efgh 203.0.113.123:60538 172.31.16.202:80 0.001 0.001 0.000 200 200 268 185 "GET https://acm-tokyo.example.com:443/index.html HTTP/2.0" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/target1/12345678abcdefgh h2 2016-08-11T18:11:15.669450Z app/AppELB01/1234abcd5678efgh 203.0.113.123:60538 172.31.13.255:80 0.003 0.003 0.000 404 404 66 412 "GET https://acm-tokyo.example.com:443/favicon.ico HTTP/2.0" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/target1/12345678abcdefgh h2 2016-08-11T18:11:45.483859Z app/AppELB01/1234abcd5678efgh 203.0.113.123:60543 172.31.16.202:80 0.001 0.001 0.000 200 200 243 185 "GET https://acm-tokyo.example.com:443/index.html HTTP/2.0" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/target1/12345678abcdefgh h2 2016-08-11T18:11:45.667471Z app/AppELB01/1234abcd5678efgh 203.0.113.123:60543 172.31.13.255:80 0.002 0.003 0.000 404 404 65 412 "GET https://acm-tokyo.example.com:443/favicon.ico HTTP/2.0" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/target1/12345678abcdefgh h2 2016-08-11T18:11:57.910847Z app/AppELB01/1234abcd5678efgh 203.0.113.123:60543 172.31.9.54:80 0.003 0.003 0.000 200 200 28 205 "GET https://acm-tokyo.example.com:443/target/index.html HTTP/2.0" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/target2/abcdefgh12345678 https 2016-08-11T18:45:24.888764Z app/AppELB01/1234abcd5678efgh 203.0.113.123:61578 172.31.16.202:80 0.003 0.003 0.000 200 200 106 281 "GET https://acm-tokyo.example.com:443/index.html HTTP/1.1" "curl/7.43.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/target1/12345678abcdefgh https 2016-08-11T18:45:35.445859Z app/AppELB01/1234abcd5678efgh 203.0.113.123:61580 172.31.9.54:80 0.001 0.001 0.000 200 200 113 301 "GET https://acm-tokyo.example.com:443/target/index.html HTTP/1.1" "curl/7.43.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/target2/abcdefgh12345678
アクセスログの詳細は以下のドキュメントを参照して下さい。
Access Logs for Your Application Load Balancer
CloudWatchのメトリクスも確認してみます。
ELBとは異なり、ApplicationELBという名称になっています。
ロードバランサーのメトリクスは、以下のようになっています。
ターゲットグループは独立したメトリクスを持っており、以下のようになっています。
HealthyHostCountとUnHealthyHostCountがロードバランサーのメトリクスでなくなっているので注意が必要です。監視を行うときには
メトリクスの詳細は以下のドキュメントを参照して下さい。
CloudWatch Metrics for Your Application Load Balancer
削除保護についても確認してみましょう。先ほど削除保護の設定を行ったので削除を実行してみます。
保護されているためエラーになりました。
さいごに
以前のELBに対する良くある不満であったパスベースのルーティングが可能になり、HTTP/2やWebSocketのネイティブ対応がされるようになりました。
パスベースのルーティングを活用することで細かいルール設定ができるので、静的コンテンツと動的コンテンツのポートを分けて動的コンテンツはAPサーバが直接受けることも可能になります。
ELBからALBに変更するだけでHTTP/2でのアクセスを受けられます。モダンなWebブラウザはほとんどがHTTP/2に対応しているので、クライアントのパフォーマンス向上を期待できます。
既存のELBでは対応できていなかった部分がサポートされるようになっているので、ALBの活用が進みそうです。
