Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

オンプレミスから AWS への劇的ビフォーアフター

8,182 views

Published on

2014/7/5 に行われた「夏の JAWS-UG 三都物語 2014」のスライドです。
http://santo2014.jaws-ug.jp/

  • Be the first to comment

オンプレミスから AWS への劇的ビフォーアフター

  1. 1. オンプレミスから
 AWSへの
 劇的ビフォーアフター シナジーマーケティング株式会社 坂井 学
 2014/7/5 夏のJAWS-UG 三都物語 2014
  2. 2. テクニカルトラックですが 技術の話はあまりしません
  3. 3. なお劇的は当社比です
  4. 4. 自己紹介 ‣ 坂井 学 / @manabusakai ‣ シナジーマーケティング株式会社
 iNSIGHTBOX事業推進室 所属 ‣ 開発からインフラ構築、運用までひと通り ‣ 好きなサービスはAmazon EMR
  5. 5. グーグルも認めた はったりエンジニアです
  6. 6. シナジーマーケティングについて ‣ CRMを中心としたマーケティング支援を行って いる会社です ‣ CRM市場における売上高調査シェアNo.1 ‣ ‣ 大阪に本社を構え、社員数は約210名
  7. 7. 本題に入る前に 今日お話しするのは当社が提供するクラウドサー ビスの1つ iNSIGHTBOX をAWSに移行した話 です。
  8. 8. 今日の話 ‣ iNSIGHTBOXについて ‣ オンプレミスを捨ててAWSへ ‣ 守りから攻めのチームへ
  9. 9. 今日の話 ‣ iNSIGHTBOXについて ‣ オンプレミスを捨ててAWSへ ‣ 守りから攻めのチームへ
  10. 10. iNSIGHTBOXとは 購買履歴やクリック履歴などのビッグデータをも とに、刺さりそうな顧客やキーワードを教えてく れるマーケティング支援のクラウドサービス。 性別や年代といった単純な属性情報ではなく、
 人の価値観に注目しているのが大きな特徴。
  11. 11. WBSでも取り上げられました 2013/7/22 放送
 「WBS 価値観マーケティング」
 で検索!
  12. 12. 開発スタイル ‣ 言語 : Scala ‣ フレームワーク : Play Framework ‣ データベース : PostgreSQL + HBase ‣ その他 : スクラム開発
  13. 13. 今日の話 ‣ iNSIGHTBOXについて ‣ オンプレミスを捨ててAWSへ ‣ 守りから攻めのチームへ
  14. 14. オンプレミスを捨ててAWSへ ‣ オンプレミスに依存するものは1つ残らず排除 ‣ 実は移行したのは6月末
  15. 15. Full AWS, No on-premises ‣ VPC ‣ EC2 ‣ ELB ‣ RDS (PostgreSQL) ‣ EMR (HBase) ‣ SES ‣ Route 53 ‣ S3 + Glacier ‣ CloudWatch
  16. 16. 移行した理由 ‣ データ量の増加にインフラ構築が追いつけない
  17. 17. 移行した理由 ‣ データ量の増加にインフラ構築が追いつけない ‣ 安心してビッグデータを入れられない
  18. 18. 移行した理由 ‣ データ量の増加にインフラ構築が追いつけない ‣ 安心してビッグデータを入れられない ‣ 営業が安心して売れない、売りたがらない
  19. 19. 移行した理由 ‣ データ量の増加にインフラ構築が追いつけない ‣ 安心してビッグデータを入れられない ‣ 営業が安心して売れない、売りたがらない プロダクトが失敗してしまう!
  20. 20. プロダクトの成長を インフラ要因で止めない
  21. 21. ボトルネックはHBase ‣ HBaseを支えるHadoopクラスタ ‣ ディストリビューションはCDH 3 ‣ スレーブノードは物理サーバ ‣ スレーブノード8台構成
  22. 22. ボトルネックはHBase ‣ HBaseを支えるHadoopクラスタ ‣ ディストリビューションはCDH 3 ‣ スレーブノードは物理サーバ ‣ スレーブノード8台構成 データ量に対して
 ノード数が足りない!
  23. 23. オンプレミスでの見積もり ‣ スレーブノードを8台から10台に増強 ‣ 見積もり工数 2人月 ‣ サーバの発注、DCへの設置、OSやミドル ウェアのセットアップなど
  24. 24. 増強のたびに2ヶ月も 待ってられない!
  25. 25. 移行するなら
 絶好のタイミング!
  26. 26. AWS移行スケジュール 3月 5月 7月 9月 シーズン2 7月以降 データ移行検証 5∼6月 AWS検証 2∼5月 ‣ 性能検証やデータ移行検証を入念に ‣ AWSだからできる新しいことにも挑戦(後述)
  27. 27. 劇的ビフォーアフター ‣ 先ほどのHBaseを例に挙げるとEMRに移行した ことで… ‣ Management Consoleで数クリック ‣ ものの1分あればスケールアウトできる
  28. 28. オンプレミス AWS
  29. 29. 21120分かかる作業が
 わずか1分に!
  30. 30. 「ほんまかいな?」
  31. 31. Demo
  32. 32. 今日の話 ‣ iNSIGHTBOXについて ‣ オンプレミスを捨ててAWSへ ‣ 守りから攻めのチームへ
  33. 33. これまでの運用(1) ‣ オンプレミスでは開発と運用が別グループ ‣ ちょっとしたことでも作業依頼が必要
  34. 34. これまでの運用(1) ‣ オンプレミスでは開発と運用が別グループ ‣ ちょっとしたことでも作業依頼が必要 スクラム開発にスピード感が合わない
  35. 35. これまでの運用(2) ‣ インフラ構成を理解しているのは一部の人だけ ‣ アラートメールが飛んでも運用が対応できない
  36. 36. これまでの運用(2) ‣ インフラ構成を理解しているのは一部の人だけ ‣ アラートメールが飛んでも運用が対応できない 開発者が対応したほうが結果的に良い
  37. 37. AWSに移行したのに 運用はそのまま?
  38. 38. 全員がDevOps ‣ iNSIGHTBOXの開発メンバーは4人 ‣ インフラエンジニア経験者は自分だけ ‣ 開発から運用まですべての面倒を見る ‣ アラートメールも開発者自身が受ける
  39. 39. 工夫した3つのこと 1. わざと障害を起こす 2. 使い捨てにできるサーバ 3. シンプルなインフラ構成
  40. 40. 1. わざと障害を起こす ‣ NetflixのChaos Monkeyを参考 ‣ 誰かが意図的に障害を起こして、他のメンバー がリカバリさせる ‣ 得た知見を障害対応フローにまとめる
  41. 41. 障害を非日常にしない
  42. 42. 2. 使い捨てにできるサーバ ‣ いわゆるImmutable Infrastructure ‣ コマンド一発で必要なサーバが立ち上がる ‣ アプリのデプロイはCloudInitを活用 ‣ ログはS3へ同期
  43. 43. 障害時は潔く
 新しいサーバを立ち上げる
  44. 44. 3. シンプルなインフラ構成 ‣ 複雑さは暗黙知を生み出すので極力シンプルに ‣ AWSに任せられることは任せてしまう ‣ DBのバックアップ、メール配信、ログの保管 ‣ 特定の人しかわからない構成にはしない
  45. 45. いつでも作り直せる
 安心感
  46. 46. 考え方が変わってきた ‣ たとえばメモリを大量に使うバッチ処理 ‣ オンプレミスだと、いかにメモリ消費を抑え るかに頭を使ってた ‣ でも、それって本質的じゃない ‣ これがAWSなら…
  47. 47. バーンと立ち上げて
 ガーッとやって
 スパッと落とせばいい!
  48. 48. 今後の課題 ‣ 立ち上げっぱなしのサーバを減らしたい ‣ 1クリックで本番環境のクローンを作りたい ‣ CloudFormationはEMRに未対応><
  49. 49. ビフォーアフターのまとめ ‣ オンプレミスと比べて圧倒的に短期間で、しか も簡単にスケールアウトできる ‣ インフラの制約がなくなったことで、開発者が 主体になって攻めていける ‣ 結果的にチームも変わってきた
  50. 50. Q&A

×