はじめに
EC2は触ったことがあったのですが、ELBやAutoScalingはなかったので、
今回この記事を作ることにしました。
よくある構成だとは思いますが、
一連の流れを備忘として残して起きます。
今回構築するシステムの概要図は以下の通りです。
Application Load Balancer（ALB）で通信の負荷分散を行います。
また、Auto Scalingを用いて、アクセス量に応じてEC2のインスタンス数を増減させます。
インスタンス数の増減は、Cloud Watchで平均CPU使用率を求めて、
一定の使用率に達したらインスタンスの増減を行うようにしています。
Auto Scalingを行うことにより、
アクセス数の少ない時間帯（深夜や早朝？）はインスタンス数を減らし、
アクセス数の多い時間帯（昼間〜夕方）はインスタンス数を増やすことができます。
それによってEC2のコストを抑えることが出来るという仕組みですね。
セキュリティグループの作成
はじめにセキュリティグループを作成します。
ブラウザからHTTPでアクセスするので、自分のIPアドレスかつ、
HTTPプロトコルの場合のみアクセス出来るようなセキュリティを作成します。
セキュリティグループの作成はEC2から行いますので、コンソールからEC2を選択して、
左ペインからセキュリティグループを選択します。
新しく作成する必要があるので、セキュリティグループを作成をクリックします。
セキュリティグループ名はなんでもいいです。
今回はFor Web Serverとかにしておきます。
画像では入力されていませんが、説明も入力する必要があります。
This is Demo Securityとかにしておきます。
インバウンドルールにてルールを追加をクリックし、
タイプをHTTP、ソースをマイIPにします。
アウトバウンドルールはいじらなくて大丈夫です。
タグですが、今回の記事で作ったものだと分かりやすくなるように、
キーにSystem、値をDemoELBとしてセキュリティグループを作成します。
ターゲットグループの作成
次に、負荷分散を行うターゲットグループの作成を行います。
ターゲットグループの作成はEC2から行いますので、
EC2からの左ペインからターゲットグループを選択します。（結構下の方にあります。）
ターゲットグループの作成をクリックします。
ターゲットタイプはインスタンスを選択します。
ターゲットグループ名はDemoTargetGroupにします。
プロトコルとVPC、プロトコルのバージョンはデフォルトのままでいきます。
ヘルスチェックプロトコルもHTTPを選択し、
ヘルスチェックパスは/を指定します。（デフォルト）
ヘルスチェックの詳細設定は、少し修正していきます。（デフォルトでも平気です。）
間隔を３０秒から１０秒に変更します。（すぐに確認できるようにするため）
タグは今回の記事で統一すつので以下のようにします。
これから色々作成するたびにこのタグを入れるので次からは省略します。
全て入力が終わったら、次へをクリックします。
ターゲットはまだ登録できないので、そのままにして作成します。
Application Load Balancer（ALB）の作成
複数のEC2インスタンスで同じWebアプリケーションを起動します。
入り口として、ALBを用いて負荷分散を行います。
先ほど作成した、セキュリティグループやターゲットグループを用いて、
特定のIPアドレスから特定のターゲットに負荷分散を行うことが可能です。
ALBの作成はEC2から行いますので、
EC2からの左ペインからロードバランサを選択します。（結構下の方にあります。）
何もない状態なので、ロードバランサの作成をクリックします。
ロードバランサの種類は、一番左のApplication Load Balancerを選択。
基本的な設定は以下の通りになります。
ロードバランサ名はそのままの意味です。
ここで入力する名前が、ロードバランサのDNS名に反映されます。
スキームは、インターネット向けを選択します。
内部のEC2からEC2にアクセスする際に負荷分散を行う場合は内部でいいですが、
今回はブラウザから普通にアクセスするので、インターネット向けにします。
ネットワークマッピングの設定は以下の通りです。（見切れてます。。。）
VPCは、とりあえず試すだけなのでデフォルトで設定します。
またAZに関しては、可用性を考慮するために、AZ-aとAZ-cにしました。
ap-northeast-1aとap-northeast-1cにチェックをすればOKです。
セキュリティグループは、先ほど作成したFor Web Serverを選択します。
リスナーとルーティングは、先ほど作成したDemoTargetGroupを選択します。
ロードバランサの設定は以上になりますので、
ロードバランサの作成をクリックして作成します。
セキュリティグループの作成
またセキュリティグループの作成？？と思うかもしれませんが、
次は、先ほど作成したALBからEC2にアクセスするためのセキュリティグループを作成します。
面倒な方は飛ばしても大丈夫ですが、
そんなに面倒ではないですし、知っておいた方がいいことだと思います。
まず、セキュリティグループを作成する前に、
ALBのIPアドレスを調べる必要があります。
EC2の左ペインからネットワークインターフェースを選択します。
検索欄にALBの名前を入力します。
私の場合はDemoELBです。
すると先ほど作成したALBのインターフェースがありますので、
その中のプライベート IPv4アドレスを確認します。
ちなみに、もう一つの方は172.31.43.58でした。
セキュリティグループの作成の手順は、一部割愛します。
インバウンドルールの箇所では、タイプをHTTPにし、
ソースはカスタムを選択後、右の空欄に172.31.0.0/16の形式で入力します。
/16にすることで、172.31.1~255.1~2551のアドレスがアクセスできます。
172.31.0.0の前半二つ（第二セグメントまで）の内容は私と異なっている可能性があります。
私自身きっちりと理解できておらず申し訳ないです・・・。
もう一つ、SSH接続するためのインバウンドルールを追加します。
ルールを追加をクリックし、タイプはSSHを選択、ソースはマイIPを選択。
アウトバウンドルールについてもルールの追加を行います。
HTTPとHTTPSの許可を行いました。
起動設定の作成
Auto Scalingでどのようなインスタンスを起動させるか設定します。
今回は、Amazon Linux 2 インスタンスを利用します。
EC2の左ペインからインスタンスを選択し、インスタンスを起動をクリックします。
マシンイメージが表示されていると思いますので、
クイックスタートの中にある、Amazon Linux 2 AMIを探します。
太文字の後に記載されている、ami-02892~~~をコピーしてください。
64ビットの前までで大丈夫です。（もしかしたら記載内容違うかもしれないです。）
コピー後に右上のキャンセルして終了をクリックします。
次にEC2の左ペインから起動設定を選択し、起動設定の作成をクリックします。
名前は、DemoStartupSettingsとかにしておきました。
AMIですが、先ほどコピーしたやつを貼り付けて、表示されたものを選択します。
インスタンスタイプは、無料利用枠対象のt2.microを選択します。
続いて、追加設定項目ですが、高度な詳細タブを開きます。
するとユーザデータという項目があるので、下記を入力します。
ユーザデータとは、初回起動時に自動実行してデプロイを自動かする機能です。
今回は、Apacheをインストール・起動して、
index.htmlにAZ、インスタンスID、IPアドレスを書き込んでいます。
# !/bin/bash -ex
yum -y update
yum -y install httpd
systemctl enable httpd.service
systemctl start httpd.service
AZ=`curl --silent http://169.254.169.254/latest/meta-data/placement/availability-zone`
INSTANCE_ID=`curl --silent http://169.254.169.254/latest/meta-data/instance-id`
IP_ADDRESS=`curl --silent http://169.254.169.254/latest/meta-data/public-ipv4`
echo $AZ\<br\> >> /var/www/html/index.html
echo $INSTANCE_ID\<br\> >> /var/www/html/index.html
echo $IP_ADDRESS\<br\> >> /var/www/html/index.html
ユーザデータ以外はデフォルト値でOKです。
入力後は以下のようなイメージです。
ストレージは、デフォルトでOKです。
セキュリティグループは先ほど作成した、ALB to EC2を選択します。
EC2に接続する際に必要なキーペアですが、今回は新しいキーペアの作成を選択します。
キーペア名を適当に入力してから、キーペアのダウンロードをクリック。（必須）
Auto Scalingグループの作成
次にEC2の左ペインにある、Auto Scalingグループを選択します。
名前は、適当な名前を入力します。
起動設定は、項目の右上にある、起動設定に切り替えるという文字をクリックします。
その後先ほど作成した起動設定のものを選択して次へをクリックします。
ネットワークの設定では、サブネットにAZ-aとAZ-cを追加して次へをクリックします。
次に詳細設定ですが、ロードバランサは作成しているので、
既存のロードバランサにアタッチを選択します。
これを選択することにより、ALBのターゲットに追加されることになります。
ターゲットグループは先ほど作成したものを選択します。
その他の設定項目はデフォルトのままで次へをクリックします。
グループサイズは以下のように設定しました。
最小でも2つのインスタンスを起動し、アクセス数が増えたら最大で10個まで起動します。
スケーリングポリシーは以下の通りです。
全てのインスタンスの平均CPU使用率が60%を超えた場合にインスタンスを追加します。
通知設定は特に行わないので、スキップして作成を行います。
Auto Scalingグループが作成できました。
動作確認
一通り構築が完了したので、これから動作確認を行いたいと思います。
インスタンス確認
EC2インスタンスを確認したところ、Auto Scalingにより、
最小数である2つのインスタンスが作成されたことが分かります。
ヘルスチェック確認
左ペインのターゲットグループから、対象のターゲットを選択します。
インスタンスが2つ紐づいており、ヘルスステータスもhealthyであることが確認できました。
Auto Scalingグループ確認
左ペインのAuto Scalingグループから、対象のグループを選択します。
インスタンス管理を開くと、2つのインスタンスを管理していることが確認できました。
インスタンス接続確認
左ペインのロードバランサーから、対象のELBを選択します。
下にELBの情報が表示されますので、その中からDNS名をコピーします。
ブラウザを開き、URL欄に先ほどコピーしたものを貼り付けます。
すると、インスタンスのリージョンとインスタンスID、
パブリックIPアドレスが記載されていることが確認できます。
何度か更新してみて、二つのインスタンスの情報が表示されていることを確認します。
確認できたら、しっかりと負荷分散できているということになります。
次に、インスタンスのIPアドレスのみで検索した場合に、
表示されずにエラーが返ってくることを確認しましょう。
EC2へは、自分のPCからのSSH接続か、ELB経由のHTTP接続しか許可されていません。
なので、ELBを経由しないダイレクトなアクセスは拒否されます。
スケールアウトの確認
問題なく構築できていることが確認できたので、
次にCPU使用率を60%以上にした場合の動きを見ていきます。
まずは、インスタンスに負荷をかけるために、
インスタンスに対してSSH接続を行います。
起動設定でダウンロードしたキーペアの出番です。
私の場合はMacで操作しているので、Windowsの方は少し操作が異なると思います。
まず、ターミナルを開いて以下のコマンドを実行します。
/******/は、キーペアが格納されている場所によって異なります。
ファイルをターミナルにドラッグ＆ドロップすれば自動で入力されるのでオススメです。
-rw-r--r--が、-r--------に変わればOKです。
$ ls -al /******/DemoEC2key.pem
-rw-r--r--@ 1 ryosuke staff 1674 10 2 15:21 /******/DemoEC2key.pem
$ chmod 400 /******/DemoEC2key.pem
$ ls -al /******/DemoEC2key.pem
-r--------@ 1 ryosuke staff 1674 10 2 15:21 /******/DemoEC2key.pem
次にターミナルからSSH接続を行います。（windowsはTeraTermなどを利用します。）
1行目は各自のインスタンスのIPアドレスにしてください。
また、途中でyes/no/[fingeprint]と聞かれますので、yesと入力しEnterを押します。
[ec2-user@ip-**-**-**-** ~]$ と表示されればOKです。
$ ssh -i /*******/DemoEC2key.pem ec2-user@<パブリックIPアドレス>
The authenticity of host '54.64.219.57 (54.64.219.57)' can't be established.
ECDSA key fingerprint is SHA256:iISNxlgrJI8+2dVkZYWTGmJ+clGEHIplU8w0W9RXkdk.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '54.64.219.57' (ECDSA) to the list of known hosts.
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
[ec2-user@ip-172-31-12-149 ~]$
これでインスタンスにログインすることができました。
次に負荷をかけてCPU使用率を上げようと思います。
ログインした状態で以下のコマンドを実行します。
実行後に応答が返ってきませんが、それが正常ですのでご安心を。
また、複数ターミナルを開いて実行すると早く使用率が上がります。
$ yes > /dev/null
実行後にAuto Scalingグループを確認します。
EC2の左ペインから、Auto Scalingグループを選択し、対象のグループを選択します。
その後、モニタリングタブを開きEC2を選択します。
すると、CPU使用率の点グラフ？があります。
複数ターミナルを開いてやったので、使用率がほぼ100％になってます。
テストだからいいもののリアルだったら恐怖ものですね・・・。
しばらく時間をおいてから、インスタンスの数が増えているか確認した結果、
2つだったインスタンスが4つに増えていました。
CPU使用率が増えた（アクセス量が多くなった）時に、
インスタンスの数が増えるような流れが、これで確認できました。
スケールインの確認
次にCPU使用率が減った時にインスタンスの数が減るのかを確認していきます。
先ほどのyes > /dev/nullコマンドを、control + cで中止します。
少し時間を置いてから確認したところCPU使用率が下がっておりました。
CPU使用率が下がっているということは、インスタンスが減っていることが期待値です。
EC2インスタンスの個数を確認したところ、最小個数の2つになっていました。
以上で一通りの動作確認も完了しました！
さいごに
かなり長くなってしまいました・・・。
作成したインスタンスやセキュリティグループ、ELBなどは削除して大丈夫です。
というよりも、削除しないと無駄に料金がかかる可能性があります！
以上、最後までご覧いただきありがとうございました！