実際に使ってみてよくわかったMovable Type for AWSの特徴まとめ
こんにちは、エンジニアの池田です。
シナップサイトがリニューアルされました。以前のサイトを憶えていますか。一週間前のことながらわたしはもう思い出せませんでした。こんなでした。
自社のサイトながら、正直、古いな......という気持ちを禁じ得ませんでした。皆さんは、リニューアルされた今のサイト、どう感じるでしょうか。
さて、今回のエントリーは、そのリニューアルにちなんだお話です。
シナップは、ウェブサイトの制作ではMovable Type（MT）の使用を得意としています。プロジェクト事例ページで紹介しているプロジェクトも、半分ほどはMTの案件です。そしてもちろん、今回のリニューアルでも、MTを使用しています。
2015年の現在、MTを動かす環境には様々な選択肢がありますが（「Movable Typeシリーズの違いをまとめてみた」をご覧ください）、リニューアルで使用したのは、必要なソフトウェアや設定が全てセットアップ済みのAWS EC2インスタンスが使える、Movable Type for AWSです。この記事では、実際使ってみて、特徴的だと思ったことを挙げていきたいと思います。
Movable Type for AWSとは
Movable Type for AWSは、MTに必要なセットアップが全て済まされている状態の「サーバーの雛形」です。
AWSという、Amazon社が運営しているクラウドサービスでは、ユーザー（ここではシックス・アパート社）がサーバーの雛形を登録し、それを元に誰でも（ここではシナップ）、簡単に、何台もサーバーを起動させることができます。それも、ブラウザーで管理画面にアクセスして、料金プランなどを選択していくだけで、サーバーの調達やMTを含む必要なソフトのインストールまでがあっという間に終わってしまいます。
やや詳しい話をすると、Nginx、PSGI（Starman）、PHP FPM、MySQLがインストール・設定済みの状態で起動するので、管理画面が高速に動作し、ストレスの少ない編集が行えます。
Movable Type クラウドやMovableType.netとは違い、サーバーやインストールされたソフトウェアの管理は自分で行いますが、逆に言うと自由にプラグインを使える、他のツールとの連携に制限がない、といった柔軟性は確保されたままということになります。
それでは特徴をご紹介していきましょう。
使い始めるまでが早い
MTを使うまでには、通常、
- レンタルサーバーを借り......
- シックス・アパート社とライセンス契約を結び......
- MTのファイルをダウンロードし......
- ファイルを展開し......
- データベースの設定などを行い......
- ファイルをサーバーへアップロードし......
という手順が必要です。
また、MT for AWSのように、自分で管理しているサーバーで使う場合には、
- サーバーにNginxやStarmanやPHP FPMやMySQLをインストールし......
- それぞれの設定を正しく行い......
といった作業まで行わなければなりません。
これがMT for AWSでは、AWSの管理画面で数クリックするだけで、以上すべてのことが終わった状態のサーバーが起動します。ライセンス発行などの待ち時間もないため、使おうと思い立ってから30分程度で、もうサイトを作り始められるようになってしまいます。
今回のリニューアルでは、なるべく早く実装に着手したかったため、こうして素早く環境を用意できるのはとても役立ちました。
また、別のプロジェクトですが、MTのライセンス契約について、稟議も含めて数日〜数週間の期間を要する物がありました。ただ、実装自体は始めていないと、プロジェクト後半に苦しくなることが分かっています。そこで、一時的にMT for AWSでサイトを制作しておいて、契約やドメインの決定などが済んで本番サーバーを用意できる段になってからAWSからデータを移すようにしました。最終的にデータやファイルを移行する手間はかかるのですが、待ち時間がもったいなく、事実その間に実装が終わるほどのボリュームだったので、ここでも使い始めまでの素早さが活躍しています。
従量課金制なのでフレキシブルに運用できる
MT for AWSの料金体系も、通常のMTとは異なっていて、従量課金制になっています。一時間使用するごとに、AWSを経由してシックス・アパート社に利用料が支払われる仕組みです。
もし上の「別プロジェクト」のような運用を通常のライセンスで行おうとすると、
- シナップとしてライセンス契約を結び、MTをインストールする（二、三日）
- クライアントの準備ができた段階で契約を結んでもらい、本番環境にMTをインストールする（稟議等の前処理次第）
と、二度MTライセンスを購入する必要が出てきてしまいます（ライセンスは譲渡できないため）。始めのシナップが購入するライセンスは、明らかに無駄です。実質的には、このような作業は不可能でしょう。
これがMT for AWSであれば、利用した時間分のみの安価な料金で済むので、多少の無駄で済みます。実装をスムースに行えることを考えると、充分ペイします。
もう一つリーズナブルな点があって、AWSの一番性能の低いサーバーであれば、MTの使用料は無料に設定されています。Amazon社の方に、サーバーの実費を支払うだけで済むのです。リリース前の実装・確認作業であれば、当然高性能なサーバーは必要ないので、更にコストを節約できます。
ディレクトリー構造が独特
始めからサーバー設定などが既に終わっているので、普段はサーバー内のディレクトリー構造を気にすることはありません。ただ、MTを経由しないでファイルをアップロードしたい場合などには必要になってきます。
MT for AWSで採用されているディレクトリー構造は、レンタルサーバーなどでよく見る構造とは異なっているため、戸惑うかも知れません。公式ドキュメントで網羅されているので、確認しておきましょう。
DBにパスワード無しでログインできる
データベースサーバーであるMySQLがMTからアクセスできるよう、予めユーザーやパスワードが設定されています。これは便利なのですが、管理者であるrootユーザーのパスワードが設定されていません。サーバー外からのアクセスは禁止されているので、即座に問題とはならないのですが、変更しておいたほうがいいでしょう。
定期実行タスクが登録されていない（されていました）
MTでは非常によく使う、run-periodic-tasksというスクリプトがあります。定期的にサイトを監視して、日時指定の公開があればその処理をしたりしてくれるスクリプトです。
MT for AWSが至れり尽くせりなので油断してしまいましたが、このスクリプトの実行は設定されていませんでした。シナップではほぼどのプロジェクトでも設定しているものなので、始めから動作していると嬉しかったのですが......。
シックス・アパート様からご指摘いただいたのですが（読んでいただいてありがとうございます！）、設定されていました。
/etc/cron.d/movabletypeに、run-periodic-tasks実行の設定が書かれていました。
よく確認せず申し訳ありませんでした。お詫びして訂正いたします。
バージョンアップが非常に簡単
バージョンアップが非常に簡単です。「yum update」コマンドを実行するだけです。
MTに新バージョンが発表され、アップデートするときには通常は、
- シックス・アパート社のサイトにログインし......
- 新バージョンのファイルをダウンロードし......
- 手元で展開し......
- サーバーへアップロード......（またはアップロードしてから展開）
という手順を踏む必要があります。
書くと簡単なようですが（実際難しくはありませんが）yumコマンド一発の簡単さ、心理的敷居の低さには敵いません。更に、NginxやMySQLといったほかのソフトウェアと同一の方法でアップデートできるので、管理方法を統一し、単純化できます。
バージョンアップというのは、一番のセキュリティ対策になるため、いつでも行うべきです。手順が多いと費用、心理的な敷居、作業の所要時間が増えることからバージョンアップを妨げ、好ましくありません。コマンド一つで実行できるのは重要なメリットです。
ただ、アップデートすると自動的にPSGIサーバーが再起動されるようなので、そこは注意してください。
設定再読み込みができない
旧来のようにMTをCGIで動かしていれば、プラグインのアップロードや設定ファイルの変更はすぐに反映されますが、MT for AWSではPSGIで動いているため、その都度再読み込み処理を行う必要があります。
ここでも予めPSGIサーバー（Starman）の管理スクリプトが用意されていて、Apache HTTP Serverなどと同様に、再読み込みであれば
$ sudo service movabletype reload
とコマンドを打てば行えるようになっています。
......なっているように見えました。ところが、実際に実行してみると、このコマンドは常に失敗してしまいます。
しかたがないので、
$ sudo kill -HUP $(cat /app/run/movabletype.pid)
でStarmanに直接シグナルを送って再読み込みするか、
$ sudo service movabletype restart
で再起動してしまう必要があります。
AWSのメリットを享受できる
AWSというのは、Amazonが運営する複数のサービスをまとめて呼ぶ呼び方で、MT for AWSで使っているのは、そのうち、サーバーの雛形を登録して使い回したり、実際それを元にサーバーを起動できるEC2というサービスです。
AWSには非常に多くのサービスがあり、しかも相互に連携を取りやすくなっています。MT for AWSは、AWSで動いているということで、そういった連携しやすさというメリットも自動的に享受できるようになっています。この組み合わせは膨大のため紹介し切れませんが、主には以下が挙げられるでしょう。
スケールアップが簡単
AWSのEC2は、数クリックで簡単にサーバー性能を上げることができます。
- 現在動いている物とは別の高性能サーバーを用意し、
- そこへデータやコンテンツを移し、
- DNSやロードバランサーの設定を変えて新サーバーを使用する
といった煩わしさはなく、ブラウザーで管理画面にアクセスし、数クリックするだけで、同じデータやファイルを保ったまま、性能を上げたサーバーでの運用ができるようになります（数分の再起動時間が必要です）。
例えば、サイトがテレビで取り上げられることになった、など、ある一定期間だけ集中してアクセスが見込まれる、といった場合にぴったりです。
バックアップが簡単
MTのサイトのバックアップには、
- データベースのデータ
- 再構築で作成したファイル
- CGIファイル
- その他サーバーの設定ファイルなど
を、定期的にどこか（バックアップサーバーなど）へ保存する必要があります。このためにSFTPソフトで自分のパソコンへダウンロードしたり、保存するためのスクリプトを用意して他のサーバーへ転送したりします。保存のためのサーバーが必要にもなります。
ところが、AWSでは、サーバーをそのまま、しかも無停止でバックアップする「スナップショット」という機能があるため、これを使うだけでワンクリックでバックアップができてしまいます。当然、スクリプトでスナップショット作成を自動化することもできます（スナップショットの保存サイズに応じて課金されます）。
監視が簡単
ほかにも、監視のためのCloudWatchというサービスがあります。予めAWS側で設定された項目（サーバーが起動しているか、CPU使用率はどの程度か、など）であれば、有効にするだけですぐに監視をスタートできます。それ以外も、自分で監視スクリプトなどを用意し、CloudWatchにデータを集めることで、一箇所に監視に必要な物を集めることができます。
監視がない状態では、万が一障害でサイトが見られなくなってしまった場合にも気付けず、知り合いから教えてもらって初めて知る、というばつの悪い思いをすることもあります。とは言え、そのためのサーバーを用意し、そこへ監視ソフトウェアをインストールする、というのも、それなりの専門知識が必要なことで、手が出ないこともあるでしょう。
CloudWatchでは、インストールまでは既に終わっているようなものなので、あとは監視項目を選んだり、問題が生じた場合の通知先を設定するだけでひとまずは監視体制を整えることができます。それも、ブラウザーによる管理画面操作だけで、です。
以上のように、Movable Type for AWSは、気を付けるべきことがありつつも便利に使えるシーンが多いので、新規構築や、既存サイトのメンテナンスの手間を減らしたいといった場合には検討してみるといいでしょう。
