“MT on AWS”でWebサイト構築！!作り手が気をつけておきたいポイント

清水貴規 Takanori Shimizu

清水貴規　Takanori Shimizu takanori@monster-dive.com

n  株式会社MONSTER DIVE　取締役／チーフディレクター

n  1997年より映画情報メディアの運営からWeb業界に参加。 以降、エンタメ系を中心に、 企業やメディアのWebサイト／Webシステムの制作・開発を担当

n  デザインからプログラム、コンテンツ企画、マーケティングまで 広く浅く長く経験した結果、 インフラ構築・運用まで担当することも…。

自己紹介

MONSTER DIVEについて

株式会社MONSTER DIVE（もんすたーだいぶ） n  2009年創業。本社：東京都港区西麻布

n  2011年、SixApart ProNet および PowerCMS Partner 登録 n  Webと映像のプロダクション・カンパニー

MONSTER DIVEのご紹介

Webプロダクション事業 クリエイティブからインフラまで、120％のホスピタリティで。

平井レーシングチーム

運用体制が重要な スポーツ系も!

IPTVフォーラム

きっちりおカタイ 企業／団体系も!

遊びゴコロが大事な エンタメ系も!

映画「銀魂」

http://mon.st 詳しくはコチラまで！

MONSTER DIVEのご紹介

映像・スタジオ事業 自社スタジオを運営。映像コンテンツ製作＆ストリーミング配信。

n  USTREAM、YouTube Live、ニコニコ生放送の撮影・配信。 n  映像編集、企画、CM・VPの製作。

n  ライブやイベントのプロデュース＆撮影・配信。

www.MONSTER-STUDIO.jp 詳しくはコチラまで！

MONSTER DIVEのご紹介 メディア＆サービス事業

自社ドメインのWebサービス、モバイルAppsの展開。

n  RIZE/DragonAshのベーシスト「KenKen」が教える教則アプリや、 元JUDY AND MARYのギタリスト「TAKUYA」が教えるアプリを販売中

n  昨年の事業部発足から現在までに、 自社ドメインで5タイトルのモバイルアプリをリリース。 そのほか複数のWebサービスや映像コンテンツを展開

Session //!MTを効率的に構築するための EC2インスタンス選び

はじめに：一般的なWebサイト用の環境構成

Route 53

EC2-Master EC2 (Slaves)

RDS!- DB-Live!- DB-Dev

Database SV

ELB

n  MTは、公式AMIではなく独自にパッケージ版をインストールする n  スタティックパブリッシング n  ページ中の一部でPHP等のプログラムが存在する（S3のWebホスティングではNG） n  本番環境、ステージング環境、開発環境の3つが必要

前提

EC2-Dev!- www.domain.com (*)!- stage.domain.com (*)!- cms.domain.com (*)

www.domain.com

※ローカルのhostsで設定

cms.domain.com!stage.domain.com

rsync+lsync

AMI

必要とされるスペックは、フェーズ毎に異なる

1. MT構築期間中

2. 構築完了（動作検証／データ投入）

3. 運用開始

1. MT構築期間中

n  テンプレートのオーサリング期間中には高い頻度で再構築が必要

n  定時処理ではなく随時出力確認したい

n  とはいえ、構築後の運用と同じ状態での動作確認も必要

n  再構築待ちの時間＝ムダ！

CPUの高いインスタンスを選ぶ c3.largeがオススメ！（感覚）

夜間・休日は インスタンスごとstopする

・開発中からEIPを割り当てる ・DNSをRoute53で管理する 　→いずれかの方法でhosts書き換えやTTLを 　　気にせず作業続行出来る。

POINT

2. 構築完了（動作検証／データ投入）

n  本番の記事ボリュームでMT操作をテストする（負荷はテンプレートの組み方次第）

n  運用を見据えてインスタンスタイプを決定する（更新頻度は毎日？ 週1回？）

n  スペック選定は運用ストレスと予算のバランスを考慮する。

n  MT構築完了＝リリースOKではない！

必要に応じてテンプレートの組み方・再構築方法を変更する 定時処理、RebuildBlogプラグイン、モジュールのPHP/SSI化

MT操作だけでなく、ユーザの閲覧レスポンスも考慮する MTを操作する頻度（再構築頻度）が低ければ、 CPUよりメモリを重視したインスタンスのほうが適切な場合も

POINT

3. 運用開始

n  CloudWatchでEC2のCPU状態や、ELBのSpillOver等を監視する

n  アクセスやレスポンス次第でインスタンスを変更する（サービスダウン無しで）

n  急激なアクセス増加にはEC2にSlaveを追加して負荷分散を準備する

n  追加開発が発生したら、本番環境と切り離されたDev専用インスタンスで行う

記事数が増加してきたら、一般的なMTの負荷軽減も当然必要 ・システムログの削除 ・テンプレート構造の見直し ・不要プラグインの削除…

POINT

改めて構成を見てみよう

Route 53

EC2-Master EC2 (Slaves)

RDS!- DB-Live!- DB-Dev

Database SV

ELB

n  スタティックパブリッシング n  MTは、公式AMIではなく独自にパッケージ版をインストールする n  ページ中の一部でPHP等のプログラムが存在する（S3のWebホスティングではNG） n  本番環境、ステージング環境、開発環境の3つが必要

前提

EC2-Dev!- www.domain.com (*)!- stage.domain.com (*)!- cms.domain.com (*)

www.domain.com

※ローカルのhostsで設定

cms.domain.com!stage.domain.com

rsync+lsync

AMI

まとめと補足

メモリよりCPUのチョイスが大事！

n  EC2のプロセスを見ていると、再構築時のCPU負荷は非常に高い

n  メモリは、アクセス数やコンテンツに応じて随時考えれば良い

RDSは、EC2と同程度のスペックのインスタンスを選んでおくと安心

n  db.m1.smallで十分の場合もあるが、 MT管理画面のレスポンスを見ながら調整する

教科書は無い！ プロジェクトごとにベストプランを見出そう

n  スペックを変動させることが出来るのが、AWSの強み

n  見積段階では幅を持たせておき、構築フェーズで最終決定するのが吉

自由度の高い環境だからこそ、自分なりのノウハウ蓄積が重要です

Tips

v  t1.microでは正常な動作は期待できません。 （なお、PowerCMSはインストール完了まで辿り着かないケースがある）

v 出力されるページ内容が完全に静的なら、S3を使わない手はありません。 （同時接続数が万単位でも快適！）

v インスタンスは、定期的にバックアップを兼ねてAMI化することを オススメします。

v セキュリティ上、SSH/FTPの接続はSecurityGroupsでしっかり制限。 運用は、可能な限りMT管理画面上で完結する設計に。

v AWSは、誰でも始められる ≠ 誰でも使いこなせる、です。 設計や構築に不安があればAWSに詳しいインテグレーターさんに相談しましょう。

最後に

メンバー募集中!!!!!

Webサイトだけでなく Webサービス、モバイルアプリのバックエンドまで、 なんでもMTで作ってしまうMONSTER DIVEでは、

Webクリエイター＆ディレクターを 大募集中です。

詳しくは http://mon.st/ にて！

お気軽に お声がけ下さい

Thank you.

株式会社 MONSTER DIVE 清水貴規

http://www.monster-dive.com/!takanori@monster-dive.com