フォローウインドのWebサーバーをMovable Type for AWSに移行しました。
Webサーバーがnginx版で、仮想化方式はHVMです。
Movable Type for AWSとは？
Movable Type for AWS は、Movable Type 6 がインストールされた、OS込みの Amazon Machine Image（AMI）です。
OS、アプリケーション、ウェブサーバー、PSGIサーバー、PHP、データベースがすべて Movable Type にチューニングされた形で提供されるため、数クリックで簡単に Amazon EC2 サーバー上に環境を構築できます。
apacheからの脱却
もう10年以上もWebサーバーはapacheを使い続けていました。
本当はapacheの方が慣れていますし、枯れているので、
ぎりぎりまでapache版にするか悩みました。
でも敢えてnginx版を選択しました。
個人的にやってみたかったんです。
でもかなり、苦労しました。
Movable Type for AWSのnginxはクセがある
ただでさえ、apacheからのnginxなのでハードルが高いのですが、
Movable Type for AWSのnginxのコンフィグファイルは結構特殊です。
最初、通常のnginxのコンフィグいじってて、全然反映されないなぁ、と焦りました。
しかも常時SSLに301リダイレクトをしたい。
一つ一つテストサーバーでトライ＆エラーの繰り返しです。
SSL証明書も前のサーバーから持って来たので、
証明書更新の際にちょっと焦りそうです。
Movable Typeのバックアップリストア
ここで最初つまづきましたね。
結論から言うと、MySQLのデータダンプして、インポートした方が確実です。
プラグインもnginxだとNGなものがあったりするので、注意が必要です。
FTPSも結構厄介
MT関連のディレクトリのオーナーはnginx（www）です。
FTPSは通常、Amazon EC2のデフォルトユーザーであるec2-userを使うので、
アクセス権がないので、テンプレートやプラグインをFTP上でいじりにくいんです。
結果、グループwwwに属するユーザーを作って、
変更が必要なディレクトリのみアクセス権を与えました。
サーバー管理者とサイト制作者が違う場合、これは必須でしょうね。
極めつけはPHP
あるフォームで「Securimage」というPHPの画像認証ライブラリを使っているのですが、
ここが一番はまりました。
2時間くらい格闘した気がします。
普通に移行しても、画像認証が通らない。。。
nginxとPHPもまたクセがあります。
答えはセッションでした。
デフォルトではPHPのセッション、貯めてくれないんです。
t2インスタンスのバーストはかなり良い
もともとt1インスタンスだったので、特に再構築の差異に、ものすごい時間がかかっていました。
t2インスタンスの強みは何と言ってもバースト！
びっくりすくらい再構築が早いです。
正直、単一ドメイン、単一サイトであれば、microインスタンスで十分では？と思います。
アップデートはyumコマンドで一発！
Movable Typeのアップデートやアップグレードって結構面倒くさいんですよね。
クラウド版もそうですが、AWS版もコマンド一つで適用されます。
アップデートする前に、スナップショット取っておけば、
万が一の時もすぐに前のバージョンに戻せますね。
そしてやっぱり秀逸なRoute53
こういった検証やテストサーバーと本番の移行。
Web関連なら最終的にDNSのお世話になります。
Amazon Route53はとにかく浸透が早い。
すぐに本番に反映されますし、問題あればすぐに元に戻せます。
以前のサーバーは停止しておいて、念のためスナップショット。
1週間くらいしたらターミネート。
もちろんElastic IPは必ず解放しましょう。
やっぱりAWSは楽しい！
次はMySQLをRDBに移行して、あとはS3への静的コンテンツの移行ですね。
もう一台あるグループウェア用のWebサーバーもt1インスタンスなので、
これも年内中にt2へ移行しようと思います。
お客様にも使っていただけるスペックとクオリティだと思います。
ここまで来ると、正直他のクラウドベンダーに手を出す勇気がないですね。
AWSはSIerにはかなり楽しいサービスだと思います。
（山下 史彦）