1. オンプレミスから
AWSへの
劇的ビフォーアフター
シナジーマーケティング株式会社 坂井 学
2014/7/5 夏のJAWS-UG 三都物語 2014

2. テクニカルトラックですが
技術の話はあまりしません

3. なお劇的は当社比です

4. 自己紹介
‣ 坂井 学 / @manabusakai
‣ シナジーマーケティング株式会社
iNSIGHTBOX事業推進室 所属
‣ 開発からインフラ構築、運用までひと通り
‣ 好きなサービスはAmazon EMR

6. グーグルも認めた
はったりエンジニアです

7. シナジーマーケティングについて
‣ CRMを中心としたマーケティング支援を行って
いる会社です
‣ CRM市場における売上高調査シェアNo.1
‣
‣ 大阪に本社を構え、社員数は約210名

8. 本題に入る前に
今日お話しするのは当社が提供するクラウドサー
ビスの1つ iNSIGHTBOX をAWSに移行した話
です。

9. 今日の話
‣ iNSIGHTBOXについて
‣ オンプレミスを捨ててAWSへ
‣ 守りから攻めのチームへ

10. 今日の話
‣ iNSIGHTBOXについて
‣ オンプレミスを捨ててAWSへ
‣ 守りから攻めのチームへ

12. iNSIGHTBOXとは
購買履歴やクリック履歴などのビッグデータをも
とに、刺さりそうな顧客やキーワードを教えてく
れるマーケティング支援のクラウドサービス。
性別や年代といった単純な属性情報ではなく、
人の価値観に注目しているのが大きな特徴。

13. WBSでも取り上げられました
2013/7/22 放送
「WBS 価値観マーケティング」
で検索！

14. 開発スタイル
‣ 言語 : Scala
‣ フレームワーク : Play Framework
‣ データベース : PostgreSQL + HBase
‣ その他 : スクラム開発

15. 今日の話
‣ iNSIGHTBOXについて
‣ オンプレミスを捨ててAWSへ
‣ 守りから攻めのチームへ

16. オンプレミスを捨ててAWSへ
‣ オンプレミスに依存するものは1つ残らず排除
‣ 実は移行したのは6月末

17. Full AWS, No on-premises
‣ VPC
‣ EC2
‣ ELB
‣ RDS (PostgreSQL)
‣ EMR (HBase)
‣ SES
‣ Route 53
‣ S3 + Glacier
‣ CloudWatch

18. 移行した理由
‣ データ量の増加にインフラ構築が追いつけない

19. 移行した理由
‣ データ量の増加にインフラ構築が追いつけない
‣ 安心してビッグデータを入れられない

20. 移行した理由
‣ データ量の増加にインフラ構築が追いつけない
‣ 安心してビッグデータを入れられない
‣ 営業が安心して売れない、売りたがらない

21. 移行した理由
‣ データ量の増加にインフラ構築が追いつけない
‣ 安心してビッグデータを入れられない
‣ 営業が安心して売れない、売りたがらない
プロダクトが失敗してしまう！

22. プロダクトの成長を
インフラ要因で止めない

23. ボトルネックはHBase
‣ HBaseを支えるHadoopクラスタ
‣ ディストリビューションはCDH 3
‣ スレーブノードは物理サーバ
‣ スレーブノード8台構成

24. ボトルネックはHBase
‣ HBaseを支えるHadoopクラスタ
‣ ディストリビューションはCDH 3
‣ スレーブノードは物理サーバ
‣ スレーブノード8台構成
データ量に対して
ノード数が足りない！

25. オンプレミスでの見積もり
‣ スレーブノードを8台から10台に増強
‣ 見積もり工数 2人月
‣ サーバの発注、DCへの設置、OSやミドル
ウェアのセットアップなど

26. 増強のたびに2ヶ月も
待ってられない！

27. 移行するなら
絶好のタイミング！

28. AWS移行スケジュール
3月 5月 7月 9月
シーズン2
7月以降
データ移行検証
5∼6月
AWS検証
2∼5月
‣ 性能検証やデータ移行検証を入念に
‣ AWSだからできる新しいことにも挑戦（後述）

29. 劇的ビフォーアフター
‣ 先ほどのHBaseを例に挙げるとEMRに移行した
ことで…
‣ Management Consoleで数クリック
‣ ものの1分あればスケールアウトできる

30. オンプレミス AWS

31. 21120分かかる作業が
わずか1分に！

32. 「ほんまかいな？」

33. Demo

34. 今日の話
‣ iNSIGHTBOXについて
‣ オンプレミスを捨ててAWSへ
‣ 守りから攻めのチームへ

35. これまでの運用（1）
‣ オンプレミスでは開発と運用が別グループ
‣ ちょっとしたことでも作業依頼が必要

36. これまでの運用（1）
‣ オンプレミスでは開発と運用が別グループ
‣ ちょっとしたことでも作業依頼が必要
スクラム開発にスピード感が合わない

37. これまでの運用（2）
‣ インフラ構成を理解しているのは一部の人だけ
‣ アラートメールが飛んでも運用が対応できない

38. これまでの運用（2）
‣ インフラ構成を理解しているのは一部の人だけ
‣ アラートメールが飛んでも運用が対応できない
開発者が対応したほうが結果的に良い

39. AWSに移行したのに
運用はそのまま？

40. 全員がDevOps
‣ iNSIGHTBOXの開発メンバーは4人
‣ インフラエンジニア経験者は自分だけ
‣ 開発から運用まですべての面倒を見る
‣ アラートメールも開発者自身が受ける

41. 工夫した3つのこと
1. わざと障害を起こす
2. 使い捨てにできるサーバ
3. シンプルなインフラ構成

42. 1. わざと障害を起こす
‣ NetflixのChaos Monkeyを参考
‣ 誰かが意図的に障害を起こして、他のメンバー
がリカバリさせる
‣ 得た知見を障害対応フローにまとめる

43. 障害を非日常にしない

44. 2. 使い捨てにできるサーバ
‣ いわゆるImmutable Infrastructure
‣ コマンド一発で必要なサーバが立ち上がる
‣ アプリのデプロイはCloudInitを活用
‣ ログはS3へ同期

45. 障害時は潔く
新しいサーバを立ち上げる

46. 3. シンプルなインフラ構成
‣ 複雑さは暗黙知を生み出すので極力シンプルに
‣ AWSに任せられることは任せてしまう
‣ DBのバックアップ、メール配信、ログの保管
‣ 特定の人しかわからない構成にはしない

47. いつでも作り直せる
安心感

48. 考え方が変わってきた
‣ たとえばメモリを大量に使うバッチ処理
‣ オンプレミスだと、いかにメモリ消費を抑え
るかに頭を使ってた
‣ でも、それって本質的じゃない
‣ これがAWSなら…

49. バーンと立ち上げて
ガーッとやって
スパッと落とせばいい！

50. 今後の課題
‣ 立ち上げっぱなしのサーバを減らしたい
‣ 1クリックで本番環境のクローンを作りたい
‣ CloudFormationはEMRに未対応＞＜

51. ビフォーアフターのまとめ
‣ オンプレミスと比べて圧倒的に短期間で、しか
も簡単にスケールアウトできる
‣ インフラの制約がなくなったことで、開発者が
主体になって攻めていける
‣ 結果的にチームも変わってきた

52. Q&A