ハンズオン3_スケーラビリティのあるブログサービスを構築する

※2021.10.03更新:くろかわ(@AwsskillC)さんに指摘いただいた内容を追記しています。


この記事を書いている私について

インフラ系PMO歴半年でAWSクラウドプラクティショナーを取ったばかりの私が
AWS CloudTechという動画学習サービスに参加し、AWSエンジニアを目指すための備忘録です:fire:
AWSを使った運用から開発まで極めるため日々精進:fire:


この記事を書こうと思った経緯
-

 前回の記事[ハンズオン2_冗長性のあるブログサービスを構築する（冗長構成）](https://qiita.com/zetzetn/items/ee50683b39f56658b586 "ハンズオン2_冗長性のあるブログサービスを構築する（冗長構成）")の続きです。


本記事の目標
-
前回の構成ではエンドユーザーから大量の通信があっても、ELBを配置しているため、
2台のEC2インスタンスに対しては通信を分散して振り分けてくれる構成でした。

しかし、2台のEC2が処理しきれないほどの通信が大量発生することも想定し、
Auto　Scalingを設定してEC2を条件に合わせて増減してくれるように構成したいと思います。

具体的には、ELBの配下にAuto Scalingグループを紐づけて、EC2インスタンスを最小２、最大４の範囲でスケーリングをさせます。

Auto Scaling全体のCPU使用率を監視するアラームを2つ作成し、アラームとAuto Scalingのスケーリングポリシーを紐づけます。
CPU使用率が70%以上になったらインスタンスを1台増やし、30%以下になったら1台減るような構成にします。



今回の構成図
-
![【ハンズオン3】スケーラビリティのあるブログサービスを構築する.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/465906/62cd7839-d04b-d082-8bd1-2721716339d4.png)

※構成図の作成に[cloudcraft](https://app.cloudcraft.co/ "cloudcraft")を利用しています。
　



構築の流れ
-

以下の流れで構築を進めます。

・前回の環境を再構築
・起動テンプレートを作成
・Auto Scalingグループを作成
・CloudWatchでアラームを設定
・アラームとスケーリングポリシーを紐づけ
・負荷テスト



・前回作成したEC2インスタンスを開始にする
-
　前回作成したEC2インスタンスが停止済みとなっていると思いますので、開始にします。
　
＊504 Gateway Timeoutと表示される場合、前回記事の「EC2再起動後に発生する問題を回避するためには」を実施してください。

・RDSを復元
-
前回保存したスナップショットからRDSを復元します。

・ブラウザからブログが閲覧できることを確認
-
EC2インスタンスからパブリックIPアドレスをブラウザに張り付け、ブログにアクセスできるか確認します。

・ロードバランサーを作成
-
今回はALBを選択しました。
2つのEC2をターゲットとにするよう設定します。


・RDSに設定されているサイトアドレスを書き換え
-
RDSにはEC2のパブリックIPアドレスが設定されている状態ですので、ロードバランサーのDNS名に登録し直します。


・ロードバランサーが動作していることを確認
-
ロードバランサーのDNS名をブラウザのアドレスバーに張り付けると、ブログサービスにアクセスできます。
更新ボタンを押すと、トップページの表示が変わればロードバランサーが正常に動いていることが確認できます。


・起動テンプレートを作成
-
インスタンスを起動するための設定情報を起動テンプレートに設定します。


・Auto Scalingグループを作成
-
既に作成しているEC2インスタンスをすべて停止状態にします。
その後、Auto Scalingグループを作成します。

この時、希望する容量2 最小キャパシティ2 最大キャパシティ4とします。
その為、EC2インスタンスの画面に戻るとインスタンスが2つ立ち上がっていることが確認できます。


・CloudWatchでアラームを設定
-
CPU使用率によってEC2の数を増減させるため、
CPU使用率が70％以上、30％未満の時に検出するアラームを作成します。


・アラームとスケーリングポリシーを紐づけ
-
作成したAuto Scalingグループからスケーリングポリシーを追加してアラームを紐付けます。

・負荷テスト
-
EC2インスタンスに手動で負荷を掛けます。
そのため、稼働しているEC2インスタンスを選択し、インスタンスに接続します。

下記のコマンドを4回実行し、CPU負荷を掛けます。

```terminal:EC2
# yes >> /dev/null &
```

CPU後負荷でインスタンスが立ち上がっているかを確認します。
ここでは10分ほど待つとEC2インスタンスが最大４の構成になっていることが確認できます。

最後にプロセスを終了させます。
topコマンドでPIDを確認。

```terminal:EC2
# kill [PID]
```

プロセスを終了させCPUが30%より低くなると、スケーリングポリシーにより
不要となったインスタンスはシャットダウンされていることが確認できます。

2021.10.03追記
スケールインする時は私の体感で5分ほど待つ必要がありました。
詳細モニタリングを設定すると監視間隔が１分と短くなりますので待ち時間も短くなりますので、是非お試しください。

[設定]
スケーリングポリシーを設定するときに「詳細モニタリング」を有効にする。

[参考サイト]
・インスタンスの詳細モニタリングを有効または無効にする
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-cloudwatch-new.html
・Amazon CloudWatch の料金
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/465906/ed899a43-1695-10f2-eb1d-ec38fec95fd6.png)

https://aws.amazon.com/jp/cloudwatch/pricing/
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/465906/7524898f-93b9-dc22-ab55-28ee2427dacf.png)




サービス停止
-
お約束ですが、下記サービスを使わないときは切っておきましょう。

■EC2(オンデマンド)→時間単位または秒単位で計算されるため停止中にすること。

■RDS(オンデマンド)→RDS の使用料は秒ごとに課金されるため、スナップショットを取って削除すること。

■ALB→実行時間に対して時間単位、または1時間未満で使用料を課金されるため、削除すること。

■AutoScaling→AWS Auto Scaling は無料で使用できますが、不要であれば紛らわしいので削除しましょう。


ハンズオン3に発生する費用一覧
-
・EC2 x 4
・データ転送
・ALB
・RDSx 2


1時間に22円ほどです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/465906/8123546e-c1ba-ef38-3486-9e340810c940.png)





最後に
-

前回の記事はコチラ↓↓↓
[ハンズオン2_冗長性のあるブログサービスを構築する（冗長構成）](https://qiita.com/zetzetn/items/ee50683b39f56658b586 "ハンズオン2_冗長性のあるブログサービスを構築する（冗長構成）")


AWS CloudTechの課題としてこれらが残っていますので、
やったことを今後のQiita記事にして発信していきたいと思います。

これから始められる方の参考になれば嬉しいです。

今後の学習予定↓↓↓
・独自ドメインの設定と障害時の設定
・HTTPS通信でのアクセス
・キャッシュサーバーの配置
・CloudFormationの作成、更新
・Lamda関数
・Docker

内容に不備がございましたら、ご指摘いただけますと幸いです。

この記事はAWS初学者を導く体系的な動画学習サービス「AWS CloudTech」のハンズオンを基に作成しました。
https://aws-cloud-tech.com/

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/465906/00637e63-5339-1b83-c3c1-720e95174ec0.png)