Movable Type ＋ AWSでECサイトを構築してわかったこと

Movable Type case study Vol.3

エムロジック 田島2014/06/15

自己紹介

田島 誠facebook.com/mtajima

エムロジック株式会社

代表取締役・裏方

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

Windows派少数民族

Movable Type担当

エムロジック株式会社

１９９８年創業

千代田区神保町で１５年＋α

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

草食系企業

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

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

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

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

関根 元和（CHEEBOW）

本日のお品書き

１．MTでECを作った話

２．MT+AWSでECの話

３．気を付けたいこと

１．MTでECを作った話

２．MT+AWSでECの話

３．気を付けたいこと

本日のお品書き

実際に構築する人向け

検討する人向け

本日のお品書き

１．MTでECを作った話

２．MT+AWSでECの話

３．気を付けたいこと

この製品の設計・開発を担当しました

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

MTコマース

•株式会社ネットコンシェルジェの製品

•MTで本格的なECサイトを構築

•実際に多数のECサイトを構築

ざっとご紹介

ダッシュボード

商品管理と商品一覧

注文管理と決済画面

在庫管理とカート画面

会員管理とマイページ

基本機能は備えています！

他にこんな機能も

•ポイント・クーポン機能

•メルマガ機能

•簡易レコメンデーション

•高機能なフォーム作成（※）

•商品購入者の閲覧制限ページ（※）

※次期バージョンにてリリース予定

ポイント・クーポン

メルマガ作成・登録

フォーム定義・受付データ詳細

MTでEC作ってみて

いい感じです！

ECサイトを

売るだけのサイトでは終わらせない

強力なCMSと組むことで

マーケティングプラットフォーム

として機能するところを目指したい

発展例その１

ブログ＋商品

•コーディネートブログ着ている商品の価格と在庫も表示

•掲載雑誌一覧雑誌に紹介された商品をそのまま購入

•ハンドメイドアクセサリーブログ使用パーツの購入も

発展例その２

マイページ＋購入履歴＋閲覧制限

•購入商品の問い合わせフォーム購入履歴から問い合わせフォーム

•購入者向けダウンロード購入履歴から閲覧制限ページにリンク

•購入商品のサポート情報を掲載商品にサポートブログのIDを持たせて

MTでEC作る強み

Movable Type で作ったサイトが

クライアントの利益を直接産む

MTでEC作る強み

企画

開発

制作

運用

弱い！なかなか循環しない・・・

MTでEC作る強み

企画

開発

制作運用

販売

利益！

企画

開発

制作運用

販売

MTでEC作る強み

モチベーションで循環する！

MTでEC作る強み

Movable Type を飯の種に！

本日のお品書き

１．MTでECを作った話

２．MT+AWSでECの話

３．気を付けたいこと

いきさつ

MTコマース開発当初

Movable Typeのバージョンは5.0

CGI全盛期！

いきさつ

動的会員サイトの構成

会員管理者

CGI管理画面 HTML

認証のみ認証とコンテンツ

全部MTアプリケーション(MT::App)

タスク実行mt.cgi

ユーザー

アクセス先

サーバ上の動作

MTコマースの構成

いきさつ

会員管理者

CGI管理画面 HTML

認証のみ認証とコンテンツ

MT::App

タスクmt.cgi

API

ユーザー

アクセス先

サーバ上の動作

MTコマースの構成

いきさつ

ユーザー管理者

CGI管理画面 HTML

認証のみ認証とコンテンツ

MT::App

タスクmt.cgi

API

カート内容・ユーザー情報などの参照のみ

でもCGI

少し軽い

エンジニアの考え

PHPは使いたくない開発スピード重視・言語間の動作互換性つらい

いざとなればFastCGI

当時PSGI/Plackの開発が進んでおり、MTも対応できそうな予感が。

「絶対に止められないサービスが、そこにはある」

運用チームの毎日が

スピードとの戦い

「捌けねぇ鯖はただの鯖だ」

運用チームでSAN値の低下

「1インスタンスでどうやれと」

「24コアでもCPUとメモリが限界」

「なぜ今再構築する！？」

「タイムセールやめてーーー」

「データの転送に1日以上」

「セール時のログ超でかい」

「サーバのアップデートしなきゃ」

さらなるSAN値の低下

「Amazonは0.1秒遅くなると売上が1%ダウンする」

「Googleは0.5秒遅くなるとアクセス数が20%ダウンする」

「一般的に表示スピードが1秒遅くなると、PVは11%、コンバージョンは

7%、顧客満足度は16%ダウンする」出典：Aberdeen Group Report

「今動かなきゃ、今やらなきゃ、

みんな死んじゃうんだ！

もうそんなの嫌なんだよ！」

出典：碇シンジ 『新世紀エヴァンゲリオン』

京都 KYOTO by Yoozigen, on Flickr https://www.flickr.com/photos/yoozigen/1491005376

そうだ

アマゾン、

移行。

☽

●

※大部分フィクションです。

構築用標準インフラを

国内VPSサービスから

AWSへ変更

変更の理由

複数インスタンス運用が

やりやすい

魅惑のサービス

EC2(+EBS)以外の決め手

１．ELB

２．S3

３．RDS

４．CloudWatch

５．Route53

６．CLI

魅惑１

ELB

•ロードバランサー

•SSLターミネーション

•Availability Zoneで安心感++

•LVS+keepalivedで構築する気が失せるほどあっさり設定可能

魅惑２

S3

•ストレージ

•大量ログの蓄積に

•スナップショット

•静的ファイルの配信にも使える

•安い

魅惑３

RDS

•データベース

•手間からの解放•フェイルオーバー•バックアップ•アップデート

•MHA+HAProxyでの構築を忘れてしまいそう

Amazon++

詳しい方がいらっしゃるので

いろいろ解説されているに

違いない！

（私も聞きたい）

本日のお品書き

１．MTでECを作った話

２．MT+AWSでECの話

３．気を付けたいこと

閑話休題

•複数インスタンス運用するときライセンスはどうなるんでしょう？→ インスタンス分必要です

•最大を想定して買う？→ 使わなかったらムダすぎる

閑話休題

ありました！Movable Type Advanced

http://www.sixapart.jp/movabletype/solutions/mta.html

でもケースによっては高くつくかも。。。

閑話休題

でました！Movable Type 6 for AWS

インスタンスを使った分だけ課金

ライセンス料金：0.07ドル／1時間

マイクロインスタンスだと無料！

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

SixApart++

気兼ねなくスケールできます

そんなわけでMTコマースも検討中・・・

動的サイトで気を付けたいこと

１．スワップボリューム

２．負荷分散

３．SMTP（メール送信）

４．RDSチューニング

５．Workerの数

６．キャッシュ

７．監視 DataAPIにもあてはまります！

スワップボリューム

•AmazonLinuxのAMIでインスタンスを作成した場合スワップが設定されない

•スワップがないとどうなる？•メモリが足りなくなると突然プロセスが殺される

•OOM Killer (Out of Memory Killer)

→スワップは作りましょう！

スワップボリューム

•スワップも足りなくなればどうなる？•結局OOM Killerがやってくる。

•大事なプロセスは殺されないよう守ってあげましょう• oom_adj

•セール時の構成案

マスターサーバからlsyncdでビルド配信

負荷分散

再構築 メール送信

負荷分散その１

•再構築は１インスタンスにまとめましょう•公開キューでリビルドするようにしてタスクで全部再構築しましょう

•MTコマースは商品ページの再構築をジョブキューで実行します

•１インスタンスにまとまれば他インスタンスへのビルドファイルの配信が楽になります！

※SPOFにもなるのでバックアップ大事！

負荷分散その２

•「再構築中にサーバが重い」• 1インスタンスだけ重くなってしまうとバランスが悪くなりうかつにオートスケールできなくなります

•マスターサーバはELBから分離してしまいましょう

•（予算に）余裕があればタスク専用のサーバがあると快適！

•非セール時の最小構成案

図を省略して、、

SMTP

security group

•非セール時の最小構成案(省略版)

ELB、EC2、RDSの接続についてのみ書いています

1インスタンスで管理画面、フロント、再構築、メール送信を行う構成（メール送信・再構築は負荷にならない程度と想定）

SMTP

再構築 メール送信

•セール時の構成案Update1

マスターサーバからlsyncdでビルド配信

SMTP

再構築 メール送信

SMTP

「SPAMになるメールが」

「Amazonさんからお知らせが」

↓

SMTP使うときは

要事前申請です

↓

これ、、、インスタンス増やすたびにやらなきゃダメ？＞ダメ

SMTP

解決策

•メール送信は１インスタンスにまとめましょう•マスターサーバにゲートウェイ設置してマスターサーバから送信するように設定

• MTコマースはフロントからのすべてのメールがジョブキューで送信されます（次期リリースにて実装）

•メールの負荷が重いサーバではメール送信のサーバと管理画面のサーバを分離しましょう

•タスクからの送信はMTに欲しいなー

•セール時の構成案Update2

タスクサーバからlsyncdでビルド配信

RDSチューニング

再構築 メール送信

RDSチューニング

•「インスタンス増えても捌けるユーザーが増えなくなった」•調べてみた

• JMeterで100ユーザーが連続で検索・購入するシナリオを実行

•妙に遅かった。何故？

0

50

インスタンス2 インスタンス3

トランザクション数 (RDS SMALL)

インスタンス2 インスタンス3

RDSチューニング

•「CloudWatchでRDSの負荷がハンパないんだけど」•なんだかんだでMTは結構DBアクセス多いと思います

•現在RDSのデフォルトはクエリキャッシュが無効です＞有効にしましょう

• RDSも立派なインスタンス、MySQLのチューニングを怠ってはいけません

•MTコマースの場合、これで急回復！•どうしても改善できないときはプラン変更を・・・

Worker数

•ここまでやるとフロント用のEC2インスタンスはフロントに集中できる状態になっているはず•メール・再構築・タスク実行がない

•あとはインスタンス内の調整を

Worker数

•スワップを作ったとしてもスワップはあくまでも保険•使わないよう実行プロセスの調整をしましょう

•Starmanで実行しているのであればWorker数で調節します

--workers 2 ←ココ

•使わないプラグイン・アドオン・CGIを消すというのももちろん実施

Worker数

•大雑把なメモリの図

Starmanの使用メモリをWorker数で調節します

実行しながらtopでにらめっこするとか

心のゆとり

ココ！

OS

Worker数

•MTコマースでは静的ページ用の軽量なShopAPIを分離実行できる•アクセスの傾向を調べてShopAPIを大量実行するという方法も

•MTではData APIだけ実行するサーバーとかも考えられます

•ちょっとしたサイト構成でメモリの使用量が変わることがあるので常時メモリのチェックはしておくと吉

キャッシュ

•遅いレスポンスと速いレスポンスの違いを考える•処理の複雑さ•DBアクセスの多さ

↑簡単には変えられない！

•テンプレートのビルド↑

ここが大きい！

•制作でできることを考えます

キャッシュ

•MTにも重いタグが存在する(MTコマースにも)

•対策•テンプレートモジュールのキャッシュを活用特定のイベントでキャッシュをクリアできるので便利

•memcachedの導入RDSの負荷を下げることにも貢献設定するとMT内部で使用されます。

キャッシュ

•MTコマースでは…•GoodsPartialCache

商品詳細ページの再構築時にフロントの各所で使用する商品パーツを一括でビルド＆キャッシュしておくファイルにすると配信を考えなければならないためDBに格納している

このあたりがキャッシュ

開発でフォローした例として

キャッシュ

•MTコマースでは…•レスポンスキャッシュ

商品検索は動的部分（ユーザー情報）を分離できるため、商品データに変更がなければ検索条件ごとに固定のHTMLを出力できるためこれをmemcachedにキャッシュしている

レスポンスキャッシュはDataAPIなどでも活用できそうです（MTにも欲しいなー）

•セール時の構成案Update3

全インスタンスそれぞれでmemcached設定

キャッシュ

再構築 メール送信 memcached

•セール時の構成案Update4

常時稼働しているインスタンスに集中させる

キャッシュ

再構築 メール送信 memcached

キャッシュ

•memcached•全インスタンスで同じ設定を使いましょう

•インスタンスごとにキャッシュの内容が違うと問題が発生します

•キャッシュの使用頻度があがるようであればElastiCacheを検討

監視

•CloudWatch•常に設定しましょう•いろんなアラート出せるので便利

•ただECの場合、負荷以外にも不正使用のアラートなどCloudWatchではフォローできないアラートも必要

•監視は複数系統用意しましょう

（おまけ）深夜の戦い

「アラートメール便利なんですけど夜中メールみないんで起きないんですよね」

(ﾟДﾟ;)

作りました！

✕

「電話は目が覚めちゃうんで

やめてください！」(ﾟДﾟ;)

結局SMSを送信することで決着

KDDI ウェブコミュニケーションズさま便利なサービスをありがとうございます

※も・・もちろん大部分フィクションです。

まとめ

•MTとECってすごく相性がいいです

• AWSは動的サイトの運用には超便利です（Data APIの登場で需要増）

•いまからでもMovable Type for AWSを使ってみるといいよ！

•複数インスタンスにする可能性があるならば最初から備えておかないと大変

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

お問い合わせは株式会社ネットコンシェルジェまで