LoginSignup
1
2

More than 3 years have passed since last update.

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

Posted at

概要

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

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

前回作成した構成図

スクリーンショット 2021-04-10 15.39.53.png

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

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

今回作成する構成図

スクリーンショット 2021-04-10 15.35.20.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

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

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

スクリーンショット 2021-04-12 20.47.11.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

pタグでweb server1という目印をつけましょう!
スクリーンショット 2021-04-12 21.26.30.png

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

EC2を複製する

スクリーンショット 2021-04-12 21.27.44.png

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

スクリーンショット 2021-04-12 21.29.38.png

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

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

ではインスタンスのページに行ってインスタンスを起動をクリックします。
スクリーンショット 2021-04-12 21.33.40.png

こちらのマイAMIにいくと先ほど作成したWebServerのAMIがあります。
こちらを選択していきます!
スクリーンショット 2021-04-12 21.35.12.png

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

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

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

セキュリティグループは既存のwebサーバーのセキュリティグループを選択しましょう!
基本的にセキュリティグループは揃えましょう!
スクリーンショット 2021-04-12 21.37.48.png

こちらで起動と作成です。
ではwebserver2が作成できたので、停止していたwebサーバー1を起動にしましょう!
スクリーンショット 2021-04-12 21.39.46.png

これで2つのWebServerが立ち上がったかと思います!
スクリーンショット 2021-04-12 21.40.57.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

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

vi index.php

こちらで先ほどと同様に今回はwebServer2の目印をつけます
スクリーンショット 2021-04-12 21.46.01.png
:wqa!で上書き保存します!
スクリーンショット 2021-04-12 21.49.54.png

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

スクリーンショット 2021-04-12 21.51.04.png

ロードバランサーの作成でALBを選択します。
名前は今回はLB-1とします
スキームはインターネット向け
スクリーンショット 2021-04-12 21.53.00.png

my-vpcのpublic-subnet1,2にアベイラビリティゾーンは設定します。
こちらでで次にセキュリティグループの作成を行っていきます。
スクリーンショット 2021-04-12 21.55.27.png

名前はLB-SG-1としておきます。
こちらで次に進みなす。
スクリーンショット 2021-04-12 21.57.06.png

ターゲットグループはTG-1としヘルスチェックのパスは/readme.htmlとします。
スクリーンショット 2021-04-12 21.58.35.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
とすると現在は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

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

ではDNS名でブログが閲覧できるか確認しましょう!
先ほど入力したDNS名を今度はブラウザに貼り付けてみましょう!!
スクリーンショット 2021-04-13 8.22.19.png

スクリーンショット 2021-04-13 8.22.33.png

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

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

スクリーンショット 2021-04-13 8.28.25.png

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

スクリーンショット 2021-04-13 8.29.34.png

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

スクリーンショット 2021-04-13 8.31.04.png

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

スクリーンショット 2021-04-13 8.33.10.png
2の方を停止させましょう!

スクリーンショット 2021-04-13 8.34.04.png
停止しても1の方でブログが閲覧できることが確認できました!!
リロードしてもずっと1のはずです!

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

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

最後にRDSを冗長化する

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

スクリーンショット 2021-04-13 8.37.32.png
ここは超簡単にできます。
データベースの設定画面がから変更を押します。

スクリーンショット 2021-04-13 8.38.33.png

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

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

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

スクリーンショット 2021-04-13 8.51.41.png
スクリーンショット 2021-04-13 8.52.00.png

フェイルオーバーで再起動にします!
スクリーンショット 2021-04-13 8.52.30.png
データベースが再起動中になっているのがわかるかと思います!

サイトにアクセスしてみてください。
スクリーンショット 2021-04-13 8.54.26.png

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

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

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

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

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
2