Using GAE+Dataflow+Bigquery to create private dmp

1. GCPで
プライベートDMP
を作ってみた
2017/06/26

2. Agenda
1. 自己紹介
2. GCPを始めたキッカケ
3. DMPのGCP構成
4. GCPの嬉しいところ
5. 頑張ったこと
6. 感想と反省
7. 担当サービス紹介
8. 質疑

3. 1. 自己紹介
株式会社オプト
テクノロジー開発部
張明橡 m.cho@opt.ne.jp
https://www.opt.ne.jp/opttechnologies/
↑↑ We’re hiring!

4. 1. 自己紹介
◎ 2005.03 来日 広島呉市 オフシェア開発
◎ 2006.08 上京 SI開発
◎ 2008.12 ネット業界に転職
(アドネットワーク開発、運用、インフラ)
◎ 2015.03 オプトに入社
経歴
GCP歴：2016/11〜
その前ちょこちょこAWSをいじったぐらい、基本
的オンプレミス
puppetでデータセンター移行を遂行した

5. 1. 自己紹介
◎ 他の開発をしながら、一人(1.2？)で1年間がかかっ
た(2013〜2014)
○ 物理サーバのセットアップ(SDDの交換など)
○ OpenIPMIでリモートでサーバの再起動
○ CentOS => Debianの移行(自作のパッケージなど)
○ 冗長構成: NTP server, 内部DNS,Proxy server,NAT
server…
○ Openvzでステージング環境の仮想化
○ ロードバランサーのチューニング(Kernelパラメーター、
LVS, Nginx)
◎ なんでAWS(EC2)にしなかった？
○ 実は外部DNSとHadoopクラスターはAWSにした
前職のインフラ(データセンター移行)
楽しい？辛い？ => 大変
ビジネス的には？ => Cloudでしょう

6. 2. GCPを始めたキッカケ
ビジネス
◎ スマートアプリのイベントログを貯めたい
◎ ログのロストは許されない
◎ ビッグデータでも自由に分析したい
◎ 拡張性がある
◎ 低コスト
エンジニア
◎ データの収集(高負荷、autoscale)
◎ いい感じなデータウェアハウス
◎ データの分析(確認,検証,連携しやすい)

7. 2. GCPを始めたキッカケ
DMP(データの蓄積) 管理画面(データの応用)
既存システム構成(AWS)

8. ◎ BigQueryが容量に気にしない、検索(大量データも安
定)、安価(使い方次第)
◎ GAEがAutoscale, インスタンス立ち上げが早い
◎ 全体インフラコストが安い
◎ フルマネジドサービスが揃っている
◎ ...
◎ Redshiftのアラートがきている。容量が足りない...
◎ SQL実行時間が不安定、チューニングが必要
◎ アクセスピーク時に事前にELBの暖気申請が..
◎ インフラコストがどんどん増えている
◎ インフラエンジニアが社外頼り
2. GCPにした経緯
AWSはSpinAppとの相性？
GCPは

9. 3. DMPのGCP構成

10. 3. DMPのGCP構成
DMPのデータフロー

11. 3. DMPのGCP構成
◎ default: リクエストを受けてログをキューに入れる
◎ worker: キューから取り出し、ファイルをGCSにアップロー
ド (GAEのCronに呼び出す)
◎ dataflow: GCSファイルをDataflowに投げ集計する(GAEの
Cronに呼び出す)
マイクロサービス

12. 4. GCPの嬉しいところ
◎ インフラコスト=>約1/6ぐらい
◎ アクセスの負荷、データウェアハウスの負荷に気
にしなくお客様への導入が勧められる
◎ BigQueryが直接使えるので、エンジニアに依頼
しなくでいい(SQLをかける前提)
◎ データ分析が色々できる
◎ 他のBIツールとの連携
ビジネス

13. 4. GCPの嬉しいところ
◎ 設計自体はすごく自然になる(micro service)
◎ データ収集の部分はインフラコードがZERO
◎ BigQueryの検索が早い。調査、検証が楽
◎ Dataflowでコーディング量が減った。しかもフルマ
ネジド
◎ Stackdriver でログを集中できに管理できて監視設
定も楽です
◎ Google Support(Gold)英語ならすぐ返事がくる
エンジニア

14. 4. GCPの嬉しいところ
エンジニア
◎ GAEのAutoscaleはうわさ通り早く、安い
300qps以上が、課金されるinstanceが1です

15. 5. 頑張ったこと
◎ ログを追跡するため、ログにunique_id(gaeの
request_id)を入れましたが, stackdriverログの
request_idと合わない問題
Google support: 次のリリースでなおる
暫定対応:s/0001(..){1,3}$/000100/

16. 5. 頑張ったこと
◎ ログロストを検知するため、対象アプリのrequest
カウントをdatastoreに入れて次の日にbigquery
の数字と比較している
1, Datastore sharding: https://cloud.google.com/appengine/articles/sharding_counters
2, Hot keys: are keys that receive more than 100 queries per second (QPS) in the memcache.
3, Distribute Memcache Load:
https://cloud.google.com/appengine/articles/best-practices-for-app-engine-memcache#distribute_load_across
_the_keyspace
でもアクセスが多いところ、shardingを使ってもdatastoreには厳しいでしょう
GAE専用memcache 1G(最大5000 write/s)にして、リクエストごとにmemcacheに
incrementして、cronで１分１回にカウントをmemcacheからdatastoreに移す
しかし、memcacheのエラーが頻発していた。=> qps 500なのに...
Supportに問い合わせした結果、hot keys[2]問題がありました。
[1]のやり方でmemcacheのアクセスを分散化してみたら、numShards=10が足りな
かった。=> 20にしたが、偶にエラーがある。監視なので許容レベル
オンプレミスのmemcachedと全然違う

17. 5. 頑張ったこと
◎ BigQueryのStream Insertにpartionができるように
com.google.cloud.dataflow.sdk.util.BigQueryTableInserter
table_name => table$yyyymmdd パーティーションにする

18. 5. 頑張ったこと
◎ RedshiftからBigqueryの移行
● 月単位にRedshiftからtsvにDumpする
● S3からgoogle cloud storageに転送する
● 既存のDataflowをちょっとコードを修正してイン
ポートができた

19. 5. 頑張ったこと
◎ 手動でdataflow cronを押すと、複数dataflowが同
時に動いた。一つファイルが複数処理された
1, 集計する対象ファイルを取得してdatastoreにあるファイル
(処理中)を取り除く
2, ファイル名(+job名)をdatastoreに入れてから処理を始める
dataflowの事前処理
◎ dataflowに渡すパラメーターのバッファーサイ
ズ制限がある
何らかの原因でdataflowが止まってファイルが溜まった場
合がある。
一回処理するファイル数を制限する => 2000

20. 5. 頑張ったこと
dataflowの事後処理
処理されたファイルの移動、datastoreからフィアル一覧を削除
する
◎ たまにDataflow vmが起動されない
project内部のvmリソースが足りないか、zoneから
vmリソースが取れない。後者が発生した。
手動でjob名で絞ってdatastoreレコードを削除する。
最近出たばかりなのでscript化されていない
◎ 事後処理が実行されない
原因: timeoutか？google supportが調査している
対応: job名をパラメーターでscriptを実行する

21. 6. 感想と反省
◎ Biqueryにデータを溜まった=>基盤ができた
横展開が進める
● firebaseデータとの結合
● redashなどのBIツールとの連携
● tensorflowを使って機械学習
◎ Cloud pub/sub + Dataflow Stream modeを使た
ら、今の構成より楽かも

22. 6. 感想と反省
◎ Cloudなので、オンプレミスでは起きないことが
起きる
◎ Cloud APIは失敗する可能性があるので、リト
ライすることを常に頭に入れる
◎ 発生する確率が低いから、油断したら大変で
す。とりあえず、最初に全てのエラーをログに
残す。確認したあと外す。監視とかも最初多め
に入れる
◎ (配信系)あらゆるエラーを想定してできる限り
データの復旧、退避ができるようにしましょう

23. 6. 感想と反省
◎ Cloudサービスが色々便利ですが、制約があ
ります(timeout, access rate per second, hot
keys…)、制約を事前に把握したら後々落ち着
き対応できる
全部事前に把握って無理だ。Google
supportを参加した方がいいです
◎ GCPの資料が多いですが、分散している。英
語の方が多いです。全部把握するのは無理で
す。試しながらやるのは多いです。
◎ GCP supportですが、英語の方はリスポンスが
早い、安心(自分だけ？)

24. 7. 担当サービス
Spin App

25. 7. 担当サービス
Spin App とは各種SDKが取得したデータを蓄積・分析・活用するため
の、アプリを特化したDMPです。
Adjust・AppsFlyerを導入済みの場合SDKの追加導入なく、施策実施が
可能です。

26. 7. 担当サービス
SpinApp特徴
独自分析, Firebase, Webログなどとの連携

27. 7. 担当サービス
https://spin-app.jp
詳しくは 担当者に聞いてくだい

28. 8. 質疑
ご静聴ありがとうございました