こんにちは。CSチームの坂本です。
今回も、前回の「Nginx + WordPress S3篇」に引き続き、「Nginx + WordPress ロードバランサー篇」の構成での運用上の問題点を、AWSのサービスを使って解消していきたいと思います。
画像のアップロード先の問題は解決しましたが、MySQLのデータベースサーバーがまだSPOF(単一障害点)となっています。EC2でインスタンスをもう1台起動してレプリケーション環境を構築することも可能ですが、今回はAWSのサービス「Amazon RDS」を使ってこの問題を簡単に解決したいと思います。
目次
1. Amazon RDSとは?
今回、データベースとして利用するAWSのサービスは「Amazon RDS」という「耐障害性の高い」AWSのリレーショナルデータベースサービスです。
このサービスを使うことで簡単にMySQLの環境が構築でき、「Multi-AZ」という設定をおこなうだけで、SPOFとなる心配もなくなります。
どれだけ簡単に構築できるのかは、以下の3. RDSインスタンスの作成で確認してみてください。
2. Multi-AZとは?
Multi-AZとは、異なるAvailability Zone間でレプリケーション環境を構築してくれる仕組みです。
Multi-AZを設定すると、以下の図のようにZone-aにマスターがある場合は、Zone-bにスレーブが置かれ、同期レプリケーションをおこなってくれます。
Zone-aのマスターで障害が起きた場合は、Zone-bのスレーブに数分で切り替わります。
▲異なるAvailability Zone間で同期レプリケーション
3. RDSインスタンスの作成
では、どのくらい簡単に「耐障害性の高い、MySQLの環境」が構築できるのかを確認してみましょう。
まず、AWS Management ConsoleのRDSの画面から「Launch DB Instance」ボタンを押すと、Launch DB Instance Wizardが表示されますので、「ENGINE SELECTION」で「MySQL」を選択して進みましょう。
Multi-AZにするために、次の「DB INSTANCE DETAILS」の「Multi-AZ Deployment」で「Yes」を選択します。この選択だけで、先ほどのレプリケーション環境の設定ができます。
あとは、Launch DB Instance Wizardに従って、設定してください。
今回の設定を確認後、「Launch DB Instance」ボタンを押してしばらく待てば完了です。たったこれだけの手順で「耐障害性の高い、MySQLの環境」が構築できてしまいます。
▲「Multi-AZ Deployment」で「Yes」を選択
▲今回の設定。確認後、「Launch DB Instance」ボタンを押してRDSインスタンスを作成
RDSインスタンスが作成できたら、Webサーバーからアクセスできるようにセキュリティグループの設定をおこないます。
こちらは、現在使用しているWebサーバーのセキュリティグループを設定します。「Connection Type」で「EC2 Security Group」を選択すると、プルダウンメニューでEC2のセキュリティグループが選択できるようになりますので、選択して「Add」ボタンを押します。
▲設定後、現在使用しているWebサーバーのセキュリティグループが設定されているのを確認
4. データベースのバックアップ、リストア
RDSインスタンスが作成できたので、今度は現在のデータベースサーバーからデータを移行しましょう。
現在のデータベースサーバーへ接続して、データベースのダンプファイルを作成し、それをRDSインスタンスにリストアします。
mysqldump -u root -p blog > blog.sql mysql -h wordpress.xxxxxxxxxxxx.ap-southeast-1.rds.amazonaws.com -u sakamoto -p blog < blog.sql
※接続先は、AWS Management Consoleで確認できます。確認したいRDSインスタンスをチェックして「Description」タブを選択し、Endpointを確認してください。
Endpoint: wordpress.xxxxxxxxxxxx.ap-southeast-1.rds.amazonaws.com
※MySQLからRDSへのデータの移行に関しては、以下の記事でも触れられています。
既存のMySQLサーバからRDSインスタンスへの移行をテストする
5. WordPressの設定変更
最後に、WordPressのwp-config.phpのデータベースの情報を変更しましょう。
今回の環境での作業手順としては、ロードバランサーの後ろでWebサーバーが3台稼働していますので、まずどれか1台をロードバランサーの分散先から一旦はずし、そのサーバーで設定変更をおこないます。
define('DB_NAME', 'blog'); /** MySQL データベースのユーザー名 */ define('DB_USER', 'sakamoto'); /** MySQL データベースのパスワード */ define('DB_PASSWORD', '*********'); /** MySQL のホスト名 */ define('DB_HOST', 'wordpress.xxxxxxxxxxxx.ap-southeast-1.rds.amazonaws.com');
設定後は、そのサーバーのAMIを作成します。
▲54.XXX.XXX.41を分散先からはずして、設定変更後AMIを作成
その後、設定済みの1台をロードバランサーの分散先に戻し、未設定の2台は分散先からはずします。その2台と元のMySQLのデータベースサーバーははターミネイトしましょう。
▲54.XXX.XXX.41を分散先に戻す。不用になったサーバーはターミネイト
先ほど作成したAMIから2台のインスタンスを起動し、EIPを割り当て直して、またロードバランサーの分散先に戻しましょう。
upstream backend { server 54.XXX.XXX.41; server 54.XXX.XXX.42; server 54.XXX.XXX.43; }
▲AMIから2台起動後、EIPを割り当て直してロードバランサーの分散先に戻す
これで、RDSへの移行が全て完了しました。
6. まとめ
Webサーバーを負荷分散した場合の、データベースサーバーのSPOFの問題をRDSを使って簡単に解消することができました。
今回はテスト環境ですので設定していませんが、RDSでは自動バックアップの設定ができますので、必要に応じて設定しておきましょう。デフォルトの1日の保持期間で利用する限りは、バックアップに追加料金はかからないそうです。
※とても簡単に設定できてしまうMulti-AZですが、料金は1台構成のときの2倍になりますので、利用の際はお気をつけください…。
次回は、現状の構成でSPOFとなっているNginxのロードバランサーをAWSのサービスを使ってカイゼンしたいと思います。