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