概要
Web アプリケーションの運用において、単一のサーバーにすべてのトラフィックが集中すると、負荷の増大によるレスポンス低下や、サーバー障害時のサービス停止といったリスクが生じます。こうした課題に対して、トラフィックを複数のサーバーに分散する仕組みがロードバランサーです。
Elastic Load Balancing（ELB）は、AWS が提供するフルマネージドなロードバランシングサービスです。受信したトラフィックを複数の EC2 インスタンスやコンテナ、Lambda 関数などのターゲットに自動的に分散し、アプリケーションの可用性とスケーラビリティを向上させます。
本記事では、ELB の基本概念を理解し、Application Load Balancer（ALB）を作成して複数の EC2 インスタンスにトラフィックを分散する構成を体験します。
クラウドおさる1 台の売店にお客が全部押し寄せたら、猿山でも行列が崩れて大騒ぎでござる。この記事では ALB を作って、2 台の EC2 にリクエストが振り分けられるところを確かめるでござる。
この記事のメリット
- Elastic Load Balancing の種類と使い分けを理解できる
- Application Load Balancer（ALB）を作成し、トラフィック分散を体験できる
- ターゲットグループの作成とヘルスチェックの仕組みを把握できる
- リスナーとルーティングルールの基本的な設定方法を習得できる
- 複数のアベイラビリティゾーンにまたがる高可用性構成を理解できる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
クラウドおさるとひさん、ロードバランサーはサーバーの負荷を分散するものだと聞いたでござる。AWS だと、どういうサービスがあるのでござるか？
土肥AWS には Elastic Load Balancing、略して ELB っていうフルマネージドなロードバランシングサービスがあるよ。受信したトラフィックを複数のターゲットに自動的に分散してくれるんだ。しかもトラフィックの増減に応じてロードバランサー自体も自動スケーリングするから、キャパシティの事前計画は不要なんだよ。
クラウドおさるロードバランサー自体がスケーリングしてくれるのでござるな！ どんなときに使うものでござる？
土肥主なユースケースはこんな感じだね。
- Web アプリケーションの高可用性確保
- マイクロサービス間のトラフィック制御
- 複数アベイラビリティゾーンにまたがる負荷分散
- SSL/TLS 終端の一元化
クラウドおさるけっこう幅広い用途があるのでござるな。ロードバランサーは 1 種類だけでござるか？
土肥いや、ELB には 4 種類のロードバランサーがあるんだ。
| 種類 | 略称 | 動作レイヤー | 主なユースケース |
|---|---|---|---|
| Application Load Balancer | ALB | レイヤー 7（HTTP/HTTPS） | Web アプリケーション、マイクロサービス、パスベースルーティング |
| Network Load Balancer | NLB | レイヤー 4（TCP/UDP/TLS） | 超低レイテンシーが求められるアプリケーション、固定 IP が必要なケース |
| Gateway Load Balancer | GWLB | レイヤー 3（IP） | サードパーティ仮想アプライアンスの展開（ファイアウォール、IDS/IPS） |
| Classic Load Balancer | CLB | レイヤー 4/7 | レガシー（新規利用は非推奨） |
土肥今回は最も一般的に利用される ALB を使っていくよ。
クラウドおさるALB はレイヤー 7 で HTTP/HTTPS を扱うのでござるな。では、ALB はどんな構成要素で成り立っているのでござるか？
土肥ALB は「ロードバランサー」「リスナー」「ターゲットグループ」の 3 つが基本のコンポーネントで、リスナーには振り分け方を決めるリスナールールが付くんだ。順番に見ていこう。
- ロードバランサー: クライアントからの接続を受け付けるエントリポイントです。複数のアベイラビリティゾーンに配置することで高可用性を実現します
- リスナー: ロードバランサーが接続を受け付けるプロトコルとポートの設定です。HTTP（ポート 80）や HTTPS（ポート 443）を指定します
- リスナールール: リスナーが受け取ったリクエストをどのターゲットグループに転送するかを定義するルールです。パスやホストヘッダーなどの条件に基づいてルーティングできます
- ターゲットグループ: リクエストの転送先となるターゲット（EC2 インスタンスなど）をグループ化したものです。ヘルスチェックにより、正常なターゲットにのみトラフィックが分散されます（すべてのターゲットが異常になったときは例外で、後述します）
クラウドおさるリスナーでリクエストを受けて、ルールに従ってターゲットグループに振り分ける、という流れでござるな。
クラウドおさるところで、ターゲットのサーバーが落ちてしまったらどうなるでござる？ 落ちたサーバーにもリクエストが飛んでしまうのでござるか？
土肥そこはヘルスチェックの仕組みがあるから大丈夫だよ。ターゲットグループに登録されたターゲットに対して、定期的にヘルスチェックが実施されるんだ。ヘルスチェックに失敗したターゲットは自動的にルーティング対象から除外されて、復旧すると再びトラフィックが分散されるようになるよ。ただし、ターゲットが全部同時に異常になったときは、ALB は「フェイルオープン」といって、ヘルスステータスにかかわらず全部のターゲットに振り分けるんだ。全部止めてしまうよりはまし、という考え方だね。
クラウドおさる自動で切り離してくれるのでござるか。猿山の監視当番が、寝込んだ倉庫番を当番表から外しておき、元気になったら戻すのと同じでござるな。ヘルスチェックにはどんな設定があるのでござる？
土肥主な設定項目はこの表のとおりだよ。
| 設定項目 | 説明 |
|---|---|
| プロトコル | ヘルスチェックに使用するプロトコル（HTTP、HTTPS） |
| パス | ヘルスチェックリクエストの送信先パス（例: /） |
| 正常のしきい値 | 正常と判断するまでの連続成功回数 |
| 非正常のしきい値 | 異常と判断するまでの連続失敗回数 |
| タイムアウト | ヘルスチェック応答のタイムアウト秒数 |
| 間隔 | ヘルスチェックの実行間隔 |
クラウドおさるしきい値や間隔を調整できるのでござるな。これなら障害時でもユーザーへの影響を最小限にできそうでござる！
実践
前提条件
- リージョン:
ap-northeast-1（東京） - 以下のリソースが作成済みであること
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| VPC | elb-lab-vpc | 検証用 VPC（CIDR: 10.0.0.0/16） |
| パブリックサブネット | elb-lab-public-subnet-1a | AZ-a のパブリックサブネット（CIDR: 10.0.1.0/24） |
| パブリックサブネット | elb-lab-public-subnet-1c | AZ-c のパブリックサブネット（CIDR: 10.0.2.0/24） |
| インターネットゲートウェイ | elb-lab-igw | インターネット接続用 |
| EC2 インスタンス | elb-lab-web-1a | AZ-a の Web サーバー |
| EC2 インスタンス | elb-lab-web-1c | AZ-c の Web サーバー |
| セキュリティグループ | elb-lab-web-sg | EC2 用 SG（ポート 80 を許可） |
- 2 台の EC2 インスタンスにはそれぞれ簡易的な Web サーバーが起動しており、HTTP（ポート 80）でレスポンスを返す状態であること
この実践で作成するリソース
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| セキュリティグループ | elb-lab-alb-sg | ALB 用 SG |
| ターゲットグループ | elb-lab-tg | EC2 インスタンスのグループ |
| Application Load Balancer | elb-lab-alb | トラフィック分散用 ALB |
ALB 用セキュリティグループの作成
AWS マネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。
上部の検索バーに EC2 と入力し、表示された「EC2」を選択します。
左側ナビゲーションの「ネットワーク＆セキュリティ」→「セキュリティグループ」を選択します。
「セキュリティグループを作成」をクリックします。
以下の情報を入力します。
- セキュリティグループ名:
elb-lab-alb-sg - 説明:
Security group for ALB - VPC:
elb-lab-vpc
「インバウンドルール」セクションで「ルールを追加」をクリックし、以下を入力します。
- タイプ:
HTTP - リソースタイプ:
Anywhere-IPv4（選ぶと、ソース欄に0.0.0.0/0が入ります） - 説明:
Allow HTTP from anywhere
アウトバウンドルールはデフォルト（すべてのトラフィックを許可）のままにします。
「セキュリティグループを作成」をクリックします。
EC2 セキュリティグループのインバウンドルール更新
EC2 インスタンスのセキュリティグループ elb-lab-web-sg に、ALB からのトラフィックを許可するルールを追加します。elb-lab-web-sg には、前提として 0.0.0.0/0 からの HTTP を許可するルールが入っています。
左側ナビゲーションの「ネットワーク＆セキュリティ」→「セキュリティグループ」を選択し、elb-lab-web-sg を選択します。
「インバウンドルール」タブを選択し、「インバウンドルールを編集」をクリックします。
「ルールを追加」をクリックし、以下を入力します。
- タイプ:
HTTP - リソースタイプ:
カスタム（デフォルト）のまま、ソース欄にelb-lab-alb-sgと入力し、候補に表示されたelb-lab-alb-sg | sg-…を選択 - 説明:
Allow HTTP from ALB
「ルールを保存」をクリックします。
クラウドおさるALB の SG はインターネットから、EC2 の SG は ALB の SG から、と許可の元を分けたのでござるな。本番では、EC2 側に残っている 0.0.0.0/0 のルールを消して、ALB からしか入れないようにするのが定石でござる。
ターゲットグループの作成
左側ナビゲーションの「ロードバランシング」→「ターゲットグループ」を選択します。
「ターゲットグループの作成」をクリックします。作成は「ターゲットグループの作成」→「ターゲットを登録」→「確認と作成」の 3 ステップです。
「基本的な設定」セクションで以下を設定します。
- ターゲットタイプの選択:
インスタンス - ターゲットグループ名:
elb-lab-tg - プロトコル / ポート:
HTTP/80 - VPC:
elb-lab-vpc - プロトコルバージョン:
HTTP1
「ヘルスチェック」セクションでは以下を確認します。
- ヘルスチェックプロトコル:
HTTP - ヘルスチェックパス:
/
その他の項目はデフォルトのままにします。
「次へ」をクリックします。
「使用可能なインスタンス」の一覧から elb-lab-web-1a と elb-lab-web-1c を選択し、「保留中として以下を含める」をクリックします（インスタンスを選ぶまで、このボタンは押せません）。
「次へ」をクリックし、確認画面で「ターゲットグループの作成」をクリックします。
ALB の作成
左側ナビゲーションの「ロードバランシング」→「ロードバランサー」を選択します。
「ロードバランサーの作成」をクリックします。
「Application Load Balancer」の「作成」をクリックします。
「基本的な設定」セクションで以下を設定します。
- ロードバランサー名:
elb-lab-alb - スキーム:
インターネット向け - IP アドレスタイプ:
IPv4
「ネットワークマッピング」セクションで以下を設定します。
- VPC:
elb-lab-vpc - マッピング:
ap-northeast-1a（elb-lab-public-subnet-1a）とap-northeast-1c（elb-lab-public-subnet-1c）を選択
「セキュリティグループ」セクションで以下を設定します。
- 最初から選択されている
defaultのセキュリティグループを削除し、elb-lab-alb-sgを選択
「リスナーとルーティング」セクションで以下を設定します。
- プロトコル:
HTTP - ポート:
80 - デフォルトアクション:
elb-lab-tgを選択
その他の項目はデフォルトのままにします。
画面最下部の「ロードバランサーの作成」をクリックします。
作成が完了すると、ロードバランサーの詳細画面に遷移し、成功のメッセージが表示されます。ステータスが「プロビジョニング中」から「アクティブ」に変わるまで待ちます（今回は 2 分ほどでした）。
動作確認
ロードバランサーの詳細画面で「DNS 名」をコピーします。
ブラウザで ALB の DNS 名にアクセスします。
http://<ALB の DNS 名>Web サーバーからのレスポンスが表示されることを確認します。ページをリロードすると、異なるインスタンスからレスポンスが返される（トラフィックが分散されている）ことが確認できます。
ターゲットのヘルスステータス確認
左側ナビゲーションの「ロードバランシング」→「ターゲットグループ」を選択し、elb-lab-tg を選択します。
「ターゲット」タブを選択し、登録された 2 台のインスタンスのヘルスステータスが「Healthy」であることを確認します。
クラウドおさるリロードするたびに応答するインスタンスが替わり、ターゲットは 2 台とも healthy。トラフィックの分散とヘルスチェックの両方を確かめられたでござる。
まとめ
- Elastic Load Balancing は、トラフィックを複数のターゲットに自動分散するフルマネージドサービスである
- ALB はレイヤー 7（HTTP/HTTPS）で動作し、Web アプリケーションのロードバランシングに適している
- ALB は「ロードバランサー」「リスナー」「ターゲットグループ」の 3 つのコンポーネントで構成され、リスナーにはリスナールールが付く
- ターゲットグループのヘルスチェックにより、正常なターゲットにのみトラフィックが分散される（すべてのターゲットが異常なときはフェイルオープンし、全ターゲットに振り分ける）
- 複数のアベイラビリティゾーンにまたがる構成により、高可用性を実現できる
- ALB 用とターゲット用のセキュリティグループを分離し、ALB からのトラフィックのみを許可する構成がベストプラクティスである
参照先
- Elastic Load Balancing とは – Elastic Load Balancing
- Application Load Balancer とは – Elastic Load Balancing
- Application Load Balancer のターゲットグループ – Elastic Load Balancing
- Application Load Balancer のヘルスチェック – Elastic Load Balancing
- Application Load Balancer のリスナー – Elastic Load Balancing
