冗長性のあるブログサービスを構築する

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

## 前回までの環境
前回のハンズオンでは、VPCにパブリックサブネットにEC2、プライベートサブネットにRDSを配置したシングル構成を構築しました。モック図は下記のようになります。
またRDSを削除している場合は、スナップショットより復元できます。
![スクリーンショット 2021-09-26 15.52.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1006791/95c521e0-f7f4-bcdd-eddd-c73acafd08ff.png)


## はじめに
以前の投稿では、基本的なブログサービスを構築する「シングル構成」を作成しました。
具体的には、VPC、EC2、RDSを使用して作成しました。
今回はそれに冗長化とスケーラビリティを構築していく手順を追っていきます。
主に使用するサービスとモック図は下記のようになります。
・VPC
・RDS
・EC2
・ELB
・CloudWatch
・AutoScaling
![スクリーンショット 2021-10-21 23.34.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1006791/2392f826-0296-2320-424e-40709676df2e.png)


## 冗長性のあるブログサービスとは
冗長性とは、耐障害性を高めるためシステム全体を二重化して予備システムを準備すること。冗長性によって信頼性、安全性を確保できる。また、二重構造をとるので、負荷分散にもなる。

## ELBとは
ELB(Elastic Load Balancing)とは、Webサービスに発生する負荷を分散するロードバランシングのこと。今回の場合だと、2つのAZにそれぞれEC2を配置することで負荷分散することができます。また、負荷分散をするだけでなく、片方のEC2が異常状態になった時に正常な方に接続させることができます。

## 構築手順
①現在起動中のEC2よりAMIを作成
②2つのAZに同じEC2をそれぞれ配置する
③ELBを設定して、冗長化構成にする。
④RDSも同じくマルチAZで配置する。

## 実際の冗長化の手順
### 起動テンプレートの作成
現在起動中のEC2をインスタンスの状態より停止させます。停止を確認したら、アクションよりイメージを作成を選択します。イメージ名を入力すると作成ができます。実際に作成する際は、EC2を作成を選択したのち、マイAMIの欄を見ると下記のように追加されています。その後のキーペアやセキュリティグループは、既存のものと同じ設定にします。
![スクリーンショット 2022-01-20 21.09.09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1006791/5771a66b-630a-083a-3a4c-c000b2aafdb3.png)

### 冗長性を確認するためそれぞれのindex.phpを編集
それぞれのEC2が冗長化しているのを確認するため、「web server1」と「web server2」とindex.phpを記入します。
ディレクトリは「/var/www/html/」配下のindex.phpです。

### ELBを作成
EC2のページのメニュー欄からロードバランサーを選択します。
・手順１では、名前と、冗長化するそれぞれのAZとサブネットを選択します。
・手順３では、セキュリティグループの設定をします。今回は、80番ポートの0.0.0.0/0の全ての通信を許可する新しいセキュリティグループを作成します。
・手順４では、ターゲットグループの作成を行います。ターゲットグループは、HTTPの80番ポートに設定します。ヘルスチェックは、下記のように設定します。この設定で、10秒間隔に２回のヘルチェックを行い、２回正常であれば異常判定にはならない設定です。![スクリーンショット 2022-01-20 21.12.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1006791/e4824637-d298-0e0e-0c22-6d009f0dd7c7.png)
・手順５では、ターゲットの登録を行います。どのインスタンスをターゲットグループにするか選択を行います。

### ヘルスチェックの確認
メニュー欄よりターゲットグループを選択し、タブのターゲッツを選択すると、先ほどターゲットにしたインスタンスの状態がわかります。何度かリロードすると正常の「herthy」になっているのが確認できます。

### DNS名の書き換え
RDSに設定されているサイトアドレスをロードバランサーのDNS名に書き換えます。
ターミナルから

```
mysql -h d「①database-1.xxxxxxxxxxxxxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com」 -u 「②wordpress」 -p
```

を入力する。①にはRDSのエンドポイント、②はwordpressのユーザー名を記入します。
次にワードプレスのDBを使用する

```
USE wordpress
```

を入力します。
次に下記のSQLを入力すると

```
SELECT * FROM wp_options WHERE option_name IN ('siteurl', 'home');
```

テーブルが表示されます。テーブルにはpublic IP アドレスが表示されているので、こちらを書き換えます。

```
UPDATE wp_options SET option_value = 「③'http://xx.xx.xx.xx'」 WHERE option_name IN ('siteurl', 'home');
```
③にロードバランサーのDNS名を記入して実行すると下記のように書き換えられているのが確認できます。
![スクリーンショット 2022-01-20 23.16.11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1006791/6326c105-b30e-1b9a-870d-ca3f26456f3c.png)

### 冗長化していることを確認
先ほど記入したラードバランサーのDNS名で検索すると、ページに遷移します。何度かリロードをすると、
![スクリーンショット 2022-01-20 23.16.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1006791/7cef14b8-cc3f-1eea-4925-a0238fbbc6d7.png)
![スクリーンショット 2022-01-20 23.17.37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1006791/66d41cfa-2066-9a7a-acc6-1c005c611148.png)
「Web server 1」になったり、「Web server 2」になったるを繰り返すので冗長化していることが確認できます。

### セキュリティグループを設定変更
現在全ての通信が許可されているので、ロードバランサーからの通信のみ許可されるように設定します。EC2のセキュリティグループの設定から、インバウンドルールの編集から、80番ポートをRDSのセキュリティグループに設定します。

### 障害テストをする
片方のEC2インスタンスを停止して、接続しても、ブログサイトを継続して接続できることが確認できます。

### RDSの冗長化構成
RDSから変更を押して、マルチAZ配置のスタンバイインスタンスを配置を選択する。しばらく待つとマルチAZになったことが確認できます。
![　.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1006791/e40bf2cc-991a-abe2-c43c-ed154c15134a.png)
実際に再起動を押してみると、フェールオーバーをして再起動されるので、ブログは閲覧できる状態になっています。また、RDSの最近のイベントの欄からも確認ができます。
![スクリーンショット 2022-01-20 23.46.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1006791/f9a4f92f-67dd-430a-f246-599a7d790ab0.png)

## 感想
最初は見落としが多く、動画で言われたことをただただやっている状態でしたが、今の作業の目的や何をしようとしてるのかを意識しつつ行っていくことでスムーズに学習が進められました。
最初の構成図を見て、パッと順序立てて考えられるよう繰り返し行っていきたいと思います。