実践！AWSネットワーク構築・運用30日チャレンジ: Day 13

Last updated at 2025-07-25Posted at 2025-07-25

Day 13: ロードバランサー（ALB/NLB）：トラフィック分散と高可用性

皆さん、こんにちは！「実践！AWSネットワーク構築・運用30日チャレンジ」のDay 13へようこそ！

これまでの学習で、AWSクラウド内にセキュアで柔軟なネットワーク基盤を構築し、オンプレミスとの接続方法も学びました。しかし、構築したWebサーバーやアプリケーションサーバーが単一のインスタンスでは、トラフィックの増加に対応できなかったり、インスタンスに障害が発生した場合にサービスが停止してしまったりする問題があります。

今日のDay 13では、これらの課題を解決し、アプリケーションのトラフィックを効率的に分散させ、高可用性とスケーラビリティを実現するための重要なサービス、「Elastic Load Balancing (ELB)」とその主要なタイプである「Application Load Balancer (ALB)」と「Network Load Balancer (NLB)」について詳しく学びます。

1. ロードバランサーとは？なぜ必要か？

ロードバランサーは、複数のサーバー（EC2インスタンスなど）に対して、受信したネットワークトラフィックを均等に（または定義されたルールに基づいて）分散させる役割を持つデバイスまたはサービスです。

なぜロードバランサーが必要なのでしょうか？

高可用性 (High Availability): 複数のサーバーにトラフィックを分散させることで、たとえ一部のサーバーに障害が発生しても、残りのサーバーがサービスを継続できます。ロードバランサーは、異常なサーバーを自動的に検出し、トラフィックの転送を停止します。
スケーラビリティ (Scalability): トラフィックが増加した場合、サーバーの数を増やすことで、ロードバランサーが自動的に新しいサーバーにトラフィックを分散させ、アプリケーションの処理能力を向上させます。
パフォーマンス向上: トラフィックを複数のサーバーに分散させることで、個々のサーバーの負荷を軽減し、アプリケーションの応答速度を向上させます。
セキュリティ強化: ロードバランサーをインターネットとサーバーの間に配置することで、サーバーのIPアドレスを直接公開せずに済み、セキュリティ層を追加できます。SSL/TLS終端機能も提供します。
ヘルスチェック: サーバーが正常に動作しているか（アプリケーションが応答しているか）を定期的に確認し、異常なサーバーへのトラフィック転送を停止します。

AWSでは、このロードバランサーの機能が「Elastic Load Balancing (ELB)」というフルマネージドサービスとして提供されています。

2. Elastic Load Balancing (ELB) の主要なタイプ

ELBには主に3つのタイプがありますが、現在主流で利用されるのは以下の2つです。

Application Load Balancer (ALB): アプリケーション層（HTTP/HTTPS）のリクエストを処理するロードバランサー。
Network Load Balancer (NLB): ネットワーク層（TCP/UDP/TLS）のトラフィックを処理するロードバランサー。

それぞれの特徴を見ていきましょう。

2.1. Application Load Balancer (ALB)

ALBは、OSI参照モデルの第7層（アプリケーション層） で動作します。HTTP/HTTPSトラフィックに特化しており、より高度なルーティング機能を提供します。

特徴:

パスベースルーティング: URLのパス（例: /users はユーザーサービス、/products は商品サービス）に基づいてトラフィックを異なるターゲットグループ（サーバー群）にルーティングできます。
ホストベースルーティング: ホスト名（例: api.example.com はAPIサービス、web.example.com はWebサービス）に基づいてルーティングできます。
クエリ文字列/HTTPヘッダーベースルーティング: HTTPリクエストのクエリ文字列やヘッダーに基づいてルーティングできます。
SSL/TLS終端: クライアントからのHTTPSリクエストをALBで終端し、ALBからバックエンドのサーバーへはHTTPで通信できます。これにより、サーバー側のSSL/TLS処理の負荷を軽減できます。
WebSockets、HTTP/2のサポート: 最新のWebプロトコルに対応しています。
Lambda関数へのルーティング: ALBから直接Lambda関数を呼び出すことも可能です。
固定IPアドレスなし: ALB自体には固定のパブリックIPアドレスは割り当てられません。DNS名（例: my-alb-123456789.ap-northeast-1.elb.amazonaws.com）でアクセスします。
セキュリティグループの適用: ALBにもセキュリティグループを適用し、インバウンドトラフィックを制御できます。

向いているシナリオ:

マイクロサービスアーキテクチャで、異なるサービスを同じALBの背後でルーティングしたい場合
コンテナベースのアプリケーション (ECS/EKS)
HTTP/HTTPSトラフィックを扱うWebアプリケーション
SSL/TLS終端をロードバランサーで行いたい場合

2.2. Network Load Balancer (NLB)

NLBは、OSI参照モデルの第4層（ネットワーク層） で動作します。TCP、UDP、TLSトラフィックに特化しており、非常に高いパフォーマンスと低レイテンシを提供します。

特徴:

超高速・低レイテンシ: パケットレベルで転送を行うため、非常に高いスループットと低いレイテンシを実現します。秒間数百万リクエストを処理できます。
固定IPアドレス: 各アベイラビリティゾーンで静的なIPアドレス（Elastic IP）を割り当てることが可能です。これは、特定のIPアドレスからのアクセスを許可するファイアウォールルールを持つシステムとの連携に便利です。
ソースIPアドレスの保持: クライアントのソースIPアドレスをバックエンドサーバーにそのまま渡します。ALBでは通常、ALBのプライベートIPアドレスがソースIPとなります（X-Forwarded-ForヘッダーでクライアントIPを渡す）。
TLS終端: TLSリスナーを設定することで、TLS終端も可能です。
UDPトラフィックのサポート: UDPベースのアプリケーション（例: DNS、ゲームサーバー）にも対応します。
セキュリティグループの適用なし: NLB自体にはセキュリティグループを直接適用できません。バックエンドのターゲットグループに属するインスタンスのセキュリティグループで制御します。

向いているシナリオ:

非常に高いパフォーマンスと低レイテンシが求められるアプリケーション
TCP/UDPベースのトラフィックを扱うアプリケーション（ゲームサーバー、DNS、IoTバックエンドなど）
固定IPアドレスが必要な場合
クライアントのソースIPアドレスをバックエンドで直接利用したい場合
Direct ConnectやVPN経由でオンプレミスからアクセスされる内部システム

3. ロードバランサーのコンポーネントと設定の流れ

ELBを構築する際の主要なコンポーネントは以下の通りです。

リスナー (Listener): ロードバランサーがクライアントからの接続リクエストをリッスンするポートとプロトコルを定義します（例: HTTP:80, HTTPS:443）。
ターゲットグループ (Target Group): ロードバランサーがトラフィックを転送するサーバー群（EC2インスタンスなど）を定義します。ヘルスチェックの設定もここで行います。
ターゲット (Target): ターゲットグループに登録される個々のサーバー（EC2インスタンスのIPアドレスまたはインスタンスID）。

設定の流れは以下のようになります。

ターゲットグループの作成: トラフィックを受け取るEC2インスタンスを登録し、ヘルスチェックを設定します。
ロードバランサーの作成: ALBまたはNLBを選択し、VPCとサブネット（複数AZに分散）を指定します。
リスナーの設定: ロードバランサーがリッスンするポートとプロトコル、およびトラフィックを転送するターゲットグループを関連付けます。
（ALBの場合）セキュリティグループの設定: ALBへのインバウンドトラフィックを許可するSGを設定します。
（バックエンドEC2のSG更新）バックエンドEC2のセキュリティグループ更新: ロードバランサーからのインバウンドトラフィックを許可するように、バックエンドEC2インスタンスのセキュリティグループを更新します。

4. ロードバランサー (ALB) の実践的なデプロイ

Day 8で起動したWebサーバー (MyWebServer01) をターゲットとして、ALBを構築してみましょう。

事前準備：Webサーバーの準備

Day 8で起動した MyWebServer01 (パブリックサブネット、web-server-sg 適用済み) が実行中であることを確認してください。
SSHで MyWebServer01 に接続し、Apache HTTPサーバーが起動しており、index.html が存在することを確認してください。

4.1. ターゲットグループの作成

AWSマネジメントコンソールで「EC2」サービスを開きます。
左側ナビゲーションペインから「ターゲットグループ」をクリックし、「ターゲットグループの作成」ボタンをクリックします。
ターゲットタイプを選択: 「インスタンス」を選択します。
ターゲットグループの詳細を指定:
- ターゲットグループ名: my-web-target-group
- プロトコル: HTTP
- ポート: 80 (Webサーバーがリッスンするポート)
- VPC: あなたのメインVPCを選択します。
- ヘルスチェック:
  - プロトコル: HTTP
  - パス: / (ルートパスへのアクセスでヘルスチェック)
  - 詳細設定: デフォルトのままでOK (正常しきい値2、異常しきい値2、タイムアウト5秒、間隔30秒)
「次へ」をクリックします。
ターゲットの登録:
- 利用可能なインスタンスのリストから、MyWebServer01 を選択します。
- 「保留中として以下を含める」をクリックします。
「ターゲットグループの作成」をクリックします。

数分後、ターゲットグループの「ターゲット」タブで、MyWebServer01 のステータスが「healthy」になることを確認してください。

4.2. Application Load Balancer (ALB) の作成

EC2サービスの左側ナビゲーションペインから「ロードバランサー」をクリックし、「ロードバランサーの作成」ボタンをクリックします。
ロードバランサーのタイプを選択: 「Application Load Balancer」の「作成」をクリックします。
ロードバランサーの設定:
- ロードバランサー名: my-alb
- スキーム: インターネット向け (インターネットからアクセス可能にする)
- IPアドレスタイプ: IPv4
- VPC: あなたのメインVPCを選択します。
- アベイラビリティゾーン:
  - 少なくとも2つのAZを選択し、それぞれのAZでパブリックサブネットを選択します。（例: ap-northeast-1a の my-vpc-public-subnet-a と ap-northeast-1c の my-vpc-public-subnet-c）
    - ポイント: ロードバランサーは高可用性のため、複数のAZにデプロイする必要があります。
- セキュリティグループ:
  - 「新しいセキュリティグループを作成する」を選択し、以下を設定します。
    - SG名: my-alb-sg
    - 説明: Allow HTTP/HTTPS to ALB
    - インバウンドルール:
      - タイプ: HTTP (ポート 80), ソース: 0.0.0.0/0
      - タイプ: HTTPS (ポート 443), ソース: 0.0.0.0/0 (今回はHTTPのみですが、将来的にHTTPSを追加する可能性を考慮)
    - ポイント: ALBに適用するSGは、クライアントからのアクセスを許可するルールを設定します。
- リスナーとルーティング:
  - プロトコル: HTTP
  - ポート: 80
  - デフォルトアクション: 「ターゲットグループに転送」を選択し、先ほど作成した my-web-target-group を選択します。
「ロードバランサーの作成」をクリックします。

作成には数分かかります。ステータスが「active」になるまで待ちましょう。

4.3. バックエンドEC2インスタンスのセキュリティグループ更新

最後に、MyWebServer01 に適用されている web-server-sg のインバウンドルールを更新し、ALBからのトラフィックのみを許可するようにします。これにより、インスタンスへの直接アクセスを防ぎ、セキュリティを強化します。

「セキュリティグループ」リストで、web-server-sg を選択します。
「インバウンドルール」タブで「インバウンドルールを編集」をクリックします。
既存のHTTP (80番ポート) と HTTPS (443番ポート) のソース 0.0.0.0/0 のルールを編集（または削除して再作成）し、ソースを my-alb-sg (ALBに適用したSG) に変更します。
- タイプ: HTTP (ポート 80)
- ソース: my-alb-sg (ALBのSGを選択)
- タイプ: HTTPS (ポート 443)
- ソース: my-alb-sg (ALBのSGを選択)
「ルールを保存」をクリックします。

4.4. 動作確認

ALBが「active」になったら、ロードバランサーの詳細画面にある「DNS名」をコピーし、Webブラウザでアクセスしてみてください。

MyWebServer01 で設定した「Hello from My AWS EC2 Web Server!」というページが表示されれば成功です！これで、インターネットからのトラフィックがALBを経由して、バックエンドのEC2インスタンスに到達するようになりました。

5. AI時代におけるロードバランサーの活用シナリオ

AI/MLワークロードでは、ロードバランサーは推論APIの提供や、大規模な分散学習環境において重要な役割を果たします。

リアルタイム推論APIの公開:
- ALB: Webアプリケーションやモバイルアプリからアクセスされるリアルタイム推論API（例: 画像認識、自然言語処理）をALBの背後で公開します。ALBのパスベースルーティングを利用して、異なるモデルの推論エンドポイントをルーティングできます。
- NLB: 非常に低レイテンシが求められる推論（例: 金融取引、自動運転）や、TCP/UDPベースのカスタムプロトコルを使用する推論サービスの場合、NLBが適しています。
オートスケーリングとの連携: ALB/NLBをAuto Scaling Group (ASG) と組み合わせることで、推論リクエストの負荷に応じてEC2インスタンス（GPUインスタンスなど）を自動的にスケールイン/アウトさせ、コスト効率と可用性を最適化できます。
モデルのA/Bテスト/カナリアリリース: ALBの高度なルーティング機能を利用して、新しいバージョンのMLモデルをデプロイしたインスタンスに少量のトラフィックを流し（カナリアリリース）、問題がなければ徐々にトラフィックを増やしていくといったデプロイ戦略を実現できます。
内部サービス間通信: プライベートサブネット内のALB/NLBを使用して、異なるマイクロサービス間（例: データ前処理サービスから推論サービスへ）のトラフィックを分散させ、内部通信の高可用性を確保します。
GPUインスタンスの負荷分散: 特にNLBは、GPUインスタンスのような高価なリソースの負荷分散に優れています。高いスループットでリクエストを効率的に分散し、GPUリソースを最大限に活用できます。

本日のまとめと次へのステップ

今日は、アプリケーションのトラフィック分散と高可用性を実現する「Elastic Load Balancing (ELB)」について、主要なタイプである「Application Load Balancer (ALB)」と「Network Load Balancer (NLB)」を中心に学び、ALBの構築を実践しました。

ALB: アプリケーション層（HTTP/HTTPS）で動作し、パス/ホストベースルーティングやSSL終端など高度な機能を持つ。Webアプリケーションやマイクロサービスに最適。
NLB: ネットワーク層（TCP/UDP/TLS）で動作し、超高速・低レイテンシ、固定IPアドレスが特徴。高パフォーマンスや特定のプロトコル要件に最適。
ロードバランサーは、リスナー、ターゲットグループ、ターゲットというコンポーネントで構成される。

ロードバランサーは、AWSでスケーラブルで高可用性なシステムを構築する上で不可欠なサービスです。この知識があれば、より堅牢なWebアプリケーションやAI/ML推論サービスを設計できるようになります。

明日のDay 14では、2週間の振り返りを行います。ぜひここまでの内容を復習してみて下さいね。

今日のALBの構築、無事に成功しましたか？Webページが表示されたら、ぜひ「いいね」👍で教えてください！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up