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