IDCFクラウドが個人向けサービスを閉じるとのことで急遽GCPへ移行した。GCPでの運用は、無料のf1-microインスタンスとプリエンプトなg1-smallインスタンス2つを使う構成。常時稼働のf1-microをディスパッチャにしてg1-smallにphp-fpmやmysqlなどの実体プロセスを置く。しかし、プロキシ的なプロセスのみのf1-microが安定しない。一定期間経過すると(おそらくスラッシングで)沈黙してしまう。いろいろ工夫はしてみたんだけど、残念ながら改善には至らなかった。

GCP+GAE構成も考えた。こちらの問題はwordpressのアプリケーション部分がGAEになるので既存のキャッシュ機構が使えなくなってしまうこと。手前にvarnishを置く構成も検討してみた。それにはwordpressの各URLを相対パスで動かす必要があるのだが、この変更がなかなかうまくいかなかった。ログイン処理がおかしくなったり、キャッシュがいつまでも消えなくなったり。もしかしたらマルチサイト化してなければ、そこまで難しくはなかったのかもしれないが。そもそも構成がやたら複雑なのも嫌気して、これも諦めた。

そこで白羽の矢が立ったのがIDCFクラウド。何だかんだいって使い続けられそうだったので、もう出戻りしてしまおうかと。そもそも以前の実績はあるし。この機会に現代的な変更も加えて再構築するか。という訳で、久々にIDCFクラウドを触る。そろそろcloud-initに対応してるかと思ったけど、どうやらまだのようだ。ワンタッチでカスタムインスタンスを作れるようにしたかったが、そこは次回に譲る。以前まではCentOS7で作っていたが、今回はUbuntuにして、更にLXCでのコンテナ構成も捨てる。

インスタンスをホストOS扱いにしてLXCコンテナを切ると、非常に柔軟な構成が取れて、自宅環境と同等の仕組みを作れるんだけど、ネットワーク的に複雑なことをやらざるを得ないのと再構築がだる過ぎてしまう。いまどきはイミュータブルであることを優先して再構築効率を引き上げたい。要は普通に作るだけなんだけど、インスタンスそのものにwordpress環境を構築する。最も構造的に変化するのはLVSがなくなってしまうこと。ロードバランサはIDCFの無料のものを使えばいいかな。

Ubuntuのインストールやnginx, php-fpm, mysqlの設定はお手のもの。2台目も作ってロードバランサも設定して冗長なwordpress環境の構築完了。こんな簡単に環境を作れるなんて、ほんとクラウド時代に大感謝。何の問題もなく普通に使えていたんだけど、ある日wordpressのバージョンアップを促すメッセージが。おもむろにバージョンアップを実行するが、どうしてもタイムアウトしてしまってエラーになってしまう。nginxやphp-fpmのタイムアウトを伸ばしても解消しない。何だこれ。

結論から言うと、IDCFロードバランサのタイムアウトだったようです。しかも、その時間は50秒固定で変更できないらしい。うーん、惜しかった。やむなくロードバランサを介さずに1号機直結のポートフォワードに変更。これで無事バージョンアップが出来た。やはりロードバランサの問題か。有料のインフィニットLBだったら問題ないらしいけど、こんな理由で切り替えるのもねえ。LVSに戻すにしてもWebサーバに同居させる構成って取れるんだっけ。一時期そう言う構成を取ってたような記憶もあるけど問題もあったような。

まあ、keepalivedで共有IP方式を取って、その先にhaproxyかnginx辺りで振り分ける辺りが落としどころか。php-fpmに繋ぐ手間でどうせnginxは使っているので、そこで振り分けるのがスマートなんだけど、その場合はリモートもphp-fpmに接続する必要がある。wordpressの管理ページがリモートphp-fpmだと動かなくなったりするんだよなあ。理由は追求しきれていないんだけど。これを機に解決してnginxでのロードバランスを使うか。nginxは事前に切り離すことをしてくれないから、そこはLVSの方が優秀なんだけどね。

最後に画像を置くストレージとしてGCSを使う。元々はIDCFオリジナルのクラウドストレージがあったんだけどサービス終了してしまった。wordpressの画像置き場としてGCSを使うのはGCPのときにもやっていたので、それほど抵抗はない。GCP側でバケットを作って、それをIDCFで登録する。GCSをインターネット経由で使うと通信量に対してお金がかかるので、gcsfuseを入れてマウント、そこをwordpressで参照する。既存ディレクトリは一度mkdirしないと見えないので注意。GCSになったことで以前より高速化したね。