マルチAZ構成のWordPressを構築

以前の記事でAWS環境にWordPressを構築する記事を投稿しましたが、今回はマルチAZ構成でWordPressを構築した内容の備忘録となります。

シングルAZで構築したWordPressの投稿は以下記事になります。

参考 AWS環境にWordPressを構築ITサービス指向エンジニアブログ

今回作成する構成図は以下です。

インターネットゲートウェイの背後にALBを配置し、各AZのPublicSubnetに配置されたEC2に対してHTTP通信を振り分けます。

単一でEC2に障害が発生したとしても、もう片方のEC2にリクエストを振り分けることによって、単一障害点を回避します。

Table of Contents

構築の手順

STEP.1

どちらに接続しているかの目印を作る

冗長構成にすることで、どちらのAZのEC2に接続しているのかの判別をするためにindex.phpのコードをviで入力する

STEP.2

AMIを作成する

ap-northease-1aのPublicSubnetに配置されたE2のAMIを作成する

STEP.3

ALBを作成する

Nameタグ, プロトコルの設定, VPC,AZおよびサブネット, ターゲットを追加

STEP.4

RDSのサイトアドレスをロードバランサーのDNS名に書き換える

mysqlに接続し、siteurl,homeをロードバランサーのDNS名にUpdateする

STEP.5

書き換えたDNS名でWordPressに接続する

URL窓にDNS名を打ち込みWordPressに接続できることを確認する、また、何度かリロードし、二つのAZのWordPressに接続できていることを確認する

STEP.6

ALBのセキュリティグループを設定する

EC2をALBからの接続を許可する設定にする

STEP.7

片方のAZのEC2インスタンスを停止して動きを確認する

ALBが問題なく振り分けできているかを確認するため、片方のEC2を削除し、ALBのDNS名で接続し確認する

STEP.8

RDSの冗長化構成をする

RDSのマルチAZ配置でスタンバイインスタンス

上記の流れで構築します。

index.phpのコードを修正する

PublicSubnetに存在するEC2にSSH接続をし、/var/www/html/ディレクトリにあるindex.phpのコードを修正します。

ssh -i keyの名前 ec2-user@パブリックIPアドレス

cd /var/www/html/

移動した先のディレクトリでls -l コマンドでindex.phpが存在することを確認し、vi index.phpとコマンド入力します。

以下のようにechoでindex.php表示時に Web Server 1などと表示されるように編集します。

define('WP_USE_THEMES', true);

echo '<p>Web Server 1</p>'

AMIを作成

AMIとは

AMI = Amazon Machine Imageの略
EC2インスタンスの構築に必要な情報がまとまっている起動テンプレートです。
OSやメモリ、CPUといったものをどうやって構成していくか？の情報です。

図にするとこんな感じです。

すでに作成しているEC2インスタンスのAMIイメージを作成すると、全く同じ構成のインスタンスを作成できます。

EC2の画面から対象のインスタンスを選択し、アクション→イメージとテンプレート→イメージを作成を選択します。

イメージ名を入力(わかりやすくEC2インスタンスの名前を同じで良いでしょう)し、イメージを作成します。

インスタンスを起動からマイ AMIを選択します。

インスタンスタイプはt2.microを選択

インスタンスの詳細設定で対象のVPC、サブネット、自動割り当てパブリックIPは有効にし、ストレージの追加へ

ストレージはデフォルトのまま

Nameタグを適当に作成

セキュリティグループの設定で既存のセキュリティグループを選択し、HTTP, SSH接続のインバウンド許可がされているものを選択(後ほど、ALBからの許可を受ける設定に変更する)

キーペアは新たに作成もしくは既存のキーペアを選択し、EC2を起動する。

ALBを作成する

ALBとは

ALB = Application Load Balancerの略
いわゆる負荷分散をするサービス
ユーザーからのアクセス急増し、Webページの表示速度が遅くなる、といった場合、一つのインスタンスでは処理が滞っている場合に、別のインスタンスに処理を分散する。

ALBの特徴はリクエストを飛ばしたい先のターゲットに対してルーティング設定を行うことができること。
– プロトコルは何を使うか？
– ポートは？
– ヘルスチェックの詳細設定をどうするか？
など

ヘルスチェックって？

ヘルスチェックとは

ALBは登録されたターゲットに対して定期的にリクエストを送信し、ステータスチェックを行っている。
上記のことをヘルスチェックという。
ALBのターゲットグループを作成する際に、リクエストをルーティングし、ターゲットに対して正常にリクエストが到達するかどうかをチェックし、正常であると合格する必要がある。

参考ターゲットグループのヘルスチェックAWS公式ドキュメント

では実際にALBを作成していきます。

EC2インスタンスの画面からロードバランサーを選択し、ロードバランサーの作成を選択します。

ロードバランサーの設定でNameタグを入力し、

リスナーをHTTPプロトコルを選択し、ポートは80

リスナーとは

外部からアクセスするプロトコルやポートのこと。
ロードバランサーは設定したリスナー状況で接続を待ち受けます。

VPC, アベイラビリティゾーン, サブネットを選択します。

ロードバランサーを使用するため、通常複数AZと複数サブネットに振り分ける設定を行います。

セキュリティグループは新たに作成し、HTTPプロトコルでポート80番のみ受け付けます。

ルーティング設定でターゲットグループを設定します。

ヘルスチェックを設定します。

デフォルト設定のままだと上記の状態ですが、以下まとめます。

設定	詳細
正常のしきい値	5回ヘルスチェックを実行してOKだった場合正常とみなす
非正常のしきい値	2回ヘルスチェックを実行して失敗した場合非正常であるとみなす
タイムアウト	ヘルスチェックを失敗とみなす、ターゲットからレスポンスがない時間 – デフォルト値は5秒。
間隔	ヘルスチェックを行う間隔 – デフォルト値は30秒
成功コード	正常だった場合に返すコード – 200

HTTPレスポンスステータスコード

内容	ステータスコード
情報レスポンス	100～199
成功レスポンス	200～299
リダイレクトメッセージ	300～399
クライアントエラーレスポンス	400～499
サーバーエラーレスポンス	500～599

参考 HTTPレスポンスステータスコードMDN Web Docs Mozilla

ターゲットの登録をします。

各AZに配置したEC2にをターゲットに登録しします。

対象のEC2インスタンスを選択して「登録済みに追加」をします。

問題なければ上記で作成します。

RDSのサイトアドレスを書き換え

RDSのスナップショットがある場合は復元する。

復元する際は、可用性と耐久性の選択項目で「マルチAZ DBインスタンス」のラジオボタンを選択します。

上記を条件にDBインスタンスを復元するか、もしくは新たに作るかします。

RDSの中に設定されているサイトアドレスをロードバランサーの名に書き換えるには、

EC2にSSH接続→mysqlに接続→対象テーブルを選択→wp_optionsテーブルの’siteurl’, ‘home’の値をロードバランサーのDNS名にUpdateします。

まず、EC2にSSH接続します(コマンドは頻出しているので省きます)

mysqlに接続します。

mysql -h RDSのエンドポイント -u マスターユーザー名 -p

RDS接続時、次のようなエラーメッセージが出た場合は以下が原因と思われますので、確認してみてください。

参考 MySQL接続エラーITサービス指向エンジニア

ERROR 2003 (HY000): Can't connect to MySQL server on

mysqlのマスターユーザー名等はデータベースの設定タブで確認できます。

テーブルを選択します。

use wordpress

siteurl,homeの値を確認

select * from wp_options where option_name in ('siteurl','home');

selectするとoption_valueが以下のようにIPアドレスで接続しにいくような設定になっているため、これをLBのDNS名にUpdateをします。

LBのDNS名はロードバランサー画面の説明タブから確認できます。

UPDATE wp_options SET option_value = 'http://LBのDNS名' WHERE option_name IN ('siteurl', 'home');

Updateを行い、その後Selectして値がDNS名に書き換わって入ればOKです。

サイトURLの書き換えまでの手順を言語化してみました。

言語化

siteurl,homeの値をEC2のIPアドレスに設定してしまうと
LBが分散する際に、片方のEC2へしかトラフィックを流さなくなるため、
LBの意味がなくなってしまう。

そのため、双方のEC2にインストールしたWordPressのサイトURLをLBのDNS名にしておくことで、
LBのDNS名でユーザーからトラフィックが流れてきたら、VPC内部DNSで名前解決を行い、
WordPressサイトを表示することができる、という理解

簡易図

DNSによるVPC内部名前解決の仕組みについて

VPC内部名前解決の仕組みはAWSでは「Route 53 Resolver」という仕組みがあります。

AWSのVPC内部名前解決の前に一度DNSの仕組みについて整理してみました。

DNSの仕組みについて以前書いた記事も参考にしてください。

参考【初心者向け】DNSの仕組みを解説ITサービス指向エンジニアブログ

上記の図を見る限り、DNSの仕組みではフルサービスリゾルバというサーバが各サーバに問い合わせを行い、最終的にIPアドレスを返す仕組みになっていますが、この仕組みがAWSサービスのRoute 53 Resolverと呼ばれるサービスで、Route 53 Resolverが名前解決をするための司令塔となってくれます。