MTTokyo01プレゼン資料。 「巨大トラフィックの捌き方」というよりは「メディア運営においてMT+AWS使うならこれやるといいよ」的なものになっています。

1. MTを使った
巨大トラフィックの捌き方
mediageneでの施策について
2014.04.20
mediagene

2. 自己紹介
• 緒方昂児（おがたこうじ）
• メディアジーンのテクニカルディレク
ター
• 元Web Director / Flash Developer
• 外資系大手飲料メーカーの公式サイトや
ミニゲームなどを制作
• 国内大手AV機器メーカーの直販ECサイト
のディレクションなどを担当

3. なんでmediageneに？
• オウンドメディアの時代がきたので
（2011年中頃）
• 自社メディアがやってみたかった
• Lifehacker[日本版]の読者だった
• ガジェットが好きだった

4. 入社時の課題
• 制作フローやエヴィデンス保全の仕組みに甘さ
を感じるのでなんとかできないか
※編集部はWeb制作のプロ集団ではないので必然。メーカーのMD
部門のWeb担当者など、他業種他職種でも同じ悩みはあった
• ファイルアップロード等のルールが未整備なの
をなんとかできないか
• MTの管理画面のレスポンスを改善できるか

5. 私がやったこと
• MTのアップローダーのアップロードパスを固定
• 外注とのやりとりにプロジェクトマネージメントツールを導
入
• PSGIの導入
• 内制できる体制の確保
• 外注の整理・選別
• 再構築の効率化
• サーバーの仮想化推進
• 転送コストの圧縮

6. 私がやったこと
• MTのアップローダーのアップロードパスを固定
• 外注とのやりとりにプロジェクトマネージメントツールを導
入
• PSGIの導入
• 内制できる体制の確保
• 外注の整理・選別
• 再構築の効率化
• サーバーの仮想化推進
• 転送コストの圧縮
※MTに関係ありそうなもの

7. MTのアップローダーのアップロードパスを固定
/{MT}/tmpl/cms/include/asset_upload.tmpl
↓コピー
/{MT}/alt-tmpl/cms/include/asset_upload.tmpl
冒頭に追記するだけ
<mt:setvarblock name="extra_path">
images/<$mt:date format="%Y/%m"$>
</mt:setvarblock>
もっと厳密にやるなら…
• <input name=“extra_path” readonly=“readonly”…>
• <select name=“site_path” …></select>の中身も一部<mtignore></mtignore>で
囲ってしまう。

8. MTのアップローダーのアップロードパスを固定
correct!
※これをやらないとhtdocs/*.(jpg|png|gif|...)みたいなのが散乱します

9. PSGIの導入
とにかく記事数が多く、プラグインも多用しているのでMTの管理画面が重かった
↓
過去にFastCGIを導入したりDBチューニングをしたりといろいろ試行錯誤をしていたが、それも限界に
↓
MT5.2から「mt.psgi」が正式リリースされたとのこと。
↓
「なんだそりゃ？」調べる
↓
なぜ、MT5.2ではnginx/PSGIに対応したのか。（SixApart柳下氏）http://blog.sixapart.jp/2012-10/mt52-
supports-nginx-and-psgi.html
↓
なるほど、MTをnginxその他のナウいWebサーバーに対応させるための実装のようです。
そして巷の評判も上々。
FastCGIと比べて約1.4倍のスピード！ 開発中のmt.psgiを使ってみたhttp://www.mtcms.jp/movabletype-
blog/tech/201204132197.html
MovableType管理画面をPSGIで動かしたら快適すぎて生きるのがつらい
http://dqn.sakusakutto.jp/2012/04/movabletype-psgi-starman.html
なるべくカンタンにMovableType 5.2の新しい高速な管理画面を試す方法（Apache＋mod_proxy＋PSGI）
http://riatw.me/blog/mt52_apache_psgi.html

10. PSGIの導入
[結果]
女性系媒体3メディアが同居するMTの表示がスト
レスを感じないレベルまで高速になった（体感）
環境構築の敷居が若干高いかもしれないが、記事
数が多いなどでMT管理画面の動作速度に不満があ
る場合にはオススメの対応といえる。

11. 再構築の効率化
公開キュー経由での再構築をもっと活用したい
↓
制作外注しているパートナーの方から提案が。
「run-periodic-tasksを並列実行しましょう」
↓
やりましょう。

12. 再構築の効率化
% cd /path/to/mt/
% ./tools/run-periodic-tasks --daemon --randomly --
load=10 --sleep=5 &
% ./tools/run-periodic-tasks --daemon --randomly --
load=10 --sleep=5 &
...
希望のプロセス数までrun-periodic-tasksをデーモン
起動しておくだけ。

13. 再構築の効率化
結果：
全体再構築に掛かる時間がデーモンプロセス数分
早くなりました。
最適なプロセス数はまだ模索段階。CPUのコア数
（スレッド数）を越えないほうが良いと思われる。

14. サーバーの仮想化推進
クラウド環境への移行
• SNSでのバズ、Yahoo!トピックス等での取
り上げ（いわゆるYahoo!砲）、Smartnews
等の台頭で突発的なトラフィックに対処
できる環境を構築する必要がある
• 物理サーバーでは要件を満たすのにコス
トが掛かり過ぎる

15. origin-1
origin-2
cms
LB
CDN
rdb
www
lsync / rsync
log
サーバーの仮想化推進

16. サーバーの仮想化推進
CDNを常時使用することでオリジンのイン
スタンスサイズは最小に留めた。
→「過負荷でサーバーダウン」ということ
がかなりあった女性系媒体で「負荷で落ち
る」ということはほぼ無くなった。
現在男性系媒体にも適用拡大中。

17. 転送コストの圧縮
月間PVが1000万を超えるようになると転送
量（料）もバカにならない。
html等のテキストファイルについてはクラ
ウド環境のスケーラビリティを享受しつつ、
画像等のアセットデータ系については転送
料の掛からないアセットサーバーに分けた
い

18. origin-1
origin-2
cms
（MT）LB
CDN
DBwww
lsync / rsync
log
assets-1
assets-2
こんな感じ。
バランシングはLBでなく
JSで行う。
jpg/gif/png/etc...
html/js/css/etc...

19. 転送コストの圧縮
結果：
EC2とCloudFrontの料金がほぼ同額だったが、
CloudFrontの料金（転送料・ヒット数課金含
む）を半分以下まで大幅に圧縮。

20. 転送コストの圧縮
ただし：
assetsサーバーを分けることはいいことづくめのように思
えたが、サーバー台数が増える分管理コストはかさむので、
転送量がどの程度まで膨らむかを事前に試算すべき。
実際mediageneの媒体では同じような構成のサーバーでも
assetsサーバーを分ける/分けないの方針は媒体毎に違う。

21. まとめ
• 開発者の心得として、MTユーザーのWebリテラシーを信
用しすぎず、Fool Proofな実装を心がけるべき
• PSGIの採用はWebサーバーの選択肢を広げる
• 再構築の効率化は待機工数の削減にも繋がる
• 低コストで急激なトラフィックにも対応するならCDNの
常時導入が吉
• アセットサーバーの切り分けはトラフィック規模によっ
ては効果が薄いので要事前試算

22. ありがとうございました