MT東京-03 Movable TypeケーススタディVol.3 にて使用したスライドです

1. Movable Type ＋ AWSで
ECサイトを構築してわかったこと
Movable Type case study Vol.3
エムロジック 田島
2014/06/15

2. 自己紹介
田島 誠
facebook.com/mtajima
エムロジック株式会社
代表取締役・裏方
鹿児島県出身 ４〇才 ２児の父
Windows派少数民族
Movable Type担当

3. エムロジック株式会社
１９９８年創業
千代田区神保町で１５年＋α
エンジニア２名（１名は私）事務１名の３人
草食系企業
当初はWindows、PalmOS方面であれこれ開発
Movable Type日本語化の頃よりこちらの世界
最近はiOSとMovable Typeの２本立て

4. 最近この人の名前を出したほうが
話が早いことがあります・・・
関根 元和（CHEEBOW）

5. 本日のお品書き
１．MTでECを作った話
２．MT+AWSでECの話
３．気を付けたいこと

6. １．MTでECを作った話
２．MT+AWSでECの話
３．気を付けたいこと
本日のお品書き
実際に構築する人向け
検討する人向け

7. 本日のお品書き
１．MTでECを作った話
２．MT+AWSでECの話
３．気を付けたいこと

8. この製品の設計・開発を担当しました
By NetConcierge Co.,LTD.
http://netconcierge.jp/mtcommerce/

9. MTコマース
• 株式会社ネットコンシェルジェの製品
• MTで本格的なECサイトを構築
• 実際に多数のECサイトを構築

10. ざっとご紹介

11. ダッシュボード

12. 商品管理と商品一覧

13. 注文管理と決済画面

14. 在庫管理とカート画面

15. 会員管理とマイページ
基本機能は
備えています！

16. 他にこんな機能も
• ポイント・クーポン機能
• メルマガ機能
• 簡易レコメンデーション
• 高機能なフォーム作成（※）
• 商品購入者の閲覧制限ページ（※）
※次期バージョンにてリリース予定

17. ポイント・クーポン

18. メルマガ作成・登録

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

20. MTでEC作ってみて
いい感じです！
ECサイトを
売るだけのサイトでは終わらせない
強力なCMSと組むことで
マーケティングプラットフォーム
として機能するところを目指したい

21. 発展例その１
ブログ＋商品
•コーディネートブログ
着ている商品の価格と在庫も表示
•掲載雑誌一覧
雑誌に紹介された商品をそのまま購入
•ハンドメイドアクセサリーブログ
使用パーツの購入も

22. 発展例その２
マイページ＋購入履歴＋閲覧制限
•購入商品の問い合わせフォーム
購入履歴から問い合わせフォーム
•購入者向けダウンロード
購入履歴から閲覧制限ページにリンク
•購入商品のサポート情報を掲載
商品にサポートブログのIDを持たせて

23. MTでEC作る強み
Movable Type で作ったサイトが
クライアントの利益を直接産む

24. MTでEC作る強み
企画
開発
制作
運用
弱い！
なかなか循環
しない・・・

25. MTでEC作る強み
企画
開発
制作運用
販売
利益！

26. 企画
開発
制作運用
販売
MTでEC作る強み
モチベーション
で循環する！

27. MTでEC作る強み
Movable Type を飯の種に！

28. 本日のお品書き
１．MTでECを作った話
２．MT+AWSでECの話
３．気を付けたいこと

29. いきさつ
MTコマース開発当初
Movable Typeのバージョンは5.0
CGI全盛期！

30. いきさつ
動的会員サイトの構成
会員管理者
CGI管理画面 HTML
認証のみ
認証とコ
ンテンツ
全部MTアプリケーション
(MT::App)
タスク実行mt.cgi
ユーザー
アクセス先
サーバ上
の動作

31. MTコマースの構成
いきさつ
会員管理者
CGI管理画面 HTML
認証のみ
認証とコ
ンテンツ
MT::App
タスクmt.cgi
API
ユーザー
アクセス先
サーバ上
の動作

32. MTコマースの構成
いきさつ
ユーザー管理者
CGI管理画面 HTML
認証のみ
認証とコ
ンテンツ
MT::App
タスクmt.cgi
API
カート内容・
ユーザー情報な
どの参照のみ
でもCGI
少し軽い

33. エンジニアの考え
PHPは使いたくない
開発スピード重視・言語間の動作互換性つらい
いざとなればFastCGI
当時PSGI/Plackの開発が進んでお
り、MTも対応できそうな予感が。

34. 「絶対に止められない
サービスが、そこにはある」
運用チームの毎日が
スピードとの戦い
「捌けねぇ鯖はただの鯖だ」

35. 運用チームでSAN値の低下
「1インスタンスでどうやれと」
「24コアでもCPUとメモリが限界」
「なぜ今再構築する！？」
「タイムセールやめてーーー」
「データの転送に1日以上」
「セール時のログ超でかい」
「サーバのアップデートしなきゃ」

36. さらなるSAN値の低下
「Amazonは0.1秒遅くなると売上が
1%ダウンする」
「Googleは0.5秒遅くなるとアクセス
数が20%ダウンする」
「一般的に表示スピードが1秒遅くなる
と、PVは11%、コンバージョンは
7%、顧客満足度は16%ダウンする」
出典：Aberdeen Group Report

37. 「今動かなきゃ、今やらなきゃ、
みんな死んじゃうんだ！
もうそんなの嫌なんだよ！」
出典：碇シンジ 『新世紀エヴァンゲリオン』

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

39. そ
う
だ
ア
マ
ゾ
ン
、
移
行
。
☽
●
※大部分フィクションです。

40. 構築用標準インフラを
国内VPSサービスから
AWSへ変更

41. 変更の理由
複数インスタンス運用が
やりやすい

42. 魅惑のサービス
EC2(+EBS)以外の決め手
１．ELB
２．S3
３．RDS
４．CloudWatch
５．Route53
６．CLI

43. 魅惑１
ELB
•ロードバランサー
•SSLターミネーション
•Availability Zoneで安心感++
•LVS+keepalivedで構築する気
が失せるほどあっさり設定可能

44. 魅惑２
S3
•ストレージ
•大量ログの蓄積に
•スナップショット
•静的ファイルの配信にも使える
•安い

45. 魅惑３
RDS
•データベース
•手間からの解放
• フェイルオーバー
• バックアップ
• アップデート
•MHA+HAProxyでの構築を忘れ
てしまいそう

46. Amazon++
詳しい方がいらっしゃるので
いろいろ解説されているに
違いない！
（私も聞きたい）

47. 本日のお品書き
１．MTでECを作った話
２．MT+AWSでECの話
３．気を付けたいこと

48. 閑話休題
•複数インスタンス運用するときライ
センスはどうなるんでしょう？
→ インスタンス分必要です
•最大を想定して買う？
→ 使わなかったらムダすぎる

49. 閑話休題
ありました！
Movable Type Advanced
http://www.sixapart.jp/movabletype/solutions/mta.html
でもケースによっては高くつくかも。。。

50. 閑話休題
でました！
Movable Type 6 for AWS
インスタンスを使った分だけ課金
ライセンス料金：0.07ドル／1時間
マイクロインスタンスだと無料！
http://www.sixapart.jp/movabletype/aws/

51. SixApart++
気兼ねなくスケールできます
そんなわけでMTコマースも検討中・・・

52. 動的サイトで気を付けたいこと
１．スワップボリューム
２．負荷分散
３．SMTP（メール送信）
４．RDSチューニング
５．Workerの数
６．キャッシュ
７．監視 DataAPIにも
あてはまります！

53. スワップボリューム
•AmazonLinuxのAMIでインスタン
スを作成した場合スワップが設定さ
れない
•スワップがないとどうなる？
• メモリが足りなくなると突然プロセス
が殺される
• OOM Killer (Out of Memory Killer)
→スワップは作りましょう！

54. スワップボリューム
•スワップも足りなくなればどうな
る？
• 結局OOM Killerがやってくる。
•大事なプロセスは殺されないよう
守ってあげましょう
• oom_adj

55. • セール時の構成案
マスターサーバからlsyncdでビルド配信
負荷分散
再構築 メール送信

56. 負荷分散その１
•再構築は１インスタンスにまとめま
しょう
• 公開キューでリビルドするようにして
タスクで全部再構築しましょう
• MTコマースは商品ページの再構築を
ジョブキューで実行します
•１インスタンスにまとまれば他イン
スタンスへのビルドファイルの配信
が楽になります！
※SPOFにもなるのでバックアップ大事！

57. 負荷分散その２
•「再構築中にサーバが重い」
• 1インスタンスだけ重くなってしまう
とバランスが悪くなりうかつにオート
スケールできなくなります
• マスターサーバはELBから分離してし
まいましょう
• （予算に）余裕があればタスク専用の
サーバがあると快適！

58. • 非セール時の最小構成案
図を省略して、、
SMTP
security group

59. • 非セール時の最小構成案(省略版)
ELB、EC2、RDSの接続
についてのみ書いています
1インスタンスで管理画面、フ
ロント、再構築、メール送信
を行う構成（メール送信・再
構築は負荷にならない程度と
想定）
SMTP
再構築 メール送信

60. • セール時の構成案Update1
マスターサーバからlsyncdでビルド配信
SMTP
再構築 メール送信

61. SMTP
「SPAMになるメールが」
「Amazonさんからお知らせが」
↓
SMTP使うときは
要事前申請です
↓
これ、、、インスタンス増やすたび
にやらなきゃダメ？＞ダメ

62. SMTP
解決策
• メール送信は１インスタンスにまとめ
ましょう
• マスターサーバにゲートウェイ設置して
マスターサーバから送信するように設定
• MTコマースはフロントからのすべての
メールがジョブキューで送信されます
（次期リリースにて実装）
• メールの負荷が重いサーバではメール送
信のサーバと管理画面のサーバを分離し
ましょう
• タスクからの送信はMTに欲しいなー

63. • セール時の構成案Update2
タスクサーバからlsyncdでビルド配信
RDSチューニング
再構築 メール送信

64. RDSチューニング
•「インスタンス増えても捌けるユー
ザーが増えなくなった」
•調べてみた
• JMeterで100ユーザーが連続で検索・
購入するシナリオを実行
• 妙に遅かった。何故？
0
50
インスタンス2 インスタンス3
トランザクション数 (RDS SMALL)
インスタンス2 インスタンス3

65. RDSチューニング
•「CloudWatchでRDSの負荷がハン
パないんだけど」
• なんだかんだでMTは結構DBアクセス
多いと思います
• 現在RDSのデフォルトはクエリキャッ
シュが無効です＞有効にしましょう
• RDSも立派なインスタンス、MySQL
のチューニングを怠ってはいけません
• MTコマースの場合、これで急回復！
• どうしても改善できないときはプラン
変更を・・・

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

67. Worker数
•スワップを作ったとしてもスワップ
はあくまでも保険
• 使わないよう実行プロセスの調整をし
ましょう
•Starmanで実行しているのであれば
Worker数で調節します
--workers 2 ←ココ
•使わないプラグイン・アドオン・
CGIを消すというのももちろん実施

68. Worker数
•大雑把なメモリの図
Starmanの使用メモ
リをWorker数で調節
します
実行しながらtopでに
らめっこするとか
心のゆとり
ココ！
OS

69. Worker数
•MTコマースでは静的ページ用の軽
量なShopAPIを分離実行できる
• アクセスの傾向を調べてShopAPIを大
量実行するという方法も
•MTではData APIだけ実行するサー
バーとかも考えられます
•ちょっとしたサイト構成でメモリの
使用量が変わることがあるので常時
メモリのチェックはしておくと吉

70. キャッシュ
•遅いレスポンスと速いレスポンスの
違いを考える
• 処理の複雑さ
• DBアクセスの多さ
↑
簡単には変えられない！
• テンプレートのビルド
↑
ここが大きい！
•制作でできることを考えます

71. キャッシュ
•MTにも重いタグが存在する(MTコ
マースにも)
•対策
• テンプレートモジュールのキャッシュ
を活用
特定のイベントでキャッシュをクリア
できるので便利
• memcachedの導入
RDSの負荷を下げることにも貢献
設定するとMT内部で使用されます。

72. キャッシュ
•MTコマースでは…
• GoodsPartialCache
商品詳細ページの再構築時にフロントの各
所で使用する商品パーツを一括でビルド＆
キャッシュしておく
ファイルにすると配信を考えなければなら
ないためDBに格納している
このあたりがキャッシュ
開発でフォロー
した例として

73. キャッシュ
•MTコマースでは…
• レスポンスキャッシュ
商品検索は動的部分（ユーザー情報）を分
離できるため、商品データに変更がなけれ
ば検索条件ごとに固定のHTMLを出力でき
るためこれをmemcachedにキャッシュし
ている
レスポンスキャッシュはDataAPIなどでも
活用できそうです（MTにも欲しいなー）

74. • セール時の構成案Update3
全インスタンスそれぞれでmemcached設定
キャッシュ
再構築 メール送信 memcached

75. • セール時の構成案Update4
常時稼働しているインスタンスに集中させる
キャッシュ
再構築 メール送信 memcached

76. キャッシュ
•memcached
• 全インスタンスで同じ設定を使いま
しょう
• インスタンスごとにキャッシュの内容
が違うと問題が発生します
• キャッシュの使用頻度があがるようで
あればElastiCacheを検討

77. 監視
•CloudWatch
• 常に設定しましょう
• いろんなアラート出せるので便利
• ただECの場合、負荷以外にも不正使
用のアラートなどCloudWatchでは
フォローできないアラートも必要
• 監視は複数系統用意しましょう

78. （おまけ）深夜の戦い
「アラートメール便利なんですけど夜中
メールみないんで起きないんですよね」
(ﾟДﾟ;)

79. 作りました！
✕
「電話は目が覚めちゃうんで
やめてください！」
(ﾟДﾟ;)

80. 結局SMSを送信することで決着
KDDI ウェブコミュニケーションズさま
便利なサービスをありがとうございます
※も・・もちろん大部分フィクションです。

81. まとめ
• MTとECってすごく相性がいいです
• AWSは動的サイトの運用には超便利
です（Data APIの登場で需要増）
• いまからでもMovable Type for AWS
を使ってみるといいよ！
• 複数インスタンスにする可能性がある
ならば最初から備えておかないと大変

82. 御清聴ありがとうございました
お問い合わせは株式会社ネットコンシェルジェまで