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界
クラウド界

小物界の生存戦略
このへん
ウェブ界
MT界
クラウド界

本日のお品書き
１．Movable Type for AWS の特徴
２．Movable Type for AWS の運用での注意点
３．Movable Type for AWS を活用する

本日のお品書き
１．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
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
Elastic Load
Balancing

これでも60円ｘ24で・・・
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
Elastic Load
Balancing
Ψ(｀∀´)Ψｹｹｹ

正直面倒です・・・
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
t2.micro
Elastic Load
Balancing

要は「ずっと使える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最初の壁
インスタンス起動したあと
何をすればいいのか？

おさらい
今日はココ
ウェブ界
MT界
クラウド界

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 を用いた環境構築のポイント

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Movable Type for AWS を用いた環境構築のポイント

Similar a Movable Type for AWS を用いた環境構築のポイント (20)

Movable Type for AWS を用いた環境構築のポイント