※～MTの再構築を改善！～パフォーマンスチューニングとシステム構成の集中講座 【１】の続きです
次いで3点目の『サーバスペック』。
まずハード的な観点。MTについてはメモリよりもCPUパワーが重要、メモリは4GB程度で十分とのことです。まあ、これは専用サーバを用意するようなサイトの話しですけどね。そして、DB関係についてはDiskのI/Oがボトルネックになるので、RAID構成やSSDを使用することでパフォーマンス向上も望めるとのこと。SSDについては3倍ほどパフォーマンスが向上することもあるとか。
で、ソフト的な観点についてはMySQLの話しが中心。MT5からMySQLを強く推奨しているのですが、その理由はMySQLの技術情報の多さだそうです。PostgreSQLユーザー会協賛会員の立場としては、ちょっと受け入れがたかったりしますが、確かに大規模ハイパフォーマンスの構築事例はMySQLが多く、それらのフィードバック情報も豊富ですよね、、、。MySQLのストレージエンジンはInnoDB（標準はMyISAM）を使用する方がよいそうです。そして、my.cnfでパラメーターのチューニングをすることで、某有名ブログサイトで9時間かかっていた再構築が1時間まで短縮されたそうです。それは、すごい。
実は私が関わってるMovable Typeは全てPostgreSQLで構築しているのですが、パラメータチューニングが難しいのは事実ですね。というか、PostgreSQLを運用する上でのチューニング以上のことが難しいです。もうちょっと、PostgreSQLの構造的な部分を考えてチューニングをすべきなのですが、如何せん情報が少なくて苦労しています。うーん、ハイパフォーマンスサイトを構築する場合は、MySQLの選択も考えないといけないですね。っていうか、MT5はMySQL使うべきですね、現時点では。
と話しがそれましたが、ソフト的な話しでは当然だったりしますがmemcachedの利用でのパフォーマンス向上も考えられるそうです。まー、HDDにアクセスしなくなれば当然パフォーマンスは向上しますよね。
そして、最後の『システム構成（サーバ分散）』について。
MTの構成を考えるとWeb/App/DBの3層モデルになっているので、それらを分散させることは容易。そして、分散させることでパフォーマンス向上が望めます。サーバスペックをあげていくスケールアップよりも、スケールアウトでサーバ台数を増やす方がパフォーマンス向上が容易な場合も多いとのこと。
具体的な例として、mt.cgiを別サーバで動かすだけでも効果があるそうです。サーバ分散の例は、「[Web/App/DB] → [Web | App/DB] → [Web | App | DB]」の順番で分割しましょうとのことです。ちなみに、MTのライセンスはmt.cgiが動いているかどうかなので、上記の範囲で分散する限りライセンスは1つで問題ないようです。
MT4からターゲットを法人に移したので、大規模なサーバ構成のものの相談が増えてきているみたいですね。そのあたりでも、SixApartさんに相談するのもありですね。ちなみに、某社のシステム構築例を見せてもらいましたが、もはやMT云々じゃなくてサイト全体のシステム構築の話しですよね。このあたりに来ると、かなりの大規模サイトでコンテンツなんかも大量なサイトの話しですが、いざという時のために知っておくべきお話でした。ああ、大規模サイトMTで構築してみたい。
というわけで、かなり長くなってしまいましたが、ProNet勉強会「～MTの再構築を改善！～パフォーマンスチューニングとシステム構成の集中講座」についてでしたー。