ELB ロードバランサーの種類と特性比較
Amazon Elastic Load Balancing (ELB) は、異なるワークロードと要件に対応するため、4つの主要なロードバランサータイプを提供しています。本記事では、Application Load Balancer (ALB)、Network Load Balancer (NLB)、Gateway Load Balancer (GLB)、Classic Load Balancer (CLB) の具体的な特徴と適切なユースケースを詳細に比較・解説します。
はじめに
ELB は、着信トラフィックの変化に応じてロードバランサーの容量を自動的に拡張し、複数のコンピューティングリソース間でワークロードを分散させることで、アプリケーションの可用性と耐障害性を向上させます。
AWS 認定試験での重要性
AWS認定ソリューションアーキテクト-アソシエイト試験では、ワークロードの要件に基づいて適切なロードバランシング戦略や各ロードバランサーの概念を理解し、推奨するスキルが問われます。また、AWS認定クラウドプラクティショナー試験においても、ロードバランサーの目的を特定するスキルが求められています。
共通の基本機能
すべてのロードバランサーは以下の基本機能を提供します：
- ヘルスチェック: 登録されたターゲットのヘルス状態を継続的にモニタリング
- 正常なターゲットへのルーティング: 正常なターゲットにのみトラフィックをルーティング
- 単一障害点の排除: 複数のターゲットへの分散による耐障害性向上
- セキュリティ強化: 暗号化および復号の処理をオフロード
- AWS マネージドサービス: グローバルネットワークセキュリティによる保護
Application Load Balancer (ALB)
Application Load Balancer (ALB) は、OSI参照モデルのレイヤー7 (アプリケーション層) で動作し、HTTP/HTTPS トラフィックに最適化されています。
基本動作
ALB は、クライアントからのリクエストを受信すると、リスナールールを優先度順に評価し、ターゲットグループに設定されたルーティングアルゴリズム（デフォルトはラウンドロビン）を使用してターゲットを選択します。
主要な特徴と機能
高度なルーティング機能
ALB は、以下の条件に基づいてトラフィックを異なるターゲットグループにルーティングできます：
- URL パス: 特定のパスパターンに基づく分散
- ホスト名: 仮想ホストによる分散
- HTTP ヘッダー: カスタムヘッダーに基づく分散
- クエリ文字列: URL パラメータに基づく分散
- 送信元 IP アドレス: クライアント IP による分散
追加機能のサポート
- URL リダイレクト: 特定の URL から別の URL への自動リダイレクト
- カスタム HTTP レスポンス: 固定レスポンスの返却
- 柔軟なターゲット: IP アドレスや Lambda 関数をターゲットとして登録
- VPC 外ターゲット: オンプレミス環境や他のクラウドサービスとの統合
コンテナ化されたアプリケーションへの適合性
Amazon Elastic Container Service (Amazon ECS) と緊密に統合されており、Docker コンテナを実行、停止、管理する ECS サービス全体に受信トラフィックを分散させることができます。
セキュリティとパフォーマンスの強化
- TLS 終端: HTTPS/TLS トラフィックをロードバランサーで終端
- 証明書管理: AWS Certificate Manager (ACM) や IAM でのサーバー証明書管理
- HTTP/2 サポート: 最大128のリクエストを並行送信可能
- AWS WAF 統合: アプリケーション層でのセキュリティ強化
- ユーザー認証: 企業 ID やソーシャル ID による認証サポート
接続の多重化
複数のクライアントからのリクエストを1つのバックエンド接続に多重化することで、レイテンシーが改善され、アプリケーションの負荷が軽減されます。
高可用性
ロードバランサーレベルでクロスゾーン負荷分散が常に有効になっているため、トラフィックが複数のアベイラビリティーゾーンに存在するターゲットに均等に分散されます。
Network Load Balancer (NLB)
Network Load Balancer (NLB) は、OSI参照モデルのレイヤー4 (トランスポート層) で動作し、TCP、UDP、TLS トラフィックに最適化されています。
基本動作
NLB は、極めて高いスループットと低レイテンシーを要求するワークロード向けに設計されており、揮発性の高いワークロードを処理し、毎秒数百万のリクエストに対応する能力を持ちます。
接続を受信したロードバランサーノードは、プロトコル、送信元IP/ポート、送信先IP/ポート、TCP シーケンス番号に基づくフローハッシュアルゴリズムを使用して、ターゲットを選択し、接続中は単一のターゲットにルーティングし続けます。
主要な特徴と機能
静的 IP アドレスのサポート
ロードバランサーに対して有効になっているサブネットごとに1つの Elastic IP アドレスを割り当てることができ、静的 IP アドレスを使用したい場合に特に有効です。
VPC 外ターゲットの登録
IP アドレスによってターゲットを登録でき、ロードバランサーの VPC 外のターゲットを含めることができます。
堅牢なパフォーマンス
- 高い接続維持能力: 大量の同時接続を安定して処理
- 迅速な IP 再マッピング: 既存の接続を中断することなく IP アドレスを再マッピング
- 超低レイテンシー: マイクロ秒レベルの低レイテンシーを実現
TLS リスナーのサポート
TLS リスナーを設定することで、ロードバランサーでクライアントからの TLS トラフィックを終端させることが可能です。
クロスゾーン負荷分散
デフォルトでは無効になっていますが、ロードバランサーの作成後いつでも有効または無効に切り替えることができます。
Gateway Load Balancer (GLB)
Gateway Load Balancer (GLB) は、OSI参照モデルのレイヤー3 (ネットワーク層) で動作し、仮想アプライアンス（ファイアウォール、IDS/IPS など）のデプロイ、管理、スケーリングを容易にするために特別に設計されています。
基本動作
GLB は、ネットワークトラフィックを仮想アプライアンスに透過的にルーティングし、アプライアンスがトラフィックを検査または変更した後に、元の宛先にルーティングし直すことを可能にします。
主要な特徴と機能
アプライアンスの透過的統合
- アプライアンスベンダーとの統合: AWS が認定したアプライアンスベンダーとの統合
- 透過的な処理: トラフィックの検査や変更のためのアプライアンスとの連携
- 信頼性の考慮: アプライアンスベンダーのソフトウェアの選択と信頼性の評価が必要
クロスゾーン負荷分散
デフォルトでは無効ですが、GLB 作成後にいつでも有効または無効に設定できます。
ゾーンシフト機能
可用性向上のためのゾーンシフト機能を提供します。
Classic Load Balancer (CLB)
Classic Load Balancer (CLB) は、Elastic Load Balancing の旧世代のロードバランサーです。現在、AWS は現行世代のロードバランサーである Application Load Balancer (ALB) または Network Load Balancer (NLB) への移行を強く推奨しています。
主要な特徴
ルーティングアルゴリズム
- TCP リスナー: ラウンドロビンルーティングアルゴリズム
- HTTP/HTTPS リスナー: 最小未処理リクエストルーティングアルゴリズム
接続の多重化
ALB と同様に、接続の多重化を使用することでレイテンシーが改善され、アプリケーションの負荷が軽減されます。
プロトコルサポート
- フロントエンド接続: HTTP/0.9、HTTP/1.0、HTTP/1.1
- バックエンド接続: デフォルトで HTTP/1.1
クロスゾーン負荷分散
- API/CLI での作成: デフォルトで無効
- AWS Management Console での作成: デフォルトで有効
- 作成後の変更: いつでも有効/無効を切り替え可能
移行の推奨
移行方法
- 移行ウィザード: GUI ベースでの移行支援
- ロードバランサーコピーユーティリティ: 自動化ツールによる移行
- 手動移行: 詳細な設定が必要な場合
移行後の更新作業
- IAM ポリシー: 現行世代対応への更新
- CloudWatch メトリクス: 新しいメトリクスへの対応
- AWS CLI コマンド: 新しいコマンド体系への更新
- CloudFormation テンプレート: 新しいリソース定義への更新
- API コール: 新しい API への更新
ロードバランサー比較表
| 特徴 | ALB | NLB | GLB | CLB |
|---|---|---|---|---|
| OSI レイヤー | レイヤー7 | レイヤー4 | レイヤー3 | レイヤー4/7 |
| 主要プロトコル | HTTP/HTTPS | TCP/UDP/TLS | IP | HTTP/HTTPS/TCP |
| ルーティング | 高度なルーティング | シンプルなルーティング | 透過的ルーティング | 基本的なルーティング |
| 静的 IP | ❌ | ✅ | ✅ | ❌ |
| HTTP/2 | ✅ | ❌ | ❌ | ❌ |
| AWS WAF | ✅ | ❌ | ❌ | ❌ |
| Lambda ターゲット | ✅ | ❌ | ❌ | ❌ |
| コンテナ統合 | ✅ | ✅ | ❌ | ❌ |
| パフォーマンス | 高 | 極高 | 高 | 中 |
| 推奨度 | 推奨 | 推奨 | 特定用途 | 非推奨 |
適切なロードバランサーの選択指針
Application Load Balancer (ALB) を選択する場合
適用シーン
- ウェブアプリケーション: HTTP/HTTPS トラフィックが主体
- マイクロサービス: パスベースルーティングが必要
- コンテナ化アプリケーション: ECS や EKS との統合
- 認証が必要: ユーザー認証機能が必要
- 高度なルーティング: 複雑なルーティング要件
具体的な使用例
- EC2 インスタンス: 複数のウェブサーバーへの分散
- ECS サービス: Docker コンテナへの分散
- Lambda 関数: サーバーレスアプリケーション
- オンプレミス: ハイブリッドクラウド構成
Network Load Balancer (NLB) を選択する場合
適用シーン
- 高パフォーマンス要件: 毎秒数百万リクエスト
- 低レイテンシー要件: マイクロ秒レベルの応答
- 静的 IP が必要: ホワイトリスト登録など
- TCP/UDP アプリケーション: 非 HTTP トラフィック
- 極端なトラフィック変動: 瞬間的な大量トラフィック
具体的な使用例
- ゲームサーバー: リアルタイムゲーム
- IoT アプリケーション: 大量のデバイス接続
- データベース: 高性能データベース接続
- VoIP システム: 音声通話システム
Gateway Load Balancer (GLB) を選択する場合
適用シーン
- セキュリティアプライアンス: ファイアウォールの統合
- ネットワーク監視: IDS/IPS の統合
- トラフィック分析: DPI (Deep Packet Inspection)
- コンプライアンス要件: セキュリティ検査が必須
具体的な使用例
- エンタープライズセキュリティ: 企業内セキュリティ
- 金融系システム: 高セキュリティ要件
- 政府系システム: コンプライアンス対応
- マルチテナント: テナント間のセキュリティ
Classic Load Balancer (CLB) から移行する場合
移行の優先順位
- ALB への移行: HTTP/HTTPS トラフィックの場合
- NLB への移行: TCP トラフィックや高性能要件の場合
- 機能比較: 現在の機能と新機能の比較
- 移行計画: 段階的な移行戦略
最適化のポイント
パフォーマンス最適化
ALB の最適化
- ターゲットグループの適切な設定: アルゴリズムの選択
- ヘルスチェックの調整: 間隔とタイムアウトの最適化
- スティッキーセッション: 必要に応じた有効化
NLB の最適化
- クロスゾーン負荷分散: 必要に応じた有効化
- プリウォーミング: 予想される負荷の事前申請
- 接続ドレイン: 適切なドレイン時間の設定
セキュリティ最適化
共通のセキュリティ対策
- セキュリティグループ: 適切なアクセス制御
- VPC エンドポイント: プライベート接続の利用
- CloudTrail: API コールの監査
ALB 固有のセキュリティ
- AWS WAF: アプリケーション層保護
- SSL/TLS: 証明書の適切な管理
- 認証機能: OIDC/SAML 認証の活用
コスト最適化
料金モデルの理解
- ALB: 時間単位 + LCU (Load Balancer Capacity Unit)
- NLB: 時間単位 + NLCU (Network Load Balancer Capacity Unit)
- GLB: 時間単位 + GLCU (Gateway Load Balancer Capacity Unit)
最適化戦略
- 適切なサイズ: オーバープロビジョニングの回避
- 使用量監視: CloudWatch による利用状況の把握
- Reserved Capacity: 予約による割引の活用
まとめ
ELB の4つのロードバランサータイプは、それぞれ異なる要件と用途に特化して設計されています。
選択の基本原則
- ALB: HTTP/HTTPS トラフィックで高度なルーティングが必要
- NLB: 高性能・低レイテンシーが要求される TCP/UDP トラフィック
- GLB: セキュリティアプライアンスとの統合が必要
- CLB: 新規導入は非推奨、既存環境は移行を推奨
成功のためのポイント
- 要件の明確化: パフォーマンス、セキュリティ、機能要件の整理
- 段階的な導入: 小規模から開始し、徐々に拡張
- 継続的な監視: CloudWatch による性能とコストの監視
- 定期的な見直し: 技術進歩に合わせた最適化
将来への対応
- 新機能の活用: AWS の継続的な機能拡張への対応
- ベストプラクティス: 業界標準への準拠
- コンプライアンス: 規制要件への対応
適切なロードバランサーの選択により、アプリケーションの可用性、パフォーマンス、セキュリティを大幅に向上させることができます。ワークロードの特性を理解し、継続的な最適化を行うことで、AWS クラウドの利点を最大限に活用できるでしょう。