Downloaded 27 times
Uploaded byKenta Suzuki
Data Engineering at VOYAGE GROUP #jawsdays
#jawsdays 2015での発表スライドです。 http://jawsdays2015.jaws-ug.jp/speaker/suzuki/
More Related Content
![[JAWS DAYS 2017 ワークショップ] 不安で夜眠れないAWSアカウント管理者に送る処方箋という名のハンズオン](https://cdn.slidesharecdn.com/ss_thumbnails/20170311jawsdays2017h1-170311030315-thumbnail.jpg?width=640&height=640&fit=bounds)
![[JAWS Days 2015 LT]使い始めて3年半、ようやくテスト始めました](https://cdn.slidesharecdn.com/ss_thumbnails/jasw-days-lt-150323200941-conversion-gate01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://cdn.slidesharecdn.com/ss_thumbnails/auroradeep-150322203758-conversion-gate01-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Data Engineering at VOYAGE GROUP #jawsdays
![[AWSマイスターシリーズ] Amazon DynamoDB](https://cdn.slidesharecdn.com/ss_thumbnails/20131002aws-meister-regenerate-dynamodb-public-131004025730-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Data Engineering at VOYAGE GROUP #jawsdays
- 1. Data Engineering at VOYAGEGROUP JAWS DAYS 2015 2015/03/22 @suzu_v
- 2. 自己紹介 • 鈴木健太、すずけん、@suzu_v • http://suzuken.hatenablog.jp/ •ソフトウェアエンジニア • アドテクノロジー事業（SSP, DMP）に従事
- 4.
- 6.
- 7. 私達とAWS • 2009年から利用開始 • 2011年からアドテクノロジー領域でも利用を開始 •今日はアドテクノロジー領域でのAWS利用につい てお話します
- 8.
- 9.
- 10.
- 11.
- 12.
- 13. 行動ターゲティングの課題 • なるべく速く書き込みたい。ユーザが何かをみたら、 すぐにターゲティング可能な状態にしてほしい。反 映が速ければ速いほどいい。 • 案件や対象ユーザが増えても、システム全体が問題 なくスケールすること •読み込みが安定して低レイテンシであること。でき れば5ms以内。
- 14. Targeting Infrastructure ELB EC2 EC2 EC2 EC2 request EC2 S3 DynamoDB EMR ELB EC2 EC2EC2 EC2 http api fluentd fluentd (aggregator) out_exec_filter out_dynamodb servlet (scala) dynamic-dynamo EC2 Growth Forecast EC2 EC2 VPC 1 VPC 1 VPC 2 (targeting) VPC Peering VPC Peering ephemeral cluster
- 15. ELB EC2 EC2 EC2 EC2 request EC2 S3 DynamoDB EMR ELB EC2 EC2EC2 EC2 http api fluentd fluentd (aggregator) out_exec_filter out_dynamodb servlet (scala) dynamic-dynamo EC2 Growth Forecast EC2 EC2 VPC 1 VPC 1 VPC 2 (targeting) VPC Peering VPC Peering ephemeral cluster 配信用VPC ターゲティング 基盤VPC
- 16. ELB EC2 EC2 EC2 EC2 request EC2 S3 DynamoDB EMR ELB EC2 EC2EC2 EC2 http api fluentd fluentd (aggregator) out_exec_filter out_dynamodb servlet (scala) dynamic-dynamo EC2 Growth Forecast EC2 EC2 VPC 1 VPC 1 VPC 2 (targeting) VPC Peering VPC Peering ephemeral cluster Fluentdの forwardで連携
- 17. ELB EC2 EC2 EC2 EC2 request EC2 S3 DynamoDB EMR ELB EC2 EC2EC2 EC2 http api fluentd fluentd (aggregator) out_exec_filter out_dynamodb servlet (scala) dynamic-dynamo EC2 Growth Forecast EC2 EC2 VPC 1 VPC 1 VPC 2 (targeting) VPC Peering VPC Peering ephemeral cluster Event Streamノード c3.xlarge複数台 td-agent2
- 18. ELB EC2 EC2 EC2 EC2 request EC2 S3 DynamoDB EMR ELB EC2 EC2EC2 EC2 http api fluentd fluentd (aggregator) out_exec_filter out_dynamodb servlet (scala) dynamic-dynamo EC2 Growth Forecast EC2 EC2 VPC 1 VPC 1 VPC 2 (targeting) VPC Peering VPC Peering ephemeral cluster out_exec_filterでログを加工 DynamoDBに書き込み
- 19. ELB EC2 EC2 EC2 EC2 request EC2 S3 DynamoDB EMR ELB EC2 EC2EC2 EC2 http api fluentd fluentd (aggregator) out_exec_filter out_dynamodb servlet (scala) dynamic-dynamo EC2 Growth Forecast EC2 EC2 VPC 1 VPC 1 VPC 2 (targeting) VPC Peering VPC Peering ephemeral cluster ユーザのセグメント情報を書き込み 全てのログ
- 20.
- 21.
- 22. シンプルなストリーム処理 in_forwardで受け入れたレコード out_exec_filterで加工 {id: "hoge", segment:"seg1", created: 1426406962, ...} DynamoDBテーブルへ {id: "hoge", url: "http://fuga.com/kuke", user_agent: ..} {id: "hoge", url: "http://hoge.com/a", user_agent: ..} if (domain(url) == "fuga.com") seg = "seg1"
- 23. <match hoge.log> type exec_filter command./our/special/filter/command buffer_type file buffer_path /path/to/ephemeral/disk/hoge </match> ! <match filtered.hoge.log> type dynamodb dynamo_db_table our_targeting_table buffer_type file buffer_path /path/to/ephemeral/disk/filtered ... <secondary> type s3 s3_bucket your-bucket s3_region ap-northeast-1 s3_object_key_format ... buffer_type file buffer_path /path/to/ephemeral/disk/filtered.secondary ... </secondary> </match> in_forwardでおくられてきた ログをうけとり、フィルターする filterしたログをDynamoDBに書き込む batchWriteItemを利用 もし書き込みが失敗したらs3へ 書ききれてませんが、s3への転送もしてます
- 24. <match hoge.log> type exec_filter command./our/special/filter/command buffer_type file buffer_path /path/to/ephemeral/disk/hoge </match> ! <match filtered.hoge.log> type dynamodb dynamo_db_table our_targeting_table buffer_type file buffer_path /path/to/ephemeral/disk/filtered ... <secondary> type s3 s3_bucket your-bucket s3_region ap-northeast-1 s3_object_key_format ... buffer_type file buffer_path /path/to/ephemeral/disk/filtered.secondary ... </secondary> </match> バッファは全てファイル ephemeral diskに
- 25. EventStreamノードの運用 • ノードを作り直す場合にはforward側からフェイルしたノー ドを外し、全ての転送が終わったら落とす • Output先を詰まらせないこと。fluentdにバッファをなる べく貯めないことが望ましい。定常的にバッファが貯まる ようなら改善が必要。 •バッファがたまってしまった場合は原因を特定して詰まり を解消した上で、強制的にflush • $ pkill -USR1 -f fluentd
- 26.
- 27. ストリーム処理における状態 プロセッサ id: 1 k: 2 データ あるidがk:1を満たしていたら通したい
- 28. ストリーム処理における状態 プロセッサ id: 1 k: 2 データ NG あるidがk:1を満たしていたら通したい
- 29.
- 30. ストリーム処理における状態 プロセッサ データ id: 1 k: 1 あるidがk:1を満たしていたら通したい
- 31. ストリーム処理における状態 プロセッサ データ id: 1 k: 1OK! あるidがk: 1を満たしていたら通したい
- 32.
- 33. 留めるデータが増えるケース プロセッサ id: 1 k: 2 データ あるidがk:1とk: 2両方を満たしていたら通したい
- 34. プロセッサ id: 1 k: 2 データstay あるidがk: 1とk: 2両方を満たしていたら通したい 留めるデータが増えるケース
- 35. プロセッサ id: 1 k: 3 id:1 k: 2 id: 1 k: 1 データ 条件がくるまで 滞留させる必要がある あるidがk: 1とk: 2両方を満たしていたら通したい 留めるデータが増えるケース
- 36. プロセッサ id: 1 v: ok データ 条件をみたしたのでOK あるidがk:1とk: 2両方を満たしていたら通したい 留めるデータが増えるケース
- 37. ストリーム処理における状態 プロセッサ id: 1 k: 3 id:1 k: 2 id: 1 k: 1 データ 条件がくるまで 滞留させる必要がある 対象とする時間の幅（window）が長くなれば なるほど多くのデータをストリーム処理可能 な場所に保持する必要がある。データの流量 が増えるとそれだけ多くのリソース（RAM 等）が必要になる。 あるidがk: 1とk: 2両方を満たしていたら通したい
- 38. 行動ターゲティングの課題 （再掲） • なるべく速く書き込みたい。ユーザが何かをみたら、 すぐにターゲティング可能な状態にしてほしい。反 映が速ければ速いほどいい。 • 案件や対象ユーザが増えても、システム全体が問題 なくスケールすること •読み込みが安定して低レイテンシであること。でき れば5ms以内。
- 39. いろいろ試した結果 • シンプルなmap処理のみリアルタイムに • (30日前にページAをみたand さっきページBをみ た)というセグメントにも対応しなければいけなかっ た・・。のでバッチも併用することに。 • 結果横に並べればシンプルなmap処理についてはス ケールする構成になったので良かった
- 40. ELB EC2 EC2 EC2 EC2 request EC2 S3 DynamoDB EMR ELB EC2 EC2EC2 EC2 http api fluentd fluentd (aggregator) out_exec_filter out_dynamodb servlet (scala) dynamic-dynamo EC2 Growth Forecast EC2 EC2 VPC 1 VPC 1 VPC 2 (targeting) VPC Peering VPC Peering ephemeral cluster EMRでDynamoDBとS3からデータ抽出 再集計してDynamoDBへ書き込み
- 41. EMR / Hive •Amazon Hadoop 2.4.0, Hive 0.13.1, core: m1.xlarge * 30, task: c3かr3系統をspot instanceで。専用のSecurity Group を用意。基本的にRCFileで扱う。 • 200クエリ / 日。1日1クラスタ立ち上げて、ひたすらそこに投 げている。DynamoDBとs3からデータを読み込み、集計し、s3 に書き出している。使うHiveクエリは管理ツールから自動生成 or リポジトリにコミットしてJenkinsからs3に上げている。 • アドホックに使う場合には都度別クラスタを立ち上げている。 分析者も手元からThrift経由で。
- 42. SET dynamodb.throughput.read.percent=0.8; ! CREATE EXTERNALTABLE IF NOT EXISTS users ( id string, seg string, created bigint ) stored as rcfile location 's3://path/to/my/user/table'; ! CREATE EXTERNAL TABLE if not exists users_from_dynamodb ( id string, seg string, created bigint) STORED BY 'org.apache.hadoop.hive.dynamodb.DynamoDBStorageHandler' TBLPROPERTIES ( "hive.jdbc.update.on.duplicate" = "true", "dynamodb.table.name" = "our_special_user_table_name", "dynamodb.column.mapping" = "id:id,seg:seg,created:created"); ! INSERT OVERWRITE TABLE users SELECT * FROM users_from_dynamodb; DynamoDBのthroughputをどれくらい使うか DynamoDBカラムとHiveテーブルの カラム対応関係 DynamoDBから全データを 抽出してs3に書き込み
- 43. EMRの利点と課題 • 利点 • Hadoopのバージョンアップなど、EMR側がやってくれるので楽 •潰して、立ち上げなおして、が簡単にできる • bootstrapを工夫すれば様々なHadoop関連ミドルウェアを手軽に試せる • https://github.com/awslabs/emr-bootstrap-actions • 課題 • クラスタ立ち上げは時間がかかる • ジョブスケジューリングは自前で頑張る必要あり • EMRコマンドのデバッグには極論EMRを立ち上げるしか無い
- 44.
- 45. 行動ターゲティングの課題 （再掲） • なるべく速く書き込みたい。ユーザが何かをみたら、 すぐにターゲティング可能な状態にしてほしい。反 映が速ければ速いほどいい。 • 案件や対象ユーザが増えても、システム全体が問題 なくスケールすること •読み込みが安定して低レイテンシであること。でき れば5ms以内。
- 46. DynamoDB、最高です • ご存知フルマネージドNoSQL DBon AWS • 2年半ほど継続して利用。AWSを使っていて最も選 んでよかったと思っているデータストア。 • 30億レコード入っている。1リクエスト3msで返る。 しかも1度もダウンしたことがない。
- 47.
- 48. ELB EC2 EC2 EC2 EC2 request EC2 S3 DynamoDB EMR ELB EC2 EC2EC2 EC2 http api fluentd fluentd (aggregator) out_exec_filter out_dynamodb servlet (scala) dynamic-dynamo EC2 Growth Forecast EC2 EC2 VPC 1 VPC 1 VPC 2 (targeting) VPC Peering VPC Peering ephemeral cluster 配信サーバからセグメントデータを読み込み
- 49. apache (prefork) +PHP apacherequest DynamoDB
- 50. apache (prefork) +PHP apacherequest Process DynamoDB
- 51. apache (prefork) +PHP apacherequest Process DynamoDB 新規コネクション ( 10ms)
- 52. apache (prefork) +PHP apacherequest Process DynamoDB GetItem
- 53. apache (prefork) +PHP apache Process DynamoDB response
- 54. apache (prefork) +PHP apache DynamoDB response
- 55. apache (prefork) +PHP apache DynamoDB response リクエストからレスポンスまで 30ms
- 56.
- 57.
- 58. • PHP製のapiをScalaで再実装。Servletを利用。 • DynamoDBへのコネクションをプールするように •responseが早くなり、同時接続数が増えすぎるこ となく、安定して稼働
- 59.
- 60. ELB EC2 EC2 EC2 EC2 request EC2 S3 DynamoDB EMR ELB EC2 EC2EC2 EC2 http api fluentd fluentd (aggregator) out_exec_filter out_dynamodb servlet (scala) dynamic-dynamo EC2 Growth Forecast EC2 EC2 VPC 1 VPC 1 VPC 2 (targeting) VPC Peering VPC Peering ephemeral cluster out_exec_filterでログを加工 DynamoDBに書き込み
- 61.
- 62.
- 63.
- 64. テーブル設計イメージ user_id String (hash key) segment String (range key) created Number … hogeseg1 1426406962 hoge seg2 1426406962 fuga seg1 1426406962 kuke seg1 1426406962
- 65. DynamoDB Tips • 1Itemあたりのバイト数を小さくする（1KBを超え ないように •hot keyを作らないようにする（hash keyに同じID が大量に存在する状態にしないようにする • DynamoDB - EC2の新規コネクションはそれなり にコストが高い（ 10ms）ので、コネクションを プールする（つながれば安定して速い 参考: http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-amazon-dynamodb
- 66.
- 67.
- 68. 部分的にBigQueryを利用 • EC2 ->S3 -> SQS -> EC2(worker) -> GCS • アドホックな分析用はこちらに移行中 https://cloud.google.com/bigquery/?hl=ja
- 69. BigQuery • いいところ • クラスタのメンテしなくていい。（Hadoopクラス タの面倒見なくていいし）。速い。コンソールも 最初からついてる。GoogleAppsと連携できる。 • 使いづらい所 • 権限周り。まだAWSと比べて細かい制御が難しそ う。UDFが（まだ）使えない。
- 70. 現状の使い分け • Large Batch:EMR + Hive • Short Batch: BigQuery • Stream Processing: Fluentd + out_exec_filter 参考: http://www.slideshare.net/tagomoris/hcj2014-sql
- 71.
- 72. プロダクトオーナーシップ • インフラも、データも、サービスも、営業も • 「このデータを取れるようにしたいだけど？」に対 して、全方面に答えられる必要がある。ログに10 バイト情報を増やすだけで、10バイト250億だ け月に扱う量が増える。帯域、ディスク、関連する コストが増える。それらに見合うだけの価値があと から出せるのかを考える必要がある。
- 73.
- 74. cf. Amazon • AmazonKinesis Developer Managerの Goさんの話 • AmazonのLeadership PrinciplesのOwnership について • インフラチームもサービ スチームもOwnershipを
- 75. ビジネス的な改善の重視 • VOYAGE GROUPのエンジニアは技術的なレビュー を受ける。人事評価も影響する。 •現場のエンジニアでもプロダクトの数値を「見え る」ようにすることを意識させられる。 • データをうまく扱う環境をつくること -> ビジネス を改善すること 参考: http://gihyo.jp/design/serial/01/creative/0006
- 76.
- 77.
- 78.