冗長化とスケーラビリティのある構築をする

#記事の目的

前回の演習で作成した基本的なブログサービスの構築では、単一障害点となり障害発生時にはブログサービスが閲覧できなくなってしまいます。

前回の記事：https://qiita.com/ShotaMo/items/03819bee6d3523eecf48

そこでAutoScalingとCloudWatchを設定することで、前回よりも冗長性の高い構築をしていきます。
※今回は前回構築後にRDSとEC2インスタンスを削除していたため、RDSの起動から記載していきます。

#構成図

以下が今回構築しようとしている構成図になります。


#実際に構築していく
■RDSの起動
　以前RDSを作成したときのスナップショットを利用してRDSを起動していきます。
（スナップショットを利用したRDSの起動については前回記載したため、今回は省略します。）
　ちなみに、この時ECSインスタンスはまだ停止した状態のためURLにアクセスしてもブログサイトは閲覧できません。

■AutoScalingの設定
AutoScalingグループを設定していきます。
1.起動テンプレートとして、以前作成したLaunchTemplate1を利用し以下を確認、設定していきます。
　(起動設定でも紐付けれるが、起動テンプレートで紐付けることをAWSでは推奨されている)
　・バージョン
　・インスタンスタイプ
　・キーペア名
2.起動するEC2インスタンスのVPC(サブネット)を選択(MyVPC内のPublicSubnet1,2)します。
　詳細オプションとして以下を設定します。
　・ロードバランサーの設定
　(ロードバランサーとの紐付けをするために設定。指定するターゲットグループは以前作成していた「TG-1」とする)
　・ヘルスチェックの設定
　（デフォルトではEC2インスタンスの起動チェックのみのため、ELBのチェックボックスも選択することでエンドユーザーが閲覧できる状態なのかまで確認することでができる)
　・モニタリングについては、CloudWatchを設定した際に関連付けるためここでは空欄としておきます。
3.グループサイズは以下のようにしていきます。
　希望容量：２　最小キャパシティ：２　最大キャパシティ：４
4.スケーリングポリシーはあとで設定するためここでは設定しません。
(これはEC2インスタンスがどのような状態になったら動作をどうするのかを設定するもの)
5.インスタンスのスケールイン保護はチェックしないようにする。
（ここをチェックするとスケールインしなくなってしまうため）
6.通知、タグについては今回は設定しません。
（この通知はEメール通知などについて設定もの)

上記設定で作成します。
作成した段階で、AutoScalingによってEC2インスタンスが起動状態となります。
(ここでブログサイトは閲覧できます)

■AutoScalingの動作確認
実際にEC2インスタンスを停止した際に、希望する動作となるのかを確認していきます。
AutoScalingグループのアクティビティにてログを見ることができるため、EC2インスタンスを片方停止することでログの出力とEC2インスタンスの動作を確認しました。
結果として、停止にともなって自動でEC2インスタンスが新たに起動され、AutoScalingで設定した通りの動作が確認できました。(ログについても停止、起動に伴って出力されていることを確認)

■CloudWatchの設定
次にアラームの作成より以下の順序で作成していきます。
・メトリクスの選択(メトリクスとはグラフのこと)
　EC2 → AutoScaling → 前手順で作成したTest-AutoScaling1(CPUUtilization)を選択
・統計：平均値
・期間：5分
・条件は以下で設定(2種類のアラームを設定する)
　共通：静的
　High側：70％より大きい(欠落データの処理は欠落データを閾値を超えているとして処理)
　Low側：30％より小さい(欠落データの処理はデフォルトのまま)
※欠落データの処理はCPU使用率が上がりすぎた時にメトリクスを送れなくなくなってしまう可能性があるため、High側で設定している。
・通知(アラームが発生しているときの通知先)
　既存のSNSトピックで登録しているものを使用します。

上記内容でCPU_High,CPU_Lowを設定します。

■AutoScalingグループにCloudWach連携
AutoScalingグループの自動スケーリングタブを開き、動的なスケーリングポリシーの作成ボタンより関連付けをしていきます。設定は以下の通りです。
・シンプルなスケーリング
・名前：CPU_add(High側), CPU_remove(Low側)
・CloudWatchアラーム：適当な方を選択
・アクションを実行
　add：追加1, キャパシティユニット
　remove：削除1, キャパシティユニット
・待機：30(ポリシー作動後の待機時間のこと)

■サーバーに負荷をかけた際の動作の確認
続いてEC2インスタンスにあるEC2 Instance ConnectでSSH接続し負荷を掛けて動作確認していきます。
それぞれのEC2インスタンスに接続し、以下のコマンドを実施していきます。

#現在のリソース利用状況を継続監視する(ここではCPUの動作を確認したいためCPUの項目を確認しておく。)
top

#topコマンドより一旦抜ける
Ctrl + C
#以下のコマンドでサーバーに負荷をかける
#コマンドの意味
#yes:yesという出力を繰り返す　>>:標準入力の内容をファイルに追記
#/dev/null:特殊ファイルの一つでデータをどれだけ受け取ってもデータを返さないファイル
#&:バックグラウンドで実施(現在のCLI画面では表示せずに裏でコマンドの実行がされているイメージ)
yes >> /dev/null &

#再度topコマンドでCPU使用率を確認し、負荷が上がっていることを確認
top

上記のコマンドを入力しメトリクス画面でもCPU使用率が上がった時にアラーム状態となり、EC2インスタンスが追加されたことを確認できました。
次に以下のコマンドを入力し、掛けていた負荷をなくしたときの動作を確認します。

#現在実行されているプロセスを停止する(プロセスIDで指定する)
#以下で入力している{x..z}は連番のプロセスIDの際に利用でき、まとめて信号を送れる。
kill { プロセス番号 .. プロセス番号 }

#再度このコマンドでCPU使用率が下がっていることを確認する。
top

しかし上記のコマンドを入力しメトリクス画面でもCPU使用率が下がっても、EC2インスタンスは削除されませんでした。
これはターゲットグループの設定の一つの登録解除の遅延の影響によるものです。
この設定は、エンドユーザーが急なサーバー停止によって困らないように、一定の処理が終了してから削除できるために設定されています。

#最後に
今回はAutoScalingを設定しているため、これまで通りにEC2インスタンスを削除しても、自動で新規のものが起動されてしまいます。そのため終了時にはAutoScalingの削除も実施する必要があります。

---

この記事はAWS初学者を導く体系的な動画学習サービス
「AWS CloudTech」の課題カリキュラムで作成しました。
https://aws-cloud-tech.com

---