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