Movable Type + AWSでECサイトを構築してわかったこと
Movable Type case study Vol.3
エムロジック 田島2014/06/15
自己紹介
田島 誠facebook.com/mtajima
エムロジック株式会社
代表取締役・裏方
鹿児島県出身 4〇才 2児の父
Windows派少数民族
Movable Type担当
エムロジック株式会社
1998年創業
千代田区神保町で15年+α
エンジニア2名(1名は私)事務1名の3人
草食系企業
当初はWindows、PalmOS方面であれこれ開発
Movable Type日本語化の頃よりこちらの世界
最近はiOSとMovable Typeの2本立て
最近この人の名前を出したほうが話が早いことがあります・・・
関根 元和(CHEEBOW)
本日のお品書き
1.MTでECを作った話
2.MT+AWSでECの話
3.気を付けたいこと
1.MTでECを作った話
2.MT+AWSでECの話
3.気を付けたいこと
本日のお品書き
実際に構築する人向け
検討する人向け
本日のお品書き
1.MTでECを作った話
2.MT+AWSでECの話
3.気を付けたいこと
この製品の設計・開発を担当しました
By NetConcierge Co.,LTD.http://netconcierge.jp/mtcommerce/
MTコマース
•株式会社ネットコンシェルジェの製品
•MTで本格的なECサイトを構築
•実際に多数のECサイトを構築
会員管理とマイページ
基本機能は備えています!
他にこんな機能も
•ポイント・クーポン機能
•メルマガ機能
•簡易レコメンデーション
•高機能なフォーム作成(※)
•商品購入者の閲覧制限ページ(※)
※次期バージョンにてリリース予定
MTでEC作ってみて
いい感じです!
ECサイトを
売るだけのサイトでは終わらせない
強力なCMSと組むことで
マーケティングプラットフォーム
として機能するところを目指したい
発展例その1
ブログ+商品
•コーディネートブログ着ている商品の価格と在庫も表示
•掲載雑誌一覧雑誌に紹介された商品をそのまま購入
•ハンドメイドアクセサリーブログ使用パーツの購入も
発展例その2
マイページ+購入履歴+閲覧制限
•購入商品の問い合わせフォーム購入履歴から問い合わせフォーム
•購入者向けダウンロード購入履歴から閲覧制限ページにリンク
•購入商品のサポート情報を掲載商品にサポートブログのIDを持たせて
MTでEC作る強み
Movable Type で作ったサイトが
クライアントの利益を直接産む
MTでEC作る強み
企画
開発
制作
運用
弱い!なかなか循環しない・・・
MTでEC作る強み
企画
開発
制作運用
販売
利益!
企画
開発
制作運用
販売
MTでEC作る強み
モチベーションで循環する!
MTでEC作る強み
Movable Type を飯の種に!
本日のお品書き
1.MTでECを作った話
2.MT+AWSでECの話
3.気を付けたいこと
いきさつ
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)以外の決め手
1.ELB
2.S3
3.RDS
4.CloudWatch
5.Route53
6.CLI
魅惑1
ELB
•ロードバランサー
•SSLターミネーション
•Availability Zoneで安心感++
•LVS+keepalivedで構築する気が失せるほどあっさり設定可能
魅惑2
S3
•ストレージ
•大量ログの蓄積に
•スナップショット
•静的ファイルの配信にも使える
•安い
魅惑3
RDS
•データベース
•手間からの解放•フェイルオーバー•バックアップ•アップデート
•MHA+HAProxyでの構築を忘れてしまいそう
Amazon++
詳しい方がいらっしゃるので
いろいろ解説されているに
違いない!
(私も聞きたい)
本日のお品書き
1.MTでECを作った話
2.MT+AWSでECの話
3.気を付けたいこと
閑話休題
•複数インスタンス運用するときライセンスはどうなるんでしょう?→ インスタンス分必要です
•最大を想定して買う?→ 使わなかったらムダすぎる
閑話休題
ありました!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コマースも検討中・・・
動的サイトで気を付けたいこと
1.スワップボリューム
2.負荷分散
3.SMTP(メール送信)
4.RDSチューニング
5.Workerの数
6.キャッシュ
7.監視 DataAPIにもあてはまります!
スワップボリューム
•AmazonLinuxのAMIでインスタンスを作成した場合スワップが設定されない
•スワップがないとどうなる?•メモリが足りなくなると突然プロセスが殺される
•OOM Killer (Out of Memory Killer)
→スワップは作りましょう!
スワップボリューム
•スワップも足りなくなればどうなる?•結局OOM Killerがやってくる。
•大事なプロセスは殺されないよう守ってあげましょう• oom_adj
•セール時の構成案
マスターサーバからlsyncdでビルド配信
負荷分散
再構築 メール送信
負荷分散その1
•再構築は1インスタンスにまとめましょう•公開キューでリビルドするようにしてタスクで全部再構築しましょう
•MTコマースは商品ページの再構築をジョブキューで実行します
•1インスタンスにまとまれば他インスタンスへのビルドファイルの配信が楽になります!
※SPOFにもなるのでバックアップ大事!
負荷分散その2
•「再構築中にサーバが重い」• 1インスタンスだけ重くなってしまうとバランスが悪くなりうかつにオートスケールできなくなります
•マスターサーバはELBから分離してしまいましょう
•(予算に)余裕があればタスク専用のサーバがあると快適!
•非セール時の最小構成案
図を省略して、、
SMTP
security group
•非セール時の最小構成案(省略版)
ELB、EC2、RDSの接続についてのみ書いています
1インスタンスで管理画面、フロント、再構築、メール送信を行う構成(メール送信・再構築は負荷にならない程度と想定)
SMTP
再構築 メール送信
•セール時の構成案Update1
マスターサーバからlsyncdでビルド配信
SMTP
再構築 メール送信
SMTP
「SPAMになるメールが」
「Amazonさんからお知らせが」
↓
SMTP使うときは
要事前申請です
↓
これ、、、インスタンス増やすたびにやらなきゃダメ?>ダメ
SMTP
解決策
•メール送信は1インスタンスにまとめましょう•マスターサーバにゲートウェイ設置してマスターサーバから送信するように設定
• 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を使ってみるといいよ!
•複数インスタンスにする可能性があるならば最初から備えておかないと大変
御清聴ありがとうございました
お問い合わせは株式会社ネットコンシェルジェまで