web-dev-qa-db-ja.com

ELBはURLに応じてリクエストをリダイレクトできますか？

Amazon Elastic Load Balancerの背後にアプリケーションサーバーをセットアップしようとしています。古いバージョン専用の1つのサーバーと、新しいバージョン専用の他のすべてのサーバーがあると考えています。私はパスパラメータにバージョンIDを使用してこれを実装することを考えています

例えば.

現在のバージョン（3.0）： http://example.com/APPNAME/service

旧バージョン（2.2）： http://example.com/APPNAME/v2.2/service

私が知りたいのですが：

  1. ELBにはHTTPリクエストを調べる機能がありますか？
  2. ELBはURLパスパラメータに応じてリクエストをリダイレクトできますか？
amazon-web-servicesload-balancingamazon-elb
46
subhashlg26

更新2017-04-05

昨年の夏にパスベースのルーティングサポートを備えた新しい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に個別のターゲットにルーティングできます。グループ。

更新2016-08-11

AWSはちょうど（2016年8月11日）新しい Elastic Load BalancingサービスのApplication Load Balancer を開始しました。これはリアルタイムアプリケーション、マイクロサービスの柔軟性とパフォーマンスを改善するために設計されています 、コンテナベースのアーキテクチャ、およびストリーミングアプリケーション：

WebSocketプロトコルとHTTP/2もサポートするこの新しいロードバランサー、アプリケーション層で動作し、コンテンツベースのルーティングを提供します サポート。これにより、Application Load Balancerは、1つ以上のAmazon Elastic Compute Cloud（Amazon EC2）インスタンスで実行されている複数のサービスまたはコンテナーにリクエストをルーティングできるため、コストを削減し、サービス検出を簡素化できます。 [エンファシス鉱山]

introductory blog post で強調されているように、この新しい Application Load BalancerオプションはELB [...]でレイヤー7で実行され、元の[オプション（現在はクラシックロードバランサーと呼ばれます）は引き続き使用でき、レイヤー4およびレイヤー7の機能を引き続き提供します。

各Application Load Balancerでは、最大10個のURLベースのルールを定義して、リクエストをターゲットグループ（AWSプラン他のルーティング方法にアクセスできるようにする.

初期回答

これは不可能です- Amazon ELB 主に（ただし、以下を参照してください）トランスポート層の負荷分散を提供します（ [〜＃〜] osi [〜＃〜] =レイヤー4）は、TCP接続のみに基づいて負荷分散の決定を行いますが、アプリケーションペイロードは無視します。後者はアプリケーション層の負荷を許可しますバランシング（ [〜＃〜] osi [〜＃〜] layer 7）。実際の負荷分散の決定のためにアプリケーションペイロードが考慮されます。

Amazon ELBのデフォルト設定は、実際にはHTTP/HTTPS/SSLの基本的なアプリケーションレベルのサポートを提供します（たとえば、SSL接続の終了とX-Forwarded-*ヘッダー）、ただし、この構成を調整することはできません。別の言い方をすれば、ELBは HTTP要求を実際に調べますが、この点でELBの動作を制御することはできません。

これについては、 ロードバランサーのリスナーの選択 で詳しく説明します。例：

Elastic Load BalancingでTCP/SSL（レイヤー4）を使用する

TCPをフロントエンド接続とバックエンド接続の両方に使用すると、ロードバランサーはヘッダーを変更せずにリクエストをバックエンドインスタンスに転送します。この構成では、セッションの持続性やX-Forwarded- *ヘッダーのCookieも挿入されません。

[...]

Elastic Load BalancingでHTTP/HTTPS（レイヤー7）を使用する

フロントエンド接続とバックエンド接続の両方にHTTP（レイヤー7）を使用する場合、ロードバランサーはリクエスト内のヘッダーを解析し、登録済みインスタンスにリクエストを再送信する前に接続を終了します（ s）。これは、Elastic Load Balancingが提供するデフォルトの構成です。

[エンファシス鉱山]

Architectural Overview は、イラストと詳細も提供します。

53
Steffen Opel

質問を投稿してから何年も経ちましたが、Amazonは最近Application（Layer 7）Load Balancing Functionalityを発表しました。これはあなたが探しているものをサポートするはずです。

基本的に、「ルール」（URLパスパターンなど）に基づいてトラフィックがルーティングされるさまざまなターゲットグループを定義できます。ルールは必要に応じて優先順位を付けることができます。

詳細は https://aws.Amazon.com/elasticloadbalancing/applicationloadbalancer/ をご覧ください

3
jstell

ここに私が見た解決策があります。ロードバランシングにネイティブのNginx Plusを使用するほど理想的ではありませんが、ELBを使用する必要がある場合は機能します。

次のようなアーキテクチャを想像してみましょう。

                        ELB
                         |
          Server 1    Server 2   Server...
          (Current)   (Current)  (Current)
              \           |         /
                      Server X
                      (Legacy)

最初のレイヤーの各サーバーは、「現在の」実装を実行します。また、アプリレイヤーの前で、WebサーバーとしてNginxまたはApacheを実行します（これは一般に、すべてのWebアプリ、IMOの前でのベストプラクティスです）。

Nginx/Apacheの各構成ファイルには、これがサーバーXへのリクエストをプロキシするレガシーコールであることを示すURLパラメーターの行チェックが含まれています。レガシーコールでない場合は、「現在の」アプリへのリクエストを継続します。

欠点は、既存のサーバーにプロキシするために現在のサーバーで数サイクルを使用しているが、アーキテクチャが非常に単純であり、集中型のフローがあることです。

0
mwielbut