movable type for aws を用いた環境構築のポイント

Movable Type for AWS を

用いた環境構築のポイント

MTDDC Meetup Tokyo 2014

エムロジック田島 2014/11/29

自己紹介

たじままこと

田島誠

facebook.com/mtajima

エムロジック株式会社代表取締役・裏方

鹿児島県出身４〇才２児の父

Windows派少数民族 Movable Type担当

エムロジック株式会社

１９９８年創業

千代田区神保町でもうすぐ１６年

エンジニア２名（１名は私）事務１名の３人

草食系企業

当初はWindows、PalmOS方面であれこれ開発

Movable Type日本語化の頃よりこちらの世界

最近はiOSとMovable Typeの２本立て

この人の名前を出したほうが話が早いことがあります・・・

関根元和（CHEEBOW）

最近のMTのお仕事

設計・開発を担当しています

By NetConcierge Co.,LTD. http://netconcierge.jp/mtcommerce/

※ 今日はECの話はありません

本日の傾向

分析しました！

本日の状況

「見渡す限りその世界の大物ばかり」

「バッティングが怖い！（草食系）」

「すでにＨＰが足りない」

ウェブ界

MT界クラウド界

小物界の生存戦略

このへん

ウェブ界


本日のお品書き

１．Movable Type for AWS の特徴

２．Movable Type for AWS の運用での注意点

３．Movable Type for AWS を活用する





検討

入門

活用

Movable Type for AWS とは

Movable Type for AWS は、Movable Type 6 がインストールされた、OS込みの Amazon Machine Image（AMI）です。 OS、アプリケーション、ウェブサーバー、PSGIサーバー、PHP、データベースがすべて Movable Type にチューニングされた形で提供されるため、数クリックで簡単に Amazon EC2 サーバー上に環境を構築できます。

出典：http://www.sixapart.jp/movabletype/aws/


要は「すぐに使えるMT」です。

１．クリックしてから数分でMTが使える




http://www.sixapart.jp/movabletype/aws/

ここから！





ここを決めて





クリック





これで完成


要は「お安く使えるMT」です。

２．初期コストをかけずにMTが使える




ライセンス料金も含めて

「使った分だけ」月払い




t2.mediumを「24時間30日」使ったときのデータ転送コストなどを省いた固定費用

ライセンス料金は2年間使い続けるとパッケージライセンスと同じくらいになる感じ




さらに




一番下のt2.microではなんと「ライセンス料金無料」！！

１日使っても６０円かからない計算




つまり・・・

妄想

t2.micro t2.micro t2.micro t2.micro






Elastic Load Balancing

これでも60円ｘ24で・・・








Ψ(｀∀´)Ψｹｹｹ

正直面倒です・・・









要は「ずっと使えるMT」です。

３．さまざまな変化にインフラもMTも対応




現実問題１

MTのアップデート




現実問題１


ソフトウェアですから緊急性の高いセキュリティアップデートも

現実問題発生しますよね。




現実問題１


基本これでOK

# yum update movabletype




現実問題２

ある日のYaｈ○o砲・WBS砲




現実問題２


できればちゃんとコンテンツを表示したいですよね。




現実問題２


CloudFront(CDN)ありマス




現実問題３

システムの肥大化・速度低下




現実問題３

システムの肥大化・速度低下

まぁ、使い続けますからそうなりますよね。




現実問題３

システムの肥大化・速度低下インスタンス変更すればいいですしおすし


まとめ

Movable Type for AWS は

「すぐに」「お安く」「ずっと」

使えるMT です。

Movable Type for AWS の運用での注意点

Movable Type for AWS いいですよね！

弊社の場合... 1. 公開サーバとして

S3に転送してStaticWebsiteHosting

2. 新規開発時のテストサーバとしてぱっと立ち上げてテストして終わったらTerminate

3. 案件用の開発サーバとして納品後もしばらくはStop状態でインスタンスを持っておく


MTAWS最初の壁

インスタンス起動したあと

何をすればいいのか？

おさらい

今日はココ

ウェブ界



Movable Type for AWS に特化した話


基本構成(現時点)

OS： AmazonLinux AMI 2014.09版

Webサーバ： nginx + starman(PSGI)

PHP： php-fpm

DBサーバ： MySQL

メールサーバ： Postfix

いたって一般的ですが


使ってみてわかった

Movable Type for AWS

の注意点


注意点１：

一部のパスが独自仕様


注意点１：


Movable Type インストールディレクトリ： /app/movabletype/

なので・・・

プラグインディレクトリ： /app/movabletype/plugins/

アドオンディレクトリ： /app/movabletype/addons/

になります。


注意点１：


ドキュメントルート： /data/file/static/

起動時点で初期コンテンツがコピーされています。

もちろんこれは初期設定としてのパスなので変更可能です。


注意点１：


nginx設定ファイル： /data/conf/nginx.conf

MySQLデータディレクトリ： /data/database/

Starmanログ出力先： /data/logs/movabletype/

Starman設定ファイル： /data/conf/movabletype.conf

AmazonLinux管理外のPerlモジュール: /app/local/


注意点１：


/app/ ・・・アプリケーション関連のファイル

/data/ ・・・各種データファイル・設定ファイル

を眺めてみましょう。


注意点２：

管理画面へのアクセスは「/mt/admin」


注意点２：

管理画面へのアクセスは「/mt/admin」

これはmt-config.cgiの環境変数「AdminScript」を

設定しているから。

/app/movabletype/mt-config.cgi から変更可。


注意点３：

タイムゾーンが「UTC」


注意点３：


日本から使う場合、cronなどで地味に不便です。


注意点３：


OSの設定変更：

Movable Typeの設定変更(mt-config.cgi)：

変更したらMovable Typeをリロード：

$ sudo cp /usr/share/zoneinfo/Japan /etc/localtime

DefaultLanguage ja

DefaultTimezone 9

$ sudo kill –HUP `cat /app/run/movabletype.pid`


注意点４：

設定がmicroインスタンス向け


注意点４：


このままではもったいない。


注意点４：


StarmanのWorker数変更：

/data/conf/movabletype.conf

MySQLのキャッシュ、バッファプールの設定変更：

/etc/my.cnf

php-fpmのサーバ数変更：

/etc/php-fpm.conf


注意点４：


mt-search.cgiやmt-data-api.cgiなどのアプリケーションを

公開する場合はStarmanのWorker数重視

ダイナミックパブリッシング、DynamicMTMLを使う場合には

php-fpmのサーバ数重視

・・・のように、運用したいサーバのスタイルにあわせて

調整しましょう。


動作が重く、設定でも改善しない場合

インスタンス増強の前に！



インスタンス増強の前に！ • まずデータベースをRDSに分離することを検討しましょう。




• ただしRDSはインスタンスの停止ができないので気をつけましょう。





• MTのDBはあまり大きくなりにくいのでdb.t2.microインスタンスでも結構改善したりします。






• DBを独立させることで、MTの複数インスタンス構成も容易になります。






• DBを独立させることで、MTの複数インスタンス構成も容易になります。

• くれぐれもRDSでクエリキャッシュの有効化をお忘れなく。

Movable Type for AWS を活用する

活用の前に

Movable Type と AWS の相性は？


Movable Type と AWS の相性

１．静的ファイル出力 • フロントへのアクセスが負荷にならない • S3に転送してStaticWebsiteHosting • アクセス多いならCloudFront CPUのコストがあまりかからないつまりは低コストで運用できます！


Movable Type と AWS の相性

２．再構築とT2インスタンス • T2インスタンスでは高負荷時に自動的に性能をアップする機能（バースト）が実装されています。

• MTが重たいのはテンプレートビルドのとき、24時間管理画面を使うわけではないですよね？

再構築時は高負荷になるので自動的にバーストしてくれます。つまりt2.microインスタンスでも再構築がかなり速い。


結論

Movable Type と AWS の相性は最高


(補足)T2インスタンスの実力

10月18日開催の「JAWS-UG 沖縄 CMS 祭り！」で発表されたシックス・アパート高山さんのスライドにて

• インスタンス別再構築勝負 • 記事数：約3,500件 • 調査したインスタンス：

t2.micro、t2.medium、c3.large、c3.xlarge


再構築勝負結果バーストすごい！

インスタンスタイプ再構築時間

t2.micro 2分55秒

t2.medium 2分47秒

c3.large 2分51秒

c3.xlarge 2分48秒


勝負で得た教訓

• １プロセスでの再構築に限っては t2.micro で十分 • ただし DataAPI など複数のリクエストを同時に処理したい場合には、t2.micro は不向き。

• コストを考えると DataAPI 使用サイトは t2.medium が有利。

DataAPI 勝負の結果など詳しい内容は高山さんのスライドをご参照ください！（ありがとうございました）


本題に戻ります


活用例１：

S3でのStaticWebsiteHosting


活用例１：


聞きますよね？「S3から配信」とか。

そうです、あれです。

アプリケーションはEC2

静的ファイルはS3


活用例１：


S3 Management Consoleで設定

Route53でEndpointを登録すれば

独自ドメインのホスト名で使える


活用例１：


S3への転送方法：

1. Amazonプラグイン

http://tec.toi-planning.net/mt/amazon/

特定の拡張子であれば転送といった使い方もできる

素敵プラグイン


活用例１：



2. AWS CLI s3 sync もしくは s3cmd sync

• lsyncdでディレクトリを監視してS3と常に同期便利だけどちょっと設定が面倒なことも。


活用例１：



2. AWS CLI s3 sync もしくは s3cmd sync

• シェルから都度実行任意のタイミングで同期処理。再構築時に余計なことをしないのでサーバにはやさしい。それに・・・


活用例１：


EC2側をステージングサーバ、S3/CloudFrontを公開サーバにする

リアルタイムに転送するのではなく、適切なタイミングで同期処理を行うことで可能に

EC2で確認 S3で公開


活用例１：


弊社ではこんなプラグイン使ってます

近日公開します


StaticWebsiteHostingとRoute53(DNS)の

ステキな組み合わせ（正常時）

mt-data-api.cgi等

静的ファイル＋エラードキュメント

Route53で名前解決と

HealthCheck

リダイレクトする空のバケット



ステキな組み合わせ（障害発生時）

インスタンス停止！

mt-data-api.cgiの代わりにエラーファイル

リダイレクト

フェイルオーバー名前解決の変更



ステキな組み合わせ

切り替わりは決して早くはない

でも、

アラートメール受けてマニュアルで対応するより

相当早いです


活用(？)例２：

MTAssetThumbnailURL対策


活用(？)例２：


みなさんお気づきでしょうか？


活用(？)例２：


MTAssetThumbnailURLを多用するほど再構築のコストが増えることに。


活用(？)例２：


何故か？


活用(？)例２：


何故か？

商用CMS故の厳格な処理でした

画像をMT以外からでも上書きできる環境では、上書きされた結果突然サムネイルを作成できなくなるケースが想定されるため、毎回画像を開いて確認している為。


活用(？)例２：


画像を開く＝処理用メモリを確保 •画像が大きいとメモリを切り詰めている環境には致命傷になりうる（t2.microとか）

•そんな環境ではできるだけリサイズ済みの画像を使うようにし(て、タグの使用を回避し)ましょう


活用(？)例２：


弊社ではこんなプラグイン使うことも

1. サムネイル生成可能であるかの確認処理方法を切り替え可能にする機能

2. 省メモリで高速にリサイズする機能

3. ただし、サーバに直接画像をアップロードしない、もしくは誰が上書きアップロードするかが厳格に管理できる環境限定

4. 黒魔術(?)系のプラグインなのでご了承ください

近日公開します


活用(？)例２：


計測(参考値)：

インスタンスタイプ： t2.micro

画像：３６４８ｘ２７３６程度のもの２５枚

計測方法： /mt/admin?__mode=list&_type=assetにアクセスして３回実施中の最速のWait時間を記録


活用(？)例２：


結果： asset_c内のファイルが揃っている状態

asset_c内のファイルを消した状態（リサイズ発生）

ノーマル 3.48sec

プラグイン 165.7msec

ノーマル 24.32sec

プラグイン 3.68sec

（おまけ）直前の戦い

2日前・・・

ｱﾉﾋｼﾞｬﾈｴｶ(ﾟДﾟ;)

Dear Amazon EC2 Customer, One or more of your Amazon EC2 instances in the ap-northeast-1 region is scheduled for retirement. The following instance(s) will be shut down after 12:00 AM UTC on 2014-11-29.

今回やるべきことは

Stop→Startのみ、ただし冗長化なし

「EC2のメンテナンスのためサーバを停止させてください！」

「クラウドなのになんで止まるんですか？」

ｴｯ(ﾟДﾟ;)

事務連絡

約９時間

メンテナンス作業

約１０分

クラウドだってどこかで動いているサーバ

そんなことより

簡単なメンテナンス作業で済むことに感謝

※も・・もちろん大部分フィクションです（震え声）

まとめ

•Movable Type for AWS は超オススメ •これからドキュメントが整備されていくことを期待しています！ •プラグインは近日公開いたします（ドキュメント整備中デス…orz）

•田島誠先生の次回作にご期待ください。

御清聴ありがとうございました

お問い合わせはエムロジック株式会社田島まで

movable type for aws を用いた環境構築のポイント

Engineering