【AWS】「ELB」、構築手順

ELBとは？

Webサーバーが2台ある場合にアクセスを分散するロードバランサの役割をします。

概要

複数のEC2インスタンスに負荷分散をします。

複数のAZにある複数のEC2インスタンスの中から正常なターゲットにのみ振り分けます。（ヘルスチェック）

複数のAZに振り分ける際に最も効果を発揮します。複数あるEC2インスタンスの中で正常に稼働しているサーバーに振り分けます。

SSLターミネーションとしての役割

ELBに証明書をアタッチすることで、通信の暗号化複合化を行ってくれてEC2は本来の役割に専念できます。ちなみに、証明書はAWS Certificate Manager(ACM)で作成すれば無料になります。（無料の証明書はLet's Encryptが有名だが、ACMはコンソールからポチポチ操作ができるので簡単です。）

特徴

スケーラブル（オートスケール）

ELB自体も負荷に応じて自動でスケールアウト・スケールインします。大量のアクセスが来てもELBの処理が追いつかないということがありません。

AZをまたがる構成

ELBを利用する場合は一つのリージョンを選んで、そのリージョン内AZをまたがるように構成できます。

名前解決

DNS名を割り当てることが可能で、ELBへの接続ポイントへのアクセスにDNSを使用します。

安価な従量課金

従量課金で利用可能

マネージドサービス

運用が楽

内外のロードバランサ種類

2種類に分かれます。外部も内部もどちらのロードバランサもプライベートIPアドレスを対象にするのでWebサーバにパブリックIPアドレスを設定する必要がありません。

外部向けELB

外部通信のバランシングに使われます。

内部向けELB

内部通信のバランシングに使われます。オンプレでは内部のロードバランサはあまり使われないでしょうが、AWSでは基本的な設計パターンになります。

アイドルタイムの設定

デフォルトで60秒であり、60秒間通信がなければELBがコネクションを閉じる動きとなります。

リスナー

図

設計方針

• DNS(Route53など)でアクセスすること。
• ELB自体をVPC内、アベイラビリティゾーン内に配置する。
• ELBは外側からのアクセスを受け付けるためパブリックサブネットに配置する。
• ターゲットは外部からアクセスさせる必要がないのでプライベートサブネットに配置する。

トラフィックを受け付けるポートとプロトコルを設定しておく。

リスナーにはあらかじめポートとプロトコルを設定しておきます。

トラフィックをターゲットグループへルーティングする。

ターゲットグループ

「トラフィックの送信先（流す対象）」のこと。EC2、Lambda、またはプライベートIPアドレス（オンプレミスを対象にできる。）になります。

ルール

ターゲットグループ、条件、優先順位を指定したもの。

設定した条件に合致した場合、設定したアクションが実行される。

ヘルスチェック

トラフィック送信先のEC2状態が正常か監視するためEC2が一定の間隔でEC2にリクエストを送信してチェックの結果正常の状態のみEC2にリクエストを送信します。

レスポンスタイムアウト

ターゲットからのレスポンスが返ってこない場合に失敗とみなす秒数。デフォルトで5秒。

インターバル

ヘルスチェックが行われる間隔。デフォルトは30秒、5秒〜300秒

HealthyThresholdCount

異常なターゲットが正常であると見なされるまでに必要なヘルスチェックの連続成功数、範囲は2-10、デフォルトは5

ロードバランサの種類

ELBで選択できるロードバランサには下記の3種類があります。

• Application Load Balancer
• Network Load Balancer
• Classic Load Balancer

Application Load Balancer

L7(アプリケーションレイヤー：HTTP、HTTPS、HTTP/2)で負荷分散する場合に使います。Webサービスを作成する際は基本的にはこのロードバランサを選びます。スケールするとIPアドレスが変わってしまうのでアクセスする際は必ず独自ドメインでアクセスするようにしましょう。

Network Load Balancer

L4(TCP、UDP、TLS)で負荷分散する場合に使います。ネットワーク通信経路を分散できます。行きの経路は「Application Load Balancer」と同じですが、帰りの経路がロードバランサを介さずに直接クライアントに通信を返します。なのでApplication Load Balancerに比べるとより遅延がない通信を実現できます。高いパフォーマンスを求めるのであればこちらを使った方が良いですが、普通のWebサービスを作るのであれば「Application Load Balancer」で十分でしょう。なお、アクセスしてもIPは変わらないので必ずしも独自ドメインを使わなくても良いです。

Classic Load Balancer

Network Load Balancerに近いですが、旧バージョンになるので基本的には選ばなくても良いでしょう。スケールするとIPアドレスが変わってしまうのでアクセスする際は必ず独自ドメインでアクセスするようにしましょう。

構築のポイント

アベイラビリティゾーンを跨って配置すること

あるエリアがダメになっていても別のエリアで稼働をさせることができます。

Webサーバをステートレスに構築すること

Webサーバーに状態を持たせないように構築することです。持たせるデータは必ずDBサーバーを別途構築する等、別サーバーに分けると良いでしょう。

WebサーバのKeep-aliveのタイムを長くする。

WebサーバはKeep-aliveの設定をロードバランサのアイドルタイムよりも長くすることが推奨されています。

サーバーを冗長化する。

新しく冗長化するためのサブネットを作成する。

すでに冗長化したいサーバーを作成しているリージョンのVPC内に新しくサブネットを作成します。作成する際は、冗長化対象のサーバーが配置してあるAZとは別のアベイラビリティゾーンを選択します。

AMIイメージを作成する。

「EC2→アクション→イメージ→イメージの作成」で「イメージ名」だけ入力して「イメージの作成」をクリックします。

AMIから起動する。

「イメージ→AMI」にて作成されたAMIを確認することが可能です。「起動」をクリックし新しくEC2インスタンスを作成します。その際は下記の点に注意しましょう。

• サブネットは先ほど作成したサブネットを選択する。
• セキュリティグループは既存のWebサーバのセキュリティグループを使いましょう。
• キーペアも既存で使っているキーペアをそのまま流用すると良いでしょう。

構築手順

ELBの作成：手順1：ロードバランサーの設定

名前

ロードバランサの名前を入力しましょう。

スキーム

Webサーバーを冗長化したいのであればインターネット向けを選択しましょう。

リスナー

接続リクエストをチェックするプロセスになります。WebサーバであればHTTPの80番で良いでしょう。

VPC

対象のVPCを選びます。

アベイラビリティーゾーン

冗長化したいAZをそれぞれ選択します。

ELBの作成：手順2：セキュリティ設定の構成

特にそのままで大丈夫です。

ELBの作成：手順3：セキュリティグループの設定

新しいセキュリティグループを作成します。Webサーバーの場合はHTTPアクセスをフルオープンするような設定とすると良いでしょう。

ELBの作成：手順4：ルーティングの設定

ターゲット

EC2インスタンスを選びます。

プロトコル

HTTP:80を選びます。

ロードバランサ作成後

正常時の動作確認

alb（ロードバランサ）のURLができます。実際に、何度もアクセスしてみればわかりますが、アクセスする度に別の冗長化されたサーバーへアクセスが自動的に振り分けが行われます。

ただ、このままではURLのドメイン名が動的に生成された無機質な物になってしまっているので、実務で運用する場合は独自ドメインを取得してRoute53のAレコードのエイリアスの値に生成されたロードバランサのURLを指定するようにしましょう。

サーバ停止時の動作確認

実際に、どちらかのEC2インスタンスを停止させてURLにアクセスしてみればわかるのですが、ELBのヘルスチェック機能が働いてサーバーがunhelthyと判定され振り分けが行われなくなります。ステータスがhelthyとなっているサーバのみにアクセスを運ぶようになります。