wordpressの運用は既に8年近くに渡っているが、まともな複数台運用が実現できていなかった。大したコンテンツではないが、それでもクラウド費用くらいは稼いでくれるので、出来る限りダウンタイムの少ない運用を行いたい。その結果としてwordpressサーバは大胆な停止が行えなくなり、構造変更がまともに出来ず、古臭い構成に成り下がってしまう。クラウドに移行した一番のモチベーションは、複数台構成にすることで頻繁に更新出来る環境を維持したかったからだ。

最初のGMOクラウドでは、active/slave構成を前提に構築してしまったため、2台あったものの結局1台運用と変わらない状況だった。内部ネットワークの貧弱さが同期的なマルチマスターを嫌厭させたという見方も否めなくはないが。IDCFクラウドでは期待通りLANの形でクラウドが使えるため、マルチマスター構成の導入に踏み切った。まず、DBをMySQLからGalera ClusterのMariaDBに置き換え、更にアプリを配置するディレクトリをGlusterFSでマルチマスター化した。Web UIで更新を行うwordpressではDBと同期的にアプリ部分の変更がなされる必要があるからだ。この2つのミドルウェアを導入することで、念願の複数台運用を実現した。

nginx+php-fpm+mariadbという構成のサーバを2つ用意し、wordpress本体はGlusterFS上に配置する。その2台をLBでラウンドロビンさせて動作確認を行う。admin-barにホスト名が表示される設定を入れてあるので、ラウンドロビンしている状態はすぐにわかる。記事を更新すると双方のサーバで更新状態を確認することが出来たので動作的には問題なさそうだ。しかし、いかんせん処理が遅い。1リクエストに数秒のオーダーで時間がかかってしまう。マルチマスターだと、やはり性能が犠牲になってしまうのかと絶望しかけたが、念のため切り分けくらいはやっておく。

DBのqueryに数秒かかるのであればslow.logに出現するはずだが、幸い何も出ていない。実際、wordpressが発行するqueryを手元で叩いてみるが全然遅くない。どうやらDBが原因ではなさそう。続いてマルチマスター化したGlusterFSをローカルのファイスシステムに戻してみるが、それでも改善しない。仕方がないのでLBのロードバランスをNATに戻して1台構成に切り戻す。何と、この変更で応答性能が問題ないくらいに改善した。どうやら仮想LBでの振り分けに時間がかかっている可能性が高い。試しにnginxのproxyで振り分ける構成に変更してみると、2台構成でも応答速度は問題なくなった。あまり深く追求していないが、IDCFクラウドの仮想LBは使わない方が無難かもしれない。

そして最も悩んだのが2台構成時ののcache戦略。私が利用しているWP Super Cacheは非常に優秀で、これを使うと100msec未満のレスポンスタイムを実現できる。pluginによるcacheが極めて有効なのは、その処理速度だけではない。ミドルウェアによるcacheが一定時間で破棄するくらいの動作しか出来ないのに対し、アプリレベルのcacheは記事更新等をhookしてタイムリーにcacheを破棄してくれる。このpluginのcacheファイルがwordpress本体ディレクトリの中にあり、これを2台で共有すべきか、それぞれに持つべきか、という点に迷うことになった。

cacheは再利用されなければ意味がないので、再利用率の高い前者の方が望ましい事は明白。とはいえ、2台運用の稼働状況を日常的に確認するためには、admin-barでそれぞれのホスト名が見えていて欲しい。admin-barも当然cache対象となるためcacheファイルを共有してしまうと、どちらのサーバが応答したかではなく、どちらのサーバでcacheしたかという意味になってしまう。双方のサーバが稼働していることを確認し易くするには、cacheディレクトリをそれぞれのサーバに持たせる必要があった。2台くらいであれば、そこまでcache効率が劣化するわけではないので、とりあえずは個別にcacheファイルを持たせてみた。リクエストするごとに互いのサーバが応答していたので、全てが期待通りに動作しているかのように思えた。

しかし、あるとき記事を更新した際に、最新記事と一世代前の記事が混在してしまっている状態に気が付いた。どうやら記事更新hookのcache破棄が更新サーバでしか行われず、もう一方のサーバでは古いcacheが残ってしまていたのだ。この問題を解決するには、例えば削除処理のみnotifyして、もう一方のサーバに同期するとか？その構造の複雑さとcacheを分けることで得られる利便性を天秤にかけて、cacheの個別サーバ化は諦めた。管理画面はcache対象外なので、そこで健全性を確認することは出来るはずだし。

この2台構成で数ヶ月運用を続けているが、今のところ何も問題は起きていない。その間にwordpress本体の更新やpluginの更新も対応したが、普通に処理できてしまった。nginxのproxy設定で明示的にdown設定を入れれば、片肺にしてメンテナンスも出来るので、サイト運用しながらOS再インストールやlxcコンテナの再構築など、immutableな運用も可能。あとは事前確認用のstageが作れると尚いいんだけど、wordpress起因の事故はあまり起きていないので、とりあえずここまででいいかなｗ