殿堂入り記事

【新機能】新しいロードバランサー Application Load Balancer(ALB)が発表されました

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ウィスキー、シガー、パイプをこよなく愛する大栗です。

現在開催中の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

なお、ALBの発表に伴い元々あったELBは標準ロードバランサ(Classic load balancer)という位置づけになっています。

価格

価格体系がELBと若干異なっています。以下の2つの料金の合算となっています。

  • 1時間あたりの料金(ELBに較べて10%引き)
  • 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の設定は以下の流れになります。

  1. ターゲットグループを作成する
  2. ターゲットグループにインスタンスを登録する
  3. ALBを作成する
  4. ルールを作成してターゲットグループへのルーティングを設定する

構成は、以下の様に作成します。通常はtarget1へルーティングして、パスが/target/*の場合はtarget2へルーティングします。

alb_https

ターゲットグループを作成する

ターゲットグループのtarget1target2を作成します。
まずtarget1を作成します。

ターゲットグループ

設定項目 内容
ターゲットグループ名 target1
プロトコル HTTP
ポート 80
VPC デフォルト VPC

ヘルスチェックの設定

設定項目 内容
プロトコル HTTP
パス /index.html

EC2_Management_Console

target2の場合も同様に作成します。

ターゲットグループにインスタンスを登録する

作成したターゲットグループにEC2インスタンスを登録します。

ターゲットグループを選択してコンテキストメニューでインスタンスの登録と登録解除をクリックするか、ターゲットタブの編集をクリックします。

EC2_Management_Console

インスタンスtarget1-atarget1-cを登録します。

EC2_Management_Console

ALBにインスタンスが登録されます。ロードバランサに登録していないため状態はunusedとなります。

EC2_Management_Console

同様にtarget2にもインスタンスtarget2-atarget2-cを登録します。

ALBを作成する

ALBを作成します。アプリケーションロードバランサーを選択します。

EC2_Management_Console

ロードバランサの基本的な設定を行います。
プロトコルはHTTPHTTPSのみとなっています。今回はHTTPSを選択します。

EC2_Management_Console_と__1_KDDI_ChatWork_-_AWSチーム

HTTPSを選択したのでSSL証明書を選択します。
ACMで証明書を作成していたので、それを選択します。セキュリティポリシーは「ELBSecurityPolicy-2015-05」しか選択できないようです。

EC2_Management_Console

セキュリティグループを選択します。
クライアントからHTTPSを許可し、EC2インスタンスへHTTPアクセスできるセキュリティグループを選択します。

EC2_Management_Console

ルーティングを設定します。
ターゲットグループはtarget1を選択します。ヘルスチェックはindex.htmlとしておきます。

EC2_Management_Console

ターゲットのEC2インスタンスを登録します。 ここではターゲットグループに登録されているインスタンスを確認します。

EC2_Management_Console

作成内容を確認して、作成をクリックします

EC2_Management_Console

この様にALBが作成されます。

EC2_Management_Console

ルールを作成してターゲットグループへのルーティングを設定する

target2へのルールを作成します。

作成したALBを選択して、リスナータブを選択します。 ALBを作成する時に登録したターゲットグループtarget1がデフォルトのルールとして登録されています。ここのルールを追加するをクリックします。

EC2_Management_Console

パスパターンに/target/*を入力して、ターゲットグループにtarget2を選択して保存します。

EC2_Management_Console

/target/以下のURLはtarget2へルーティングされて、それ以外はtarget1へルーティングされます。

EC2_Management_Console

対象ALBの説明タブで属性の編集をクリックします。
削除保護の有効化とアクセスログの有効化を行います。

EC2_Management_Console

動作を確認する

ルーティングの動作を確認します。

各インスタンスには/index.html/target/index.htmlを用意しています。

まずはhttps://example.com/index.htmlを見ます。
target1を向いています。今回はtarget1-cへアクセスしています。

https___acm-tokyo_oguri_classmethod_info_index_html

次にhttps://example.com/target/index.htmlを見ます。
target2を向いています。今回はtarget2-aへアクセスしています。

https___acm-tokyo_oguri_classmethod_info_target_index_html

この様にURLのパスベースでルーティングをすることができます。

アクセスログを確認します。
ログファイルはgz圧縮されて保存されています。

S3_Management_Console

アクセスログの中身を見ます。
先頭が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という名称になっています。

CloudWatch_Management_Console

ロードバランサーのメトリクスは、以下のようになっています。

CloudWatch_Management_Console

ターゲットグループは独立したメトリクスを持っており、以下のようになっています。
HealthyHostCountUnHealthyHostCountがロードバランサーのメトリクスでなくなっているので注意が必要です。監視を行うときには

CloudWatch_Management_Console

メトリクスの詳細は以下のドキュメントを参照して下さい。

CloudWatch Metrics for Your Application Load Balancer

削除保護についても確認してみましょう。先ほど削除保護の設定を行ったので削除を実行してみます。

EC2_Management_Console

保護されているためエラーになりました。

EC2_Management_Console

さいごに

以前のELBに対する良くある不満であったパスベースのルーティングが可能になり、HTTP/2やWebSocketのネイティブ対応がされるようになりました。
パスベースのルーティングを活用することで細かいルール設定ができるので、静的コンテンツと動的コンテンツのポートを分けて動的コンテンツはAPサーバが直接受けることも可能になります。
ELBからALBに変更するだけでHTTP/2でのアクセスを受けられます。モダンなWebブラウザはほとんどがHTTP/2に対応しているので、クライアントのパフォーマンス向上を期待できます。

既存のELBでは対応できていなかった部分がサポートされるようになっているので、ALBの活用が進みそうです。