図解でわかるAWSロードバランサ！基本の「キ」とメリット

ウェブサイトやアプリケーションをインターネット上に公開する際、多くのユーザーからのアクセスにどう対応するかは、システムの安定稼働やユーザー体験において非常に重要な課題です。特に、突然のアクセス増加や特定のサーバーへの負荷集中は、サービスの停止や応答速度の低下を引き起こし、ビジネスに大きな影響を与えかねません。

この記事では、こうした課題を解決するために不可欠な技術である「ロードバランサ」に焦点を当てます。そして、クラウドコンピューティングのリーディングカンパニーであるAmazon Web Services（AWS）が提供する「AWSロードバランサ」（Elastic Load Balancing: ELB）について、その基本から種類、仕組み、そして導入することで得られる数々のメリットを、図解イメージを交えながら徹底的に解説します。

AWSロードバランサについて「基本のキ」からしっかり理解し、あなたのシステムをより堅牢で、より多くのトラフィックに対応できるものにするための第一歩を踏み出しましょう。

1. なぜロードバランサが必要なのか？システムの課題と解決策

現代のウェブサービスやアプリケーションは、想定外のアクセス集中や、常に安定したサービス提供が求められます。もし、あなたのサービスがたった1台のサーバーで運用されていたら、どんな問題が起きるでしょうか？

1-1. ロードバランサがない場合の問題点

想像してみてください。あなたが運営する人気ウェブサイトが、テレビ番組で紹介されたり、SNSでバズったりして、突然大量のアクセスが集中したとします。

[図1: ロードバランサがない場合のイメージ]
– ユーザーからのアクセスは、すべて1台のサーバーに直接向かいます。
– このサーバーは、処理できる能力に限界があります。
– アクセス数がサーバーの処理能力を超えると、どうなるでしょうか？

問題点1：応答速度の低下、最悪サービス停止
サーバーは許容量以上のリクエストを受け付けられず、処理に時間がかかるようになります。ユーザーからは「ページがなかなか表示されない」「エラーになる」といったクレームが増え、最終的にはサーバーがダウンしてしまう可能性もあります。これはビジネス機会の損失に直結します。

問題点2：シングルポイント障害 (Single Point of Failure)
サーバーが1台しかない場合、そのサーバー自体に何らかの障害（ハードウェア故障、ソフトウェアエラー、ネットワークの問題など）が発生すると、サービス全体が停止してしまいます。これはシステムの「可用性」が低い状態です。

問題点3：メンテナンス時のサービス停止
サーバーのOSアップデートやアプリケーションのデプロイなど、メンテナンス作業が必要になった場合、サービスを一時的に停止せざるを得なくなります。ユーザーにとっては、いつ利用できなくなるか分からない不安定なサービスに見えてしまいます。

こうした問題を解決するためには、単一のサーバーに依存せず、複数のサーバーでシステムを構築し、それらのサーバーにうまく仕事を分散させる仕組みが必要です。そこで登場するのが「ロードバランサ」です。

1-2. ロードバランサがある場合の解決策

ロードバランサは、ユーザーからのアクセス要求を受け付け、背後に控える複数のサーバー（ウェブサーバー、アプリケーションサーバーなど）の中から、適切だと判断したサーバーにその要求を振り分ける（負荷分散する）役割を担います。

[図2: ロードバランサがある場合のイメージ]
– ユーザーからのアクセスは、まずロードバランサに向かいます。
– ロードバランサは、受け取ったアクセスを複数のサーバー（サーバーA, サーバーB, サーバーC…）に分散させて振り分けます。
– 各サーバーは分散されたアクセスを処理し、ロードバランサを経由してユーザーに応答を返します。

この仕組みにより、ロードバランサがない場合の様々な問題点が解決されます。

解決策1：負荷分散による安定稼働
アクセスが集中しても、ロードバランサが複数のサーバーに負荷を分散させるため、1台あたりの処理負荷が軽減されます。これにより、応答速度の低下を防ぎ、サーバーがダウンするリスクを大幅に低減できます。

解決策2：高可用性の実現
ロードバランサは、背後のサーバー群を常に監視しています（これを「ヘルスチェック」と呼びます）。もし、特定のサーバーに障害が発生したり応答がなくなったりした場合、ロードバランサはその異常なサーバーへのトラフィックの振り分けを自動的に停止し、正常なサーバーのみにアクセスを誘導します。これにより、一部のサーバーがダウンしてもサービス全体は停止せず、ユーザーは引き続きサービスを利用できます。

解決策3：スケーラビリティの確保
アクセスが増加して現在のサーバー数では処理しきれなくなりそうな場合、サーバーの台数を増やすことで、ロードバランサが自動的に増設されたサーバーにもトラフィックを分散させるようになります。これにより、サービスの規模を柔軟に拡大（スケールアウト）させることができます。

解決策4：メンテナンス中の無停止運用
メンテナンスが必要なサーバーがある場合、ロードバランサの設定を変更して、そのサーバーへのトラフィックを一時的に停止させることができます。メンテナンス完了後に、再びトラフィックを流すように設定を戻します。これにより、他の正常なサーバーが処理を続けるため、サービスを停止することなくメンテナンスを行うことが可能です（ローリングアップデートなど）。

このように、ロードバランサは現代のシステムにおいて、高負荷への対応、可用性の向上、そして運用効率の向上を実現するために不可欠な要素と言えます。

2. ロードバランサの「基本のキ」：仕組みをもっと詳しく

ロードバランサがどのようにしてこれらの役割を果たしているのか、その基本的な仕組みを図解イメージでさらに掘り下げてみましょう。

2-1. 基本的なトラフィックの流れと振り分け

ユーザーがウェブサイトにアクセスする際の、ロードバランサを介した基本的な流れは以下の通りです。

[図3: ロードバランサの基本的なトラフィックフロー]
1. ユーザーからのリクエスト: ユーザーがブラウザなどでロードバランサのDNS名やIPアドレスにアクセスします。
2. ロードバランサの受け付け: ロードバランサがこのリクエストを受け付けます。ロードバランサは、特定のポート（例: HTTPの80番、HTTPSの443番）でユーザーからの接続を待ち受けています。この待ち受けポートのことを「リスナー」と呼びます。
3. ターゲットサーバーの選択: ロードバランサは、設定されたルール（後述）や負荷分散アルゴリズムに基づいて、リクエストを処理するのに最適な「ターゲットサーバー」を複数の中から1台選択します。ターゲットサーバーは、EC2インスタンスやコンテナ、IPアドレスなど、様々な形式でロードバランサの配下に登録されます。これらのターゲットをまとめたグループを「ターゲットグループ」と呼びます。
4. リクエストの転送: ロードバランサは、選択したターゲットサーバーにユーザーからのリクエストを転送します。
5. ターゲットサーバーの応答: ターゲットサーバーはリクエストを処理し、ロードバランサに応答を返します。
6. ロードバランサの応答転送: ロードバランサは、ターゲットサーバーからの応答をユーザーに転送します。

2-2. トラフィックの振り分け方：負荷分散アルゴリズム

ロードバランサがターゲットサーバーを選択する際、どのように振り分けるかを決定するのが「負荷分散アルゴリズム」です。代表的なアルゴリズムをいくつか紹介します。

ラウンドロビン (Round Robin):
- リクエストを順番にターゲットサーバーに均等に振り分ける最もシンプルな方法です。
- [図4: ラウンドロビンアルゴリズムのイメージ]
  - リクエスト1 -> サーバーA
  - リクエスト2 -> サーバーB
  - リクエスト3 -> サーバーC
  - リクエスト4 -> サーバーA …
- 各サーバーの処理能力がほぼ同じで、個々のリクエストの処理時間が短い場合に適しています。
最小コネクション (Least Connection):
- その時点でアクティブなコネクション（接続数）が最も少ないターゲットサーバーにリクエストを振り分けます。
- [図5: 最小コネクションアルゴリズムのイメージ]
  - サーバーA: アクティブ接続 5
  - サーバーB: アクティブ接続 3
  - サーバーC: アクティブ接続 7
  - 新しいリクエスト -> サーバーB に振り分け
- 個々のリクエストの処理時間にばらつきがある場合に、より均等に負荷を分散できる傾向があります。
重み付けラウンドロビン/最小コネクション (Weighted Round Robin/Least Connection):
- 各ターゲットサーバーに「重み（Weight）」を設定し、その重みに応じて優先的に振り分ける方法です。
- [図6: 重み付けアルゴリズムのイメージ]
  - サーバーA: 重み 3
  - サーバーB: 重み 1
  - リクエストが4回来たら、3回はサーバーAに、1回はサーバーBに振り分ける、といったイメージ。
- サーバーのスペックが異なる場合や、特定のサーバーへの負荷を意図的に調整したい場合に利用されます。

AWSのロードバランサの種類によって、利用できるアルゴリズムは異なります。ALB (Application Load Balancer) はラウンドロビンと最小未処理リクエスト数、NLB (Network Load Balancer) はフローハッシュ（クライアントIP、ポート、プロトコルなどに基づいて同じターゲットに誘導）といったアルゴリズムを主に利用します。

2-3. サービスの安定稼働に必須：ヘルスチェック

ロードバランサの最も重要な機能の一つが「ヘルスチェック」です。これは、ロードバランサが配下のターゲットサーバーが正常に稼働しているか（「健康」か）を定期的に確認する仕組みです。

[図7: ヘルスチェックの仕組みイメージ]
– ロードバランサは、設定されたプロトコル、ポート、パス（ALBの場合）で、各ターゲットサーバーに定期的にヘルスチェックのリクエストを送ります。
– サーバーが正常に応答を返せば「Healthy」（正常）、設定された回数以上応答がなかったり、エラーを返したりすると「Unhealthy」（異常）と判断します。
– ロードバランサは、Unhealthyと判断されたサーバーへの新しいトラフィックの振り分けを自動的に停止します。
– Unhealthyだったサーバーが再びHealthyになった場合、自動的にトラフィックの振り分けを再開します。

このヘルスチェック機能があることで、障害が発生したサーバーやメンテナンス中のサーバーを自動的に切り離し、サービス全体の可用性を高めることができます。ユーザーは障害が発生していることに気づかず、正常なサーバーがサービスを提供し続けることが可能になります。

ヘルスチェックの設定項目には、チェックするプロトコル（HTTP, HTTPS, TCP）、ポート、リクエストパス（HTTP/Sの場合）、チェック間隔、タイムアウト、正常と判断する閾値、異常と判断する閾値などがあります。これらの設定を適切に行うことで、システムの実際の状態に即した正確なヘルスチェックを実現できます。

2-4. セッション維持の必要性：セッションスティッキー (Sticky Sessions)

多くのウェブアプリケーションでは、ユーザーがログインしている状態や、ショッピングカートに入れた商品情報など、特定のユーザーとサーバー間で状態（セッション）を維持する必要があります。

例えば、ユーザーAがサーバーXでログインセッションを確立したとします。その後のリクエストがロードバランサによって別のサーバーYに振り分けられてしまうと、サーバーYはユーザーAのセッション情報を持っていないため、「ログインされていません」となったり、ショッピングカートが空になったりしてしまいます。

これを防ぐために使われるのが「セッションスティッキー（Sticky Sessions）」または「セッションアフィニティ（Session Affinity）」と呼ばれる機能です。

[図8: セッションスティッキーの仕組みイメージ]
1. ユーザーAが最初のリクエストを送信し、ロードバランサがサーバーXに振り分けます。
2. サーバーXはユーザーAのセッションを開始し、応答の一部として「セッションID」や「セッションを維持するサーバー情報（サーバーXを示すID）」をCookieなどの形でユーザーAに返します。
3. ユーザーAからの後続のリクエストには、このCookie情報が含まれています。
4. ロードバランサは、リクエストに含まれるCookie情報を読み取り、「このユーザーは以前サーバーXに振り分けた」ことを認識します。
5. セッションスティッキーが有効になっている場合、ロードバランサはアルゴリズムによる通常の振り分けを無視して、同じユーザーAからのリクエストを再びサーバーXに振り分けようとします。

これにより、同じユーザーからの一定期間内のリクエストは、常に同じターゲットサーバーで処理されるようになり、セッションを維持した状態での通信が可能になります。

ただし、セッションスティッキーは特定のサーバーに負荷を集中させる可能性があるため、全てのサーバーが均等に負荷を分散されるわけではなくなります。利用シーンやアプリケーションの特性に合わせて、この機能を有効にするか検討が必要です。

3. AWSにおけるロードバランサの種類：ELB (Elastic Load Balancing)

AWSでは、ロードバランサのサービスを「Elastic Load Balancing (ELB)」として提供しています。ELBは、ユーザーのトラフィックを複数のターゲットに自動的に分散させるマネージドサービスです。マネージドサービスであるため、ハードウェアのプロビジョニングやソフトウェアのインストール、パッチ適用といった面倒な管理はAWSが行ってくれます。

ELBにはいくつかの種類があり、それぞれ得意とするトラフィックの種類や機能が異なります。主要なELBの種類は以下の3つです。

Application Load Balancer (ALB)
Network Load Balancer (NLB)
Gateway Load Balancer (GWLB)

かつてはClassic Load Balancer (CLB) も主流でしたが、現在は新規利用が非推奨となっており、特別な理由がない限りALBやNLBを利用することが推奨されています。ここでは、ALB, NLB, GWLBの3つを中心に詳しく見ていきましょう。

3-1. Application Load Balancer (ALB)

ALBは、HTTPおよびHTTPSトラフィックに特化したロードバランサです。OSI参照モデルの第7層（アプリケーション層）で動作します。ウェブアプリケーションやマイクロサービスなど、HTTP/HTTPSプロトコルを利用するサービスに最適です。

ALBの特徴：

HTTP/HTTPSトラフィックに特化: リクエストのURLパスやホストヘッダー、HTTPヘッダー、クエリパラメータなど、HTTPリクエストの内容に基づいた高度なルーティングが可能です。
コンテンツベースのルーティング: 例えば、「/images から始まるパスのリクエストは画像処理用のサーバーグループへ」「/api から始まるパスのリクエストはAPIサーバーグループへ」といった振り分けができます。
ターゲットグループ: 複数のターゲット（EC2インスタンス、IPアドレス、Lambda関数など）をまとめて「ターゲットグループ」として管理します。リスナーからのトラフィックは、ルールに基づいて特定のターゲットグループに転送されます。
リスナーとルール: ロードバランサがトラフィックを待ち受けるポートやプロトコルを定義するのが「リスナー」です。リスナーには「ルール」を設定でき、このルールによって受信したリクエストをどのターゲットグループに転送するかを決定します。デフォルトルールと追加ルールを設定可能です。
- [図9: ALBの構成要素とトラフィックの流れ]
  - ユーザーからのHTTP/HTTPSリクエストはALBに到達します。
  - ALBのリスナー（例: ポート80/443）がリクエストを受け付けます。
  - リスナーに設定されたルールが評価されます（例: 「パスが /api/* ならAPIターゲットグループへ転送」）。
  - ルールにマッチした場合、該当するターゲットグループ（例: APIサーバーのEC2インスタンス群）にリクエストが転送されます。
  - どのルールにもマッチしない場合、デフォルトルールで指定されたターゲットグループに転送されます。
  - ターゲットグループ内のHealthyなターゲットに、設定されたアルゴリズム（ラウンドロビンまたは最小未処理リクエスト数）で負荷分散されます。
SSL/TLS終端: ALBでSSL/TLS通信を終端（復号）させることができます。これにより、バックエンドのサーバーではHTTPで処理を行えるため、サーバー側の負荷を軽減できます。ACM (AWS Certificate Manager) と連携してSSL証明書を簡単に管理できます。
WAF連携: AWS WAF (Web Application Firewall) と連携し、SQLインジェクションやクロスサイトスクリプティング（XSS）などの一般的なウェブ攻撃からアプリケーションを保護できます。
WebSocketとHTTP/2のサポート: リアルタイム通信に利用されるWebSocketや、パフォーマンスが向上したHTTP/2プロトコルをサポートしています。
Lambda関数のターゲット: HTTPリクエストを直接Lambda関数で処理することも可能です。

ALBの利用シーン：

マイクロサービスアーキテクチャ
コンテナベースのアプリケーション（ECS, EKSなど）
複雑なウェブアプリケーション（パスやホストによる振り分けが必要）
サーバーレスアプリケーション（Lambda連携）

ALBは、アプリケーション層での詳細なルーティングやセキュリティ機能が必要な場合に非常に強力な選択肢となります。

3-2. Network Load Balancer (NLB)

NLBは、TCPおよびUDPトラフィックに特化したロードバランサです。OSI参照モデルの第4層（トランスポート層）で動作します。極めて高いパフォーマンスと低遅延、そして静的なIPアドレスが必要な場合に最適です。

NLBの特徴：

TCP/UDPトラフィックに特化: IPアドレスやポート番号といった、ネットワーク層およびトランスポート層の情報に基づいてトラフィックを分散します。HTTP/HTTPSのリクエスト内容を見ることはできません。
超高パフォーマンスと低遅延: NLBは非常に低いレイテンシー（遅延）で、毎秒数百万リクエストを処理できる高いスループットを提供します。これは、アプリケーション層の処理を行わないため、オーバーヘッドが少ないことによります。
静的なIPアドレス: 各アベイラビリティゾーン (AZ) ごとに静的なIPアドレス（Elastic IPアドレスまたはNLBが割り当てるネットワークインターフェイス）をロードバランサに関連付けることができます。これは、クライアント側が固定IPアドレスを指定する必要がある場合に重要です。
クライアントIPアドレスの保持: デフォルト設定では、バックエンドのターゲットサーバーはクライアントのオリジナルのIPアドレスを認識できます。ALBの場合は通常、ロードバランサのIPアドレスが見えます（X-Forwarded-For ヘッダーなどでクライアントIPを伝えますが）。
ターゲットタイプ: EC2インスタンス、IPアドレス、そしてALBをターゲットとして登録できます。ALBをNLBのターゲットにすることで、NLBの静的IP/高性能とALBのアプリケーションルーティング機能を組み合わせるといったことも可能です。
フローベースの分散: 同じクライアントからの同じセッション（同じソースIP、ソースポート、宛先IP、宛先ポート、プロトコルで識別されるフロー）からのパケットは、通常、同じターゲットに転送されます（フローハッシュ）。
ヘルスチェック: TCP、HTTP、HTTPSのヘルスチェックをサポートします。

NLBの利用シーン：

極めて高いスループットや低遅延が要求されるアプリケーション（例: リアルタイムゲーム、高性能コンピューティング）
静的なIPアドレスが必要なレガシーアプリケーションやネットワーク構成
長期的なTCP接続が必要なアプリケーション（例: データベース接続、MQTT通信）
ALBでは対応できないカスタムTCP/UDPプロトコル

NLBは、HTTP/HTTPS以外のプロトコルや、ネットワーク層での純粋な高速負荷分散、そして静的IPが必要な場合に最適な選択肢となります。

3-3. Gateway Load Balancer (GWLB)

GWLBは、ネットワーク仮想アプライアンス（ファイアウォール、侵入検知/防御システム (IDS/IPS)、パケットインスペクションシステムなど）をスケーラブルかつ高可用な方法でデプロイ、管理するために設計されたロードバランサです。OSI参照モデルの第3層（ネットワーク層）と第4層（トランスポート層）で動作します。

GWLBの特徴：

アプライアンスの負荷分散: VPC内で送受信されるネットワークトラフィックを、設定したネットワーク仮想アプライアンス群に透過的に転送し、負荷分散します。
透明なフロー: GWLBはGENEVEプロトコルを使用してトラフィックをカプセル化し、ターゲットアプライアンスに転送します。アプライアンスはパケットを処理・検査した後、再びGWLBに返送し、GWLBがカプセル化を解除して本来の宛先に転送します。このプロセスは通信の送信元と宛先からは見えません（透過的）。
- [図10: GWLBの構成要素とトラフィックの流れ]
  - VPC内のEC2インスタンスAからインターネット上のサーバーへのアウトバウンド通信が発生します。
  - VPCのルートテーブル設定により、このトラフィックはGWLBエンドポイントに転送されます。
  - GWLBエンドポイントはトラフィックをGWLBに送ります。
  - GWLBは、トラフィックをGENEVEでカプセル化し、配下のネットワーク仮想アプライアンス（ターゲットグループに登録）のいずれかに転送します。
  - アプライアンスはパケットを検査・処理（許可/拒否など）し、GENEVEでカプセル化してGWLBに返送します。
  - GWLBはカプセル化を解除し、パケットをインターネット上の本来の宛先に転送します。
  - インターネット上のサーバーからのインバウンド応答パケットも、同様にGWLB -> アプライアンス -> GWLB を経由してEC2インスタンスAに到達します。
一貫したフロー: 特定のフロー（同じクライアントとサーバー間の通信）からのすべてのパケットは、常に同じターゲットアプライアンスに転送されます。これは、ステートフルなアプライアンス（ファイアウォールなど、セッション状態を維持する必要があるもの）にとって非常に重要です。
ターゲットタイプ: EC2インスタンスまたはIPアドレスをターゲットとして登録できます。
ヘルスチェック: TCPヘルスチェックをサポートします。

GWLBの利用シーン：

VPCトラフィックの中央集約型インスペクション（ファイアウォール、IPS/IDS、DLPなど）
サードパーティ製のネットワーク仮想アプライアンスのデプロイ
セキュリティポリシーの適用を一箇所に集約したい場合

GWLBは、アプリケーションやネットワークサービス自体ではなく、それを保護したり検査したりするためのネットワーク仮想アプライアンスの前に配置する特殊なロードバランサです。

3-4. どのロードバランサを選べばいい？簡単な比較

特徴/種類	Application Load Balancer (ALB)	Network Load Balancer (NLB)	Gateway Load Balancer (GWLB)
得意なプロトコル	HTTP, HTTPS, WebSocket, HTTP/2	TCP, UDP, TLS	IP (GENEVEカプセル化)
OSI参照モデル層	L7 (アプリケーション層)	L4 (トランスポート層)	L3/L4 (ネットワーク層/トランスポート層)
負荷分散の単位	リクエスト	フロー/接続	フロー (アプライアンス連携用)
パフォーマンス	高い (ALBに最適化)	極めて高い、低遅延	特定のユースケース (アプライアンス連携) に最適化
IPアドレス	可変 (クライアントIPはXFFなどで取得)	静的 (AZごと)、クライアントIPを維持	静的 (AZごと)
ルーティング	コンテンツベース (パス, ホスト, ヘッダーなど)	IPアドレスとポート	GENEVEでカプセル化し、アプライアンスへ
セキュリティ	SSL/TLS終端、WAF連携	SSL/TLS終端 (NLB Listener TLS)、クライアントIP維持	アプライアンス連携によるセキュリティ対策
ターゲットタイプ	EC2, IP, Lambda, ALB (相互参照は不可)	EC2, IP, ALB	EC2, IP
主な利用シーン	Webアプリ、マイクロサービス、コンテナ、サーバーレス	高パフォーマンスDB、ゲーム、カスタムプロトコル、静的IP要求	ネットワーク仮想アプライアンス連携

選び方のヒント:

ウェブサイトやAPI、マイクロサービス: 基本的にはALBを検討しましょう。HTTP/HTTPSの詳細なルーティングやSSL終端、WAF連携が強力です。
極めて高いパフォーマンスや低遅延、静的IPが必要な場合: NLBが適しています。TCP/UDPプロトコルに特化しており、高性能です。
ファイアウォールやIDS/IPSなどのネットワーク仮想アプライアンスをデプロイしたい場合: GWLBがそのための専用ロードバランサです。

もし迷う場合は、まずALBから検討するのが一般的です。

4. AWSロードバランサを導入するメリット

ここまで、ロードバランサの基本とAWSにおける種類を見てきました。これらの知識を踏まえて、AWSロードバランサを導入することで具体的にどのようなメリットが得られるのかをまとめましょう。

4-1. 高可用性 (High Availability) の実現

サービスを常に利用可能な状態に保つ「高可用性」は、オンラインビジネスの根幹を支える要素です。AWSロードバランサは、この高可用性を非常に高いレベルで実現します。

複数アベイラビリティゾーン (AZ) への分散: AWSのAZは、物理的に離れた場所にある独立したデータセンター群です。ロードバランサは、複数のAZにまたがってターゲットサーバー（EC2インスタンスなど）を配置し、それらのAZ全体にトラフィックを分散させることができます。
- [図11: 複数AZへの分散構成イメージ]
  - ロードバランサは、AZ-aとAZ-bの両方にデプロイされ、それぞれが異なるサブネットに配置されます。
  - ターゲットグループに登録されたEC2インスタンスは、AZ-aとAZ-bの複数のインスタンスが含まれます。
  - ユーザーからのトラフィックは、ロードバランサによって両方のAZのターゲットインスタンスに分散されます。
AZ障害からの保護: もし一つのAZで大規模なネットワーク障害や停電などが発生し、そのAZ内のターゲットサーバーが応答しなくなったとしても、ロードバランサはヘルスチェックによって異常を検知し、正常な状態にある別のAZのターゲットサーバーにのみトラフィックを振り向け続けます。これにより、AZ単体の障害がサービス全体の停止につながることを防ぎます。
自動フェイルオーバー: ヘルスチェックと連動した異常なターゲットの自動切り離しは、まさに自動的なフェイルオーバー機能です。手動で切り替え作業を行う必要がなく、迅速に障害から回復できます。
ロードバランサ自体の冗長性: AWSが提供するマネージドサービスであるELBは、AWS基盤内で冗長化されています。ロードバランサ自体が単一障害点となるリスクは極めて低く設計されています。

4-2. スケーラビリティ (Scalability) の確保

トラフィックの増減に合わせて、システムの処理能力を柔軟に拡大・縮小できるのが「スケーラビリティ」です。AWSロードバランサは、このスケーラビリティを容易に実現します。

トラフィック増加への自動対応: ロードバランサ自体は、受信するトラフィック量に応じて自動的にスケールアップ/アウトします。急激なトラフィック増加（フラッシュクラウド）にも、ある程度は自動的に対応できます。
Auto Scalingとの連携: ロードバランサは、AWS Auto Scalingサービスと非常に密接に連携します。
- [図12: ロードバランサとAuto Scalingの連携イメージ]
  - ロードバランサの負荷（処理するリクエスト数や接続数など）や、ターゲットサーバーのCPU使用率などを監視します。
  - 監視メトリクスがあらかじめ設定した閾値を超えた場合（例: CPU使用率が70%を10分間継続）、Auto Scalingグループは新しいEC2インスタンスを自動的に起動します。
  - 起動した新しいインスタンスは、自動的にロードバランサのターゲットグループに登録され、負荷分散の対象となります。
  - 逆に、負荷が低下して閾値を下回った場合は、不要になったインスタンスを自動的に終了させ、コストを最適化します。
- この連携により、アプリケーションの処理能力を需要に応じて自動的に増減させることが可能になり、常に適切なリソースでサービスを提供できます。これにより、ピーク時の性能不足を防ぎつつ、アイドル時のコストを削減できます。

4-3. セキュリティ (Security) の向上

AWSロードバランサは、システムのセキュリティを強化するための様々な機能を提供します。

SSL/TLS終端: ALBやNLBは、クライアントとロードバランサ間の通信をSSL/TLSで暗号化し、ロードバランサでそれを復号する「終端」機能を提供します。
- メリット1: 暗号化/復号処理はCPU負荷が高いため、ロードバランサが行うことでバックエンドのターゲットサーバーの負荷を軽減し、本来のアプリケーション処理に集中させることができます。
- メリット2: SSL証明書の管理をロードバランサ側で行えるため、サーバーごとに証明書を設定・更新する手間が省けます。AWS Certificate Manager (ACM) と連携すれば、証明書のプロビジョニングや更新がさらに容易になります。
- メリット3: ロードバランサで最新のSSL/TLSプロトコルや暗号スイートを設定することで、バックエンドのサーバーが古いプロトコルしかサポートしていなくても、セキュアな通信を提供できます。
WAF連携: ALBは、AWS WAFと連携して、一般的なウェブ攻撃（SQLインジェクション、XSS、不正なボットなど）からアプリケーションを保護できます。ALBの前にWAFを配置することで、悪意のあるトラフィックをバックエンドに到達させる前にブロックできます。
DDoS攻撃対策: AWS Shield Standardは全てのAWS顧客に自動的に適用され、一般的なDDoS攻撃からの保護を提供します。ELBはこのAWS Shield Standardの恩恵を受けます。より高度な保護が必要な場合は、AWS Shield Advancedを利用することで、より大規模で洗練されたDDoS攻撃に対する保護や、可視性、インシデント対応サポートを受けることができます。
セキュリティグループとの連携: ロードバランサ自体や、配下のターゲットサーバーに対してセキュリティグループを設定することで、ネットワークレベルでのアクセス制御をきめ細かく行うことができます。例えば、ロードバランサにはインターネットからのアクセスを許可し、ターゲットサーバーにはロードバランサからのアクセスのみを許可するといった設定が可能です。

4-4. コスト効率 (Cost Efficiency)

AWSロードバランサは従量課金制であり、サービスの利用量に応じた費用が発生します。これは、オンプレミスで高価なロードバランサ専用ハードウェアを導入するのに比べて、初期投資を抑えられるだけでなく、リソースを効率的に利用できるというメリットがあります。

時間課金: ロードバランサの種類に応じて、稼働時間や、処理されたデータ量、新しいコネクション数などに基づいて課金されます。
マネージドサービスの恩恵: ロードバランサの運用管理（ハードウェア保守、OSパッチ、ソフトウェアアップデートなど）は全てAWSが行うため、その分の人件費や運用コストを削減できます。

4-5. 運用負荷の軽減 (Reduced Operational Overhead)

AWSロードバランサが提供する各種機能とマネージドサービスであるという特性は、運用チームの負担を大きく軽減します。

インフラ管理不要: ロードバランサのハードウェア故障対応やOSレベルのメンテナンスはAWSの責任範囲です。運用チームはアプリケーションやビジネスロジックの開発・改善に集中できます。
自動的なスケーリングとフェイルオーバー: 前述の通り、トラフィックの増減やサーバー障害に自動的に対応するため、手動での介入が必要なケースを減らせます。夜間や休日でも安心してサービスを提供できます。
モニタリングとログ: AWS CloudWatchと連携して、ロードバランサのリクエスト数、処理時間、エラー率、ターゲットのヘルス状態などを詳細に監視できます。また、アクセスログをS3バケットやCloudWatch Logsに出力することで、トラフィックの分析やトラブルシューティングが容易になります。これらの情報は、システムのボトルネック特定やキャパシティプランニングにも役立ちます。

これらのメリットを総合すると、AWSロードバランサはシステムの安定性、パフォーマンス、セキュリティを向上させつつ、運用コストと負荷を削減するための非常に強力なツールであることがわかります。

5. ロードバランサの設定例（概念レベル）

実際にAWSでロードバランサを設定する際の、大まかな手順と考慮事項を図解イメージで見ていきましょう。ここでは、最も一般的なALBの設定を例に取ります。

[図13: ALB設定に必要なコンポーネントと手順の概要]
1. VPCとサブネットの準備:
* まず、ロードバランサとターゲットサーバーを配置する仮想ネットワーク（VPC）が必要です。
* 高可用性を実現するために、最低2つ以上の異なるアベイラビリティゾーン (AZ) にサブネットを作成します。ロードバランサは、これらの公開サブネットに配置されます。ターゲットサーバーは、プライベートサブネット（インターネットから直接アクセスできないサブネット）に配置するのが一般的です。
* [図13-1: VPCと複数AZサブネットのイメージ]
2. ターゲットサーバーの準備:
* ALBがトラフィックを転送する対象となるEC2インスタンスなどを準備し、先ほど作成したプライベートサブネットに配置します。これらのインスタンス上で、ウェブサーバーやアプリケーションサーバーを起動しておきます。
* [図13-2: プライベートサブネットに配置されたEC2インスタンスのイメージ]
3. ターゲットグループの作成:
* これらのEC2インスタンスをまとめて一つの「ターゲットグループ」として定義します。
* ターゲットグループでは、負荷分散アルゴリズム（ラウンドロビン/最小未処理リクエスト数）や、ヘルスチェックの設定（プロトコル、ポート、パス、閾値など）を行います。
* 準備したEC2インスタンスを、このターゲットグループに登録します。
* [図13-3: ターゲットグループの作成とインスタンス登録のイメージ]
4. ロードバランサ (ALB) の作成:
* ALBを作成し、そのALBを配置するサブネット（複数AZの公開サブネット）を選択します。
* ALBの種類（ALB）、スキーム（インターネット向けか内部向けか）、IPアドレスタイプなどを設定します。
* [図13-4: ALBの作成と公開サブネットへの配置イメージ]
5. リスナーの設定:
* 作成したALBに「リスナー」を設定します。これは、ALBが受信するプロトコル（HTTP/HTTPS）とポート番号（80/443など）を指定するものです。
* HTTPSリスナーの場合は、SSL証明書を関連付けます（ACMで管理するのが容易です）。
* リスナーには「デフォルトアクション」を設定します。これは、特定のルールにマッチしなかった場合のリクエストを転送するターゲットグループです。通常は、このデフォルトアクションでメインのターゲットグループを指定します。
* [図13-5: リスナーとデフォルトアクションの設定イメージ]
6. ルールの設定（ALBの場合）:
* 必要に応じて、リスナーに追加の「ルール」を設定します。例えば、パスベースルーティングを行う場合、「パスが /api/* の場合は、APIサーバーのターゲットグループに転送する」といったルールを追加します。
* ルールの評価順序も指定できます。
* [図13-6: パスベースルーティングルールの設定イメージ]
7. セキュリティグループの設定:
* ALBには、インターネットからのアクセスを許可するセキュリティグループを設定します（例: HTTP/80, HTTPS/443 を許可）。
* ターゲットサーバー（EC2インスタンス）には、ALBからのアクセスのみを許可するセキュリティグループを設定します（例: ALBのセキュリティグループからのHTTP/80またはアプリケーションポートを許可）。これにより、インターネットからターゲットサーバーへの直接アクセスを防ぎ、セキュリティを高めます。
* [図13-7: セキュリティグループの設定イメージ (ALB用, ターゲット用)]
8. DNSの設定:
* 最後に、独自ドメイン（例: example.com）を使用する場合、DNSサービス（AWS Route 53など）でドメイン名をALBに関連付けます。通常は、ALBのDNS名に対するAliasレコード（またはCNAMEレコード）を作成します。これにより、ユーザーはドメイン名でサービスにアクセスできるようになります。
* [図13-8: DNS設定 (Route 53 Aliasレコード) のイメージ]

これらのステップを経て、ALBは指定されたポートでトラフィックを待ち受け、設定されたルールとアルゴリズムに基づいて、Healthyなターゲットサーバーに負荷を分散するようになります。

6. 応用的なトピック（簡単な紹介）

AWSロードバランサは、他のAWSサービスと連携することで、さらに強力なソリューションを構築できます。

6-1. Auto Scalingとの連携

前述の通り、ロードバランサとAuto Scalingを組み合わせることで、トラフィック量の変動に完全に自動で対応できる、弾力性の高いシステムを構築できます。ロードバランサがトラフィックを分散し、Auto Scalingがその負荷状況に応じてターゲットサーバーの台数を自動調整します。これがクラウドのスケーラビリティの真髄の一つです。

6-2. WAF (Web Application Firewall) との連携

ALBはAWS WAFと連携し、一般的なウェブ攻撃からアプリケーションを保護します。WAFで設定したルール（特定のIPからのアクセスブロック、悪意のある入力パターン検出など）に基づいて、不正なリクエストをロードバランサに到達する前にブロックまたはカウントすることができます。

6-3. AWS Global Acceleratorとの違い

AWS Global Acceleratorは、ユーザーの地理的な位置に基づいて、AWSグローバルネットワークのエッジロケーションへトラフィックを誘導し、そこからAWSネットワークを経由してアプリケーション（ALBやNLBなど）にルーティングするサービスです。ロードバランサは特定のリージョン内のトラフィック分散を担当しますが、Global Acceleratorは世界中のユーザーからのアクセスを最も近いAWSエッジに誘導し、パケットロスや遅延を低減することで、グローバルなパフォーマンスを向上させます。Global Acceleratorの背後にALBやNLBを配置することが一般的です。

6-4. AWS CloudFrontとの違い

AWS CloudFrontはCDN (Contents Delivery Network) サービスです。画像や動画、CSS、JavaScriptなどの静的コンテンツや、動的コンテンツの一部を世界中のエッジロケーションにキャッシュし、ユーザーから地理的に最も近いエッジからコンテンツを配信することで、表示速度を高速化します。CloudFrontは主にコンテンツ配信の最適化が目的であり、サーバーへの負荷分散はロードバランサの役割です。ウェブサイトの構成としては、CloudFrontが静的コンテンツを配信し、動的なリクエストをALBに転送するといった連携がよく見られます。

7. まとめ：AWSロードバランサでシステムを次のレベルへ

この記事では、AWSロードバランサ（ELB）の基本から、その種類、仕組み、そして導入によって得られるメリットについて、図解イメージを交えながら詳細に解説しました。

ロードバランサがない場合の単一障害点や負荷集中といった課題に対し、AWSロードバランサはトラフィックの効率的な分散、ヘルスチェックによる自動復旧、そして複数AZを活用した冗長化によって、高可用性を劇的に向上させます。

また、受信トラフィックやターゲットサーバーの負荷状況に応じて自動的にスケールし、Auto Scalingとの連携により需要に応じた最適なリソース数で運用できるため、スケーラビリティを容易に確保できます。

さらに、SSL/TLS終端、WAF連携、DDoS対策といった機能は、システムのセキュリティを多角的に強化します。

これら全ての機能がマネージドサービスとして提供されることで、ハードウェア管理やパッチ適用といった面倒な作業から解放され、運用チームの運用負荷を軽減しつつ、従量課金制によるコスト効率も実現します。

ALB、NLB、GWLBという異なる特性を持つロードバランサから、あなたのアプリケーションやネットワークの要件に最適なものを選ぶことができます。

AWSロードバランサは、単にサーバーの負荷を分散するだけでなく、システムの信頼性、パフォーマンス、セキュリティ、そして運用効率といった、サービス提供において不可欠な要素を包括的に改善するための強力な基盤となります。

ウェブサイトの応答速度に課題を感じている、突然のアクセス集中が心配、障害発生時の停止時間を最小限に抑えたい、といった悩みを抱えているなら、AWSロードバランサの導入をぜひ検討してください。この記事が、あなたのAWS環境におけるロードバランサ活用の第一歩を踏み出すための手助けとなれば幸いです。

実際のAWS環境で、ALBやNLBの作成手順を試してみることで、さらに理解が深まるでしょう。まずは無料利用枠なども活用しながら、小さく始めてみることをお勧めします。

8. 用語集

記事中で使用した主な用語をまとめました。

ロードバランサ (Load Balancer): サーバー群へのネットワークトラフィックを分散させる装置またはソフトウェア。
Elastic Load Balancing (ELB): AWSが提供するマネージド型のロードバランササービス。ALB, NLB, GWLBなどの種類がある。
Application Load Balancer (ALB): HTTP/HTTPSトラフィックに特化したELB。アプリケーション層で動作し、コンテンツベースのルーティングが可能。
Network Load Balancer (NLB): TCP/UDPトラフィックに特化したELB。トランスポート層で動作し、高パフォーマンスと低遅延が特徴。静的IPアドレスを保持できる。
Gateway Load Balancer (GWLB): ネットワーク仮想アプライアンスとの連携に特化したELB。GENEVEプロトコルでトラフィックをカプセル化・転送する。
Classic Load Balancer (CLB): 従来のELB。現在は新規利用が非推奨。
ターゲット (Target): ロードバランサがトラフィックを転送する対象。EC2インスタンス、IPアドレス、Lambda関数などがある。
ターゲットグループ (Target Group): 同じ種類のターゲット（例えば、同じアプリケーションを実行しているEC2インスタンス群）をまとめたもの。
リスナー (Listener): ロードバランサがクライアントからの接続を待ち受けるプロトコルとポート番号。
ルール (Rule): ALBのリスナーに設定する条件とアクションの組み合わせ。受信リクエストの内容（パス、ホストなど）に基づいて、転送先のターゲットグループを決定する。
負荷分散アルゴリズム: ロードバランサが複数のターゲットの中からリクエストを転送するターゲットを選択する方法（ラウンドロビン、最小コネクションなど）。
ヘルスチェック (Health Check): ロードバランサがターゲットが正常に稼働しているかを確認する仕組み。
Healthy/Unhealthy: ヘルスチェックによってターゲットが正常/異常と判断された状態。
セッションスティッキー (Sticky Sessions) / セッションアフィニティ (Session Affinity): 特定のユーザーからのリクエストを、一定期間同じターゲットサーバーに振り分け続ける機能。
SSL/TLS終端 (SSL/TLS Termination): ロードバランサでSSL/TLS暗号化/復号処理を行うこと。
WAF (Web Application Firewall): ウェブアプリケーションに対する一般的な攻撃（SQLインジェクション、XSSなど）を防御するファイアウォール。ALBと連携できる。
DDoS攻撃 (Distributed Denial of Service Attack): 複数のコンピュータから大量のトラフィックを送り付け、サービスを停止させる攻撃。AWS Shieldなどで対策可能。
アベイラビリティゾーン (AZ): AWSリージョン内の物理的に離れた独立したデータセンター群。
VPC (Virtual Private Cloud): AWSクラウド内に構築する仮想ネットワーク。
サブネット (Subnet): VPCを分割したネットワークの単位。特定のAZに関連付けられる。
セキュリティグループ (Security Group): 仮想ファイアウォールとして、インスタンスレベルでの通信を制御する仕組み。
Auto Scaling: トラフィックの増減に応じてEC2インスタンスなどの数を自動的に増減させるサービス。ELBと連携することで、スケーラビリティの高いシステムを構築できる。
GENEVE (Generic Network Virtualization Encapsulation): GWLBがトラフィックをカプセル化するために使用するプロトコル。