More Related Content
Similar to Gcpでprivate dmpを作ってみた (20)
Gcpでprivate dmpを作ってみた
- 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でしょう
- 11. 3. DMPのGCP構成
◎ default: リクエストを受けてログをキューに入れる
◎ worker: キューから取り出し、ファイルをGCSにアップロー
ド (GAEのCronに呼び出す)
◎ dataflow: GCSファイルをDataflowに投げ集計する(GAEの
Cronに呼び出す)
マイクロサービス
- 13. 4. GCPの嬉しいところ
◎ 設計自体はすごく自然になる(micro service)
◎ データ収集の部分はインフラコードがZERO
◎ BigQueryの検索が早い。調査、検証が楽
◎ Dataflowでコーディング量が減った。しかもフルマ
ネジド
◎ Stackdriver でログを集中できに管理できて監視設
定も楽です
◎ Google Support(Gold)英語ならすぐ返事がくる
エンジニア
- 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. 5. 頑張ったこと
◎ BigQueryのStream Insertにpartionができるように
com.google.cloud.dataflow.sdk.util.BigQueryTableInserter
table_name => table$yyyymmdd パーティーションにする
- 19. 5. 頑張ったこと
◎ 手動でdataflow cronを押すと、複数dataflowが同
時に動いた。一つファイルが複数処理された
1, 集計する対象ファイルを取得してdatastoreにあるファイル
(処理中)を取り除く
2, ファイル名(+job名)をdatastoreに入れてから処理を始める
dataflowの事前処理
◎ dataflowに渡すパラメーターのバッファーサイ
ズ制限がある
何らかの原因でdataflowが止まってファイルが溜まった場
合がある。
一回処理するファイル数を制限する => 2000
- 22. 6. 感想と反省
◎ Cloudなので、オンプレミスでは起きないことが
起きる
◎ Cloud APIは失敗する可能性があるので、リト
ライすることを常に頭に入れる
◎ 発生する確率が低いから、油断したら大変で
す。とりあえず、最初に全てのエラーをログに
残す。確認したあと外す。監視とかも最初多め
に入れる
◎ (配信系)あらゆるエラーを想定してできる限り
データの復旧、退避ができるようにしましょう
- 23. 6. 感想と反省
◎ Cloudサービスが色々便利ですが、制約があ
ります(timeout, access rate per second, hot
keys…)、制約を事前に把握したら後々落ち着
き対応できる
全部事前に把握って無理だ。Google
supportを参加した方がいいです
◎ GCPの資料が多いですが、分散している。英
語の方が多いです。全部把握するのは無理で
す。試しながらやるのは多いです。
◎ GCP supportですが、英語の方はリスポンスが
早い、安心(自分だけ?)
- 25. 7. 担当サービス
Spin App とは各種SDKが取得したデータを蓄積・分析・活用するため
の、アプリを特化したDMPです。
Adjust・AppsFlyerを導入済みの場合SDKの追加導入なく、施策実施が
可能です。