ELB講座

この講座では、AWSのロードバランサーサービスであるELBについて学びます。

• 単一構成の問題点（単一障害点・アクセス集中・メンテナンス）
• ロードバランサーの役割と仕組み
• ELB（Elastic Load Balancing）の種類と特徴
• ターゲットグループとヘルスチェックの設定
• リスナーとルーティングの仕組み
• ELBのセキュリティ設定（AWS Shield・WAF・通信暗号化）

1. 単一構成（シングル構成）の問題点

これまでは、1台のEC2インスタンスで全ての処理を行う方法を解説してきました。しかし、実際のサービス運用では、この構成には以下の問題点があります。

1.1 障害発生時にシステムが全停止する（単一障害点）

1つ目は、サーバが何らかの理由で停止した際に、システム全体が利用不能になってしまうリスクです。これを専門用語で「単一障害点（SPOF）」と呼びます。システムをどれだけ慎重に構築・運用していても、ハードウェアの故障、アプリケーションのバグ、OSの不具合など、予期せぬ障害は必ず発生します。1台構成の場合、その1台のダウンが即座にサービスの停止（ダウンタイム）に直結してしまいます。

1.2 アクセス集中による性能低下

2つ目は、1台のサーバにアクセスが集中した際のリスクです。想定を超えるアクセスがあると処理能力が追いつかず、動作が極端に重くなったり、最悪の場合はサーバがダウンしたりする恐れがあります。サーバのスペックを上げる（スケールアップ）ことである程度は対応できますが、1台だけでは物理的な性能に限界があります。

1.3 メンテナンスの難易度とサービス停止

3つ目は、運用メンテナンスの課題です。サーバが1台しかないため、OSの更新や再起動が必要なメンテナンスを行う際、その間サービスを完全に停止させる必要があります。「サービスを止めずにメンテナンスをする」という選択肢もありますが、スタンバイ機への切り替え作業などを手動で構築・実施するのは非常に技術的難易度が高く、リスクも伴います。

2. ロードバランサーとは

単一サーバ構成の問題を解決する仕組みがロードバランサーです。

ロードバランサーは、利用者からのアクセスを複数のサーバにバランスよく振り分ける装置です。インターネットからのリクエストを受け取り、背後にある複数のEC2インスタンス等へ均等に転送します。主なメリットは以下の3点です。

ALBを使ったマルチAZ構成による負荷分散の全体像を以下に示します。

graph TD
    User["ユーザ"] --> ALB["ALB<br>（ロードバランサー）"]

    subgraph AZ-a["AZ-a"]
        EC2a1["EC2"]
        EC2a2["EC2"]
    end

    subgraph AZ-c["AZ-c"]
        EC2c1["EC2"]
        EC2c2["EC2"]
    end

    ALB --> EC2a1
    ALB --> EC2a2
    ALB --> EC2c1
    ALB --> EC2c2

    ALB -. "ヘルスチェック" .-> EC2a1
    ALB -. "ヘルスチェック" .-> EC2c1

2.1 単一障害点の防止（可用性の向上）

1つ目は、複数のサーバでシステムを構成することで単一障害点を排除できる点です。ロードバランサーの背後は基本的に2台以上のサーバで構成されるため、仮に1台が障害などでダウンしても、もう1台で処理を継続することができます。

また、多くのロードバランサーには「ヘルスチェック」という機能が備わっています。これは、サーバから一定の応答がなければそのサーバへの転送を停止し、正常なサーバにだけ処理を振り分ける機能です。これにより、障害が発生したサーバにリクエストが送られることを防ぎ、システム全体の停止を回避できます。ALBのヘルスチェックの詳しい仕様（しきい値や間隔など）はHealth checks for Application Load Balancer target groups（AWS公式ドキュメント）に記載があります。

2.2 負荷分散（スケーラビリティの向上）

2つ目は、アクセス集中による負荷を分散できる点です。ロードバランサーは、リクエスト数やサーバの負荷状況などの指標を元に、トラフィックが均等になるように通信を制御します。これにより、1台のサーバだけに負荷が集中するのを防ぎ、システム全体の安定性を保つことができます。

なお、ロードバランサー単体の機能ではありませんが、次の講座で解説する「オートスケーリング」と組み合わせることで、現在の台数では処理しきれない場合に自動的に新しいサーバを追加するといった柔軟な構成も可能になります。

2.3 ローリングデプロイ（運用性の向上）

3つ目は、サービスを停止せずにメンテナンスや更新を行う「ローリングデプロイ」が可能になる点です。

これは複数台構成であることを活かし、1台ずつ「サーバ停止→メンテナンス（更新）→再起動」を繰り返していく手法です。作業中は他のサーバが処理を代行するため、利用者から見てシステムが停止することなく、安全にメンテナンスを完了させることができます。これにより、運用の難易度とビジネスリスクを大幅に軽減できます。

3. AWSにおけるロードバランサー（ELB）

ロードバランサーの仕組みを、AWSではElastic Load Balancing（ELB）というマネージドサービスとして提供しています。

3.1 ELBとは

ELBを利用する最大のメリットは、ロードバランサー自体の構築や運用の手間がかからないことです。本来、ロードバランサーを自前で用意する場合、そのロードバランサー自体のスペック管理や故障対応も必要になりますが、ELBであればAWS側が自動的に管理・拡張を行うため、利用者は設定を行うだけですぐに高機能な負荷分散環境を利用できます。

AWSのELBにはいくつか種類がありますが、現在主に使用されているのは以下の2種類です。

3.2 Application Load Balancer (ALB)

1つ目は、ALBと呼ばれるWebアプリケーション向けのロードバランサーです。

これはOSI参照モデルの「レイヤー7（アプリケーション層）」で動作し、主にHTTPやHTTPSの通信を処理することに特化しています。

ALBの大きな特徴は、通信の中身を見て振り分け先を変えることができる点です。例えば、URLのパスを見て /images へのアクセスは画像処理用サーバへ、/api へのアクセスはAPI用サーバへ振り分けるといった高度なルーティングが可能です。一般的なWebサイトやWebシステムの構築では、このALBが最もよく利用されます。

3.3 Network Load Balancer (NLB)

2つ目は、NLBと呼ばれるネットワークレベルでの処理に特化したロードバランサーです。

これは「レイヤー4（トランスポート層）」で動作し、TCPやUDPといったプロトコルを処理します。

NLBの特徴は、圧倒的な処理性能です。毎秒数百万リクエストという超高負荷な通信もさばくことができ、遅延（レイテンシ）も極めて低く抑えられています。Web以外の通信や、極めて高いパフォーマンスが求められるシステム、あるいは固定IPアドレスが必要なケースなどで採用されます。

AWSでシステムを設計する際は、要件に合わせてこれらを適切に選択します。通常のWebアプリケーションであれば、高機能な振り分けができるALBの採用を検討するのが基本となります。

ただし、通信要件として固定IPアドレスが必要な場合や、HTTP以外のTCP/UDPプロトコルを使用する場合、あるいは極めて高い処理性能が求められるような特殊なケースにおいては、NLBを使用します。

4. ALB (Application Load Balancer)

ALBについて詳しく解説します。

4.1 ALBの基本構成

ALB（Application Load Balancer）は、主にHTTPやHTTPSプロトコルを使用するWebアプリケーションの負荷分散に最適化されたロードバランサーであり、WebサイトやAPIサーバ構築の第一候補となります。ここではその基本構成として、配置場所とセキュリティ設定について解説します。

まず、ALBはVPC内の「サブネット」に配置します。このとき、単一のサブネットではなく、異なるアベイラビリティゾーン（AZ）にある複数のサブネットを指定して配置することが推奨されます。これにより、万が一片方のAZで障害が発生しても、もう片方のAZで処理を継続できる、いわゆる「マルチAZ構成」による高い可用性が実現できます。

ALBの後続（バックエンド）には、実際に処理を行うEC2インスタンス等を配置します。ALBと同様に、インスタンス側も複数のAZ（サブネット）に分散して配置するのが一般的です。これにより、ALBから振り分けられたリクエストを、障害に強い構成で受け取ることができます。

ALBとEC2のセキュリティグループ（SG）を適切に連携させることも重要です。具体的には、インスタンス側のSGにて「ALBに設定されたSGからの通信のみを許可する（ソースにALBのSG IDを指定する）」という設定を行います。これを行わない場合、攻撃者がALBを介さずに直接EC2インスタンスのIPアドレスへアクセスできてしまうリスクがあります。この設定により、インターネットからの直接アクセスを遮断し、必ずWAFやログ機能を持つALBを経由した正規の通信のみを処理させる、安全な構成が実現します。

4.2 ターゲットグループ

ロードバランサーの構成要素であるターゲットグループについて解説します。

ターゲットグループとは、ロードバランサーがリクエストを転送する「宛先のグループ」を管理する設定です。ロードバランサーは個々のサーバを直接管理するのではなく、このターゲットグループという論理的なグループに対して通信を振り分けます。

具体的な使い方として、まずEC2インスタンスが挙げられます。作成したターゲットグループに複数のEC2インスタンスを登録することで、ロードバランサーはそのグループ内のインスタンスに対して均等に負荷分散を行うようになります。

また、ターゲットグループの宛先はEC2だけではありません。コンテナサービスの「Amazon ECSタスク」や、サーバレスの「AWS Lambda関数」、あるいはIPアドレスを直接指定することでAWS外にある「オンプレミスのサーバ」などを指定することも可能です。これにより、多様な環境への振り分けが実現できます。

さらに、次の講座で解説する「Auto Scaling」と組み合わせる使い方が非常に重要です。Auto Scalingを設定すると、アクセス増大時に自動的に起動した新しいインスタンスが、即座にこのターゲットグループへ自動登録されます。これにより、手動で設定を変更することなく、スケーラブルな構成を維持することが可能になります。

4.3 リスナーとアクション

リスナーは、ALBで「どのポート（プロトコル）で接続を待ち受けるか」を定義するプロセスです。その中で「どのような条件で、どのような処理をするか」を定義するものをリスナールールとアクションと呼びます。

リスナーがリクエストを受け取り、ルールに基づいてターゲットグループへ振り分ける流れを以下に示します。

flowchart LR
    Internet["インターネット"] --> Listener["リスナー<br>ポート443"]
    Listener --> Rules{"ルール判定"}
    Rules -- "/api/*" --> TG1["ターゲットグループA<br>（APIサーバ）"]
    Rules -- "/images/*" --> TG2["ターゲットグループB<br>（画像サーバ）"]
    Rules -- "デフォルト" --> TG3["ターゲットグループC<br>（Webサーバ）"]
    TG1 --> EC2a["EC2"]
    TG2 --> EC2b["EC2"]
    TG3 --> EC2c["EC2"]

「リスナールール」は、条件を定義する部分です。ポート番号だけでなく、リクエストの「HTTPヘッダーの値」や「URLのパス」などの情報を元に、処理を細かく振り分けることができます。例えば、「HTTPS（ポート443）でリクエストされたらすべてターゲットグループAに振り分ける」、「/target というパスでアクセスが来たらターゲットグループBに転送する」といったルールを指定できます。

「アクション」は、そのルールに一致したときに実行する具体的な処理内容です。最も一般的なアクションは「特定のターゲットグループに転送（フォワード）する」ことですが、それ以外にも「固定のステータスコードやメッセージを返す（メンテナンス画面の表示など）」や「別のURLへリダイレクトする（HTTPからHTTPSへの誘導など）」といった処理も指定可能です。

5. NLB (Network Load Balancer)

NLB（Network Load Balancer）について、ALBとの違いに焦点を当てて解説します。

5.1 NLBの役割と使い分け

NLBは、OSI参照モデルのトランスポート層（レイヤー4）で動作するロードバランサーであり、主にTCPやUDPといったプロトコルを使用して処理を振り分けます。

最大の特徴はその処理性能です。ALBと比較して圧倒的に負荷に強く、毎秒数百万リクエストに及ぶスパイク（突発的なアクセス増）が発生するシステムや、ミリ秒単位の極めて低い遅延が求められるケースで採用されます。

また、IPアドレスの扱いにも大きな違いがあります。ALBはIPアドレスが動的に変わるのに対し、NLBは各アベイラビリティゾーンごとに固定IPアドレスを持つことができます。そのため、企業間のファイアウォール設定などで「IPアドレスの固定」が必須要件となる場合にも選定されます。

5.2 ALBとNLBの違い

ALBとNLBは設定方法や構成は似ていますが、以下の点で異なります。

使用するプロトコル

一番の違いは、動作する階層と対象とするプロトコルです。

ALBは「アプリケーション層（レイヤー7）」で動作するため、HTTP/HTTPSプロトコルを対象とします。そのため、リクエストの「中身」を見ることができ、ヘッダー情報やURLのパスなどを条件にして振り分けを行うことが可能です。

それに対して、NLBは「トランスポート層（レイヤー4）」で動作するため、TCP/UDPプロトコルを使用します。これらのプロトコルの場合、通信パケットの中身（ヘッダーやパス）までは見ず、純粋に通信を転送します。そのため、URLなどに基づいた細かい振り分けはできず、プロトコルとポート番号のみが振り分けの判断基準となります。

しかし、この「中身を解析しない」という単純さがあるため、ALBと比較して圧倒的に負荷に強く、高速な処理が可能になるというメリットがあります。

IPアドレスの固定化

もう一つの大きな違いは、IPアドレスの扱いです。

ALBは、IPアドレスが固定されず、AWS側で自動的に変更される仕様になっています。Elastic IPアドレス（固定IP）を割り当てることもできません。そのため、DNS名でアクセスする通常のWeb用途であれば問題ありませんが、接続元のファイアウォール設定などで「特定のIPアドレスのみ許可したい」といった厳格なネットワーク要件がある場合には適しません。

それに対し、NLBは固定IPアドレスを持つことができます。具体的には、各アベイラビリティゾーン（AZ）ごとに固有のIPアドレスを持つ仕様になっており、さらにElastic IPアドレスを付与することも可能です。これにより完全な固定IP化が実現できるため、企業間連携などの要件ではNLBが重要な選択肢となります。

セキュリティ機能

最後に、セキュリティ機能と暗号化処理の扱いに違いがあります。

まず、ALBはアプリケーション層で動作するため、「AWS WAF（Webアプリケーションファイアウォール）」を直接適用できます。これにより、不正アクセスや脆弱性を突いた攻撃をロードバランサー層でブロック可能です。対して、NLBにはWAFを直接適用できません。WAFを利用したい場合は、アプリケーション側で対策するか、前段にCloudFrontを配置するなどの構成が必要になります。

また、暗号化通信（SSL/TLS）の扱いも異なります。ALBは必ずロードバランサー側で暗号化を復号（SSL終端）するため、アプリケーションには復号されたHTTP通信が届きます。これにより、「クライアント証明書」などの情報はALBで止まってしまい、サーバまで届きません。

一方、NLBは暗号化されたデータをそのままサーバへ転送する「パススルー（TCPリスナー）」が可能です。これにより、アプリケーション側でクライアント証明書による厳格な認証を行いたい場合などは、NLBの採用が必須となります。

なお、DDoS攻撃を防ぐ「AWS Shield」については、ALBとNLBのどちらも適用可能です。

6. ELBのセキュリティ設定

最後に、ELBのセキュリティ機能について解説します。ELBはシステムの「入口」として機能するため、セキュリティをしっかり意識して設計することが求められます。

6.1 AWS ShieldによるDDoS対策

システムをインターネットで公開したとき、最も注意するべき攻撃の一つがDDoS攻撃です。これは、大量のアクセスをシステムに送りつけて、システムのパフォーマンス低下やダウンを狙うものです。この対策を行っていないと、攻撃を受けたときに無防備になったり、膨大なトラフィック料金を支払うことになる恐れがあります。

ELBを使用すると、AWSのDDoS保護サービスである「AWS Shield Standard」が自動的に適用されます。これにより、外部からの大量の攻撃アクセス（DDoS攻撃）があった場合でも、AWS側のインフラでその攻撃を検知・緩和し、システムを守ってくれます。追加料金なしで強力なセキュリティ対策が標準装備される点も、ELBを利用する大きなメリットの一つです。

また、有料となりますが「AWS Shield Advanced」を適用することで、AWSのDDoS対応専門チーム（SRT）による24時間365日のサポートや、攻撃によって急増した利用料金の免除（コストプロテクション）、攻撃の可視化といった、より高度で手厚い保護を受けることも可能です。

6.2 通信の暗号化

現代のWebサイトで必須となる「通信の暗号化」と、より高度な「接続元の認証」を、ELBの機能で一元的に管理できます。

ELB（ALBおよびNLB）は、通信の暗号化や復号処理を代行する「SSLオフロード」に対応しています。AWSの無料証明書「ACM」や、外部認証局の持ち込み証明書をELBに適用することで、バックエンドサーバ一台一台に証明書を設定・更新する手間がなくなります。特にACMを利用すれば、面倒な更新作業も自動化されます。

さらに高いセキュリティが必要な場合、ALBに限定されますが、「Trust Store（トラストストア）」機能を利用した相互TLS認証（mTLS）が可能です。信頼できる認証局情報をまとめたTrust StoreをALBに登録するだけで、アプリケーションを改修することなく、アクセス元の「クライアント証明書」を厳密に検証できます。これにより、特定の社内デバイスや取引先以外からの接続をELB側で遮断することが可能です。

6.3 AWS WAFによるアプリケーション保護

DDoS対策や通信の暗号化に加え、Webアプリケーションの脆弱性を狙った攻撃への対策も不可欠です。ここで活躍するのが「AWS WAF (Web Application Firewall)」です。

ALBに限定されますが、AWS WAFと直接連携させることができます。WAFを適用すると、正常な通信に見せかけた悪意ある攻撃（SQLインジェクションやクロスサイトスクリプティングなど）を、サーバに届く前にALBの段階で検知・ブロックすることが可能になります。

従来、WAFの導入には複雑なルールの作成が必要でしたが、AWS WAFでは「マネージドルール」と呼ばれる、AWSやセキュリティベンダーが作成した「推奨ルールのセット」が用意されています。これを利用することで、セキュリティの専門家でなくとも、最新の脅威に対応した防御策をスイッチ一つで簡単に導入できるのが大きな強みです。

7. 主なユースケース

ELBは、高可用性・高スケーラビリティが求められるシステムの構築に欠かせないサービスです。以下に代表的なユースケースを紹介します。

7.1 Webアプリケーションの負荷分散

ALBを使用して、複数のEC2インスタンスにHTTP/HTTPSトラフィックを分散させます。URLパスやホストヘッダーに基づくルーティングにより、マイクロサービスアーキテクチャやAPIバージョニングにも対応できます。

7.2 高可用性システムの構築

マルチAZ構成でALBを配置し、ヘルスチェックによる異常検知と自動切り替えを行うことで、単一障害点を排除した構成を実現します。1つのAZで障害が発生しても、別のAZで処理を継続できます。

7.3 企業間連携システムの構築

NLBの固定IPアドレス機能を活用して、ファイアウォールでIPアドレス制限が必要な企業間システム連携を実現します。また、クライアント証明書による認証が必要な場合も、NLBのパススルー機能で対応できます。

8. 設計のポイント

ELBを設計する際の主要な検討項目を以下にまとめます。

9. まとめ

この講座では、ロードバランサー（ELB）について学びました。

• 単一構成の問題点として、単一障害点、性能限界、メンテナンス困難がある
• ロードバランサーは複数サーバへリクエストを分散し、可用性・スケーラビリティを向上させる
• ELBはAWSが提供するマネージドなロードバランサーサービス
• ALBはHTTP/HTTPS向けで、URLパスなどに基づく高度なルーティングが可能
• NLBはTCP/UDP向けで、超高性能かつ固定IPアドレスを持てる
• ターゲットグループでリクエストの振り分け先を管理する
• リスナーとルールで待ち受けポートと振り分け条件を設定する
• AWS ShieldでDDoS対策、AWS WAFでアプリケーション層の攻撃対策ができる