Application Load Balancer: 知っておくべきことすべて

Application Load Balancer は、スケーラビリティ、パフォーマンス、可用性をインテリジェントに提供します。また、サーバーが過負荷になっていないこと、およびトラフィックの急増に対処する準備ができていることも保証します。

IT チームのセキュリティ インフラストラクチャは、ロード バランサを中心に構築されています。ロード バランサーは、アプリケーションが受信トラフィックを確実に処理できるようにします。この記事では、AWS の Application Load Balancer について詳しく説明します。

アプリケーション ロード バランサーとは何ですか?

Application Load Balancer (別名 ALB) は、AWS 上の Elastic Load Balancer または ELB です。これは、オープン システム相互接続 (OSI) モデルのアプリケーション層 (第 7 層) で動作します。

ALB には、リスナー、ロード バランサー、ターゲット グループという 3 つのコンポーネントがあります。リクエストを受信した後、 ロード バランサーは リスナー ルールを 優先順位に従って評価します (実行するルールを選択するため)。次に、ルール アクションの ターゲット グループ からターゲットを選択します。

アプリケーション トラフィックの内容に応じて、さまざまなターゲット グループにリクエストを送信するリスナー ルールを設定できます。 ALB のデフォルトのルーティング アルゴリズムはラウンドロビンです。ただし、最も未処理のリクエストのルーティング手法を選択することもできます。

ニーズの変化に応じて、アプリケーションの一般的なリクエスト フローを中断することなく、ロード バランサーからターゲットを削除したり追加したりできます。

Elastic Load Balancing (ELB) を使用すると、アプリケーションのトラフィックの時間の経過に応じてロード バランサーをスケールできます。すべての Elastic Load Balancer は、大部分のワークロードに自動的にスケールできます。

また、ロード バランサーが正常なターゲットにのみリクエストを送信するように、登録されたターゲット上のアプリケーションのステータスを監視するヘルス チェックを構築することもできます。

Application Load Balancer の機能

レイヤ 7 ロード バランシング

リクエスト属性に基づいて、HTTP/HTTPS および gRPC トラフィックを Amazon EC2 インスタンス、ECS コンテナ、AWS Lambda、サードパーティ、またはオンプレミス サーバーにロード バランシングできます。

セキュリティ機能

ALB は、HTTP desync-guardian ライブラリに基づく非同期セーフガードをサポートします。この機能は、可用性や遅延を犠牲にすることなく、Desync によって引き起こされる HTTP 脆弱性からお客様のアプリケーションを保護します。顧客は、アプリケーションのアーキテクチャに基づいて、疑わしいリクエストに対する許容レベルを設定することもできます。

前哨基地のサポート

AWS Outposts は、 AWS インフラストラクチャ、サービス、ツールをほぼすべてのデータセンター、コロケーションスペース、またはオンプレミス施設に拡張して、真に一貫したハイブリッドエクスペリエンスを実現する完全マネージドソリューションです。 Application Load Balancer は AWS Outposts で使用できます。お客様は、サポートされているインスタンス タイプに ALB をデプロイできます。ALB は、手動介入を必要とせずに、さまざまなレベルのアプリケーション ワークロードに対応するために、ラック容量に合わせて自動的にスケールアップされます。

また、ロード バランシングの容量要件に対処する際に役立つリマインダー/アラートを受信するように ALB を設定することもできます。お客様は、AWS リージョンで ALB をプロビジョニングおよび管理するために使用するのと同じ AWS コンソール、CLI、および API を使用して、Outposts で ALB をプロビジョニングおよび管理できます。

HTTPS の終了

Application Load Balancer (ALB) は、クライアントとロード バランサー間の HTTPS 終了をサポートします。これは、クライアントと ALB の間の接続は HTTPS ですが、ALB とアプリケーション サーバー (EC2、ECS など) の間の接続は HTTP であることを意味します。

ALB とアプリケーション サーバー () の間の接続は VPC 内にあるため、デフォルトでは外部エンティティによって保護されます。 ALB は、事前定義されたセキュリティ ポリシーの AWS Certificate Manager と AWS Identity and Access Management (IAM) を使用して SSL 証明書を管理できます。

HTTP/2 および gRPC のサポート

HTTP/2 は、単一の多重接続を使用して、同じ接続上で多くのリクエストを送信できるようにする新しい HyperText Transfer Protocol (HTTP) 形式です。また、クライアントに SSL 接続を提供し、ヘッダー データをバイナリ形式で送信する前に圧縮します。

gRPC トラフィックは、Application Load Balancer を使用して、マイクロサービス間、または gRPC 対応クライアントとサービス間でルーティングおよび負荷分散できます。これにより、クライアントまたはサービス側の基盤となるインフラストラクチャを変更することなく、gRPC トラフィック管理をアーキテクチャにスムーズに統合できます。

gRPC は、マイクロサービス アーキテクチャにおけるサービス間通信に最適なプロトコルであり、送信に HTTP/2 を使用します。効率的なバイナリ シリアル化、さまざまな言語のサポートなどの機能に加え、ネットワーク フットプリントの縮小、圧縮、双方向ストリーミングなどの HTTP/2 固有の利点も備えており、REST などのレガシー プロトコルよりも優れています。

スティッキーセッション

スティッキー セッションでは、同じクライアントからのリクエストを Cookie を使用して同じターゲットにルーティングできます。 ALB 属性でスティッキー セッションと Cookie を有効にするだけで、スティッキー セッションを簡単にセットアップできます。 Application Load Balancer (ALB) は、期間ベースの Cookie とアプリケーション ベースの Cookie の両方をサポートします。

ロード バランサーがユーザーのリクエストを同じターゲットに継続的に送信する時間を決定することが、スティッキー セッションを管理するための鍵となります。スティッキー セッションはターゲット グループ レベルで有効になります。期間ベースのスティッキー、アプリケーション ベースのスティッキー、およびスティッキーなしを組み合わせて、さまざまなターゲット グループに導入できます。

ネイティブIPv6サポート

ネイティブ インターネット プロトコル バージョン 6 (IPv6) は、VPC の Application Load Balancer によってサポートされています。これにより、クライアントは IPv4 または IPv6 を使用して Application Load Balancer に接続できるようになります。

リクエストトレース

ロード バランサーに送信されるすべてのリクエストで、Application Load Balancer は新しいカスタム識別子「X-Amzn-Trace-Id」HTTP ヘッダーを挿入します。リクエストトレースを使用すると、一意の ID を使用して、多数の AWS サービスに送信されるリクエストの進行状況を追跡できます。リクエストのトレースを利用して、アプリケーション スタック内のパフォーマンスやボトルネックの問題を見つけることができます。

リダイレクト

Application Load Balancer (ALB) は、受信リクエストをある URL から別の URL にリダイレクトできます。たとえば、HTTP リクエストを HTTPS リクエストにリダイレクトすることで、サイトの検索ランキングと SSL/TLS スコアを向上させながら、安全なブラウジングというコンプライアンス目標を達成できます。リダイレクトにより、ユーザーを別の Web サイトにルーティングすることもできます (たとえば、アプリケーションの古いバージョンから新しいバージョンへ)。

固定応答

Application Load Balancer は、アプリケーションがどのクライアント リクエストに対応するかを管理できます。リクエストをアプリケーションに渡さずに、HTTP エラー応答コードとカスタム エラー メッセージをロード バランサから直接受信リクエストに応答できます。

WebSocketのサポート

Application Load Balancer は WebSocket をサポートします。 WebSocket を使用すると、サーバーからの更新を要求 (またはポーリング) する必要がなく、サーバーからエンド ユーザーにリアルタイム メッセージを送信できます。長時間実行される TCP 接続を介して、WebSocket プロトコルによりクライアントとサーバー間の双方向通信チャネルが可能になります。

サーバー名表示 (SNI)

SNI (Server Name Indication) は、クライアントが TLS ハンドシェイクで接続するホスト名を指定する TLS プロトコル拡張機能です。ロード バランサは、単一のセキュア リスナーを介して多数の証明書を提示することができるため、1 つのセキュア リスナーだけで複数のセキュアな Web サイトをサポートできます。

SNI を使用すると、アプリケーション ロード バランサーはインテリジェントな証明書選択プロセスを使用して、リクエスト内のホスト名を対応する SSL 証明書と照合します。クライアントのホスト名が複数の証明書と一致する場合、ロード バランサーはクライアントの機能を含むいくつかのパラメータに基づいて最適な証明書を選択します。

ターゲットとしての IP アドレス

アプリケーション バックエンドの IP アドレスをターゲットとして使用すると、ALB を使用して、AWS、オンプレミス、さらには他のクラウド プロバイダーでホストされているアプリケーションの負荷分散を行うことができます。これにより、アプリケーション バックエンド上の任意の IP アドレスとインターフェイスへの負荷分散が可能になります。

IP アドレスは、オンプレミス (Direct Connect または VPN 経由)、ピアリングされた VPC、および EC2-Classic (ClassicLink を使用) でホストされる負荷分散アプリケーションのターゲットとしても使用できます。オンプレミスのリソースと AWS 間で負荷分散を行う機能を使用して、クラウドへの移行、クラウドへのバースト、またはクラウドへのフェイルオーバーを行うことができます。

Lambda はターゲットとして機能します

Application Load Balancer は、HTTP(S) リクエストを配信する Lambda 関数の実行をサポートしているため、ユーザーは Web ブラウザを含む任意の HTTP クライアントからサーバーレス アプリにアクセスできます。 Lambda 関数をロードバランサーのターゲットとして登録することで、コンテンツベースのルーティング ルールのサポートを使用して、リクエストを個別の Lambda 関数に送信できます。

Application Load Balancer は、サーバーおよびサーバーレス コンピューティングを利用するアプリの標準 HTTP エンドポイントとして使用できます。アプリケーションを開発するには、Lambda 関数を使用してウェブサイト全体を作成したり、ウェブサイトを EC2 インスタンス、コンテナ、オンプレミスサーバーと組み合わせたりできます。

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

アプリケーションが多数の独立したサービスで構成されているとします。その場合、Application Load Balancer は、ホスト フィールド、パス URL、HTTP ヘッダー、HTTP メソッド、クエリ文字列、送信元 IP アドレスなどのリクエストの内容に基づいて、リクエストをサービスにルーティングできます。

ホストベースのルーティング: HTTP ヘッダーの Host フィールドを使用すると、ALB はクライアント リクエストを同じロード バランサーから複数のドメインにルーティングできます。

パスベースのルーティング: HTTP ヘッダーの URL パスを使用して、クライアント要求をルーティングできます。

HTTP ヘッダーベースのルーティング: クライアント要求のルーティングには、標準またはカスタムの HTTP ヘッダー値を使用できます。

HTTP メソッドベースのルーティング: 標準またはカスタムの HTTP メソッドを使用して、クライアント要求をリダイレクトできます。

クエリ文字列パラメータベースのルーティング: クライアント要求は、クエリ文字列またはパラメータに応じてルーティングできます。

送信元 IP アドレス CIDR ベースのルーティング: クライアント要求は、送信元の送信元 IP アドレス CIDR に基づいてルーティングできます。

コンテナ化されたアプリケーションのサポート

Application Load Balancer は、単一の Amazon EC2 インスタンス上の複数のポートに負荷を分散する ( 動的ポート マッピング ) ことにより、コンテナのサポートを向上させます。 ECS タスク定義では、動的ポートを指定できます。これにより、EC2 インスタンスでスケジュールされたときにコンテナに未使用のポートが与えられます。このポートは、ECS スケジューラがタスクをロード バランサに追加するために使用します。

Web アプリケーション ファイアウォールを使用した ALB

AWS WAF を使用すると、Application Load Balancer 上のウェブアプリを保護できるようになります。 AWS WAF は、アプリケーションのダウンタイムを引き起こしたり、セキュリティを侵害したり、過剰なリソースを消費したりする可能性のある一般的な Web エクスプロイトから Web アプリケーションを保護します。

ロードバランシングアルゴリズムを使用したスロースタートモード

Application Load Balancer (ALB) は、ラウンドロビン負荷分散アルゴリズムをサポートしています。さらに、Application Load Balancer のラウンドロビン メカニズムには、リクエストで過負荷にならずに新しいターゲットを追加できる遅延開始モードが含まれています。スロー スタート オプションを使用すると、指定されたランプアップ期間中にリクエストの公平なシェアを取得する前に、ターゲットをウォームアップできます。スロー スタートは、キャッシュに依存し、クエリに最適な状態で反応する前にウォームアップ期間が必要なアプリにとって有益です。

ユーザ認証

Application Load Balancer を使用して、アプリの認証メカニズムをオフロードできます。ユーザーがクラウド アプリケーションにアクセスすると、Application Load Balancer がユーザーを認証します。 Application Load Balancer と Amazon Cognito のシームレスな統合により、エンドユーザーは、Google、Facebook、Amazon などのソーシャル ID プロバイダーだけでなく、SAML または OpenID Connect 準拠の ID プロバイダーを介した Microsoft Active Directory などのエンタープライズ ID プロバイダーを通じて認証できます。

OpenID Connect と互換性のある特注の IdP ソリューションをすでにお持ちの場合、Application Load Balancer は ID プロバイダーに直接接続してエンタープライズ ユーザーを検証することもできます。

Classic Load Balancer(CLB) から Application Load Balancer(ALB) に移行するメリット

Classic Load Balancer は、AWS の最初のタイプの Load Balancer でした。 Classic Load Balancer は強力ではありますが、ALB と NLB の導入により、徐々に時代遅れになりつつあります。現在、新しいバージョンのロード バランサーでサポートされている多くの機能は、Classic Load Balancer には存在しません。

• パス条件のサポート: リクエスト内の URL に基づいてリクエストを転送するルールを使用してリスナーを構成できます。これにより、アプリケーションをより小さなサービス (マイクロサービス) に分割し、URL のコンテンツに基づいてリクエストを適切なサービスにルーティングできます。
• ホスト条件のサポート: HTTP ヘッダーのホスト フィールドに基づいてリクエストを転送するルールを使用してリスナーを構成できます。これにより、単一のロード バランサーを使用してリクエストを多くのドメインにルーティングできるようになります。
• ルーティングは、HTTP ヘッダーの条件とメソッド、クエリ パラメーター、送信元 IP アドレスなどの要求情報に基づいてサポートされます。
• 単一の EC2 サーバー上の多数のアプリケーションにルーティング リクエストを送信できます。
• インスタンスまたは IP アドレスは、別のポート上の多数のターゲット グループに登録できます。
• リクエストをある URL から別の URL にリダイレクトできます。
• カスタム HTTP 応答を返すことが可能です。
• VPC 外部のターゲットを含む、IP アドレスによるロードバランサーのターゲットの登録のサポート。
• Lambda関数をターゲットとして登録できます。
• リクエストをルーティングする前に、ロード バランサーは企業 ID またはソーシャル ID を使用してアプリケーションのユーザーを認証できます。
• コンテナ化されたアプリがサポートされています。タスクをスケジュールするときに、Amazon Elastic Container Service (Amazon ECS) は未使用のポートを選択し、それを使用してタスクをターゲット グループに登録できます。これにより、クラスターを最大限に活用できます。
• ヘルスチェックはターゲットグループレベルで定義され、CloudWatch メトリクスはターゲットグループレベルで公開されるため、各サービスの健全性を個別に監視するためのサポートが利用可能です。ターゲット グループを Auto Scaling グループに追加すると、需要に基づいて各サービスを動的にスケーリングできます。
• 追加情報は圧縮形式でアクセスログに記録されます。

最後の言葉

Application Load Balancer は、弾力性とスケーラビリティに優れ、特に Web アプリケーションのニーズに応えるさまざまな機能を備えた新世代のロード バランサーです。 EC2 クラシック ネットワークでホストされているレガシー アプリケーションがある場合は、クラシック ロード バランサーの使用が必要になる場合がありますが、すべての新世代のワークロードでは、ALB が当然の選択肢となるでしょう。