Category: Amazon Elastic Load Balancing


新規 – AWS Application Load Balancer に対するホストベースのルーティングのサポート

昨年、新しい AWS Application Load Balancer (Elastic Load Balancing の重要な一部) をご紹介し、リクエストの URL のパス要素に基づいて受信 HTTP および HTTPS トラフィックをルーティングするための設定方法について説明しました。このパスベースのルーティングにより、たとえば /api へのリクエストをサーバーのセット (ターゲットグループとも呼ばれます) にルーティングし、/mobile へのリクエストを別のセットにルーティングすることができます。このようにトラフィックをセグメント化することで、リクエストのカテゴリ別に処理環境を制御できます。たとえば、最適な処理環境として、/api リクエストにはコンピューティング最適化インスタンスを指定し、/mobile リクエストにはメモリ最適化インスタンスを指定できます。

ホストベースのルーティングと追加のルール
この度、別のルーティングオプションが利用可能になりました。Host ヘッダーに指定したドメイン名に基づいて受信トラフィックをルーティングする Application Load Balancer ルールを作成できるようになりました。api.example.com へのリクエストは 1 つのターゲットグループに送信し、mobile.example.com へのリクエストは別のターゲットグループに送信して、他のすべてのリクエストは (デフォルトルールで) 3 番目のターゲットグループに送信することができます。ホストベースのルーティングとパスベースのルーティングを組み合わせたルールを作成することもできます。これにより、api.example.com/production へのリクエストと api.example.com/sandbox へのリクエストを別々のターゲットグループにルーティングできます。これまでは、一部のお客様はプロキシサーバー群を設定して実行し、ホストベースのルーティングに使用していました。今回のリリースにより、ルーティングは Application Load Balancer によって行われるため、プロキシサーバー群は必要なくなりました。この処理レイヤーの省略により、アーキテクチャが簡素化され、運用のオーバーヘッドが削減されます。Application Load Balancer は、ポートマッピング、ヘルスチェック、サービス検出などのコンテナベースのアプリケーションをサポートする複数の機能を既に提供しています。ホストとパスの両方でルーティングできるようになると、複数のマイクロサービスをそれぞれ異なる Amazon EC2 Container Service コンテナで実行するアプリケーションを構築し、効率的にスケールすることができます。ホストベースのルーティングを使用すると、サービス名とコンテナ名を合致させることで、これまで以上にサービス検出機構を簡素化できます。今回のリリースでは、Application Load Balancer あたりの最大ルール数が 10 から 75 に増え、新しいルールエディタも導入されます。例として、以下のターゲットグループを使用してみましょう。

ロードバランシングコンソールに、Application Load Balancer に関連付けられているリスナーが表示されます。ここで、[View/edit rules] をクリックして新しいルールエディタにアクセスします。

すべてのリクエストを web-target-production ターゲットに転送するデフォルトルールが既に設定されています。

挿入アイコン ([+] 記号) をクリックして、場所を選択します。ルールは、表示されている順に処理されます。

[Insert Rule] をクリックして新しいルールを定義します。ルールは、ホスト、パス、または両方を参照できます。ホストのみを使うことにします。

ホストベースのルーティング用に 2 つのルールを追加します。エディタは次のようになります。

プロダクションおよびサンドボックスのトラフィックを別々のターゲットにルーティングする場合は、パスを参照する新しいルールを作成できます。最初のルールは次のとおりです。

数回クリックして少し入力するだけで、強力なルール群を作成できます。

Host ヘッダーと一致するルールには、最大 3 つの “*” (0 個以上の文字と一致) または “?” (1 文字と一致) ワイルドカードを含めることができます。大規模なお客様のそれぞれに、追跡目的で、独自のホスト名を付けることにします。ホスト名の最後の部分にかかわらず、すべてのリクエストを同じターゲットグループにルーティングするルールを記述できます。シンプルな例は次のとおりです。

ルールエディタの鉛筆アイコンを使用すると、ルールの順番を変更できます。ルールを選択して、別の場所に移動し、新しい順番を保存します。

既存のルールの編集や、不要なルールの削除を行うこともできます。

今すぐ利用可能
この機能は、本日からすべてのパブリック AWS リージョン (15 か所) で利用できます。各ロードバランサーで評価される最初の 10 個のルール (ホストベース、パスベース、または両方) は無料です。その後は、ルールの評価数に基づいて課金されます (これは前回の投稿で説明したロードバランサーのキャパシティーユニット (LCU) に新しく追加されたディメンションです)。各 LCU は最大 1000 ルールの評価をサポートします。LCU の 4 つすべてのディメンションが測定されますが、課金されるのは特定の時間内で最も使用量が多いディメンションのみです。設定されていても処理されないルールは課金対象外です。

Jeff;

アプリケーションパフォーマンスのパーセンタイルと AWS アプリケーションロードバランサーへのリクエストのトレース

本日のゲストポストでは、同僚の Colm MacCárthaigh が新しいCloudWatch パーセンタイル統計およびロードバランサーの意味と利点について語ります。 また、個別のリクエストがロードバランサーに到着した時点からその進行を追跡でき、そのリクエストがアプリケーションに繋がるための新しいリクエストのトレース機能も紹介します。

Jeff;


アプリケーションパフォーマンスのパーセンタイルメトリクス
AWS Elastic Load Balancer はすでに以前から Amazon CloudWatch メトリクスに含まれ、ロードバランサーのバックグラウンドで実行しながらインスタンスとソフトウェアのヘルス状態とパフォーマンスの可視化を提供します。たとえば、ELB はアプリケーションに送られたすべてのリクエストが負荷分散される応答時間を測定します。多くのカスタマーはアプリケーションのパフォーマンスを監視するために、ビルトインの平均と最大レイテンシーメトリクスを使用しています。また、インスタンスやコンテナを負荷の変動として追加や削除するためのきっかけとしてこういったメトリクスを使用することも一般的です。新しい CloudWatch パーセンタイルサポートに基づき、ELB Classic and Application Load Balancer(ALB) はアプリケーションの応答時間によりきめ細かなデータを提供します。こういった測定により範囲内のパフォーマンスをより正確に掴むことができます。たとえば、10 番目のパーセンタイルが 2 ミリ秒とすると、10% のリクエストは 2 ミリ秒以下かかることになり、99.9 番目のパーセンタイル値が 50 ミリ秒とすると、99.9% のリクエストは 50 ミリ秒以下かかっているという具合です。

パーセンタイルがどれだけ役に立つかという現実的な例としては、ほとんどのリクエストを 1 から 2 ミリ秒で高速キャッシュから処理するアプリケーションの場合、キャッシュが空になるとリクエストの処理はさらにずっと遅くなり、100 ミリ秒 から 200 ミリ秒の範囲までも落ちてしまいます。従来の最大メトリクスでは 200 ミリ秒台の最低速の案件のみが反映され、平均には高速と低速の回答が混合して示されることになり、どれだけのリクエストが高速または低速で処理され、そしてそれぞれがどれだけの速度であったかについての詳細はほとんど提供されませんでした。パーセンタイルメトリクスは、アプリケーションのパフォーマンスをリクエストの範囲を通して映し出し、より分かりやすい情報を提供します。パーセンタイルのメトリクスはアプリケーションに対してより有意義で積極的なパフォーマンスとして使用できます。たとえば、99番目のパーセンタイルを Auto Scaling のトリガーあるいは CloudWatch アラームとして使用すると、スケーリングのターゲットを設定できるために十分なリソースが提供されて 1% を超えないリクエストのみで 2 ミリ秒以上の処理時間がかかることになります。

リクエストのトレーシング内蔵
パーセンタイルはすべてのリクエストにおけるパフォーマンスの全体像を示すことでアプリケーションの可視性を大幅に向上させますが、AWS のアプリケーションロードバランサーの新しいトレーシング機能では、アプリケーションのパフォーマンスとヘルス状態を個々のリクエストの核心レベルまで掘り下げた理解を提供できます。ALB は現在 1 つの ALB へのすべてのリクエストにおける新しいカスタム X-Amzn-Trace-ID HTTP ヘッダーを探索しています。受信リクエストにこのヘッダーがない場合、ALB は次のようなヘッダーを生成します。

X-Amzn-Trace-Id: Root=1-58211399-36d228ad5d99923122bbe354 

そしてこのリクエストをアプリケーションに渡します。ヘッダーがないため、この受信リクエストは「ルート」リクエストと考慮され、ALB が送る新しいヘッダーが無作為に生成されるルート属性に含められます。受信リクエストにヘッダーが付けられている場合、そのコンテンツは保持され、こうしてヘッダーはリクエスト間の系統やタイミングデータなどのトレーシングと診断状態を送付、保持します。たとえば、生成されるリクエストは次のようになります。

$ curl -H \
  "X-Amzn-Trace-Id: Root=1-58211399-36d228ad5d99923122bbe354; TimeSoFar=112ms; CalledFrom=Foo" \
  request-tracing-demo-1290185324.elb.amazonaws.com 

このリクエストは ALB によって多少異なるヘッダーが生成されます。

X-Amzn-Trace-Id: Self=1-582113d1-1e48b74b3603af8479078ed6;\
  Root=1-58211399-36d228ad5d99923122bbe354;\
  TotalTimeSoFar=112ms;CalledFrom=Foo 

この例にように受信ヘッダーが自身のルーツ属性に含まれる場合、ALB はそれを保持して無作為に生成される新しい「セルフ」属性を代わりに追加します。この例に TotalTimeSoFar および CalledFrom 属性は任意でありオプショナルとなり、そしてロードバランサー自体にとっては実際意味のないものですが、アプリケーションとトレーシングフレームワークがリクエスト間でデータを移動させるためにそのまま保持されます。受信リクエストにヘッダーを設定しないアプリケーションでは、ALB のリクエストのトレースはすべてのリクエストを一意に識別する働きをします。リクエスト間でヘッダーを送付するアプリケーションでは、トレース機能によってシステム全体におけるエントリポイントを容易に識別し、ルート属性によって関連するリクエストを検索し、アプリケーションがリクエストをつなぐ「パンくず」リストを作成できるようにします。X-Amzn-Trace-ID ヘッダーのコンテンツは Application Load Balancer アクセスログに記載され、これにはそれぞれのリクエストにおけるエラー表示やパフォーマンス測定が含まれ、個別のリクエストにおける事案の特定のための識別用に使用できます。

http 2016-11-08T00:04:13.109451Z app/request-tracing-demo/f2c895fd3ea253c5 \
  72.21.217.129:20555 172.31.51.164:80 0.001 0.001 0.000 200 200 276 550 \
  "GET http://request-tracing-demo-1290185324.elb.amazonaws.com:80/ HTTP/1.1" \
  "curl/7.24.0 (x86_64-redhat-linux-gnu) libcurl/7.24.0 NSS/3.16.1 \
  Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" - - \
  arn:aws:elasticloadbalancing:us-east-1:99999999999:targetgroup/echoheader/21a6f1501d2df426 \
  "Root=1-5821167d-1d84f3d73c47ec4e58577259"

パーセンタイル統計は今すべての Application Load Balancer に利用でき、CloudWatch コンソール、AWS SDKsAPI からアクセスできます。既存の Application Load Balancer とすべての Classic Load Balancer へのサポートはこれから利用できる予定です。どちらの新しい機能も無償で導入されます。

Colm MacCárthaigh、AWS Elastic Load Balancer

【新発表】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の1つとして発表します。これはレイヤー7で実行され、幾つかの先進的な機能をサポートしています。元々のロードバランサー(これからはクラシックロードバランサーと呼ばれます)は引き続き利用可能で、レイヤー4とレイヤー7の両方の機能を提供します。

アプリケーションロードバランサーはコンテントベースのルーティングと、コンテナで実行されるアプリケーションをサポートします。業界標準の2つのプロトコル (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つのプロトコルサポートを追加しました: WebSoecketHTTP/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 ScalingAmazon ECSAWS CloudFormationAWS 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岩永)