MD-Blog_Server/Network

CMSソフトウェアとしての二大巨頭「Movable Type」と「WordPress」が存在する。
どちらが優位かという話は多くのサイトや雑誌などで語られ尽くされているが、決定的な結論は出ていない。

結局、作り手の好みによるのかもしれない。

---

＜Movable Type（通称：MT）＞

長所：サーバの負荷が（WordPressに比べて）少ない。
再構築したファイルは静的ファイルとして生成されるので、ユーザアクセス時のサーバへの負荷が少ない。

短所：再構築（ファイルの出力処理）が必要。
記事数が増えれば増えるほど、再構築による待ち時間（再構築中のサーバ負荷）が増える。
1000件近くになると、それなりのサーバスペックが必要（※）。
※再構築のバックグラウンド化など出力を定時処理することも可能だが、実務ベースだとそういう訳にもいかない。またダイナミックパブリッシングについては今回は割愛。

＜WordPress（通称：WP）＞

長所：再構築不要！
PHPとDBにて構成されており、動的に表示出力されるため、管理画面から登録・編集したデータはサイトへ即時反映される。

短所：アクセス増によるサーバへの負荷が増える。
長所の裏返しだが、アクセスに応じて、サーバへの負荷が増えていく（少し語弊があるが）。

---

ただ、上記の長所と短所を補う方法が、両者にてそれぞれ存在するため、あまり比較の意味をなさない。

それぞれ方言と言える独自の手法が存在しているため、
やっぱり、作り手の好みによるのかもしれない。（二回目）

MTがPerlベース、WPがPHPベースなので、カスタマイズ時のコード解読や改修は、
やっぱり、作り手の好みによるのかもしれない。（三回目）

ちなみにMONSTER DIVEでは、クリエータの実績＆社内のノウハウ蓄積により、Movable Typeを導入することが多い。（運用フェーズに入ってから、クライアントに追加要望をもらったときに解決策がすぐに提示できるため、という理由もある）

※規模によっては、Movable Typeの兄貴分的存在のPowerCMSを使うこともある。検索周りや記事の承認フローなどをこだわる場合は、PowerCMSがオススメ。PowerCMSに関してはコチラ！

さて、そろそろ本題。

そんなMTだが、バージョン5.2.2からPSGI対応し、一部ディペロッパから「スゲー速くなった！」と賞賛の声も上がっている。
せっかくなので、その環境にて、MTを動かしてみたいと思っていたところで、時間ができたので、試しながらブログを書いてみるとする。

PSGIとはウェブサーバレイヤを抽象化する仕様で、PSGIに対応したMovable TypeはPSGIサーバ上で動作することが可能。CGIと同様、Perlで書かれている。ただ、PSGIサーバは簡易的なウェブサーバ機能しか無いので、実務ベースでは、やっぱりApacheやnginxと連携させて動かすのが吉。（Apacheやnginxは、PSGIサーバにリバースプロキシ出来る機能を備えている）

通常、当社では、
「Linux + Apache + MySQL + Perl(CGI)」
といったいわゆるLAMP環境にて、MTを構築することがほとんどだが、大規模プロジェクトなどでアクセス増のプロジェクトも増えてきたので、PSGI導入だけでなく、Apacheよりも軽量だと噂のnginxと、スケールアウトの代表格AWS（Amazon Web Service）を用いて、
「Linux(AWS EC2) + nginx + MySQL(AWS RDS) + Perl(PSGI)」
という環境でMTを構築してみようと思う。
（EnRP。。。読めない。。。）

実験開始！

前置きが長くなりすぎましたが、ここからが実験です。
今回は2013年7月10日より配布されているMT6ベータ1を用いてやりますが、現時点の安定版のMT5.2.7でも同じです。

環境は前述したとおり、
・サーバ：EC2（CentOSベース）
・フロント：nginx（リバースプロキシ設定）
・バックエンド：PSGI/Plack
・DB：RDS（MySQLベース）
で構築する。

構築の手順としては、以下。

1. AWS EC2の準備

今回は、テストなので、まっさらなAMIを利用する。

・Amazon Linux AMI 2013.03.1(64bit)
・T1 Micro

を選択。（あまりに多く語られているので、詳細は割愛）
InstanceのStateが "running"になったら、ひとまずSSH接続。

$ ssh -i hogehoge.pem ec2-user@[publicDNS]

作業手順簡略化、環境変数などのため、rootになっておく。ついでにパッケージ類のアップデートも。

# sudo su -
# yum update

2. nginxのインストール

まずは、nginxのインストール。ついでに開発ツールとしてmakeとgccもインストールする。

# yum install make gcc nginx

インストールが完了したら、お決まりの自動起動の設定と、nginxの起動を行う。

# chkconfig nginx on
# service nginx start

で、nginxを起動。ためしに、publicDNSをブラウザで叩いてみると、デフォルト画面が表示され、ちゃんと動いているのが分かる。

ちなみにAWSだと"poweredby.png"の画像がリンク切れ。
今回、そこはどーでもよいので、先に進む。

3. PSGI/Plack関連インストール

PSGI/Plack関連インストールは、CPANでも出来るが、個人的に使いにくい印象を持っているのと、関連モジュールをいれるのが面倒なので、cpanminusを使う。

ちなみに、CPANが既にセットアップされている環境では、以下のコマンド一発でインストール出来るとのこと。

# cpan App:cpanminus

今回はAWSのデフォルトAMIからなので、CPANのセットアップすらめんどくさいので、curlでcpanminusをインストール。

# yum install perl-CPAN
# cd /bin
# curl -LO http://xrl.us/cpanm --insecure
# chmod +x cpanm

やっとcpanmでPlackを入られるようになります。

# cpanm Task::Plack

なぜかインストール出来ていなかった以下も個別インストール。

# cpanm CGI::Emulate::PSGI
# cpanm CGI::Compile

XMLRPCを利用するために、XML::Parserなどなどをインストール。

# yum install openssl-devel
# yum install expat-devel
# cpanm XMLRPC::Transport::HTTP::Plack

4. nginxのリバースプロキシ設定

# vi /etc/nginx/nginx.conf

で、

location ~ \.cgi$ {
proxy_pass http://127.0.0.1:5000;
}

を追加し、設定を反映。

# service nginx restart

5. MTの設置

SixApart社のサイトより配布されているMT6をダウンロードし、以下の通り、サーバに設置する。

mt-static：　/usr/share/nginx/html/mt-static
その他のファイル：　/usr/share/nginx/html/cms
※mt-staticをcgiファイルと同じ場所でも良いが、なんとなく、静的ファイルをcgiファイルと一緒に置くのが個人的に嫌い。w

6. RDS(mySQL)の用意

# yum install mysql-server mysql mysql-devel
# cpanm DBI
# cpanm DBD:mysql

本来、RDSを使うので、EC2にmysqlを入れる必要は無いのだが、DBD:mysqlをどうしても入れられなかったので、あきらめる（恥）

7. MTの起動

# cd /usr/share/nginx/html/cms
# plackup mt.psgi
HTTP::Server::PSGI: Accepting connections at http://0:5000/

　 ここでエラーが表示されるようなら、関連するモジュールが足りていないと思われます。その場合、

cpanm モジュール名

でひたすら入れてください。

mt-config.cgiが無いと、怒られるので、起動前に一回書いておく。
起動したら、mt-check.cgiのためにリネーム。
なお、"HTTP::Server::PSGI: Accepting connections at http://0:5000/"が表示されていたら、待機状態です！

8. mt-check.cgiの確認

ブラウザから、
http://[publicDNS]/cms/mt-check.cgi
にアクセス。

もし足りないモノがあったら、地道に入れる。

9. mt-config.cgiの用意

基本的には、通常のセットアップ方法と変わらない。
今回は、RDSに事前にdatabaseを用意しておいた。

10. MTにログイン！

ブラウザから、 http://[publicDNS]/cms/
にアクセス。
慣れ親しんだ管理画面が表示される！ハズ。

その後：PIDファイルの準備

今回はココまでですが、通常運用には、PIDファイルの準備などが必要になってきます。
そのあたりはいろいろな文献が存在するようなので、ググってみてください。

まとめ！

さてさて、爆速PSGIを体験するために、長い道程になってしまいましたが、CentOS（AWS EC2）上でのPSGIサーバ構築手順があまり存在しないようなので、多少は、見ていただいた方のお役に立てればと。 もう少し実務レベルで使えるようになるには、安定性なども含めて、いろいろ実験してみたいところです。

ちなみに、速度ですが、試しに当ウェブサイトのデータをぶっ込んでみたところ、管理画面でのエントリー一覧の表示時間、記事編集時の処理など、Apache+CGIと比較して、Nginx+PSGIでは、体感値で2～4倍近く速くなっていると思われます。Memcacheなども未導入の時点でこれなので、さらに最速の環境がつくれそうな気がします。

真面目に、これらを導入すればAWSのInstance Typeもグレードが落とせるかもしれません。（コスト削減！）

今回、Nginxも同時に導入してしまったので、正直、速くなった原因が、NginxなのかPSGIなのか、明確に分かっていません。そのあたりの細かい計測は、また後日、時間があるときにでも。

なお、PSGIに対応していないMTプラグインもあるので、安易に導入してしまうと、今後の拡張時、カスタマイズ時には困ることが出てくるかも、です。

CGIかPSGIのどちらが良いのかは、
やっぱり、作り手の好みによるのかもしれない。（四回目）