Successfully reported this slideshow.

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

19

Share

Loading in …3
×
1 of 52
1 of 52

More Related Content

Related Audiobooks

Free with a 14 day trial from Scribd

See all

オンプレミスから 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

×