ELB の動作原理と詳細機能 ​

Elastic Load Balancing (ELB) は、着信トラフィックを複数のターゲット（Amazon EC2 インスタンス、コンテナ、IP アドレスなど）に自動的に分散させる高度なサービスです。本記事では、ELB がどのようにトラフィックを処理し、利用可能な様々な設定オプションについて詳細に解説します。

ELB の基本的な動作原理 ​

ELB は、登録されたターゲットの状態を継続的にモニタリングし、正常なターゲットにのみトラフィックをルーティングすることで、アプリケーションの可用性と耐障害性を高めます。この高度な負荷分散機能は、複数の技術的な仕組みによって実現されています。

アベイラビリティーゾーンとロードバランサーノード ​

ロードバランサーノードの配置 ​

ELB は、ユーザーが有効化したアベイラビリティーゾーン（AZ）ごとにロードバランサーノードを自動的に作成します。この分散配置により、単一障害点を排除し、高い可用性を実現します。

推奨される構成 ​

ロードバランサーの機能を最大限に活用するためには、有効な各アベイラビリティーゾーンに1つ以上の登録済みターゲットを配置することが強く推奨されます。

Application Load Balancer (ALB) の特別な要件 ​

特に、Application Load Balancer (ALB) を使用する場合は、少なくとも2つ以上のアベイラビリティーゾーンを有効にする必要があります。これは ALB の設計上の要件です。

高可用性の仕組み ​

この設定により、以下の利点が得られます：

  • 自動フェイルオーバー: 1つの AZ が利用不可能になった場合の自動切り替え
  • 継続的なサービス: 正常なターゲットがない AZ があっても、他の AZ でサービス継続
  • 負荷分散: 複数の AZ 間でのトラフィック分散

アベイラビリティーゾーンの無効化 ​

アベイラビリティーゾーンを無効にした場合でも、そのゾーン内のターゲットはロードバランサーに登録されたままですが、トラフィックはルーティングされません。

AWS グローバルインフラストラクチャとの連携 ​

AWS のグローバルインフラストラクチャは、低レイテンシー、高スループット、高度に冗長化されたネットワークで接続された物理的に独立したアベイラビリティーゾーンを中心に構築されており、アプリケーションやデータベースがゾーン間で中断なく自動的にフェイルオーバーできるよう設計されています。

リクエストルーティングの仕組み ​

DNS 解決プロセス ​

クライアントがロードバランサーにリクエストを送信する際の流れは以下の通りです：

  1. DNS 解決: クライアントがドメインネームシステム (DNS) サーバーを使用してロードバランサーのドメイン名を解決
  2. IP アドレス取得: AWS の DNS サーバーがロードバランサーのノードの IP アドレスをクライアントに返却
  3. リクエスト送信: クライアントが取得した IP アドレスにリクエストを送信

動的スケーリングと DNS 更新 ​

ELB は、アプリケーションへのトラフィックの変化に応じてロードバランサーの容量を自動的にスケールさせ、これに伴い DNS エントリを更新します。

DNS TTL の重要性 ​

DNS エントリには60秒の有効期限 (TTL) が設定されており、これによりトラフィックの変化に応じて IP アドレスを迅速に再マッピングすることが可能です。

ターゲット選択とルーティング ​

リクエストを受信したロードバランサーノードは、以下の手順でターゲットを選択します：

  1. ヘルスチェック: 正常な登録済みターゲットを特定
  2. ターゲット選択: 適切なルーティングアルゴリズムを使用してターゲットを選択
  3. プライベート IP 使用: プライベート IP アドレスを使用してターゲットにリクエストを送信

Network Load Balancer (NLB) の特別な動作 ​

NLB の場合、以下の特徴があります：

  • ネットワークインターフェイス: 有効化する各アベイラビリティーゾーンにネットワークインターフェイスが作成
  • 静的 IP: 各インターフェイスが静的 IP アドレスを取得
  • Elastic IP: 必要に応じて、ロードバランサーの作成時に Elastic IP アドレスを各ネットワークインターフェイスに関連付け可能

ルーティングアルゴリズム ​

ロードバランサーは、その種類に応じて異なるルーティングアルゴリズムを使用してターゲットを選択します。

Application Load Balancer (ALB) ​

基本的なルーティング手順 ​

  1. リスナールール評価: リクエストを受信した ALB ノードが、リスナールールを優先度順に評価
  2. ルール決定: 適用するルールを決定
  3. ターゲットグループ選択: ルールアクションで指定されたターゲットグループを選択
  4. ターゲット選択: ターゲットグループに設定されているルーティングアルゴリズムを使用

デフォルトアルゴリズム ​

デフォルトのルーティングアルゴリズムはラウンドロビンです。これにより、リクエストが順番に各ターゲットに分散されます。

独立したルーティング ​

各ターゲットグループでのルーティングは個別に実行され、複数のターゲットグループに登録されているターゲットであっても同様に処理されます。

クロスゾーン負荷分散 ​

  • ロードバランサーレベル: 常に有効
  • ターゲットグループレベル: 必要に応じて無効化可能

Network Load Balancer (NLB) ​

フローハッシュアルゴリズム ​

NLB ノードは、接続を受信するとフローハッシュアルゴリズムを使用してターゲットグループからターゲットを選択します。

ハッシュ計算要素 ​

このアルゴリズムは、以下の要素に基づいて決定されます：

  • プロトコル: TCP、UDP など
  • 送信元 IP アドレス: クライアントの IP
  • 送信元ポート: クライアントのポート番号
  • 送信先 IP アドレス: ロードバランサーの IP
  • 送信先ポート: ロードバランサーのポート番号
  • TCP シーケンス番号: TCP 接続の識別子

接続の永続性 ​

各 TCP 接続は単一のターゲットにルーティングされます。クライアントからの TCP 接続のソースポートやシーケンス番号が異なる場合、別のターゲットにルーティングされる可能性があります。

Classic Load Balancer (CLB) ​

リスナー別アルゴリズム ​

CLB は、リスナーのタイプに応じて異なるアルゴリズムを使用します：

  • TCP リスナー: ラウンドロビンルーティングアルゴリズム
  • HTTP および HTTPS リスナー: 最小未処理リクエストルーティングアルゴリズム

HTTP接続の特性 ​

接続の多重化 ​

Classic Load Balancer と Application Load Balancer は、どちらも接続の多重化をサポートしています。

多重化の利点 ​

複数のクライアントからのリクエストを単一のバックエンド接続を介してターゲットにルーティングすることで、以下の効果が得られます：

  • レイテンシー改善: 接続の再利用による高速化
  • アプリケーション負荷低減: 接続数の削減

ALB の HTTP サポート ​

サポートされる HTTP メソッド ​

ALB は、以下の標準的な HTTP リクエストメソッドをサポートしています：

  • GET, HEAD, POST, PUT, DELETE, OPTIONS, PATCH

プロトコルサポート ​

フロントエンド接続（クライアント → ロードバランサー） ​
  • HTTP/0.9, HTTP/1.0, HTTP/1.1: 基本的な HTTP プロトコル
  • HTTP/2: HTTPS リスナーでのみ利用可能
HTTP/2 の特徴 ​
  • 並行処理: 最大128のリクエストを並行して送信可能
  • パフォーマンス向上: 接続効率の大幅な改善
バックエンド接続（ロードバランサー → ターゲット） ​
  • デフォルト: HTTP/1.1
  • 設定可能: HTTP/2 または gRPC をサポートするターゲット向けに設定変更可能

WebSocket サポート ​

ALB は HTTP から WebSocket への接続アップグレードをサポートしますが、この場合は以下の制限があります：

  • ルーティングルール: ALB リスナーのルーティングルールは適用されません
  • AWS WAF: 統合機能は適用されません

HTTP ヘッダーの自動追加 ​

ALB は、以下の HTTP ヘッダーを自動的にリクエストに追加します：

  • X-Forwarded-For: クライアントの元の IP アドレス
  • X-Forwarded-Proto: 使用されたプロトコル
  • X-Forwarded-Port: 使用されたポート番号

サイズ制限 ​

ALB には以下のハードリミットが設定されています：

  • リクエストライン: 16KB
  • 単一ヘッダー: 16KB
  • レスポンスヘッダー全体: 32KB
  • リクエストヘッダー全体: 64KB

CLB の HTTP サポート ​

プロトコルサポート ​

  • フロントエンド接続: HTTP/0.9, HTTP/1.0, HTTP/1.1
  • バックエンド接続: デフォルトで HTTP/1.1

HTTP ヘッダー ​

ALB と同様に、X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port ヘッダーを自動追加します。

ロードバランサーのスキーム ​

ロードバランサーを作成する際、そのスキームとしてインターネット向けまたは内部向けを選択できます。

インターネット向けロードバランサー ​

特徴 ​

  • パブリック IP: ノードがパブリック IP アドレスを持つ
  • パブリック DNS: DNS 名がパブリックに解決可能
  • インターネット接続: インターネット経由でクライアントからのリクエストをルーティング

適用シーン ​

  • ウェブアプリケーション: 外部ユーザー向けのサービス
  • API ゲートウェイ: 外部システムとの統合
  • CDN オリジン: コンテンツ配信ネットワークの配信元

内部ロードバランサー ​

特徴 ​

  • プライベート IP: ノードがプライベート IP アドレスのみを持つ
  • プライベート DNS: DNS 名がプライベートに解決可能
  • VPC 内接続: VPC へのアクセス権を持つクライアントからのみルーティング

適用シーン ​

  • アプリケーションサーバー: 内部サービス間の通信
  • データベース: 内部データベース接続の負荷分散
  • マイクロサービス: 内部サービス間の通信

共通の特徴 ​

どちらのスキームのロードバランサーも、以下の共通の特徴があります：

  • プライベート IP ルーティング: 登録されたターゲットにはプライベート IP アドレスを使用してリクエストをルーティング
  • パブリック IP 不要: ターゲットはパブリック IP アドレスを必要としません

多層アーキテクチャ ​

アプリケーションに複数の層がある場合、以下のような組み合わせが可能です：

  • ウェブ層: ウェブサーバーをインターネット向けロードバランサーに登録
  • アプリケーション層: アプリケーションサーバーを内部向けロードバランサーに登録
  • データベース層: データベースサーバーを内部向けロードバランサーに登録

IP アドレスタイプ ​

ロードバランサーに指定する IP アドレスタイプは、クライアントがロードバランサーと通信する方法に影響します。

ロードバランサーの IP アドレスタイプ ​

IPv4 のみ ​

  • 対象: すべてのロードバランサータイプ
  • 通信方式: クライアントは IPv4 アドレスを使用して通信

デュアルスタック ​

  • 対象: ALB、NLB、GLB（CLB は非対応）
  • 通信方式: クライアントは IPv4 および IPv6 アドレスの両方を使用して通信可能

パブリック IPv4 を使用しないデュアルスタック ​

  • 対象: ALB のみ
  • 通信方式: クライアントはパブリック IPv6 アドレスとプライベート IPv4 アドレスを使用
  • 制限: 内部向けロードバランサーではサポートされません

ターゲットグループの IP アドレスタイプ ​

ターゲットグループに指定する IP アドレスタイプは、ロードバランサーがターゲットと通信する方法を決定します。

選択オプション ​

  • IPv4 のみ: 従来の IPv4 通信
  • IPv6 のみ: 新しい IPv6 通信

対応プロトコル ​

  • HTTP/HTTPS
  • TCP
  • TLS
  • UDP
  • TCP_UDP

ネットワーク MTU ​

MTU の基本概念 ​

最大送信単位 (MTU) は、ネットワーク上で送信できる最大のパケットサイズをバイト単位で定義します。

インターネット接続の MTU ​

インターネットゲートウェイを介して送信されるトラフィックの MTU は 1500バイト です。

ロードバランサーの MTU サポート ​

各ロードバランサータイプの MTU ​

  • ALB、NLB、CLB: ジャンボフレーム (9001 MTU) が標準
  • GLB: 8500 MTU をサポート

設定の制限 ​

ロードバランサーノードの MTU サイズは設定できません。これは AWS が管理する固定値です。

パス MTU 検出 (PMTUD) ​

パス MTU の定義 ​

パス MTU は、送信側ホストと受信側ホスト間のパスでサポートされる最大のパケットサイズであり、パス MTU 検出 (PMTUD) によって決定されます。

最適化の推奨事項 ​

以下の条件を満たすことで、最適なパフォーマンスを維持できます：

  • PMTUD の正常動作: パス MTU 検出が適切に機能すること
  • クライアント側設定: ジャンボフレームが有効になっていること
  • ターゲット側設定: ジャンボフレームが有効になっていること

期待される効果 ​

適切な設定により、以下の効果が得られます：

  • パケット断片化の防止: 効率的なデータ転送
  • パケット破棄の回避: 安定した通信
  • 最適なパフォーマンス: 高速なデータ転送

パフォーマンス最適化のポイント ​

ネットワーク設定の最適化 ​

アベイラビリティーゾーンの設定 ​

  • 複数 AZ の利用: 高可用性とパフォーマンスの向上
  • 均等な分散: 各 AZ にバランスよくターゲットを配置

MTU の最適化 ​

  • ジャンボフレームの有効化: 可能な限り大きなパケットサイズを使用
  • PMTUD の確認: パス MTU 検出の正常動作を確認

ルーティングアルゴリズムの選択 ​

ALB の設定 ​

  • 適切なアルゴリズム: ワークロードに応じたルーティング方式の選択
  • スティッキーセッション: 必要に応じたセッション維持

NLB の設定 ​

  • フローハッシュの活用: 適切な負荷分散の実現
  • クロスゾーン負荷分散: 必要に応じた有効化

監視と調整 ​

CloudWatch メトリクス ​

  • レイテンシー: 応答時間の監視
  • エラー率: 失敗率の追跡
  • 接続数: 同時接続数の監視

継続的な最適化 ​

  • 定期的な見直し: パフォーマンスの継続的な評価
  • 設定の調整: 負荷パターンに応じた設定変更

まとめ ​

ELB の動作原理を理解することで、以下の利点を得ることができます：

技術的な理解 ​

  • ルーティング仕組み: 複雑なトラフィック分散メカニズムの理解
  • 高可用性設計: 障害耐性の高いアーキテクチャ設計
  • パフォーマンス最適化: 効率的なネットワーク設定

運用上の利点 ​

  • 適切な設定: 要件に応じた最適な設定選択
  • 問題の早期発見: 動作原理に基づいた監視とトラブルシューティング
  • コスト最適化: 効率的なリソース利用

設計上の考慮事項 ​

  • スキーム選択: インターネット向けか内部向けかの適切な判断
  • IP アドレスタイプ: IPv4、IPv6、デュアルスタックの選択
  • MTU 設定: ネットワークパフォーマンスの最適化

ELB の動作原理を深く理解することで、AWS クラウドにおける高可用性で高性能なアプリケーションアーキテクチャを構築できます。継続的な学習と実践により、ELB の機能を最大限に活用し、ビジネス要件を満たすスケーラブルなソリューションを実現できるでしょう。

参考リンク ​

関連記事: ELB ロードバランサーの種類と特性比較 | Amazon ELB の基本と役割