冗長性のあるWordPressをAWSで構築する

#概要
冗長性のあるブログサービスを今回は構築していきます。
今回は第二弾で前回の続きから行っていくものとします。

前回はこちら
https://qiita.com/kohei_abe/items/456cc6c0aa91b76d56ea

##前回作成した構成図
![スクリーンショット 2021-04-10 15.39.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/61087875-4801-f2b3-b00e-d0a8a46cd70a.png)

前回作成していった構成がこちらです！
こちらの問題点としてはEC2, RDSともにシングル構成のため単一障害点が生まれます。
もしAZが何かしらの障害があった場合サービスが停止してしまいます。

またEC2のCPUに負荷がかかり、サービスが落ちた場合これもサービスが停止してしまいます。
またデータベースも複製されていないためこれは極めて危険な状況です。

##今回作成する構成図
![スクリーンショット 2021-04-10 15.35.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/710aa6f0-dcfd-2868-ecb0-4fe1ec04e7fe.png)

今回はこのような構成にしていきます。
まずはデータベースですがmasterとslave構成にしていきます。
こちらでデータを複製していきます。
これによりmasterがダウンしても自動的にslaveに切り替えることがAWSは簡単にできます！

またEC2も2台配置し、それをELBで分散させています。

ELBはDNS名のアクセスポイントが付与されるといった特徴があります。
つまりアクセスポイントを一つにし負荷分散をさせるということです。

このELBがないとwebサーバーのアクセスポイントが2つになってしまうため、どちらにアクセスして良いかわからなくなってしまいます。
また一つのサーバーがダウンするともう一つが動いていたとしてもダウンしているサーバーにいくと404ページが返ってくるようになります。

これでは意味がないですよね。
つまりELBにアクセスポイントを一つに集中させて、そこから2台のEC2に負荷分散させていくのです。


さらにELBにはヘルスチェック機能が備わっています。
ヘルスチェック...以上なインスタンスを認識し通信をストップする
つまりwebサーバーに異常を感じたらそちらの通信はストップしアクセスできないようにします。

これで一つのサーバーがダウンした際にも負荷分散ができるわけです。

さらにELBに証明書を付与することでSSLの通信の終端となります。
![スクリーンショット 2021-04-12 20.43.52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/6a3e1596-68b8-a403-cfed-148ab91b1fcf.png)

図でみていくとわかり安いかと思います。
つまりPCからELBのアクセスポイントに通信する際はSSLで暗号かします。
ただELBからEC2にアクセスする際はHTTP通信で行います。

HTTPSは暗号化するため通信が重くなります。
これによりセキュリティの高さと処理の速さの2つを実現することができます！
これをSSLターミネーションといいます。
これは現場でよく使われる技術だそうです。

![スクリーンショット 2021-04-12 20.47.11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/7021c5eb-b4c6-8c47-9280-d60de51f6de8.png)

ロードバランサーは全部で3種類あります。
ALB...httpやhttpsの負荷分散に使用する
NLB...TCPなどの負荷分散に使用する
CLB...こちらは現在は使われていないので気にしなくて大丈夫です。

ではELBがわかったところで早速手を動かしていきましょう！！！

##準備
まずは前回作成したEC2にsshでログインしましょう！

```
ssh -i my-key.pem ec2-user@パブリックIP
sudo su -
```

```
cd /var/www/html/
vi index.php
```
cdコマンドでWordPressのディレクトリに移動します。
viコマンドでindex.phpを編集します。
![スクリーンショット 2021-04-12 21.24.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/be1f5cda-facf-4c7f-d02b-dca3f6d7482a.png)

pタグでweb server1という目印をつけましょう！
![スクリーンショット 2021-04-12 21.26.30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/0146e6b6-ac59-3fc4-66a8-58b9de562e54.png)

webサーバー1がブログに入るのがわかったかと思います！

##EC2を複製する
![スクリーンショット 2021-04-12 21.27.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/c80a37f4-593a-e1b8-5648-9a43c67a74e3.png)

ではEC2を2台に増やすために同じEC2 を作成していきます。
まずは既存のEC２を停止しましょう！

![スクリーンショット 2021-04-12 21.29.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/ac303fd7-a5f0-b2db-5716-edc987c083a1.png)

次にアクションからイメージとテンプレート→イメージを作成をクリックします。
イメージ名とイメージの説明をWeb Serverとしイメージを作成します。

これは何をしたかというとイメージのAMIを作成しています。
つまりEC2を作成する際にこのAMIを選択することで簡単にWordPress環境の同じEC2が作成できてしまうということです！！！

ではインスタンスのページに行ってインスタンスを起動をクリックします。
![スクリーンショット 2021-04-12 21.33.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/6d5e4a1a-f629-3792-bdf8-f096ee2828ab.png)

こちらのマイAMIにいくと先ほど作成したWebServerのAMIがあります。
こちらを選択していきます！
![スクリーンショット 2021-04-12 21.35.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/d02fc07a-b48f-5385-231b-ed02ae2e179f.png)

my-vpcでサブネットはpublic2の方を選択します。
この辺りも構成図を確認していくととてもわかりやすいかと思います！

自動割り当てパブリックIPも有効であとはデフォルトの設定で大丈夫です。
その次ストレージはそのままで大丈夫です。

その次のタグの追加でNameタグでWeb Server2としましょう！

セキュリティグループは既存のwebサーバーのセキュリティグループを選択しましょう！
基本的にセキュリティグループは揃えましょう！
![スクリーンショット 2021-04-12 21.37.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/be1f9e73-092e-f2d9-adfe-34f808025c89.png)

こちらで起動と作成です。
ではwebserver2が作成できたので、停止していたwebサーバー1を起動にしましょう！
![スクリーンショット 2021-04-12 21.39.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/eff69478-e43b-63f7-f781-382bf4205820.png)

これで2つのWebServerが立ち上がったかと思います！
![スクリーンショット 2021-04-12 21.40.57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/12bb8ed0-80e3-a3c2-8eca-1e4cdcd221b5.png)

ではWebServer2とわかるようにこちらも編集していきましょう。
こちらのパブリップIPをコピーします！
一応アクセスできるかも確認しておきましょう！

```
ssh -i my-key.pem ec2-user@13.231.190.5
sudo su -
```
こちらでログインします！

```
cd /var/www/html
ll
```
![スクリーンショット 2021-04-12 21.44.18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/fe9a41f0-95ca-0686-f257-9bf3cdb155ee.png)

こちらでしっかりとWordPressのファイルがあることが確認できるかと思います！

```
vi index.php
```
こちらで先ほどと同様に今回はwebServer2の目印をつけます
![スクリーンショット 2021-04-12 21.46.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/ab53666c-d728-5fa9-320f-eaf3b1f53c11.png)
:wqa!で上書き保存します！
![スクリーンショット 2021-04-12 21.49.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/6735cb0b-4ac8-233e-0540-5ca72cac8522.png)

こうするとWeb server2の目印がつきます。
では2つのEC２が目印で作成してできたところでこちらをELBで負荷分散させていきます。

![スクリーンショット 2021-04-12 21.51.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/4cc889d4-f536-e097-49a0-2e6cc82c2eb0.png)

ロードバランサーの作成でALBを選択します。
名前は今回はLB-1とします
スキームはインターネット向け
![スクリーンショット 2021-04-12 21.53.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/9411c8a5-da25-d669-e030-23b1bfb68661.png)

my-vpcのpublic-subnet1,2にアベイラビリティゾーンは設定します。
こちらでで次にセキュリティグループの作成を行っていきます。
![スクリーンショット 2021-04-12 21.55.27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/6b3d8c13-607d-e64d-25b8-49bbbf1367ad.png)

名前はLB-SG-1としておきます。
こちらで次に進みなす。
![スクリーンショット 2021-04-12 21.57.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/e6f3484d-53e2-9860-d8e6-bf3232039eaa.png)

ターゲットグループはTG-1としヘルスチェックのパスは/readme.htmlとします。
![スクリーンショット 2021-04-12 21.58.35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/0824761d-4c99-ac00-5b85-cd92b546dab9.png)

ターゲットの登録で負荷分散するターゲットを選択していきます。
2台のEC2を選択し登録済みに追加をクリックします！

こちらで確認と作成を選択です！

では次にデータベースに設定されているDNS名をロードバランサーに書き換えていきます！

```
mysql -h RDSのエンドポイント -u wordpress -p
```
こちらでまずmysqlに入ります。

```
USE wordpress
SELECT * FROM wp_options WHERE option_name IN ('siteurl', 'home');
```
![スクリーンショット 2021-04-13 8.15.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/3741303a-691a-3fab-8aa1-a47f4175ac18.png)
とすると現在はWebServerのパブリックIPになっているのが確認できるかと思います！

こちらを変更しましょう

```
UPDATE wp_options SET option_value = 'http://LB-1-571701307.ap-northeast-1.elb.amazonaws.com' WHERE option_name IN ('siteurl', 'home');
```
http://の後ろはELBのDNS名を選択しましょう！
ロードバランサー→説明で確認ができます。
これで変更できました

```
SELECT * FROM wp_options WHERE option_name IN ('siteurl', 'home');
```
![スクリーンショット 2021-04-13 8.20.52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/8156ee37-ef81-edd4-20f1-1aeff8cf67ce.png)

これで確認が取れたかと思います！！

ではDNS名でブログが閲覧できるか確認しましょう！
先ほど入力したDNS名を今度はブラウザに貼り付けてみましょう！！
![スクリーンショット 2021-04-13 8.22.19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/ebd82638-a67f-0e13-80d5-510261fc5941.png)

![スクリーンショット 2021-04-13 8.22.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/14bed4de-6460-15f0-ae6f-4e00125b63e8.png)

リロードしてみるとわかるかと思いますが、1と2がランダムに切り替わると思います！
これでロードバランサーがランダムにwebServer1と2で負荷分散をしていることが確認できました！

ではこれで接続が確認できたのでwebServerのセキュリティグループをELBだけに限定しましょう！！

![スクリーンショット 2021-04-13 8.28.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/68d6f567-1113-d2e6-14bd-00f0bca5796e.png)

現在だと全てのソースから通信を受け入れることになっています。

![スクリーンショット 2021-04-13 8.29.34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/f8653e46-e27f-be9d-15bc-49bae267c3b1.png)

こちらをELBのセキュリティグループに変更しましょう！！
ブログが問題なく動作しているのが確認できたら成功です

![スクリーンショット 2021-04-13 8.31.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/edcc33bf-4355-d2a7-7a3b-c6e0785b576d.png)

ではテストで一つのEC２がダウンした時のテストをしてみましょう！！！
EC2を1台停止させます。

![スクリーンショット 2021-04-13 8.33.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/96040530-0f99-729a-d479-e143b7a8b52c.png)
2の方を停止させましょう！

![スクリーンショット 2021-04-13 8.34.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/5609d9f8-ce1d-d1ed-2a0f-86e0625fccdd.png)
停止しても1の方でブログが閲覧できることが確認できました！！
リロードしてもずっと１のはずです！

つまり本番サービスで仮にどちらかのサーバーが停止した際ももう一つのサーバーが動いているのでユーザーはサイトが観覧できる。
といったことが確認できました！！！

テストが終わったらサーバーはまた起動しておきましょう！！

##最後にRDSを冗長化する
最後にRDSを冗長化していきます。
構成図をみるとわかるかと思いますが、
master, slave構成の部分です。

![スクリーンショット 2021-04-13 8.37.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/4a35ec0f-32b1-013c-8325-80c05310ee3c.png)
ここは超簡単にできます。
データベースの設定画面がから変更を押します。

![スクリーンショット 2021-04-13 8.38.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/ac38cad7-cafa-77d7-875b-194e44c49aff.png)

スタンバイインスタンスを作成するにチェックを入れましょう！！
これで続行です。
変更スケジュールは今すぐ変更をクリックします。

これで変更すると。
RDSがmaster, slave構成になります。

これで最後にRDSのテストをしていきましょう！！
RDSを再起動しましょう

![スクリーンショット 2021-04-13 8.51.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/f342cf60-ba11-7bc6-201a-e17b1b293083.png)
![スクリーンショット 2021-04-13 8.52.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/7c92b06a-72f2-9ee9-5c35-45ad5ee697d9.png)

フェイルオーバーで再起動にします！
![スクリーンショット 2021-04-13 8.52.30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/9ef5ad28-2d85-84ae-1aaf-fade18e96e76.png)
データベースが再起動中になっているのがわかるかと思います！

サイトにアクセスしてみてください。
![スクリーンショット 2021-04-13 8.54.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/825833/456404da-7dd2-361f-681c-46e60ff666fc.png)

実際にアクセスできることが確認できたかと思います！！

こちらで最初の構成図の冗長化構成が完了になります。

最後にRDSは起動しっぱなしだと課金されていくので削除しておきましょう！
削除する際にスナップショットをとりますか？と聞かれるのでこちらを選択しておきます！！

こうすることでいつでもデーターベースを復元できることができます！
お疲れ様でした！！