Elastic Load Balancing
受信トラフィックを複数のターゲットに自動分散するロードバランサーサービスで、ALB、NLB、GLB、CLB の 4 種類を提供する
概要
Elastic Load Balancing (ELB) は、受信するアプリケーショントラフィックを EC2 インスタンス、コンテナ、Lambda 関数、IP アドレスなどの複数のターゲットに自動的に分散するサービスです。Application Load Balancer (ALB)、Network Load Balancer (NLB)、Gateway Load Balancer (GLB)、Classic Load Balancer (CLB) の 4 種類があり、ワークロードの特性に応じて選択します。ALB は HTTP/HTTPS トラフィックのレイヤー 7 ルーティングに対応し、パスベースやホストベースのルーティング、WebSocket、gRPC をサポートします。NLB は TCP/UDP/TLS トラフィックのレイヤー 4 処理に特化し、超低レイテンシと毎秒数百万リクエストの処理能力を提供します。いずれも複数のアベイラビリティゾーンにまたがって動作し、ヘルスチェックにより異常なターゲットへのトラフィック送信を自動的に停止します。
ALB と NLB - レイヤーで決まる使い分け
ELB の選択は、トラフィックをどのレイヤーで処理するかで決まります。Application Load Balancer (ALB) は HTTP/HTTPS を理解するレイヤー 7 ロードバランサーで、URL パスやホストヘッダーに基づくルーティング、Cognito / OIDC 連携による認証、WAF との統合が可能です。1 つの ALB で複数のマイクロサービスを振り分けられるため、サービスごとにロードバランサーを立てる必要がありません。Lambda 関数をターゲットとして直接登録できる点は ALB 独自の機能で、Azure Application Gateway にはこの仕組みがありません。一方、Network Load Balancer (NLB) はレイヤー 4 で TCP/UDP パケットをそのまま転送し、マイクロ秒単位の超低レイテンシを実現します。静的 IP アドレスの割り当てが可能で、PrivateLink のエンドポイントサービスとしても使用できるため、ゲームサーバーや IoT デバイスからの接続、VoIP など TCP/UDP レベルの制御が必要な場面に適しています。
ヘルスチェックとターゲットグループの設計
ELB の信頼性はヘルスチェックの設計に大きく左右されます。ALB のヘルスチェックは HTTP/HTTPS エンドポイントに対して実行され、ステータスコード (デフォルトは 200) で正常性を判定します。単純な TCP ポート応答ではなく、アプリケーションの依存先 (DB 接続、外部 API) まで確認する深いヘルスチェックパスを設定すると、実際にリクエストを処理できないインスタンスを確実に除外できます。ターゲットグループの加重ルーティングを使えば、新バージョンに 10% だけトラフィックを流すカナリアデプロイが実現します。NLB のヘルスチェックは TCP / HTTP / HTTPS に対応しており、レイテンシ要件が厳しい場合は TCP チェックでオーバーヘッドを最小化します。ロードバランサーの専門書 (Amazon) では、ヘルスチェック設計のパターンが体系的にまとめられています。
アクセスログとトラブルシューティング
ALB のアクセスログを S3 に保存し、Athena でクエリすることで、トラフィックパターンの分析やトラブルシューティングが効率的に行えます。ログにはリクエスト元 IP、レスポンスコード、処理時間、ターゲットの応答時間が記録されるため、5xx エラーの急増やレイテンシの悪化を原因レベルで追跡できます。Connection Logs を有効にすると、TLS ハンドシェイクの失敗やクライアント証明書の検証エラーも記録され、接続レベルの問題を切り分けられます。Gateway Load Balancer (GWLB) はサードパーティのネットワークアプライアンス (ファイアウォール、IDS/IPS) をトラフィックパスに透過的に挿入するためのロードバランサーで、ALB / NLB とは用途が異なります。GENEVE プロトコルでカプセル化されたトラフィックをアプライアンスに転送し、検査後に元のフローに戻す仕組みです。