独自VPCでEC2のAutoScalingくらい秒で組めるようになりたい

タイトルの通りです。

何回か試みてはいるのですが、毎回ヘルスチェックで壁にぶつかり、独自VPC上だとIPが発行されなかったり、、、
本記事はその辺を理解してAutoScaling構成を秒で作れるようになるための一連の手順まとめです。

# Contents

* Elastic Load Balancerの使い方（デフォルトVPC使用）
* Auto Scalingの使い方（デフォルトVPC使用）
* VPCの切り方
* Elastic Load Balancer/Auto Scalingの使い方（独自VPC使用）

# 目指す構成

よくある感じのです。Apacheを乗せたEC2にindex.html置き、ELB経由でアクセスするだけの構成から整理していきます。今回はprivateサブネットはつくりません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406130/73560f06-9712-86d8-23fb-e8acc6056e07.png)

# Elastic Load Balancerの使い方（デフォルトVPC使用）

ロードバランサとは読んで字の如しで、load(負荷)をbalance(調整/分散)する優秀なやつです。
まずは、デフォルトのVPC配下、異なるAZ下に2つのEC2(Amazon Linux)を置いてロードバランシングします。

## EC2インスタンスを立てる。

ここで、詳細設定のところで、以下の「高度な詳細」欄にテキストでシェルを書きます。これは、インスタンスを立てる最初に実行したい処理をかけるスペースです。今回は使わずにインスタンスを立て、個々にsshで入ってapacheをインストールしてもいいのですが、今後、AutoScalingするときに大事になってきます。都度都度sshするわけにいかないですからね。

```shell:高度な詳細
#!/bin/sh

yum install httpd -y
sudo service httpd start
sudo chkconfig httpd on
```

今回はインスタンス間で違いをみるため、異なるindex.htmlを配置したいので個々にsshで侵入して配置します。

```html:index.html(1つ目)
Hello I am instance1!
```

```html:index.html(2つ目)
Hello I am instance2!
```


## ターゲットグループを作成する

ターゲットグループとは、ロードバランシングする対象のEC2をひとまとめにしたグループです。
ヘルスチェックなどの設定もここで行ないます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406130/a7f9a3d2-f435-1198-5f65-83d108d4906c.png)

* ターゲットグループ : グループの名前
* ターゲットの種類 : ロードバランシングする対象です。今回はインスタンス。
* ヘルスチェック : 定期的にインスタンスにアクセスしてちゃんと生きてるかELBが確認してくれます。
* パスはヘルスチェック対象の場所 : 後述

### ヘルスチェックとは

前述の通り、ELBは、定期的に各インスタンスにアクセスしにいきます。それは私たちがwebブラウザからアクセスするように、指定したポート（上記では80）へ指定のパスへアクセスします。
このパスに`/var/www/html/index.html`を書くみたいなサイトを見た記憶がありますが、変える必要はないです。

パスに何も指定しない`/`のみ　→ ブラウザにEC2のIPを打つのと一緒 = `xx.xxx.xxx.xxx`
当然アクセスできます。index.htmlがお出迎えです。

パスに`/var/www/html/index.html`を書く　→ ブラウザに`xx.xxx.xxx.xxx/var/www/html/index.html`としてるのと一緒。
当然、弾かれます。

## ロードバランサーを作成、アクセスしてみる

作成画面からALBを選択します。
ここでの`インターネット向け`と`内部`はどこからELBにアクセスするかです。今回のようにhttpでVPC外からアクセスする場合は前者を選びます。
セキュリティグループの設定や、ターゲットグループの設定を終えると終了です。（この辺は流れに沿っていくだけ）

ELBがactiveになるまで数分待ったのち、発行されるDNS名にアクセスしてみましょう。`Hello I am instance1`（もしくは`2`）と出たでしょう。アクセスする度に数字が変わると思います。
これが負荷分散です。

次のAutoScalingに行く前にターゲットグループに設定したインスタンスを登録から外しましょう。インスタンスももう不要です。

# Auto Scalingの使い方（デフォルトVPC使用）

## 起動設定を書く。

ここでは、AutoScaling（スケールアウト）が発動し、インスタンスを立てる際に元となる起動情報を記述します。
基本的にはEC2インスタンスを立てる時と変わりはないです。

```:高度な詳細
#!/bin/sh

yum install httpd -y
sudo service httpd start
sudo chkconfig httpd on
cd /var/www/html
sudo touch index.html
sudo echo "Hello" > index.html
```

## AutoScalingGroup(ASG)の作成

### 1 Auto Scaling グループの詳細設定

配置するAZを指定します。複数選択して可用性を向上しましょう。
今回は初期2台を選択します。
高度な詳細を開くとロードバランサ配下に置くことができます。`ロードバランシング`にチェックを入れ、ターゲットグループに先ほどのものを指定します。
他は特に弄らず次へ。

### 2 スケーリングポリシーの設定

ここでは、スケーリングする条件を指定します。CPU使用率やアラームによってコントロールできますが、今回は意図的にインスタンスを落としてAutoScaleの挙動を確認するため、「このグループを初期のサイズに維持する」を選択し、次に行きます。

それ以降の設定はオプションです。通知が欲しければつけてください。

ASGを作成します。

## 実験

それでは、AutoScalingのテストです。事故を仮定してASGのインスタンスを1台停止してみましょう。
stoppedに変わった数秒後、新たにインスタンスが生成してきます。

ロードバランサのDNSにアクセスするとちゃんと`Hello`が出てきてASGに接続できていることも確認できます。
（ほんとはここもipがわかるようなhtmlを書けるといいのだが知識がたりない、、、）

# VPCの切り方

手順的にはこんな感じ。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406130/e3a5b508-5525-9d2a-d0f5-38dfd6df3352.png)


## 1. VPCを作る。

VPCとは：仮装プライベートネットワーク・・・AWSアカウントのネットワークを論理的に分割した範囲。

EC2コンソールへ行き、サイドバーからVPCを選択して作成。
テナンシーはホストコンピュータを占有するかどうか。
（EC2の仕組みは1つのはすとコンピュータ上に複数のインスタンスが乗っており、ユーザにインスタンスを貸し出している。このホストコンピュータごと指定して占有するにはお金がかかるのだ）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406130/3b3a7646-3bf0-de8f-19e8-a7942f408e87.png)

## 2. サブネットを作る。

同じくEC2コンソールのサイドバーからサブネットを選択して作成。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406130/291ca2ff-aace-2249-9da7-1f78b257298d.png)

VPCを論理的に分割するのでCIDERブロック`/16`で区切ったVPCの中で区切る（16〜28の範囲で指定）。
一般的にはパブリックサブネットとプライベートサブネットとし、前者はインターネットと繋ぎ、後者は繋がない（VPC内からしかアクセスできない）といった使い方をします。

なお、のちにEC2を立てるときに自動でパブリックIPを付与するようにするなら、サブネットを作成後にここで設定を編集します。

このままではこのVPCはインターネットと繋がっていないので、EC2を立ててもsshで入ることもできない。なので、インターネットゲートウェイを設定します。

## 3. インターネットゲートウェイ・ルートテーブルを設定する。

インターネットゲートウェイとは：VPCをインターネットに繋ぐためのルータのようなもの。

同じくEC2コンソールのサイドバーからインターネットゲートウェイを選択し、作成します(名前をつけるだけ)。
アクションから[VPCヘアタッチ]を選択して作成したものにアタッチ。

ついで、ルートテーブルを作成する。サイドバーより選択。
名前をつけた後、アクションから[ルートの編集]を選択し、送信先`0.0.0.0/0`のターゲットを作成したインターネットゲートウェイに設定します。

これでVPCと接続できたが、まだVPC内部のサブネットには繋がっていない状態です。

## 4. ルートテーブルをサブネットに紐づける。

サイドバーのサブネットを選択し、アクションから[ルートテーブルの関連付けの編集]を選択。
ルートテーブルを上で作成したものに設定する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406130/e01b3f36-a290-9c73-4333-53015b64ed3e.png)

# Elastic Load Balancer/Auto Scalingの使い方（独自VPC使用）

上記の方法で設定したVPCを使います。ただし、2つのAZにEC2を配置したいので、追加でサブネットをもう一つ作って同じようにネットワークとつないでください。

* 1つめのサブネット(AZ-a): 10.0.0.0/24 (作成済み)
* 2つめのサブネット(AZ-c): 10.0.1.0/24

## ELBを設定する。

変更点のみ記します。
今回は、ロードバランサ作成時に指定するVPCをデフォルトではなく、上記で作成した物に変えます。その際、VPC関連でミスっていると以下のように警告されます。

> インターネット向けロードバランサーを作成中ですが、次のサブネットにはアタッチされたインターネットゲートウェイが存在しません

# Auto Scalingを設定する。

変更点のみ記します。
起動設定の高度な詳細の中で、`IPアドレスタイプ`を選択する欄があります。「パブリック IP アドレスを各インスタンスに割り当てます。」を選択。
これがないとASG作成に際して以下の警告が出ます。

> パブリック IP アドレスは割り当てられません
デフォルトの VPC およびサブネットで起動することを選択しなかったため、この Auto Scaling グループのどのインスタンスにもパブリック IP アドレスが割り当てられません。
デフォルト VPC のデフォルトサブネットのみを選択することにより、この設定で起動されたインスタンスにパブリック IP アドレスが割り当てられるようにすることができます。

あと、少し謎だったが、起動設定を作成する流れでセキュリティグループを作成したところ、セキュリティグループのVPC IDがデフォルトのもので設定されてしまい、以下のエラーでASGが作成できない問題に遭遇しました。
セキュリティグループのコンソールからまず、VPC IDを指定して作成し、起動設定作成時に既存のものから選択という形で対応することができた。

> One or more security groups in the launch configuration are not linked to the VPCs configured in the Auto Scaling group

起動設定にあるセキュリティグループのVPC IDとAuto Scaling Groupで設定しようとしているVPCが違うよと怒られています。

上記を一通り終えると、同じくELBのDNS名にアクセスすると`Hello`が拝めます。

# おしまい

まあ、ロードバランサを立てる時点で数分待たないといけないので秒で構築はできないわけなんですが、だいぶ分かってきました。
~~次は、AutoScalingGroupへCodeDeployからデプロイを試みます。~~

# 追記

* [超ミニマムなチュートリアルを通してCodeDeployを理解する2(AutoScaling編)](https://qiita.com/Kept1994/items/8abeeb8fa0980f95ab56)