ELB

外部からの通信リクエストを分散をさせたい場合、AWSでは"ELB"（読み：イー・エル・ビー）を利用することが一般的である。正式名称を"Elastic Load Balancing"という。
このELBについては、まず ロードバランサ について知っておく必要がある。

ロードバランサとは

ロードバランサとは、以下の図のようにインターネット等の外部ネットワークからのリクエストを複数のサーバに割り振る装置。これによって、ネットワークの負荷を分散（ロードバランシング）することができる。

ロードバランサを利用する理由

スマートフォンのブラウザで動くゲームAを例とする。

このゲームAでは、常時100人以上の人がアクセスしている。このゲーム用のサーバは同時に100アクセスであれば1台のサーバで対応できるものの、ブラウザのゲームなので画面が変わるたびにアクセスが発生する。そうなると常時100人以上の人がアクセスしている場合、サーバへのアクセス数はその数倍となる300〜500アクセスとなる。そのため、1台のサーバでは処理できない。

このような時にロードバランサを利用する。例えば、ロードバランサに6台のサーバを配下に持たせる。こうすることで1台では100アクセスしか対応できなかったものが、6台あるので600アクセス(6台×100アクセス)まで対応できるようになる。

さらにこのゲームでは6台配下に持たせているので、1台サーバが停止しても500アクセス受け付けられるのでユーザには影響がない。つまり、サーバ障害に強い構成にすることができる。

そして、最近ではSSLという暗号を利用したWeb用の通信(HTTPS通信)が推奨されているが、ロードバランサを利用することでロードバランサにそのSSLの設定を行うことで、ロードバランサ配下のサーバにはSSLの設定が不要にすることができる。

これによって、サーバ自体の設定を簡略することができる。

ロードバランサとELBの比較

上記を踏まえた上で話をELBに戻すと、ELBとはAWSで利用可能なロードバランサのこと。そのため、ELBはロードバランサの構成図と同様になるよう設定する（下記の図を参照）
また、ELBを利用する理由もロードバランサを利用する理由と同じ。

なおELBには、

CLB(Classic Load Balancer)
ALB(Application Load Balancer)
NLB(Network Load Banancer)

の3種類がある(2019年現在)。

開発者であればALBを使うことが多い。しかし、それぞれのELBによってできることとできないことがあるので、実現したいことによって使い分ける。詳細な使用用途についてはこちら https://aws.amazon.com/jp/elasticloadbalancing/を参照。

ELB設定例の紹介

ELBの設定例として、上記の構成図と同じようにELBの配下にEC2インスタンスを接続した上で、HTTP通信を受け付けるための設定例を紹介する。なおELBはALBを利用している。

なおALBやCLBには無料枠がありますが、2台以上のELBを稼働させたりELBを通過した一ヶ月の通信量が15GBを超える場合は課金が発生しますので注意が必要。

また、ELBの配下に接続するEC2インスタンスは事前準備をする。またnginxも動いている状態にしておく。

ELBの作成を開始する
サービス→EC2をクリック

「ロードバランサ」をクリック（左側カラムの真ん中あたりにある）し、「ロードバランサの作成」をクリック

Application Load Balancerのところにある作成をクリック

必要な設定値を入力して、セキュリティ設定の構成をクリック
（ALBの名前の入力やHTTP/HTTPSの別、対象VPCとアベイラビリティゾーンのチェックなどを実施）

右下にある「セキュリティグループの設定」をクリックしてから、HTTP/HTTPSの別に合わせてセキュリティグループを設定する（下記画像はHTTPのみ用のALBの場合）設定後ルーティングの設定をクリックする。

ターゲットグループの設定値を入力してから「ターゲットの登録」をクリック
（ターゲットグループの名前を入力したり、配下のサーバの生存確認＝ヘルスチェックで利用するパス等を入力）

配下に組み入れるEC2インスタンス選択してから「登録済みに追加」をクリック

追加できたら「次の手順：確認」をクリック

設定内容を確認して問題なければ「作成」をクリック

作成が完了したら「閉じる」をクリックする

サービス→EC2→ターゲットグループ→ターゲットを開き、状態がhealthyになってることを確認

説明→DNS名でアクセスできるかを確認する
以下の例だと http://sampleELB-958896705.ap-northeast-1.elb.amazonaws.com でアクセスするとALB配下のEC2で動いているホームページが見える。
見えない場合は設定を見直す。

これでELB(ALB)の設定が完了。
もし使わない場合はすぐに削除して、不要な課金が発生しないようにする。

ELBを使う時の注意点

ELBはリクエストを分散できるので便利だが、以下のような場合は注意が必要。

アプリケーションが1台のサーバで完結することを前提にしている場合

例えばショッピングサイトでは「商品をカゴに入れる→注文に必要な情報を入れる→最終確認後に注文ボタンを押す→注文が確定する」という一連の流れが発生する。しかしロードバランサによって最初に振り分けられたサーバと別のサーバに振り分けられると、そこで一連の流れが途切れてしまいまた最初からやり直しが必要だったりする。

そこでこのような場合は、ELBでセッション維持の設定を行う。
設定したい場合は、以下のように設定することで設定情報を持つ秒数の間は一定のサーバに振り分けられるようになる。

ELBを作成した後に"維持設定の編集"をクリック
"ロードバランサーによって生成された Cookie の維持を有効化"を選択
設定情報を持つ秒数を入力

なおこれはELBに限らず、ロードバランサを利用する時も同様。
（設定方法はロードバランサによって異なるので、利用しているロードバランサに合わせて設定方法を確認する）

なおセッション維持はELBの設定による方法だけでなく、redisなどのKVSを利用する方法等もある。それぞれメリットとデメリットがあるのでサービスの要件に応じて使い分ける。

AutoScale

AWSならではのサービスとして"AutoScale"（読み：オートスケール）と呼ばれるサービスがある。

AutoScaleとは

世の中のWebサービスには、昼間はほとんどアクセス数はないが夜になるとアクセス数が増えるとか、何か事件などがあった時に突発的にアクセス数が増えるといったものがある。

このように時間帯によるアクセス数の増減が大きかったり予測ができない場合に役立つのが、AutoScaleである。これによって、必要な時に必要な数のインスタンスを用意することが可能。

CPU使用率やトラフィック量を事前に設定しておいた値を超えたらインスタンス台数が増え、その値より下がったら起動するインスタンス台数を減らすといった挙動ができる。AutoScaleでは外部からのアクセスはまずはELBで受けるため、ユーザはその配下のインスタンス台数を意識する必要はない。

EC2やELBに相当するものはクラウドができる以前からあったが、このようなAutoScaleはなかった。そのためAutoScaleはクラウドならではのサービスといえる。

AutoScale設定例

AutoScaleの設定例を挙げる。
なお課金はEC2インスタンスやELBの利用として発生する。（無料枠もEC2インスタンスやELBに従う）

起動設定の作成

EC2→Auto Scaling グループ→Auto Scaling グループの作成をクリック

「今すぐ始める」をクリック

AutoScaleで利用するAMIの「選択」をクリック

インスタンスサイズを選択し、「次の手順：詳細設定」をクリック

設定名を入力して「確認画面にスキップ」をクリック
（下記の例では sampleAS という名前になっている）

設定内容を確認し、問題なければ「起動設定の作成」をクリック

EC2インスタンスで利用するキーペアを選択して「起動設定の作成」をクリック
EC2インスタンス作成時と同様に行う。

AutoScalingグループの作成

設定値を入力してから「スケーリングポリシーの設定」をクリック
（下記の例では sampleAS-01 というグループ名に、その他VPCやサブネット、ELBを使う場合はその設定等を行う）

「このグループを初期のサイズに維持する」→「次の手順：通知の設定」を選ぶ
これはEC2インスタンスに障害が発生してシャットダウンしても、自動的に1台起動する設定。
これによって、いつでも必ず1台のEC2インスタンスが動いている状態を作り出すことでサービス全体が停止する状態を防ぐことができる。

なおAutoScaleの発動条件や起動するEC2インスタンスの最大数を設定したい場合は、もう一つの「スケーリングポリシーを使用して（以下略）」の方を選ぶ。