このブログを CentOS + apache + mod_php + MySQL から GAE/php に移行した話2016-08-01

ここのところ数週間かけて、このブログ、ひいては www.otchy.net 全てを CentOS + apache + php_mod + MySQL だった環境から、GAE/php の環境へ移行する作業をしていて、ようやく一通り完了したので、どういった作業を行ったのかをまとめておこうと思います。

ゴール

• サーバ移行
  
  • 当たり前ですが、自前で構築した環境から GAE という環境へのサーバ移行を行うことが最も重要なゴールです。
• URL 移行
  
  • サーバと環境の移行をするに当たり、URL もこれまでと同じものが使えるようにする必要がありました。従って、ブログのシステムとしてはこれまでのデータをそのまま使える WP 一択になります。
  • とは言え、元々の www.otchy.net ドメインでは、節操なく WP とは無関係な所にもファイルを多く置いて使っていたので、それらについてはリダイレクト等を検討する必要がありました。
• レスポンシブ
  
  • どうせサーバもシステムも移行するなら、ついでにデザインをレスポンシブにして、今更ではありますが、ちゃんとモバイル対応するというのもゴールの1つになります。

実は GAE/php 上で WP が動くと知る前は、wordpress.com で自分のブログをホストすることも考えていました。餅は餅屋で、WP を使い続ける限り、wordpress.com に全部ホストしてもらうのが実は楽そうだったからです。

ですが、以前いろいろと調べたところやはり制限が多く、ゼロからブログを立ち上げて、完全に wordpress.com に乗っかるのであればかなり楽ではあるものの、ここのように、すでにコンテンツ資産を持っていたり、多少は凝ったこともやりたいと思うと、かなり面倒 (あるいは不可能) という点で、他の選択肢を探していました。

その後、最近めっきりファンになった GAE で WP が動くと知るところになり、そうなったからにはもう GAE/php 以外の選択肢はあり得ない、と言うことで今回の移行作業に踏み切りました。これ以降では実際にどのような作業を行ったか順を追って解説していこうと思います。

WordPress on App Engine Starter Project

WP を GAE 上で動かすにあたって、必須となるのが WordPress on App Engine Starter Project です。これは Google の中の人が書いた GAE/php の WP 向けスケルトン + WP プラグインで、WP を GAE 上で動かすにあたって必要なものは基本的に全てここに含まれています。

元々の WP 自体、色々なシーンでそのままローカルサーバにファイルを書き込んで使おうとする傾向にあるのですが、GAE のウェブサーバのインスタンスでは、一切のファイル書き込みが禁じられていて、それらローカルファイルに依存する機能は、そのままだとことごとくエラーになって使えません。
また、GAE では基本的にディスクへのアクセスが高価であるように設計されています。逆に memcached は標準で使えるようになっていてとても安価に設定されているので、可能であればディスクアクセスをなるべく避けるためどんどんキャッシュは活用していくべきです。
これら既存の WP では対応していない部分を、GAE のマナーに合わせて救い出してくれるのがこの WP プラグインであると言えます。

さて、まずはまっさらな環境で WP を動かしてみて、とりあえずちゃんと動作するという事を確かめたかったので、WordPressをGAEで簡単に使う10のステップ を大いに参考にさせていただき、セットアップしてみました。記事が少し古いものなので、画面のスクリーンショットなど今のバージョンとは異なる部分が多々ありましたが、それは基本的に読み替えで問題無く進むことが出来ました。

一点大きく異なったのは、Cloud SQL インスタンスに関しての部分です。現在は、Cloud SQL 第2世代という高パフォーマンスを謳った新バージョンの利用が推奨されています。これはベータ版という扱いになっていて、現状では SLA の保証がなかったり、ポイントインタイムリカバリ (サーバクラッシュ直前まで戻れるリカバリ) が出来なかったりという不利な点があります。個人ブログで気にするものでもないですし、むしろ将来第1世代が廃止される時の移行作業が面倒にならない方が良いと思ったので、第2世代を選択しました。
ところが、選択前には確認出来なかったマイナーな警告の中に、PHP からの DB 接続に問題があるような記述があり、一瞬ヒヤッとしました。まあ、結果的には特に問題もなく使えているので、第2世代で正解だったと思います。

さて、無事に WP の初期インストール画面が表示され、まっさらな WP は動くことが確認出来ました。次は、既存の WP で動いているデータの移行作業を行っていきます。

WP データベースの移行

とりあえず何はさておき、既存の MySQL のデータを全て新しい環境の Cloud SQL に持ってきてみることにしました。ただ、絶対にその方法はあるはずだ、と確信を持ってはいたものの、パッと見ではどうやってデータをインポートしたら良いのかが分かりませんでした。インポートというメニューを選んだら、ローカルのファイルを指定するダイアログが立ち上がるかと思っていたら、肩すかしを食らった格好です。

実のところ Cloud SQL から読み込み可能なファイルを置く場所というのが限られていて、そこに置かない限り、Could SQL のインポート画面に現れません。Amazon を知っている人であれば、EBS をイメージすると分かりやすいと思います。Amazon では EC2 インスタンス上に書き込んだファイルはインスタンスを落とすと消えてしまいますが、GAE ではそもそも書き込めなくして、読み書きするなら必ずここな！という風になっているので、分かりやすいと言えば分かりやすいかも知れません。

WP データの修正

WP のデータベースを丸ごと移行することで、さしあたって各記事は元と同じ URL (この時点では異なる仮ドメイン上の同じ相対パス) で表示されるようになったものの、画像ファイルのパスなどはことごとく切れていて、ろくすっぽ何も表示されない状態でした。それよりもさらに困ったことに、WP のバージョンの違いによる影響か、WP アカウントのログイン情報が正しく動作しておらず、元のデータの管理者アカウントでログインは出来るものの、何の権限もなく管理画面が開けない、という状態でした。
データの内容を読んで修正できないか試みたものの、シンプルそうなくせに、何が原因かを想像することも出来ず、いったん丸ごと全部移行することは諦めることにしました。

色々検証した結果、データを移行した時に問題が発生するのは wp_users、wp_usermeta、wp_options の 3 つのテーブルであると分かったので、元データののダンプからこれらのテーブルの除いた SQL を作り、デフォルトのまっさらな DB にその SQL を被せることで権限の問題は解決しました。wp_options も対象だったので、設定等の移行は手動でやる必要がありましたが、それが済んだ時点でとりあえず新環境でも、管理画面が正しく使えて、新規の投稿をしたり、新規のファイルアップロードをしたりする分には問題無い状態になりました。

さて次は、元々ある投稿内容で画像やリンクが切れまくってる問題を解決しないといけないのですが、それはまた次のポストで書こうと思います。