Amazon Elastic Load Balancer の背後にアプリケーション サーバーをセットアップしようとしています。1 台のサーバーを古いバージョン専用にし、他のすべてのサーバーを新しいバージョン専用にすることを考えています。パスパラメーターでバージョンIDを使用してこれを実装することを考えています
例えば
現在のバージョン (3.0) : http://example.com/APPNAME/service
古いバージョン (2.2) : http://example.com/APPNAME/v2.2/service
私が知りたいのですが：
昨年の夏にパスベースのルーティングをサポートする新しい Application Load Balancer をリリースした後 (前の更新を参照)、AWS はAWS Application Load Balancer のホストベースのルーティング サポートも追加しました。
[...] Hostヘッダーで指定されたドメイン名に基づいて着信トラフィックをルーティングする Application Load Balancer ルールを作成できるようになりました。api.example.comへのリクエストを 1 つのターゲット グループに送信し、mobile.example.comへのリクエストを別のターゲット グループに送信し、その他すべて (デフォルト ルールによる) を 3 番目のターゲット グループに送信できます。ホストベースのルーティングとパスベースのルーティングを組み合わせたルールを作成することもできます。これにより、api.example.com/production および api.example.com/sandbox へのリクエストを個別のターゲット グループにルーティングでき ます。
AWS はちょうど (2016 年 8 月 11 日) 、Elastic Load Balancing サービス用の新しい Application Load Balancer を開始しました。これは、リアルタイム アプリケーション、マイクロサービス、コンテナー ベースのアーキテクチャ、およびストリーミング アプリケーションの柔軟性とパフォーマンスを向上させるように設計されています。
WebSocket プロトコルと HTTP/2 もサポートするこの新しいロード バランサーは、アプリケーション レイヤーで動作し、コンテンツ ベースのルーティングサポートを提供します。これにより、Application Load Balancer は、1 つ以上の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行されている複数のサービスまたはコンテナ間でリクエストをルーティングできるようになり、コストを削減し、サービス検出を簡素化するのに役立ちます。[鉱山を強調]
紹介ブログ投稿で強調されているように、 ELB 用のこの新しいApplication Load Balancer オプション [...] はレイヤー 7 で実行され、多数の高度な機能をサポートします [一方] 元のオプション (現在は Classic Load Balancer と呼ばれています) は引き続き使用できます。レイヤ 4 およびレイヤ 7 機能を提供し続けます。
具体的には、各 Application Load Balancer で最大 10 個の URL ベースのルールを定義して、ターゲット グループにリクエストをルーティングできるため、ELB は目前のシナリオをサポートするようになりました(AWS は、時間の経過とともに他のルーティング方法へのアクセスを提供する予定です)。
これは不可能です。Amazon ELBは主に (ただし以下を参照)トランスポート層の負荷分散 ( OSIレイヤー 4)を提供します。これは、負荷分散の決定を TCP 接続のみに基づいて行いますが、アプリケーションのペイロードは無視します。後者は、アプリケーション層のロード バランシング ( OSIレイヤー 7)を可能にし、アプリケーション ペイロードが実際のロード バランシングの決定に考慮されます。
Amazon ELB のデフォルト設定は、実際には HTTP/HTTPS/SSL の基本的なアプリケーション レベルのサポート (SSL 接続の終了とX-Forwarded-*ヘッダーの挿入など) を提供しますが、この設定を調整することはできません。別の言い方をすれば、ELB は実際にここで HTTP リクエストを調べますが、この点に関して ELB の動作を制御することはできません。
これについては、 Choose Listeners for Your Load Balancerで詳しく説明しています。
Elastic Load Balancing での TCP/SSL (レイヤー 4) の使用
フロントエンド接続とバックエンド接続の両方に TCP を使用すると、ロードバランサーはヘッダーを変更せずにリクエストをバックエンド インスタンスに転送します。この構成では、セッション スティッキまたは X-Forwarded-* ヘッダー用の Cookie も挿入されません。
[...]
Elastic Load Balancing で HTTP/HTTPS (レイヤー 7) を使用する
フロントエンド接続とバックエンド接続の両方に HTTP (レイヤー 7) を使用する場合、ロード バランサーはリクエストのヘッダーを解析し、登録済みのインスタンスにリクエストを再送信する前に接続を終了します。これは、Elastic Load Balancing によって提供されるデフォルトの設定です。
[鉱山を強調]
アーキテクチャの概要では、図と詳細も提供されています。
質問を投稿してから何年も経ちますが、Amazon は最近、アプリケーション (レイヤー 7) 負荷分散機能を発表しました。これは、探しているものをサポートするはずです。
基本的に、「ルール」 (URL パス パターンなど) に基づいてトラフィックがルーティングされるさまざまなターゲット グループを定義できます。必要に応じて、ルールに優先順位を付けることができます。
https://aws.amazon.com/elasticloadbalancing/applicationloadbalancer/で詳細を参照してください。