AWS ELBとは？ロードバランサーの基本概念とメリットを解説

Elastic Load Balancing（ELB）の基本概念と役割

「サイトへのアクセスが急増して、サーバーが重くなってしまった……」 エンジニアとして運用を続けていると、一度は直面するかもしれない悩みですよね。そんな時に、システムの安定性を守る強力な助っ人となってくれるのが Elastic Load Balancing（ELB）です。

今回は、初心者の方に向けて「そもそもロードバランサーって何をしているの？」という基本から、AWSが提供するELBの魅力まで、噛み砕いてお話ししていきます。

ロードバランサーの基本的な仕組み

ロードバランサーを一言で表すなら、「リクエストを受け取る、優秀な受付窓口」です。

通常、ユーザー（クライアント）がWebサイトを見ようとすると、そのリクエストはサーバーへ直接届けられます。しかし、サーバーが1台しかない場合、そこにアクセスが集中すると処理能力を超えてしまい、サイトの表示が遅くなったり、最悪の場合はダウンしてしまったりします。

そこでロードバランサーの出番です。ロードバランサーはクライアントと複数のサーバーの「中間」に立ちます。ユーザーからのリクエストを一度すべてロードバランサーが受け取り、その後、後ろに控えている複数のサーバーへ「今はAさんが空いているから、Aさんに送ろう」「次はBさんにお願いしよう」といった具合に、交通整理をして振り分けていきます。

この仕組みには、主に2つの大きなメリットがあります。

1. 負荷の分散: 特定のサーバーだけに仕事が集中するのを防ぎ、システム全体のパフォーマンスを維持します。
2. 可用性の向上: もしサーバーの1台が故障しても、ロードバランサーはそれを検知して、元気な他のサーバーにだけリクエストを送り続けることができます。

AWSにおけるマネージドサービスとしての利点

AWSでELBを利用する最大のメリットは、それが「マネージドサービス」であるという点です。

「マネージドサービス」とは、簡単に言うと「インフラの面倒な管理をクラウド側（AWS）が肩代わりしてくれるサービス」のこと。自分でロードバランサー専用の機材を用意したり、OSのアップデート作業に追われたりする必要はありません。

具体的には、以下のような恩恵を受けることができます。

• 自動的なスケーリング: アクセス数が少ないときは最小限のリソースで動き、キャンペーンなどでアクセスが爆発的に増えたときには、AWSが自動的にロードバランサー自体の処理能力を拡張（スケールアップ・アウト）してくれます。
• 運用の手間を削減: ロードバランサー自体のメンテナンスやパッチ適用はすべてAWS側が行います。私たちは「どのサーバーに振り分けるか」という設定に集中できるのです。

なお、以前は「Classic Load Balancer (CLB)」という旧世代の仕組みもありましたが、現在はより高機能な現行世代（ALB, NLB, GWLB）を使うことが推奨されています。これから学習・導入する場合は、新しいタイプを中心に見ていきましょう。

ELBが解決するシステム課題と導入メリット

「サーバーを1台用意して、そこに全てのアクセスを集める」という構成は、小規模なテスト環境なら問題ありません。しかし、サービスが成長してユーザーが増えてきたとき、その構成は非常に脆いものになります。

ELB（Elastic Load Balancing）を導入する最大の理由は、単に「負荷を分散させる」ことだけではありません。システムが抱える構造的な弱点を克服し、より強固で効率的なインフラへと進化させることに真の価値があります。ここでは、ELBが具体的にどのような課題を解決してくれるのか、2つの重要な側面から掘り下げてみましょう。

単一障害点を排除し可用性を高める考え方

システム設計において最も避けなければならないのが、「単一障害点（SPOF: Single Point of Failure）」です。これは、「そこが壊れたらシステム全体が止まってしまう箇所」を指します。もしサーバーが1台しかなければ、そのサーバーの故障やOSの不具合が起きた瞬間に、サービスは完全に停止してしまいます。

ELBを使うと、この問題を「可用性（Availability）」を高める設計によって解決できます。

具体的には、サーバーを複数のアベイラビリティーゾーン（AZ）に分散して配置します。AZとは、AWSが提供する物理的に離れたデータセンター群のことです。ELBは、これらの異なるAZにまたがる複数のサーバーへトラフィックを自動的に振り分けます。

これにより、以下のような事態が起きてもシステムを守ることができます。

• 特定のサーバーが故障した： ELBがそれを検知し、正常な別のサーバーへリクエストを流し続ける。
• 一つのデータセンター（AZ）が停電などで停止した： 別のAZで稼働しているサーバー群へ通信を切り替える。

暗号化・復号処理のオフロード（SSL/TLS終端）

現代のWebサービスにおいて、通信の暗号化（HTTPS通信）は必須です。しかし、この「暗号化」と「復号（鍵を使って元のデータに戻す作業）」には、実は意外と多くの計算リソースが必要になります。

もし、背後にあるアプリケーションサーバーが自前でこの処理を行っていると、本来やりたいはずの「ビジネスロジックの実行（データの保存や計算など）」に使うべきCPUパワーを、暗号化処理に削られてしまうことになります。

ここで登場するのが、ELBによる「SSL/TLS終端（オフロード）」という仕組みです。

これは、クライアントとの複雑な暗号化通信のやり取りをすべてELBが肩代わりし、サーバーに届く直前で復号してあげる仕組みのことです。イメージとしては、重い荷物（暗号化データ）を玄関（ELB）で開けて、中身だけを軽くして奥の部屋（サーバー）へ運んであげるようなものです。

この恩恵を受けることで、バックエンドのサーバーは以下のようなメリットを得られます：

1. CPU負荷の軽減： 重い暗号化計算から解放され、アプリケーションの処理にリソースを100%集中できる。
2. 証明書管理の一元化： SSL証明書を各サーバーに配る必要がなく、ELBに設定するだけで済むため、運用が劇的に楽になる。

現行世代のロードバランサーの種類と使い分け

ここまでで、ロードバランサーが「交通整理」の役割を担うことを見てきました。しかし、いざAWSで構築しようとすると、「ALB」「NLB」「GWLB」といった複数の選択肢が出てきて、「結局どれを選べばいいの？」と迷ってしまうことも多いはずです。

実は、これらはそれぞれ得意とする「通信の種類（レイヤー）」が全く異なります。ネットワークの世界には、データのやり取りを階層化したOSI参照モデルという考え方があります。この階層のどこで判断を行うかによって、ロードバランサーの性格が決まります。

ここでは、現在主流となっている3つのタイプについて、その特徴と「どんな時に使うべきか」を分かりやすく整理していきましょう。

Application Load Balancer (ALB) の特徴とユースケース

Application Load Balancer（ALB）は、OSI参照モデルの第7層であるアプリケーション層で動作する、最も汎用的なロードバランサーです。

「アプリケーション層」で動くということは、通信の中身（HTTPリクエストの内容など）を詳しく見て判断ができる、ということです。例えば、「URLのパスが /api で始まるものはAPIサーバーへ」「/images なら画像専用サーバーへ」といった、非常に高度で柔軟な振り分け（ルーティング）が可能です。

ALBが最適なケース

• WebアプリケーションやREST APIの構築: URLの構造に基づいてリクエストを振り分けたい場合。
• マイクロサービスアーキテクチャ: サービスごとに異なるコンテナやインスタンスへ通信を流したい場合。
• 高度な機能が必要な時: HTTP/2 や WebSocket、gRPC といったモダンなプロトコルを利用する場合。

一般的なWebサイトやスマホアプリのバックエンドを作るのであれば、まずはALBを検討するのが「正解」と言えるほど、現在の開発では標準的な選択肢です。

Network Load Balancer (NLB) の特徴とユースケース

一方で、Network Load Balancer（NLB）は、第4層のトランスポート層で動作します。

ALBが「通信の中身（URLなど）」を読み取るのに対し、NLBはもっと低レイヤーな「IPアドレスやポート番号」といった情報だけで判断を行います。中身を深く読み取らない分、処理スピードが圧倒的に速く、非常に高いスループット（単位時間あたりのデータ転送量）を実現できるのが強みです。

NLBが最適なケース

• 超低レイテンシー（低遅延）が求められる通信: リアルタイム性が重要なオンラインゲームや金融取引システムなど。
• 大量の同時接続が発生する場合: 数百万件規模のコネクションを高速にさばく必要がある時。
• 固定IPアドレスが必要な場合: ALBはIPアドレスが変わることがありますが、NLBは静的な（変わらない）IPアドレスを割り当てることができます。クライアント側で接続先をIP指定しなければならないような特殊な環境では、NLBが不可欠です。

Gateway Load Balancer (GWLB) の特徴とユースケース

最後に紹介するのが、少し特殊な役割を持つGateway Load Balancer（GWLB）です。これは第3層のネットワーク層で動作します。

これまでのALBやNLBが「リクエストをどこに送るか」を決めるものだったのに対し、GWLBは「通信を一度特定の装置に通してから目的地へ届ける」という、いわば検問所（セキュリティゲート）のような役割を果たします。

GWLBが最適なケース

• サードパーティ製セキュリティ機器の導入: ファイアウォールや侵入検知システム（IDS/IPS）などのネットワークアプライアンスを、クラウド上でスケーラブルに運用したい場合。

通常、こうしたセキュリティ装置は「通信の流れの中に無理やり割り込ませる」のが非常に大変なのですが、GWLBを使うことで、トラフィックを透過的（ユーザーからは意識させない形）にセキュリティ層へ流し込み、検査が終わったものだけを目的地へ届ける、という高度な構成が簡単に実現できます。

トラフィックの振り分け先を管理する考え方

ここまでで、ELBが「窓口」として機能することを見てきました。では、その窓口に届いたリクエストを、具体的にどのようにして背後のサーバーへと送り届けているのでしょうか？

実は、ロードバランサーは単に「バラバラに送る」のではなく、非常に整理されたルールに基づいて動いています。ここでは、ELBの設計において最も重要な2つの概念、「ターゲットグループ」と「リスナーとルール」についてお話しします。

ターゲットグループの役割とルーティングの単位

まず理解しておきたいのが、ターゲットグループ（Target Group）という仕組みです。これは、簡単に言うと「リクエストを転送する先の集合体」のことです。

ロードバランサーは、個々のサーバー（EC2インスタンスなど）をバラバラに管理するのではなく、まずこの「グループ」という単位で管理します。例えば、「Webサイト用サーバーのグループ」や「画像処理専用コンテナのグループ」といった具合です。

ターゲットグループに登録できるものには、以下のような種類があります。

• EC2 インスタンス：仮想サーバーそのもの
• コンテナ：ECSなどのコンテナサービスで動いているアプリケーション
• IP アドレス：特定のネットワークアドレスを持つリソース

リスナーとルールによる柔軟なルーティング設定

次に、リクエストが届いたときに「どのグループに送るか」を決める仕組みについて見ていきましょう。ここで登場するのが、リスナー（Listener）とルール（Rule）です。

リスナー：接続の待ち受け窓口

リスナーは、ロードバランサーが「どのポート番号で、どんな通信を待っているか」を定義するものです。例えば、「HTTPS（ポート443）でのアクセスを待ち受ける」といった設定がこれに当たります。クライアントからのリクエストがこのリスナーに到達したとき、初めて「次にどうするか」という判断が始まります。

ルール：高度な振り分けの条件

リスナーに届いたリクエストに対して、「もし〜だったら、このターゲットグループへ送る」という条件付けを行うのがルールです。特にApplication Load Balancer (ALB) を使うと、このルールによって非常に柔軟な運用が可能になります。

具体的には、以下のような条件（パスやホスト名）で振り分け先を変えることができます。

• パスベースのルーティング: example.com/api/* へのアクセスは「APIサーバーグループ」へ example.com/images/* へのアクセスは「ストレージサーバーグループ」へ
• ホストベースのルーティング: admin.example.com へのアクセスは「管理用サーバーグループ」へ

このように、「リスナー」で入り口を決め、「ルール」で中身を判別し、「ターゲットグループ」へ届ける。この3つの要素を組み合わせることで、複雑なWebアプリケーションのトラフィックもスマートに制御できるのです。

正常なリソースへのみ通信を届けるヘルスチェック

ロードバランサーが「トラフィックを効率よく振り分ける」役割を持っていることは、これまでのセクションでお話ししてきました。しかし、もし振り分け先のサーバーが故障していたらどうなるでしょうか？ 壊れたサーバーにリクエストを送り続けてしまうと、ユーザーにはエラー画面が表示され、システムの信頼性はガタ落ちしてしまいます。

そこで重要になるのがヘルスチェックです。ロードバランサーは単にリクエストを流すだけでなく、「後ろにいるサーバーたちは元気に動いているかな？」と常に確認を行っています。この仕組みがあるからこそ、ELBは高い可用性を維持できるのです。

ヘルスチェックがシステムの安定性を担保する仕組み

ヘルスチェックの基本的な動きは、ロードバランサーがターゲット（EC2インスタンスやコンテナなど）に対して、定期的に「生存確認」のための通信を行うことです。

具体的には、以下のようなプロセスで動作します。

1. 定期的な問い合わせ: ロードバランサーが設定された間隔（例：30秒ごと）で、ターゲットに対して特定のパス（例：/health）へリクエストを送ります。
2. 応答の判定: ターゲットから「HTTP 200 OK」のような正常なレスポンスが返ってくれば、「健康」と判断します。逆に、タイムアウトしたりエラーが返ってきたりした場合は、「異常」とみなされます。
3. ルーティングの切り替え: あるターゲットが「異常」と判定されると、ロードバランサーはそのターゲットへの通信を即座にストップし、正常なターゲットのみにリクエストを振り分けるように変更します。

アクティブとパッシブのヘルスチェックの違い

「定期的に確認する」という仕組みは理解できたと思いますが、実はそれ以外にも異常を検知する方法があります。ここで登場するのが、アクティブとパッシブという2つの考え方です。

アクティブヘルスチェック

先ほど説明した、ロードバランサー側から能動的に「生きてる？」と聞きに行く方法がこれです。ALB（Application Load Balancer）などが主にこの方式で動作します。あらかじめ決まったルールに基づいて定期実行されるため、予測可能で安定した運用ができるのがメリットです。

パッシブヘルスチェック

一方で、パッシブヘルスチェックは「実際のユーザー通信」を通じて異常を検知する方法です。ロードバランサーがユーザーのリクエストをターゲットに転送した際、その通信が失敗したり、接続が強制終了されたりしたことを察知して、「あ、このサーバーは今ダメなんだな」と判断します。

特にNLB（Network Load Balancer）では、このパッシブな検知が非常に強力に働きます。アクティブな確認を待たずとも、実際の通信エラーから即座に異常を察知できるため、より高速に障害のあるターゲットを切り離すことが可能です。

このように、複数の検知手段を組み合わせることで、ELBは「壊れたサーバーには絶対にリクエストを送らない」という鉄壁の守りを実現しているのです。

システム要件に合わせたELBの設計と運用機能

ここまで、ELBがどのような役割を持ち、種類によってどう使い分けるのかを見てきました。しかし、実際にシステムを構築する場面では、「ただトラフィックを振り分ける」だけでは不十分なことが多々あります。

「特定のユーザー体験を損なわないためにはどうすればいいか？」「サーバーの台数が変動しても、常に最適な状態で運用するには？」といった、より実務的な課題に直面します。ここでは、システムの要件に応じて活用すべき、ELBの強力な運用機能について深掘りしていきましょう。

クロスゾーン負荷分散によるAZ間のトラフィック均等化

AWSの設計において、可用性を高めるために複数のアベイラビリティーゾーン（AZ）を利用するのは鉄則です。しかし、単に複数のAZにサーバーを配置しただけでは、実は「トラフィックの偏り」という新たな問題が発生することがあります。

例えば、AZ-Aにはサーバーが4台、AZ-Bには2台ある構成を考えてみましょう。デフォルトの設定（クロスゾーン負荷分散が無効な状態）では、ロードバランサーは各AZに届いたリクエストを、そのAZ内にあるサーバーだけに振り分けます。すると、サーバーが少ないAZ-Bのサーバーは、AZ-Aのサーバーよりも多くの負荷を受け取ってしまう可能性があるのです。

これを解決するのがクロスゾーン負荷分散です。

この機能を有効にすると、ロードバランサーはAZの境界を越えて、すべてのAZにある「正常なターゲット」全体に対してリクエストを均等に分散させます。上記の例であれば、合計6台のサーバーに対して、どのAZから来たリクエストであっても均等に振り分けてくれます。サーバーの台数が各AZで異なる場合や、特定のAZに負荷が偏るのを防ぎたい場合は、この機能を有効にすることを検討しましょう。ただし、AZ間での通信が発生するため、わずかながらネットワークコストやレイテンシーに影響が出る場合があります。

スティッキーセッションによるユーザー状態の維持

Webアプリケーションを運用していると、「ログイン状態を維持したい」という要件によく遭遇します。これを実現する方法にはいくつかありますが、サーバー側で「セッション情報（誰がログインしているかなどのデータ）」を管理している場合、ロードバランサーの振り分けルールが仇となることがあります。

通常、ロードバランサーはリクエストごとに最適なサーバーへバラバラに振り分けます。しかし、1回目のリクエストで「サーバーA」に送られ、セッション情報がそこに保存されたとします。次にユーザーが操作した際、ロードバランサーが別の「サーバーB」へリクエストを飛ばしてしまうと、サーバーBは「このユーザーが誰なのか」を知らないため、ログアウト扱いになってしまうのです。

この問題を解決するのがスティッキーセッション（Sticky Sessions）です。

これは、クライアント（ユーザー）からの最初のリクエストに基づいて、その後のリクエストも継続して同じバックエンドサーバーへルーティングし続ける仕組みです。ELBはCookieを使用して「このユーザーはサーバーA担当」といった情報を記録し、ユーザー体験をスムーズに維持します。

Auto Scalingとの連携による自動的なキャパシティ管理

現代のクラウド運用において、アクセス数の増減に合わせてサーバーの台数を自動調整することは必須と言えます。ここで登場するのがAuto Scalingです。

ELBとAuto Scalingを組み合わせることで、非常にシームレスな負荷分散が可能になります。仕組みはとてもシンプルで、以下のような流れになります。

1. 負荷の検知: CPU使用率などが上昇し、システムのキャパシティが足りなくなると判断されます。
2. サーバーの追加: Auto Scalingが新しいEC2インスタンスを起動します。
3. 自動登録: 新しく起動したインスタンスは、設定に基づいて自動的にELBの「ターゲットグループ」に組み込まれます。
4. トラフィックの開始: ターゲットグループに登録され、ヘルスチェックをパスした瞬間から、ロードバランサーは新しいサーバーへリクエストを流し始めます。

逆に、アクセスが減ってサーバーが余ってきたときは、Auto Scalingがインスタンスを削除します。このとき、ELBは「今まさに通信中の接続」がある場合は、その通信が終わるまで新しい振り分けを行わないように制御してくれます（Connection Draining機能）。

まとめ

今回は、AWSにおけるElastic Load Balancing（ELB）の基本概念から、種類ごとの使い分け、実務的な運用機能までを解説しました。

ELBは、単に「トラフィックを振り分ける」だけでなく、システムの単一障害点（SPOF）を排除し、可用性とパフォーマンスを劇的に向上させるための不可欠な存在です。ALB、NLB、GWLBといった各ロードバランサーの特徴を理解し、用途に合わせて適切に選択することが、質の高いインフラ設計の第一歩となります。

また、ヘルスチェックによる監視や、Auto Scalingとの連携による自動キャパシティ管理を組み合わせることで、障害に強くスケーラブルなシステムを構築できます。