Amazon Web Services ブログ

新機能 – AWS Application Load Balancer 向けの高度なリクエストルーティング

AWS Application Load Balancer は、2016 年の夏以来活躍しています。 これらは、コンテンツベースのルーティングをサポートし、サーバーレスおよびコンテナベースのアプリケーションとも相性がよく、スケーラビリティがきわめて高いロードバランサーです。AWS のお客様の多くが既存のホストおよびパスベースのルーティングを使用して、HTTP や HTTPS アプリケーションを動作させています。同時に、ポート転送 (コンテナベースのアプリケーションには最適)、ヘルスチェック、サービスディスカバリー、リダイレクト、固定レスポンス、組み込み認証といったさまざまな ALB 機能も活用しています。

高度なリクエストルーティング
ホストベースのルーティング機能で、ホスト のヘッダーを使用してトラフィックを任意のターゲットグループにルーティングするようにルールを書くことができます。本日より、この機能を拡張、汎用化して、皆さまが標準およびカスタム HTTP ヘッダーとメソッド、クエリ文字列、ソース IP アドレスに基づいてルールを書けるように (その結果、トラフィックをルーティングできるように) なりました。さらに、そのルールと条件もパワフルになりました。ルールは複数の条件 (AND 条件すべて) が設定可能になり、その各条件も複数の値 (OR 条件のいずれか) とのマッチを指定できます。

この新機能で、お使いのアプリケーションアーキテクチャはシンプル化され、ルーティング用のプロキシフリートの必要性がなくなり、望まないトラフィックをロードバランサーでブロックできます。ユースケースをいくつかご覧ください。

  • ボットやクローラのトラフィックを人的トラフィックから分離する。
  • 顧客または顧客グループをセル (別のターゲットグループ) にアサインし、そのトラフィックをルーティングする。
  • A/B テストを実施する。
  • カナリアリリース手法によるデプロイ、またはブルー/グリーンデプロイを実施する。
  • メソッドベース (たとえば、あるターゲットグループには PUT、別のターゲットグループには GET など) で、マイクロサービスハンドラーにトラフィックをルーティングする。
  • IP アドレスまたは CDN ベースで、アクセス制限を実行する。
  • オンプレミスまたはインクラウドのターゲットグループにトラフィックを選択的にルーティングする。
  • デバイスのさまざまなタイプやカテゴリに、異なるページやユーザーエクスペリエンスを配信する。

高度なリクエストルーティングの使用法
本機能は、現在お使いの Application Load Balancer で既存のルールを編集するだけでご利用になれます。まず、プレーンテキストの固定レスポンスを返すシンプルなルールから始めます (本記事の例はあくまでテスト用、解説用です。実際には皆さまの環境ではより実践的で面白い事例になると思います)。

curl を使用してテストします。

$ curl http://TestALB-156468799.elb.amazonaws.com
Default rule reached!

[Insert Rule] をクリックして、高度なリクエストルーティングをいくつか設定します。

次に、[Add condition] をクリックすると、使用できるオプションが表示されます。

[Http header] を選択して、[jeff] という値を持つ、[user] という名前のクッキーを探す条件を作成します。次に、固定レスポンスを返すアクションを作成します。

[Save] をクリックすると、数秒後に変更が実行され、以下のペアのリクエストが発行されます。

$ curl http://TestALB-156468799.elb.amazonaws.com
Default rule reached!

$ curl --cookie "user=jeff" http://TestALB-156468799.elb.amazonaws.com
Hello Jeff

1 つ以上の IP アドレスの CIDR ブロックにマッチさせるようにルールを書くこともできます。

$ curl http://TestALB-156468799.elb.amazonaws.com
Hello EC2 Instance

クエリ文字列にマッチさせることも可能です (A/B テストには特に便利)。

$ curl http://TestALB-156468799.elb.amazonaws.com?ABTest=A
A/B test, option A selected

また、ある特定のフィールド名の有無を知りたい場合は、ワイルドカードも使用できます。

標準またはカスタムの HTTP メソッドにマッチさせることも可能です。ここでは、READ というメソッドを作ってみます。

$ curl --request READ http://TestALB-156468799.elb.amazonaws.com
Custom READ method invoked

アクション設定では、フレキシブルな選択肢が多数あります。新しいものではありませんが、ご紹介しておく価値はあるでしょう。

[Forward to] は、リクエストをターゲットグループ (EC2 インスタンスセット、Lambda 関数、IP アドレスリストのいずれか) にルーティングします。

[Redirect to] は、301 (permanent) または 302 (found) レスポンスを生成します。また、HTTP と HTTPS の切り替えにも使用できます。

[Return fixed response] は、先ほどお見せした任意のレスポンスコードで静的レスポンスを生成します。

[Authenticate] は、Amazon Cognito または OIDC プロバイダーを使用して、リクエストを認証します (HTTPS リスナーのみ適用可).

理解しておくべきこと
ここでは、この便利でパワフルな機能についていくつか理解しておくべきことを記載します。

メトリクス – [Rule Evaluations] および [HTTP fixed response count] の CloudWatch メトリクスを参照していただくと、お客様のルールにもっと関連性の高いアクティビティがわかります (詳細はこちらから)。

プログラマティックアクセス – ルールの作成、変更、検査、削除は、ALB API および CLI (CloudFormation は近日サポート開始予定) により可能です。

ルールのマッチング – ルールは文字列のマッチングによって運用されるため、お客様のルールが意図したとおりに機能しているか十分なテストやダブルチェックが必要になります。ALB アクセスログの [matched_rule_priority] および [actions_executed] フィールドは、デバッグやテスト時には有用です (詳細はこちらから)。

制限 – 各 ALB のルール数はデフォルトを除き、最大 100 が上限です。各ルールが参照できる値は最大 5 つまで、ワイルドカードは最大 5 つまで使用できます。条件数は、参照対象の一意の値の数に制限されるのみです。

今すぐ利用可能です！
高度なリクエストルーティングは、すべての AWS リージョンで追加料金なしで (つまり、お支払いは Application Load Balancer の所定の料金のみ) 今すぐでもご利用になれます。

— Jeff;