前の記事では、 Amazon RDSの基本を学びました。
これまでの学習で、 EC2でWebサーバーを動かし、 RDSへデータを保存する基本的な構成が 見えてきました。
しかし、Webサービスへのアクセスが増えてくると、 新しい問題が発生します。
1台のEC2で処理しきれない場合はどうする？
複数のEC2インスタンスを用意しても、 ユーザーからの通信を 適切に振り分ける仕組みが必要です。
そこで登場するのが、 ELB（Elastic Load Balancing）です。
ELBによる負荷分散の仕組みを理解し、 ロードバランサー・ターゲットグループ・ ヘルスチェック・ALB・NLB の役割を説明できるようになることを目指します。
ELBとは？
ELB（Elastic Load Balancing）は、 AWSで受信した通信を 複数のターゲットへ分散するためのサービスです。
Webサーバーを複数台用意している場合、 ELBを前段に配置することで、 ユーザーからのアクセスを 複数のEC2インスタンスへ振り分けられます。
なぜロードバランサーが必要なのか
Webサーバーが1台しかない構成では、 アクセスがそのサーバーへ集中します。
↓↓↓↓↓
1台にアクセスが集中
↓ ↓ ↓
複数台へアクセスを分散
ELBを利用すると、 複数のサーバーへ通信を分散できるため、 特定のサーバーへ負荷が集中するのを 防ぎやすくなります。
ターゲットとは？
ELBが通信を転送する先を、 ターゲットと呼びます。
たとえば、 複数のEC2インスタンスを ELBの転送先として利用できます。
ELBでは、 転送先となるターゲットを ターゲットグループとして まとめて管理します。
ELBを使った通信の流れ
Webサービスへアクセスした場合の 基本的な通信の流れを見てみましょう。
ユーザーは基本的に、 個々のEC2インスタンスへ 直接アクセスするのではありません。
まずロードバランサーが通信を受信し、 登録されている正常なターゲットへ 通信を転送します。
ヘルスチェックとは？
ELBの重要な機能の1つが ヘルスチェックです。
ELBはターゲットが正常に動作しているかを 定期的に確認できます。
たとえばEC2-02で障害が発生し、 ヘルスチェックに失敗した場合、 ELBはそのターゲットへの 通信転送を停止します。
これによって、 正常に動作しているサーバーへ 通信を転送し続けることができます。
複数AZにEC2を配置する
これまで学んだ アベイラビリティゾーン（AZ） の考え方もELBと関係します。
EC2を複数台用意していても、 すべて同じAZに存在すると、 そのAZで障害が発生した場合に サービス全体へ影響する可能性があります。
複数AZへEC2を配置し、 ELBで通信を振り分けることで、 1つのAZに障害が発生した場合にも 別のAZのサーバーで処理を継続しやすくなります。
ELBには複数のロードバランサーがある
AWSのElastic Load Balancingでは、 用途に応じて複数種類の ロードバランサーを利用できます。
初めに特に押さえておきたいのが、 ALBとNLBです。
HTTP / HTTPSなどの Webアプリケーション向け
TCP / UDPなどの ネットワーク通信向け
ALBとは？
ALB（Application Load Balancer）は、 主にHTTP・HTTPS通信を扱う ロードバランサーです。
ALBは、 HTTPリクエストの内容に応じて 通信先を変更することもできます。
たとえばURLのパスによって、 異なるターゲットグループへ 通信を転送できます。
/images/*
→
Target Group A
/api/*
→
Target Group B
NLBとは？
NLB（Network Load Balancer）は、 主にTCP・UDPなどの通信を扱う ロードバランサーです。
NLBは、 大量の接続や高いパフォーマンスが 求められるネットワーク通信などで利用されます。
ALBとNLBの違い
ALBとNLBは、 どのレイヤーの情報を使って 通信を振り分けるかが大きく異なります。
Webアプリケーション向け
ネットワーク通信向け
NLB → Layer 4・TCP/UDP
ELBとSecurity Group
Webシステムを構築するときは、 ELBとEC2の Security Groupの関係も重要です。
ALBを利用する一般的なWeb構成では、 インターネットからのHTTP/HTTPS通信を ALBで受け付けます。
EC2側では、 インターネット全体から通信を許可するのではなく、 ALBのSecurity Groupからの通信だけを 許可する構成にできます。
EC2へ直接インターネットから アクセスさせるのではなく、 ALBを経由させる構成を考えます。
ここまでのAWSサービスを組み合わせてみよう
ここまで学んだサービスを組み合わせると、 Webシステムらしい構成になってきます。
ユーザーからの通信をALBが受信し、 複数AZに配置されたEC2へ振り分けます。
EC2ではアプリケーションを実行し、 必要なデータをRDSへ保存する、 という構成を作ることができます。
あなたならどのロードバランサーを選ぶ？
ここまで学んだ内容を使って、 適切なロードバランサーを 選択してみましょう。
どちらを選択しますか？
通信の種類に注目して考えてみましょう。
確認問題：ELB
ELBの主な役割として 正しいものはどれですか？
ELBは受信した通信を 複数のターゲットへ振り分ける ロードバランシングサービスです。
ELBのヘルスチェックで 異常と判断されたターゲットはどうなりますか？
ヘルスチェックで異常と判断された ターゲットへの通信転送を停止し、 正常なターゲットへ通信を転送します。
HTTP/HTTPSを利用する Webアプリケーションで 主に利用されるロードバランサーはどれですか？
ALBはLayer 7で動作し、 HTTP/HTTPSを利用する Webアプリケーションなどで利用されます。
3問に挑戦してみましょう。
まとめ
ELBは 受信した通信を複数のターゲットへ分散する サービス
EC2などの転送先を ターゲットグループとして管理する
ヘルスチェックによって 正常なターゲットへ通信を転送する
複数AZへEC2を配置してELBと組み合わせることで 可用性を高められる
ALBはLayer 7で HTTP/HTTPSなどを扱う
NLBはLayer 4で TCP/UDPなどを扱う
Security Groupを利用して ALB → EC2の通信だけを許可する といった構成ができる
しかし、アクセス数は常に同じではない
ELBを利用することで、 複数のEC2インスタンスへ アクセスを分散できるようになりました。
しかし、もう1つ考えなければならないことがあります。
アクセス数は、 時間帯やキャンペーンなどによって 大きく変化します。
アクセスが増えるたびに 人がEC2インスタンスを追加し、 減ったら削除するのでは大変です。
そこで登場するのが、 Amazon EC2 Auto Scalingです。
Auto Scalingの仕組みを理解する
ELBによって通信を分散する仕組みを理解したら、 次はEC2インスタンスそのものを 自動的に増減させる仕組みを学びましょう。
次の記事では、 Auto Scaling Group・最小台数・最大台数・ 希望する容量・スケーリングポリシー などを整理します。
Auto Scalingの仕組みを理解する →