【新発表】AWS アプリケーションロードバランサー

私たちはElastic Load Balancing (ELB)を2009年にAWSで発表しました(New Features for Amazon EC2: Elastic Load Balancing, Auto Scaling, and Amazon CloudWatchを見るとこの時からAWSがどれだけ変化してきたかがわかると思います)。Elastic Load BalancingはAWS上で動くアプリケーションのキーコンポーネントとなりました。Auto Scalingとの連携によって、Elastic Load Balancingは高い可用性を保ちながらアプリケーションをスケールアップ・ダウンする仕事を非常に簡単にしてくれました。

レベル

よく知られているOSIモデルでは、ロードバランサーは一般的にレイヤー4 (ネットワーク)かレイヤー7 (アプリケーション)で実行されます。

レイヤー4のロードバランサーはネットワークプロトコルのレベルで動作しネットワークパケットの中身を見ないので、HTTPやHTTPSの機能は無視します。別の言い方をすれば、これは全てを知る必要なく負荷を分散する仕組みになります。

レイヤー7のロードバランサーはより洗練されていて強力です。パケットの中を見て、HTTPとHTTPSのヘッダにアクセスし、(他の情報も合わせて)より賢い方法で負荷をターゲットに分散させることができます。

AWS上のアプリケーションロードバランサー

本日、私たちは新しいアプリケーションロードバランサーをELBの１つとして発表します。これはレイヤー7で実行され、幾つかの先進的な機能をサポートしています。元々のロードバランサー(これからはクラシックロードバランサーと呼ばれます)は引き続き利用可能で、レイヤー4とレイヤー7の両方の機能を提供します。

アプリケーションロードバランサーはコンテントベースのルーティングと、コンテナで実行されるアプリケーションをサポートします。業界標準の２つのプロトコル (WebSocketとHTTP/2)をサポートし、またターゲットのインスタンスやコンテナのヘルス状態の可視化も追加されています。コンテナやEC2インスタンスで動いているウェブサイトやモバイルアプリケーションは、アプリケーションロードバランサーを使うことで利益を得ることができるでしょう。

それでは、これらの機能を一つ一つ見ていって、最後に新しいアプリケーションロードバランサーを自身で作成してみましょう！

コンテントベースのルーティング

アプリケーションロードバランサーはHTTPヘッダーにアクセスし、リクエストを異なるバックエンドにルーティングすることができます。例えば、/apiがURLパスに含まれているリクエストを1つのサーバグループ(これをターゲットグループと呼びます)に送り、/mobileが含まれるリクエストをもう1つのグループに送りたいとします。こういった手法でリクエストをルーティングすることで、複数のマイクロサービスをそれぞれ独立して実行しスケールさせることができます。

この後見ることになりますが、1つのアプリケーションロードバランサーでは、リクエストをターゲットグループへ向けてルーティングするURLベースのルールを10個まで定義することができます。さらにこの先、他のルーティング方式も実装することを計画しています。

コンテナベースアプリケーションのサポート

多くのAWSのお客様がマイクロサービスをコンテナ化し、Amazon EC2 Container Serviceの上で動かしています。これによって1つのEC2インスタンス上で1つ以上のサービスを実行することができますが、古いロードバランサーではポートマッピングやヘルスチェックを注意する必要があるという幾つかの課題が存在しました。

アプリケーションロードバランサーはコンテナベースのアプリケーションを認識しサポートしてくれます。これによって1つのインスタンス上で、複数のポートをlistenしている幾つかのコンテナを同一のターゲットグループの下に紐付けることができ、またより詳細なポートレベルのヘルスチェックを実施できます。

メトリクスの改善

アプリケーションロードバランサーはヘルスチェックをポートベースで実施しレポートします。ヘルスチェックは許容するHTTPのレスポンスのレンジを指定でき、詳細なエラーコードも含まれます。

コンテントベースのルーティングにより、メトリクスをマイクロサービス毎に収集することも可能になりました。これはとても良い副作用であり、各マイクロサービスは自身のターゲットグループを特定のEC2インスタンス群で実行できます。こうした可視化の改善により、各サービスの負荷に応じてスケールアップ・ダウンが可能になりました。

アプリケーションロードバランサーはいくつかの新しいCloudWatchのメトリクスを追加していて、その中には全体のトラフィック(GB単位)、アクティブなコネクション数、また1時間単位のコネクションレートが含まれます。

プロトコルとワークロードの追加サポート

アプリケーションロードバランサーは2つのプロトコルサポートを追加しました: WebSoecketとHTTP/2です。

WebSocketはクライアントとサーバの間で、長期間のTCPコネクションを利用可能にしてくれます。これは、HTTP接続を開いたままにして長い間隔の”ハートビート”を利用する様な古い方式の代替として、より効率の良いものとなっています。WebSocketはモバイルデバイスには特に良くて、電源の消費を最小にしながら、株価やスポーツの得点などの動的なデータを配信するのに利用できます。ALBはws://とwss://プロトコルを使ってWebSocketをネイティブサポートしています。

HTTP/2はHTTP 1.1プロトコルから多数の改善がされたものになります。この新しいプロトコルは1つのコネクションで上で複数のリクエストをサポートしています。これによって、ネットワークトラフィックを削減し、またプロトコルはバイナリをベースにしています。

アプリケーションロードバランサーはストリーミングやリアルタイム、そしてWebSocketのワークロードを最適化された方式で扱うために設計されています。リクエストとレスポンスをバッファリングせずに、ストリーミングとして扱います。これによって、レイテンシを削減しアプリケーションのパフォーマンスが向上します。

ALBを作成する

では、アプリケーションロードバランサーを作成し、トラフィックを捌ける様にしてみましょう！

Elastic Load Balancingコンソールでは、どちらのタイプのロードバランサーも作成できます:

アプリケーションロードバランサーをクリックし、名前を入力し(MyALB)、インターネット向けを選択します。HTTPSをリスナーとして追加します:

同じ画面で、自分のVPCを選択し(VPCだけの機能なので)、必要なアベイラビリティゾーンのサブネットを選択し、アプリケーションロードバランサーにタグをつけ、セキュリティの設定に進みます:

HTTPSのリスナーを作成したので、このアプリケーションロードバランサーは証明書が必要です。既存のIAMやAWS Certificate Manager (ACM)の証明書を選ぶか、ローカルの証明書をアップロードするか、または新しい証明書をリクエストすることができます:

次に、セキュリティグループを設定します。今回は新しいものを作成することにします。もちろん、既に作成済のVPCやEC2のセキュリティグループを使うこともできます:

次のステップは最初のターゲットグループ(main)を作成し、ヘルスチェックを設定します(デフォルトのままにします):

これでターゲットを選択する準備ができました。ターゲットは、アプリケーションロードバランサーを通ったトラフィックを受けるEC2インスタンス群になります。ここでは、80番ポートをlistenしているターゲットを選択します:

最後のステップでこれまでの選択を確認し、ALBを作成します:

作成をクリックすると、アプリケーションロードバランサーは作成中になり、1分程度でアクティブになります:

追加のターゲットグループを作成できます:

そして、/apiのリクエストをこのターゲットにルーティングする新しいルールを追加できます:

アプリケーションロードバランサーはAuto Scaling、Amazon ECS、AWS CloudFormation、AWS CodeDeploy、そしてAWS Certificate Manager (ACM)といった複数のAWSサービスと連携しています。追加のサービスとの連携についても作業をしているところです。

移行

もし現在クラシックロードバランサーを使っていて、アプリケーションロードバランサーに移行したいという場合、新しいロードバランサーコピーツールを見てみて下さい。このPythonのツールは既存のクラシックロードバランサーと同じ設定でアプリケーションロードバランサーを作成するのを手伝ってくれます。また既存のEC2インスタンスを新しいロードバランサーに登録することもできます。

利用可能リージョンと価格

アプリケーションロードバランサーは全てのAWSコマーシャルリージョン(東京リージョンも含まれます)で今日から使いはじめることができます！

アプリケーションロードバランサーの1時間あたりの利用料金は、クラシックロードバランサーより10%低くなっています。

アプリケーションロードバランサーを使うと、時間単位の課金とLoad Balancer Capacity Units (LCU)の使用量に応じた課金が発生します。LCUは1秒当りの新規コネクション数、アクティブなコネクション数、そしてデータ転送量で計測されます。この3つの指標を計測して、最も高いものを基準に課金されます。1つのLCUは以下のいずれかをサポートできます:

2 KBの証明書の場合: 25 接続/秒、3000アクティブ接続、2.22 Mbpsのデータ転送
4 KBの証明書の場合: 5 接続/秒、3000アクティブ接続、2.22 Mbpsのデータ転送

LCUの利用料は微量で1 LCUに1時間当り$0.008となります。我々の計算では、ほとんどのお客様でクラシックロードバランサーからアプリケーションロードバランサーに切り替えることで、ロードバランサーのトータル費用は実質的に削減されると思います。

— Jeff;

原文: New – AWS Application Load Balancer (翻訳: SA岩永)

Amazon Web Services ブログ