Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
GCPで
プライベートDMP
を作ってみた
2017/06/26
Agenda
1. 自己紹介
2. GCPを始めたキッカケ
3. DMPのGCP構成
4. GCPの嬉しいところ
5. 頑張ったこと
6. 感想と反省
7. 担当サービス紹介
8. 質疑
1. 自己紹介
株式会社オプト
テクノロジー開発部
張明橡 m.cho@opt.ne.jp
https://www.opt.ne.jp/opttechnologies/
↑↑ We’re hiring!
1. 自己紹介
◎ 2005.03 来日 広島呉市 オフシェア開発
◎ 2006.08 上京 SI開発
◎ 2008.12 ネット業界に転職
(アドネットワーク開発、運用、インフラ)
◎ 2015.03 オプトに入社
経歴
GCP歴:2016/...
1. 自己紹介
◎ 他の開発をしながら、一人(1.2?)で1年間がかかっ
た(2013〜2014)
○ 物理サーバのセットアップ(SDDの交換など)
○ OpenIPMIでリモートでサーバの再起動
○ CentOS => Debianの移行(自...
2. GCPを始めたキッカケ
ビジネス
◎ スマートアプリのイベントログを貯めたい
◎ ログのロストは許されない
◎ ビッグデータでも自由に分析したい
◎ 拡張性がある
◎ 低コスト
エンジニア
◎ データの収集(高負荷、autoscale)
...
2. GCPを始めたキッカケ
DMP(データの蓄積) 管理画面(データの応用)
既存システム構成(AWS)
◎ BigQueryが容量に気にしない、検索(大量データも安
定)、安価(使い方次第)
◎ GAEがAutoscale, インスタンス立ち上げが早い
◎ 全体インフラコストが安い
◎ フルマネジドサービスが揃っている
◎ ...
◎ Redsh...
3. DMPのGCP構成
3. DMPのGCP構成
DMPのデータフロー
3. DMPのGCP構成
◎ default: リクエストを受けてログをキューに入れる
◎ worker: キューから取り出し、ファイルをGCSにアップロー
ド (GAEのCronに呼び出す)
◎ dataflow: GCSファイルをDataf...
4. GCPの嬉しいところ
◎ インフラコスト=>約1/6ぐらい
◎ アクセスの負荷、データウェアハウスの負荷に気
にしなくお客様への導入が勧められる
◎ BigQueryが直接使えるので、エンジニアに依頼
しなくでいい(SQLをかける前提)
...
4. GCPの嬉しいところ
◎ 設計自体はすごく自然になる(micro service)
◎ データ収集の部分はインフラコードがZERO
◎ BigQueryの検索が早い。調査、検証が楽
◎ Dataflowでコーディング量が減った。しかもフル...
4. GCPの嬉しいところ
エンジニア
◎ GAEのAutoscaleはうわさ通り早く、安い
300qps以上が、課金されるinstanceが1です
5. 頑張ったこと
◎ ログを追跡するため、ログにunique_id(gaeの
request_id)を入れましたが, stackdriverログの
request_idと合わない問題
Google support: 次のリリースでなおる
暫定...
5. 頑張ったこと
◎ ログロストを検知するため、対象アプリのrequest
カウントをdatastoreに入れて次の日にbigquery
の数字と比較している
1, Datastore sharding: https://cloud.goog...
5. 頑張ったこと
◎ BigQueryのStream Insertにpartionができるように
com.google.cloud.dataflow.sdk.util.BigQueryTableInserter
table_name => t...
5. 頑張ったこと
◎ RedshiftからBigqueryの移行
● 月単位にRedshiftからtsvにDumpする
● S3からgoogle cloud storageに転送する
● 既存のDataflowをちょっとコードを修正してイン
...
5. 頑張ったこと
◎ 手動でdataflow cronを押すと、複数dataflowが同
時に動いた。一つファイルが複数処理された
1, 集計する対象ファイルを取得してdatastoreにあるファイル
(処理中)を取り除く
2, ファイル名(...
5. 頑張ったこと
dataflowの事後処理
処理されたファイルの移動、datastoreからフィアル一覧を削除
する
◎ たまにDataflow vmが起動されない
 project内部のvmリソースが足りないか、zoneから
vmリソース...
6. 感想と反省
◎ Biqueryにデータを溜まった=>基盤ができた
横展開が進める
● firebaseデータとの結合
● redashなどのBIツールとの連携
● tensorflowを使って機械学習
◎ Cloud pub/sub + ...
6. 感想と反省
◎ Cloudなので、オンプレミスでは起きないことが
起きる
◎ Cloud APIは失敗する可能性があるので、リト
ライすることを常に頭に入れる
◎ 発生する確率が低いから、油断したら大変で
す。とりあえず、最初に全てのエラ...
6. 感想と反省
◎ Cloudサービスが色々便利ですが、制約があ
ります(timeout, access rate per second, hot
keys…)、制約を事前に把握したら後々落ち着
き対応できる
  全部事前に把握って無理だ。G...
7. 担当サービス
Spin App
7. 担当サービス
Spin App とは各種SDKが取得したデータを蓄積・分析・活用するため
の、アプリを特化したDMPです。
Adjust・AppsFlyerを導入済みの場合SDKの追加導入なく、施策実施が
可能です。
7. 担当サービス
SpinApp特徴
独自分析, Firebase, Webログなどとの連携
7. 担当サービス
https://spin-app.jp
詳しくは 担当者に聞いてくだい
8. 質疑
ご静聴ありがとうございました
Upcoming SlideShare
Loading in …5
×

Gcpでprivate dmpを作ってみた

621 views

Published on

Using GAE+Dataflow+Bigquery to create private dmp

Published in: Data & Analytics
  • Be the first to comment

  • Be the first to like this

Gcpでprivate dmpを作ってみた

  1. 1. GCPで プライベートDMP を作ってみた 2017/06/26
  2. 2. Agenda 1. 自己紹介 2. GCPを始めたキッカケ 3. DMPのGCP構成 4. GCPの嬉しいところ 5. 頑張ったこと 6. 感想と反省 7. 担当サービス紹介 8. 質疑
  3. 3. 1. 自己紹介 株式会社オプト テクノロジー開発部 張明橡 m.cho@opt.ne.jp https://www.opt.ne.jp/opttechnologies/ ↑↑ We’re hiring!
  4. 4. 1. 自己紹介 ◎ 2005.03 来日 広島呉市 オフシェア開発 ◎ 2006.08 上京 SI開発 ◎ 2008.12 ネット業界に転職 (アドネットワーク開発、運用、インフラ) ◎ 2015.03 オプトに入社 経歴 GCP歴:2016/11〜 その前ちょこちょこAWSをいじったぐらい、基本 的オンプレミス  puppetでデータセンター移行を遂行した
  5. 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. 6. 2. GCPを始めたキッカケ ビジネス ◎ スマートアプリのイベントログを貯めたい ◎ ログのロストは許されない ◎ ビッグデータでも自由に分析したい ◎ 拡張性がある ◎ 低コスト エンジニア ◎ データの収集(高負荷、autoscale) ◎ いい感じなデータウェアハウス ◎ データの分析(確認,検証,連携しやすい)
  7. 7. 2. GCPを始めたキッカケ DMP(データの蓄積) 管理画面(データの応用) 既存システム構成(AWS)
  8. 8. ◎ BigQueryが容量に気にしない、検索(大量データも安 定)、安価(使い方次第) ◎ GAEがAutoscale, インスタンス立ち上げが早い ◎ 全体インフラコストが安い ◎ フルマネジドサービスが揃っている ◎ ... ◎ Redshiftのアラートがきている。容量が足りない... ◎ SQL実行時間が不安定、チューニングが必要 ◎ アクセスピーク時に事前にELBの暖気申請が.. ◎ インフラコストがどんどん増えている ◎ インフラエンジニアが社外頼り 2. GCPにした経緯 AWSはSpinAppとの相性? GCPは
  9. 9. 3. DMPのGCP構成
  10. 10. 3. DMPのGCP構成 DMPのデータフロー
  11. 11. 3. DMPのGCP構成 ◎ default: リクエストを受けてログをキューに入れる ◎ worker: キューから取り出し、ファイルをGCSにアップロー ド (GAEのCronに呼び出す) ◎ dataflow: GCSファイルをDataflowに投げ集計する(GAEの Cronに呼び出す) マイクロサービス
  12. 12. 4. GCPの嬉しいところ ◎ インフラコスト=>約1/6ぐらい ◎ アクセスの負荷、データウェアハウスの負荷に気 にしなくお客様への導入が勧められる ◎ BigQueryが直接使えるので、エンジニアに依頼 しなくでいい(SQLをかける前提) ◎ データ分析が色々できる ◎ 他のBIツールとの連携 ビジネス
  13. 13. 4. GCPの嬉しいところ ◎ 設計自体はすごく自然になる(micro service) ◎ データ収集の部分はインフラコードがZERO ◎ BigQueryの検索が早い。調査、検証が楽 ◎ Dataflowでコーディング量が減った。しかもフルマ ネジド ◎ Stackdriver でログを集中できに管理できて監視設 定も楽です ◎ Google Support(Gold)英語ならすぐ返事がくる エンジニア
  14. 14. 4. GCPの嬉しいところ エンジニア ◎ GAEのAutoscaleはうわさ通り早く、安い 300qps以上が、課金されるinstanceが1です
  15. 15. 5. 頑張ったこと ◎ ログを追跡するため、ログにunique_id(gaeの request_id)を入れましたが, stackdriverログの request_idと合わない問題 Google support: 次のリリースでなおる 暫定対応:s/0001(..){1,3}$/000100/
  16. 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で1分1回にカウントをmemcacheからdatastoreに移す しかし、memcacheのエラーが頻発していた。=> qps 500なのに... Supportに問い合わせした結果、hot keys[2]問題がありました。 [1]のやり方でmemcacheのアクセスを分散化してみたら、numShards=10が足りな かった。=> 20にしたが、偶にエラーがある。監視なので許容レベル オンプレミスのmemcachedと全然違う
  17. 17. 5. 頑張ったこと ◎ BigQueryのStream Insertにpartionができるように com.google.cloud.dataflow.sdk.util.BigQueryTableInserter table_name => table$yyyymmdd パーティーションにする
  18. 18. 5. 頑張ったこと ◎ RedshiftからBigqueryの移行 ● 月単位にRedshiftからtsvにDumpする ● S3からgoogle cloud storageに転送する ● 既存のDataflowをちょっとコードを修正してイン ポートができた
  19. 19. 5. 頑張ったこと ◎ 手動でdataflow cronを押すと、複数dataflowが同 時に動いた。一つファイルが複数処理された 1, 集計する対象ファイルを取得してdatastoreにあるファイル (処理中)を取り除く 2, ファイル名(+job名)をdatastoreに入れてから処理を始める dataflowの事前処理 ◎ dataflowに渡すパラメーターのバッファーサイ ズ制限がある 何らかの原因でdataflowが止まってファイルが溜まった場 合がある。 一回処理するファイル数を制限する => 2000
  20. 20. 5. 頑張ったこと dataflowの事後処理 処理されたファイルの移動、datastoreからフィアル一覧を削除 する ◎ たまにDataflow vmが起動されない  project内部のvmリソースが足りないか、zoneから vmリソースが取れない。後者が発生した。 手動でjob名で絞ってdatastoreレコードを削除する。 最近出たばかりなのでscript化されていない ◎ 事後処理が実行されない  原因: timeoutか?google supportが調査している  対応: job名をパラメーターでscriptを実行する
  21. 21. 6. 感想と反省 ◎ Biqueryにデータを溜まった=>基盤ができた 横展開が進める ● firebaseデータとの結合 ● redashなどのBIツールとの連携 ● tensorflowを使って機械学習 ◎ Cloud pub/sub + Dataflow Stream modeを使た ら、今の構成より楽かも
  22. 22. 6. 感想と反省 ◎ Cloudなので、オンプレミスでは起きないことが 起きる ◎ Cloud APIは失敗する可能性があるので、リト ライすることを常に頭に入れる ◎ 発生する確率が低いから、油断したら大変で す。とりあえず、最初に全てのエラーをログに 残す。確認したあと外す。監視とかも最初多め に入れる ◎ (配信系)あらゆるエラーを想定してできる限り データの復旧、退避ができるようにしましょう
  23. 23. 6. 感想と反省 ◎ Cloudサービスが色々便利ですが、制約があ ります(timeout, access rate per second, hot keys…)、制約を事前に把握したら後々落ち着 き対応できる   全部事前に把握って無理だ。Google supportを参加した方がいいです ◎ GCPの資料が多いですが、分散している。英 語の方が多いです。全部把握するのは無理で す。試しながらやるのは多いです。 ◎ GCP supportですが、英語の方はリスポンスが 早い、安心(自分だけ?)
  24. 24. 7. 担当サービス Spin App
  25. 25. 7. 担当サービス Spin App とは各種SDKが取得したデータを蓄積・分析・活用するため の、アプリを特化したDMPです。 Adjust・AppsFlyerを導入済みの場合SDKの追加導入なく、施策実施が 可能です。
  26. 26. 7. 担当サービス SpinApp特徴 独自分析, Firebase, Webログなどとの連携
  27. 27. 7. 担当サービス https://spin-app.jp 詳しくは 担当者に聞いてくだい
  28. 28. 8. 質疑 ご静聴ありがとうございました

×