AWS運用 ELBを用いた負荷分散で“高可用性”を実現しよう（初心者向け）

皆さんこんにちは、セールスアシスタントの犬飼です。 IT についてはまだまだ勉強の毎日ですが、ブログを執筆することで自分自身非常に勉強になっております。

本ブログでは「 ELB（Elastic Load Balancing）」について、お話をしていきます。AWS運用において、“冗長化”や“高可用性”という言葉を耳にすることはないでしょうか？

“そもそも冗長化、高可用性ってなに？”
“サーバー運用する際に、どのサービスを活用すれば高可用性を実現できるの？”
“ ELB は3種類あるけど違いは何だろう…？”　など

上記のように私自身が抱いていた疑問点について、皆さんへわかりやすく解説し、 ELB を用いたユースケースもご紹介していきたいと思います。

少しでも皆さんのAWS運用のお力添えができればという思いを込めて、本日も始めていきます〜！

AWS運用 ELBとは

本章では、まず AWS が提供している ELB について説明していきます。

「 Amazon Elastic Load Balancing（通称 ELB ）」とは、 AWS が提供している“負荷分散”、“ヘルスチェック機能”を備えたロードバランサーサービスです。 ELB にはたくさんの特徴がありますが、ひとつずつ説明すると長〜いお話になってしまいますので、今回は IT 初心者の皆さんにぜひ知っていただきたい、3つの代表的な特徴に絞ってご紹介していきたいと思います。

高可用性（スケーラブル）

ELB はトラフィックを自動的に分散し、サーバがダウンしてしまうのを防ぐ役割を持ちます。また、 ELB 自体も負荷に応じてキャパシティを自動増減するので、管理者が ELB の台数を増やしたり、スペックを上げたりする必要はありません。

ヘルスチェック

Elastic Load Balancing では、リクエストの追跡機能を提供します。これにより、接続しているサーバのパフォーマンスをリアルタイムでモニタリングできます。接続しているサーバの中で“異常なサーバを検出”すると、それらのサーバに対するトラフィックの送信を中止し、残りの正常なサーバに負荷を分散できます。

SSL証明書

ELBにSSLの設定を行うことができます。SSLを利用した場合でも特に追加の料金は必要ありません。

ELB の特徴について、少しイメージがつきましたでしょうか？
ELB は、接続しているどのサーバに仕事を依頼したら、仕事が早く終わりそうかをモニタリングしており、サーバの忙しさが均一になるように依頼を出す「司令塔」のような役割なのだと簡単に理解していただければと思います。

その他の特徴については、機会があれば記事にしたいと思います！

ELB の種類（ ALB , CLB , NLB ）

Elastic Load Balancing は、現在3種類のロードバランサーをサポートしています。サーバの要件に合わせて、ロードバランサーを選択できます。

3つも種類があったんですね…
それぞれの特徴をご紹介していきます。

	1. CLB (Classic Load Balancer)	2. NLB (Network Load Balancer)	3. ALB (Application Load Balancer)
特徴	Classic（旧型）という位置づけの汎用型 HTTP/HTTPS に追加して TCP/SSL も扱える L4, L7	暖機申請（予測される負荷を事前に申請すること）が不要なので高速処理向け TCP 専用 L4	現状の第一選択肢となる汎用型 HTTP/HTTPS 専用 L7
対象	VPC	VPC	VPC, EC2-Classic
特徴	行きも帰りも LB を経由する	行きは LB を経由するが帰りは経由しない。その分だけ他の LB より性能が良い。宛先 IP は対象サービス（EC2など）の IP に書き換えらえれる。よってクライアントへの戻りの経路を確保する必要あり。	行きも帰りも LB を経由する
プロトコル	HTTP, HTTPS	TCP	SSL, TCP, HTTP, HTTPS
Elastic IP アドレスの割り当て	—	可能	—
固定アドレスの割り当て	—	可能	—
Route 53 でのレコード	主に Alias レコード（A レコードは不可）	A レコード可能	主に Alias レコード（A レコードは不可）
セキュリティグループでの制御	〇	—	〇
基本機能（ヘルスチェック、CloudWatch メトリックス、ログ、AZ フェイルオーバ、Connection Draining）	〇	〇	〇
Web Sockets	〇	〇	—
クロスゾーンロードバランシング	〇	—	〇
SSL オフローディング	〇	—	〇
スティッキーセッション	〇	—	〇
バックエンドサーバの暗号化	〇	—	〇

項目がたくさんありますが、特に知っていただきたいポイントは下記でご説明いたします。

1. CLB (Classic Load Balancer)

AWS より初期から提供されている ELB です、複雑な設定はできないところが弱点です。HTTP/HTTPS と TCP/SSLプロトコルの標準的な L4 と L7 における、ロードバランシングが可能です。現在、 AWS からは推奨されていない旧タイプでございます。

2. NLB (Network Load Balancer)

NLB は超低遅延で高スループットを維持しながら秒間何百万リクエストをさばける様に設計された最新のロードバランサーです。 TCPプロトコルの標準的な L4 における、ロードバランシングが可能です。ですので、大量のアクセスが予測される（高負荷が予定されている）ケースに推奨されています。

3. ALB (Application Load Balancer）

HTTP, HTTPS プロトコルの L7 の対応が強化された単一ロードバランサーです。異なる URL ごとにサーバへリクエストを振り分けることが可能です。 CLB に比べて、細かい設定が可能です。
WEBアプリケーション用のロードバランサーとしてはこちらが最も利用されています。

ALB は、ヘルスチェック利用中にロードバランサーの内部のサービス状態をリアルタイムでモニタリングできる特徴があります。リクエストの追跡や Amazon CloudWatch メトリクスを利用すると、アプリケーションの状態とパフォーマンス情報を受け取ることができます。アプリケーション運用のモニタリングによって負荷を事前に察知することも可能です。

比較表にも記載している通り、 ALB と CLB は行きと帰りの通信もロードバランサを経由して、クライアントと通信します。一方、 NLB はトラフィックの宛先 IP をターゲットの IP に書き換えて転送するため、帰りはロードバランサを介さず、ターゲットからクライアントに直接通信する形になります。 NLB はロードバランサとしての処理が少なく済むため、低遅延の仕組みとなります。しかしその分、機能はシンプルです。

AWS運用 ELB 有無での比較紹介（メリット）

先述の1章、2章では ELB の特徴・機能・種類について詳しく説明しました。

本章では、 ELB を使用しない場合と使用する場合を比較していきますので、改めて ELB のメリットについてご理解いただければと思います。

ELB無しの場合

リクエストの負荷分散ができない

→ アクセスが集中してサーバがダウンしてしまうと、サイト表示が出来ない等の問題が発生する

通信を HTTPS (SSL) 化したい場合に EC2 にSSL証明書をインストールする必要がある

→ SSL証明書の購入、管理、インストール等さまざまなコストがかかる

ELB 有りの場合

通信の HTTPS (SSL) 化

→ ACM (Amazon Certificate Manager) で無料取得できるSSL証明書やお客様で購入したSSL証明書をインポートして、 ELB にインストールすることができる

※ただし、 Client -> ALB 間の通信が対象
ALB -> EC2 間の通信をSSL化したい場合は、 EC2 側にSSL証明書をインストールする必要がある。

負荷分散

→ EC2 を複数台 ELB に紐付けることでリクエスト処理を分散することができ、 EC2 1台あたりの負荷を軽減することができる

ELB のアクセスログを指定した S3 に自動保管することができる

改めて、 ELB を利用する場合のメリットをご理解いただけましたでしょうか？
ぜひ ELB を活用し、AWS運用における高可用性を実現していただければと思います。

とはいえ、上記のような文章だけだとイメージが湧きづらいと思いますので、最後の章では、弊社で実際によくご利用いただく ELB の構成パターンをご紹介していきます！！

AWS運用における ALB を用いた構成（ユースケースのご紹介）

本章では、複数のお客様から利用用途や規模に関係なく、幅広く使用いただいている ALB の利用を前提に説明していきます。

EC2 1台運用パターン

こちらの構成は、 AWS が提供している ACM の無料SSL証明書をご利用いただく為に、 ELB をご利用いただくケースが多いです。

EC2 複数台運用パターン

こちらの構成は、 ACM の無料SSL証明書に加え負荷分散目的で ELB をご利用いただくケースが多いです。複数台構成だと一般的な構成ですね〜！

EC2 複数台運用 Auto Scaling との連携パターン

こちらの構成は、 Auto Scaling を用いて複数台構成をとるケースです。需要が予想しにくい場合や、高負荷時に自動でスケーリングさせてサービスを安定稼働させたい場合によく用いられます。