• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
MTを使った巨大トラフィックの捌き方
 

MTを使った巨大トラフィックの捌き方

on

  • 3,389 views

MTTokyo01プレゼン資料。

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

Statistics

Views

Total Views
3,389
Views on SlideShare
585
Embed Views
2,804

Actions

Likes
2
Downloads
3
Comments
0

7 Embeds 2,804

http://liginc.co.jp 1640
http://hrnabi.com 1137
http://feedly.com 12
http://recruit-media.web-sample.org 6
http://s.deeeki.com 5
https://twitter.com 3
http://webcache.googleusercontent.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    MTを使った巨大トラフィックの捌き方 MTを使った巨大トラフィックの捌き方 Presentation Transcript

    • MTを使った 巨大トラフィックの捌き方 mediageneでの施策について 2014.04.20 mediagene
    • 自己紹介 • 緒方昂児(おがたこうじ) • メディアジーンのテクニカルディレク ター • 元Web Director / Flash Developer • 外資系大手飲料メーカーの公式サイトや ミニゲームなどを制作 • 国内大手AV機器メーカーの直販ECサイト のディレクションなどを担当
    • なんでmediageneに? • オウンドメディアの時代がきたので (2011年中頃) • 自社メディアがやってみたかった • Lifehacker[日本版]の読者だった • ガジェットが好きだった
    • 入社時の課題 • 制作フローやエヴィデンス保全の仕組みに甘さ を感じるのでなんとかできないか ※編集部はWeb制作のプロ集団ではないので必然。メーカーのMD 部門のWeb担当者など、他業種他職種でも同じ悩みはあった • ファイルアップロード等のルールが未整備なの をなんとかできないか • MTの管理画面のレスポンスを改善できるか
    • 私がやったこと • MTのアップローダーのアップロードパスを固定 • 外注とのやりとりにプロジェクトマネージメントツールを導 入 • PSGIの導入 • 内制できる体制の確保 • 外注の整理・選別 • 再構築の効率化 • サーバーの仮想化推進 • 転送コストの圧縮
    • 私がやったこと • MTのアップローダーのアップロードパスを固定 • 外注とのやりとりにプロジェクトマネージメントツールを導 入 • PSGIの導入 • 内制できる体制の確保 • 外注の整理・選別 • 再構築の効率化 • サーバーの仮想化推進 • 転送コストの圧縮 ※MTに関係ありそうなもの
    • 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>で 囲ってしまう。
    • MTのアップローダーのアップロードパスを固定 correct! ※これをやらないとhtdocs/*.(jpg|png|gif|...)みたいなのが散乱します
    • 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
    • PSGIの導入 [結果] 女性系媒体3メディアが同居するMTの表示がスト レスを感じないレベルまで高速になった(体感) 環境構築の敷居が若干高いかもしれないが、記事 数が多いなどでMT管理画面の動作速度に不満があ る場合にはオススメの対応といえる。
    • 再構築の効率化 公開キュー経由での再構築をもっと活用したい ↓ 制作外注しているパートナーの方から提案が。 「run-periodic-tasksを並列実行しましょう」 ↓ やりましょう。
    • 再構築の効率化 % 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をデーモン 起動しておくだけ。
    • 再構築の効率化 結果: 全体再構築に掛かる時間がデーモンプロセス数分 早くなりました。 最適なプロセス数はまだ模索段階。CPUのコア数 (スレッド数)を越えないほうが良いと思われる。
    • サーバーの仮想化推進 クラウド環境への移行 • SNSでのバズ、Yahoo!トピックス等での取 り上げ(いわゆるYahoo!砲)、Smartnews 等の台頭で突発的なトラフィックに対処 できる環境を構築する必要がある • 物理サーバーでは要件を満たすのにコス トが掛かり過ぎる
    • origin-1 origin-2 cms LB CDN rdb www lsync / rsync log サーバーの仮想化推進
    • サーバーの仮想化推進 CDNを常時使用することでオリジンのイン スタンスサイズは最小に留めた。 →「過負荷でサーバーダウン」ということ がかなりあった女性系媒体で「負荷で落ち る」ということはほぼ無くなった。 現在男性系媒体にも適用拡大中。
    • 転送コストの圧縮 月間PVが1000万を超えるようになると転送 量(料)もバカにならない。 html等のテキストファイルについてはクラ ウド環境のスケーラビリティを享受しつつ、 画像等のアセットデータ系については転送 料の掛からないアセットサーバーに分けた い
    • 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...
    • 転送コストの圧縮 結果: EC2とCloudFrontの料金がほぼ同額だったが、 CloudFrontの料金(転送料・ヒット数課金含 む)を半分以下まで大幅に圧縮。
    • 転送コストの圧縮 ただし: assetsサーバーを分けることはいいことづくめのように思 えたが、サーバー台数が増える分管理コストはかさむので、 転送量がどの程度まで膨らむかを事前に試算すべき。 実際mediageneの媒体では同じような構成のサーバーでも assetsサーバーを分ける/分けないの方針は媒体毎に違う。
    • まとめ • 開発者の心得として、MTユーザーのWebリテラシーを信 用しすぎず、Fool Proofな実装を心がけるべき • PSGIの採用はWebサーバーの選択肢を広げる • 再構築の効率化は待機工数の削減にも繋がる • 低コストで急激なトラフィックにも対応するならCDNの 常時導入が吉 • アセットサーバーの切り分けはトラフィック規模によっ ては効果が薄いので要事前試算
    • ありがとうございました