テレビ放映などで突発的なアクセス増加があるWordPressサイトを、冗長化することで負荷への対応および障害への対策を行った成功事例をご紹介します。
概要
- WordPressによるサイト制作
- テレビ放映でアクセスが集中することもある
- ブランドイメージの低下や機会損失をなくすため、サーバーダウンは避けたい
- WebサーバーおよびDBサーバーの冗長化構成を採用しました
構成
WordPressの冗長化にあたり「Webサーバーのみの冗長化」「WebサーバーおよびDBサーバーも冗長化」の2案を検討しました。DBサーバーまで冗長化するとコストも上がりますが、DB障害というクリティカルな問題に自動的に対応ができるため、Amazon RDSでマルチAZ構成を選択しました。
また、AWSのAuto Scalingを使いWebサーバーの台数を自動で縮退させることも検討しましたが、シンプルなWordPressサイトのため台数を増やすよりかは多少高スペックなサーバーを用意し、構築・管理の手間を容易にすることにしました。
構成解説
ALB（ロードバランサ）
インターネットからのアクセスをALB（Application Load Balancer）で2台のEC2インスタンス（Webサーバー）へ振り分けます。サイト閲覧者のアクセスは全て振り分ける設定としますが、WordPressの管理者画面へのアクセスは意図して片方向に寄せています。
WordPressは画像のアップロードなどを行うとファイルとしてWebサーバーに保存します。ファイルが2台のWebサーバーに分散してしまうとアクセスした際に画像が抜け落ちてしまうため、1台のWebサーバーをメインとして扱う仕組みとしました。
EC2
前項でお伝えしたように、メインのWebサーバーとサブのWebサーバーの2台構成です。それぞれにWordPressがインストールしてあります。また、Availability Zoneというデータセンターの所在を別々に分けることで片方のデータセンター自体に何かがあっても動作し続けることが可能な構成です。
WordPress自体は冗長化に対応したソフトウェアではないため、2台のWebサーバーでデータの同期を取る仕組みも必要です。今回はメインのWordPressサーバーをマスタとして、lsyncdとrsyncの組み合わせでリアルタイムにWordPressのデータの同期を実現しています。万が一同期処理に失敗した場合も、再同期を行う定期バッチも実行しています。
RDS マルチAZ
データベースはRDSで用意し、マルチAZ構成としています。通常時はWebサーバー2台はマスターサーバーとのみやり取りをします。マスタサーバーの内容は自動的にスレーブサーバーに書き込まれます。自前でマスタースレーブ構成を構築し、運用するのはひと手間かかりますので、RDSのメリットを存分に活用しています。
構築の効果
上記構成で冗長化したWordPressには次のようなメリットがあります。
サーバーダウンが発生していない
サーバーを冗長化することで負荷が分散され、突発的なアクセス増加でも高負荷になることがなくなりました。ホームページでの障害も発生しておらず安定稼働しています。
1台構成と同様の使い勝手
ALBを用いることで、特定のパスへのアクセスを任意のサーバーへ振り分けることができます。例えば、WordPressの場合は、/wp-admin/ へのアクセスをメインサーバーへ振り分ける設定をすれば良いだけです。
ホームページを管理する方は、特殊なログイン方法などを用いることなくインターネットから管理画面へアクセス可能です。Classic Load Balancerではできなかったことなので、注意してください。
構築期間の短縮
AWSのALBやRDSのマルチAZを利用することで、構築期間を短縮できました。構成の構築までであれば1日あれば準備できてしまいます。
おわりに
今回は負荷分散と障害への対策を考慮した冗長化WordPressの構築事例をお伝えしました。今回はWordPressのプラグインを使いたい背景などもあり、静的化したWordPressは採用しませんでした。ユーザーの要件に応じて適切な構成を検討し、構築コストを抑えて実現することができた事例です。
