ZAICOでは、Android・iOS・Rubyエンジニアを絶賛募集中です！ 詳しくは、採用ページをご覧ください。
こんにちは、zaico開発チームです。
ZAICO社のランディングページ（以降、LP）ではWordPress(KUSANAGI)を採用していてConoHaのVPSで稼働しています。
ZAICO社のサービス(zaicoやZAIなど)はAWSで稼働しているので、今回はそのLP環境をAWS環境に移行するということを考えてみました。
メリット・デメリット
移行する前に、メリット・デメリットを列挙してみました。
移行するにもメリットが大きくなければ移行する意味はあまりないですよね。
メリット
- １つのパブリッククラウド集約によりAWS以外の操作方法など学習コストが掛からず、普段使い慣れている操作感で扱える
- AWS提供のELB/RDS/WAFなどが使えるようになり、負荷分散やセキュリティ向上が図れる
- CloudFront(CDN)の導入も検討でき、高可用性に出来る可能性がある
デメリット
- 集約によりAWSで障害発生時にサービスだけでなくLPもすべてダウンする可能性がある
- ELBやRDSなどを導入した場合に、ランニングコストが高くなる
こんな感じでしょうか。
デメリットはあるものの、運用者目線で見たらメリットの方が大きいのではないかと思います。
移行検討
AWSに移行するにあたり、せっかくなので構成も変えてみることにします。
現状は下記のように単一のサーバにDBなどが入っており、オールインワンの構成です。
それを下記のような理想のアーキテクチャ、ロードバランサー導入(ALB)+コンテナ化(ECS)+DB分離(RDS)のように出来ないかを考えました。
理想のアーキテクチャにより以下のメリットが得られると考えました。
- 高可用性（負荷分散+オートスケーリングの迅速化）
- DoS対策（AWS Shield）
- 耐障害性
移行検証してみた結果
結論から言うと理想のアーキテクチャに出来ませんでしたorz
ハマりポイントはいくつかありクリア出来たポイントもあるのですが、検証期間に限りがあり最終的には理想の形に持っていくことが出来ませんでした。
主なハマりポイントは以下の通りでそれぞれについて述べていきます。
- WordPress(以降、WP)のバックアップデータの復元
- WPのデータベース(以降、DB)のデータの持ち方
- KUSANAGIのセットアップ
なお、検証はLPのテスト環境のデータを用いて、Dockerを使ってローカル環境で動作確認等をしてからAWSのECS+RDS環境に移行するという流れでやりました。
また、KUSANAGIをDocker環境上で動かせるKUSANAGI RoDが提供されていたのでそちらを使って検証しました。
1. WordPressのバックアップデータのリストア
※これはBackWPup Proの使い方がわからなかったためハマりました。
BackWPup Proというプラグインを用いてフルバックアップ（テーマ、プラグイン、メディア、DB）を取得しています。
BackWPup Proでバックアップしたデータのリストア方法は手動でゴリゴリ頑張るやり方とBackWPup Proのプラグインを使う２種類があります。
プラグインでバックアップしたものはプラグインでリストアするのがスムーズだと思い、プラグインでリストアを試みたのですがここでハマりました。
BackWPup Proのリストアは公式サイトから購入してダウンロードしたBackWPup Proの中に入っているスクリプトのようなものでリストアする必要がありました。
マニュアルにもそう記載があったのですが、それを読まずにWPのGUIからインストールできるBackWPupのプラグインで試してリストア画面がなかったり、ZipでアップロードしたBackWPup Proのプラグインのリストア機能を試して正常にリストア出来なかったりで苦戦しました。
<教訓>
マニュアルはちゃんと読みましょう
ここテストに出ます。
2. WPのデータベースのデータの持ち方
KUSANAGI RoDでローカル環境にKUSANAGI環境をセットアップし、テスト環境のバックアップデータをリストアまで出来ました。
その後、ブラウザでローカル環境にアクセスしたところテスト環境のLPにリダイレクトされました。
最初は「？？？」となり、URLを間違えたかと思ったのですがそんなことはなく２回目のアクセスもリダイレクトされ「！？！？」となり、調べたところWPはデータベース内にサイトのURLを保存しているということを知りました。
探して置換する必要があり「なるほど、めんどくさい…」となりかけてSearch Replace DBというツールがあるのを見つけ、そちらを使って置換することが出来ました。
置換後にローカル環境にアクセスするとリダイレクトされることなくローカル環境のLP（中身はテスト環境のデータ）が表示されました。
WPを扱う上で、ドメインが変わる移行をする場合（今回はテスト環境のドメインからローカル環境のドメインに変更）は置換をしなければならないという事がわかりました。
3. KUSANAGIのセットアップ
今回一番ハマったポイントであり、クリアできなかったポイントです。
移行環境を構築するにあたり、最初からECS+RDSという構成で作るつもりでいました。
なので、RDSは予め作成しておいてKUSANAGIのDBは使わず（作らずに）kusanagi-docker provisionコマンドで出来上がったコンテナイメージを用いてECSに展開するKUSANAGIのDB接続先を作成済みのRDSのエンドポイントにすれば良いと思っていました。
ところが、ECS環境向けのコンテナイメージを作るためにKUSANAGI RoDを使って初期構築するとDB(MariaDB)も合わせて作られてしまい、分離することが出来ませんでした。
また、KUSANAGI RoDでは kusanagi-dockerというコマンドで作成等をするため通常使う docker-composeとは異なり、どこまでKUSANAGI RoD独自のコマンドがあるのか調べきれていませんでした。
※docker-composeコマンドのwrapperとのことなので、docker-composeコマンドでやっても問題はなかったのかもしれません。
KUSANAGI RoDの利用を諦め、AMIで提供されているKUSANAGIを利用することにしセットアップを試みたのですが、こちらでも初期構築時にEC2上にDBが作られてしまうようでした。
可能であれば、初期構築時は余計なリソース（今回で言えばDB）は作成せず、理想のアーキテクチャの形で作りたかったのですがどうもうまく出来ませんでした。
KUSANAGIの使い方が不慣れなのか、WPそのものがそういう作りになっているのか、時間が足りず調べきれませんでした。
初期構築時にどうしても包括して作られてしまうのが仕様と判明した場合は、素直に諦めてDBを包括した形で初期構築した後にDBをRDSに移行するという形を取ろうかと思いました。
移行検証まとめ
いろいろと試した結果から、コンテナで動かすことはやめて以下のような構成でEC2にDBもまとめてオールインワンで稼働させることがベストな解だと思いました。
上記の構成でも以下のようなメリットが得られるかと思います。
- 移行（構成検討等含む）が低コストで可能で移行時のトラブル（原因特定が容易）も起きづらい
- ALB導入可能でWAFの利用が可能になる
- 後々RDSの分離が可能
上記の構成を実現した後に高可用性を提供するために以下のような構成もありだと思いました。
CloudFront(CDN)とS3を用いて、WPの記事を静的ページ化してS3に配置しそれをCloudFrontにキャッシュさせるという構成です。
静的ページ化する部分はプラグイン等で実装する必要がありますが、それさえできればほぼ無敵のホスティングサービスで出来るのはないかと思います。
最後に
WPは記事を書く上では便利なCMSだと思っていましたが、インフラをどうするか考えた時になかなか癖のあるものだと感じました。
今後どこかのタイミングで移行する際に今回得た教訓を活かして移行が出来たらと思いました。