Elastic Load Balancer（エラスティックロードバランサー）

Elastic Load Balancer (ELB) の概要と基本概念

Elastic Load Balancer（以下、ELB）は、クラウドコンピューティング、特にAWS（Amazon Web Services）において提供される、アプリケーションへのトラフィックを複数のターゲット（EC2インスタンス、コンテナ、IPアドレスなど）に自動的に分散させるマネージドサービスです。

自作PCの世界で例えるなら、一つの超高性能なCPUにすべての処理を任せるのではなく、複数のCPUコアにタスクを分散させてシステム全体の安定性とスループットを向上させる「マルチスレッド処理」や「並列処理」に近い概念を、ネットワークインフラレベルで実現する技術と言えます。

通常、単一のサーバー（インスタンス）でサービスを運用している場合、アクセスが急増するとCPU使用率が100%に達し、メモリ（RAM）が不足してレスポンスが低下、最悪の場合はシステムがクラッシュします。また、その一台のサーバーにハードウェア故障が発生すれば、サービスは完全に停止してしまいます。ELBは、入り口となる「単一の接点（DNS名）」を提供し、背後にある複数のサーバーにリクエストを振り分けることで、これらのリスクを排除します。

「Elastic（弾力的）」という名称がついている通り、このサービスはトラフィックの増減に応じて自動的にスケーリングします。例えば、セール期間中にアクセス数が平常時の10倍に跳ね上がったとしても、ELB自体が処理能力を自動的に拡張し、背後のAuto Scalingグループと連携してサーバー台数を増やすことで、ユーザーにストレスのない快適なブラウジング体験を提供し続けます。

ELBの主要な種類と動作メカニズム

ELBは、扱うネットワークレイヤー（OSI参照モデル）によって大きく3つのタイプに分かれています。それぞれの特性を理解することは、インフラ設計において極めて重要です。

1. Application Load Balancer (ALB)

ALBは、OSI参照モデルの第7層（アプリケーション層）で動作します。HTTPやHTTPSといったプロトコルの中身を解釈できるため、「リクエストの内容に基づいた高度なルーティング」が可能です。

• パスベースルーティング: 例えば example.com/api へのアクセスはAPIサーバー群へ、example.com/static へのアクセスは静的コンテンツサーバー群へ、といった振り分けが可能です。
• ホストベースルーティング: app1.example.com と app2.example.com で異なるターゲットグループに誘導できます。
• 最新のプロトコル対応: HTTP/2やWebSocketに対応しており、モダンなWebアプリケーションに最適です。

2. Network Load Balancer (NLB)

NLBは第4層（トランスポート層）で動作し、TCPやUDPプロトコルを扱います。ALBが「中身を見て判断する」のに対し、NLBは「宛先ポートとIPアドレスだけを見て高速に転送する」仕組みです。

• 超低遅延: パケットの中身を解析しないため、処理遅延が極めて少なく、ミリ秒未満（1ms未満）のレイテンシが要求される高頻度取引（HFT）やゲームサーバーなどに適しています。
• 静的IPアドレス: ALBとは異なり、固定のIPアドレスを割り当てることができるため、ファイアウォールのホワイトリスト登録が必要な環境で重宝されます。
• 膨大なスループット: 秒間数百万リクエストという極めて高い負荷にも耐えうる設計となっています。

3. Gateway Load Balancer (GWLB)

GWLBは、サードパーティ製の仮想アプライアンス（次世代ファイアウォールや侵入検知システム（IDS/IPS）など）を効率的にデプロイし、管理するためのロードバランサーです。トラフィックを検査用サーバーに透過的に誘導し、検査完了後に本来の宛先へ戻すというフローを構築します。

ELBタイプの比較一覧表

負荷分散の仕組みとトラフィック制御の具体例

ELBが具体的にどのようにトラフィックを制御し、サーバーの健全性を維持しているのか、その内部的な仕組みを解説します。

ヘルスチェック (Health Checks)

ELBの最も重要な機能の一つが「ヘルスチェック」です。ELBは定期的に背後のターゲット（サーバー）に対して、特定のポート（例: 80番ポートや443番ポート）にリクエストを送信し、正常なレスポンス（HTTP 200 OKなど）が返ってくるかを確認します。

もし、あるサーバーがメモリリークを起こして応答不能になったり、OSがフリーズしたりした場合、ELBは即座にそのサーバーを「Unhealthy（異常）」と判定し、トラフィックの送信を停止します。これにより、ユーザーがエラーページを目にする確率を劇的に下げることができます。

分散アルゴリズム

トラフィックの振り分けには、主に以下のアルゴリズムが採用されています。

• ラウンドロビン (Round Robin): リクエストを順番に1台ずつ割り当てる単純な方式です。
• 最小未完了リクエスト (Least Outstanding Requests): 現在処理中のリクエスト数が最も少ないサーバーに優先的に割り当てる方式です。サーバーごとの処理能力に差がある場合や、リクエストごとに処理時間が大きく異なる場合に有効です。
• スティッキーセッション (Sticky Sessions): 特定のユーザーからのリクエストを、一定時間同じサーバーに固定して送信する機能です。サーバー側でセッション情報を保持している（ステートフルな）アプリケーションで必要となります。

具体的な構成例と数値スペック

例えば、最新の Amazon EC2 m7g.large インスタンス（AWS Graviton3プロセッサ搭載）を3台使用し、その前段にALBを配置した構成を考えます。

• CPU/メモリ構成: 各インスタンスは 2 vCPUs、8GB RAM を搭載しています。
• ネットワーク帯域: m7gシリーズは最大 12.5 Gbps のネットワーク帯域をサポートしており、高速なデータ転送が可能です。
• 処理フロー:
  1. ユーザーが https://example.com (ポート 443) にアクセス。
  2. ALBがリクエストを受信し、SSL終端（TLS復号化）を実施。
  3. ALBがヘルスチェック済みの3台のインスタンスへ、ラウンドロビンでリクエストを分散。
  4. 各インスタンスは ARM64 アーキテクチャの効率的な処理を行い、レスポンスを返却。
  5. ALBがそれをまとめ、ユーザーに返信。

このような構成により、1台のサーバーが故障しても、残り2台でトラフィックを処理し続けることができ、可用性が大幅に向上します。

インフラ構成におけるパフォーマンス最適化とコスト管理

ELBを導入する際は、単に設置するだけでなく、コストとパフォーマンスの最適化（チューニング）が不可欠です。

LCU (Load Balancer Capacity Units) による課金

ELBのコストは、単純な時間料金だけでなく「LCU」という指標で計算されます。LCUは以下の4つの次元のうち、最も高い値に基づいて算出されます。

1. 新しい接続数: 秒あたりの新規接続数。
2. アクティブ接続数: 同時に維持されている接続数。
3. 処理されたデータ量: GB単位のデータ転送量。
4. ルール評価数: ALBにおけるルーティングルールの数。

例えば、1LCUあたりの料金が時間あたり約 $0.0225 (日本円で約3〜4円) と設定されている場合、大量のトラフィックを捌くサイトでは、このLCUコストが月額で数万円から数十万円に達することもあります。

パフォーマンス向上のためのチェックリスト

効率的なロードバランシングを実現するために、以下のポイントを検討してください。

• タイムアウト設定の最適化: デフォルトのアイドルタイムアウトは 60秒 ですが、長時間かかる処理がある場合はこれを延長し、逆に高速なレスポンスを求める場合は短く設定してリソースを解放させます。
• SSL/TLSのオフロード: ALBでSSL証明書を管理し、復号処理をALB側に任せることで、背後のEC2インスタンスのCPU負荷（暗号化処理）を軽減できます。
• リージョン間転送の削減: データ転送量（GB）に応じて課金されるため、可能な限り同じアベイラビリティゾーン (AZ) 内で通信を完結させる設計がコスト削減に繋がります。
• 接続維持の最適化: Keep-Aliveを有効にし、TCPハンドシェイクの回数を減らすことで、レイテンシを削減します。
• ターゲットグループの分散: 異なるAZにインスタンスを分散配置し、データセンターレベルの障害に備えます。
• CPUアーキテクチャの選択: x86_64ではなく、電力効率とコストパフォーマンスに優れた AWS Graviton3 等のARMベースインスタンスを採用することで、同一コストでより高いスループットを得られます。
• オートスケーリングの閾値設定: CPU使用率が 70% を超えたらインスタンスを増やす、といった適切なトリガーを設定します。
• キャッシュ戦略の導入: ELBの前段にAmazon CloudFrontなどのCDNを配置し、静的コンテンツをキャッシュさせることで、ELBに到達するリクエスト数自体を削減します。

2025年〜2026年に向けたクラウド・ロードバランシングの展望

クラウドインフラの世界は極めて進化が速く、2025年、そして2026年に向けてロードバランシング技術はさらなる変革期を迎えています。

AI駆動型トラフィック管理 (AI-Driven Traffic Management)

次世代のロードバランサーでは、静的なルールベースの振り分けではなく、機械学習を用いた「予測的スケーリング」と「インテリジェントルーティング」が主流になると予想されます。 例えば、過去のトラフィックパターンから「15分後にアクセスが急増する」ことをAIが予測し、負荷が上がる前にあらかじめインスタンスを起動させ、ELBのキャパシティを拡張しておく仕組みです。これにより、急激なスパイクによる一時的なレスポンス低下を完全にゼロに近づけることが可能になります。

ゼロトラスト・アーキテクチャへの完全統合

従来のロードバランサーは「境界線」として機能していましたが、今後は「Identity-Aware Proxy」としての機能が強化されます。 2025年以降の最新トレンドでは、ELBレベルでユーザーの認証・認可を詳細に制御し、正当な権限を持つリクエストのみをバックエンドに到達させる「ゼロトラスト」の考え方が標準実装されます。これにより、個別のアプリケーションサーバーで認証処理を実装する手間が省け、セキュリティレベルを均一に引き上げることができます。

サーバーレス・コンピューティングとの深化

AWS FargateやLambdaなどのサーバーレス環境との統合がさらに深化します。 従来の「サーバー（インスタンス）」という概念を意識せず、リクエストが届いた瞬間にコンテナが起動し、ELBがそれを即座に認識してルーティングする「超高速コールドスタート」の実現が期待されています。これにより、インフラ管理コストを極限まで削減し、開発者はコードの記述だけに集中できる環境が整備されるでしょう。

FAQ

Q1: ALBとNLBのどちらを選ぶべきか迷っています。判断基準は何ですか？

A1: 最もシンプルな判断基準は「レイヤー」と「要件」です。

• ALBを選ぶべきケース: HTTP/HTTPS通信であり、URLのパス（/api など）によって振り分け先を変えたい場合や、Webアプリケーションの柔軟な制御が必要な場合です。
• NLBを選ぶべきケース: TCP/UDP通信である場合、または「1ms未満の超低遅延」が必要な場合、あるいは「固定のIPアドレス」を外部に公開する必要がある場合に最適です。

Q2: ELBを導入しても、背後のサーバーが1台だけだと意味がないのでしょうか？

A2: 技術的には動作しますが、可用性の観点からは意味が薄くなります。ELBの最大のメリットは「冗長化」です。サーバーが1台だけでは、そのサーバーがダウンした瞬間にサービスが停止するため、ELBがあっても救えません。最低でも2台以上のインスタンスを異なるアベイラビリティゾーンに配置することを強く推奨します。

Q3: ELBのコストを抑えるための最も効果的な方法は？

A3: まずは「不要なLCU消費」を特定することです。特に、頻繁すぎるヘルスチェックの間隔や、不必要な大量のルーティングルールはコストを押し上げる要因になります。また、前段にCloudFrontなどのCDNを導入して、ELBに届くリクエスト数（特に静的ファイルへのリクエスト）を削減することが、最も劇的なコスト削減に繋がります。さらに、バックエンドにGravitonベースのインスタンスを採用することで、コンピューティングコスト全体の最適化を図ってください。