狠狠撸

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

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

なお剧的は当社比です

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

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

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

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

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

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

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

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

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

オンプレミスを捨てて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分あればスケールアウトできる

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

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

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

? インフラ構成を理解しているのは一部の人だけ
? アラートメールが飛んでも運用が対応できない

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

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

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

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

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

障害を非日常にしない

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

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

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

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

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

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

今後の課題
? 立ち上げっぱなしのサーバを減らしたい
? 1クリックで本番環境のクローンを作りたい
? 颁濒辞耻诲贵辞谤尘补迟颈辞苍は贰惭搁に未対応＞＜

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

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