Architecture Evolution in Repro

Slide 1

Slide 1 text

Architecture Evolution in Repro @joker1007 (Repro inc. CTO)

Slide 2

Slide 2 text

⾃⼰紹介 @joker1007 Repro inc. CTO Asakusa.rb RubyKaigi 2019 Speaker 最近は主にデータエンジニアっぽい仕事

Slide 3

Slide 3 text

Repro というサービススマホアプリ・Web サービス向けのアナリティクスユーザ属性や利⽤履歴を元にしたセグメンテーションセグメンテーション対象に対するダイレクトマーケティングセグメンテーション対象に対する広告出稿こういった機能をサービスとして提供している。

Slide 4

Slide 4 text

Retention Analytics

Slide 5

Slide 5 text

Funnel Analytics

Slide 6

Slide 6 text

User Segmentation

Slide 7

Slide 7 text

サービスのスケール総デバイス数数億超⼀度のプッシュ配信数が最⼤で1000 万〜2000 万デバイス⽉間で送信しているプッシュメッセージの数が約40 億超つまり、数千万のユーザの数⽇分の履歴やプロフィール情報を任意に組み合わせて、必要とするユーザーの集合を短時間で抽出しなければならない。それがRepro のユーザーセグメンテーション。

Slide 8

Slide 8 text

過去に戻って2016 年半ば数万ユーザの集計とセグメンテーションの時代

Slide 9

Slide 9 text

RDB の限界 MySQL でリクエスト時に集計して結果をRedis にキャッシュ。⾃分が⼊った当時で既に初回表⽰に10 秒以上かかるページがあった。

Slide 10

Slide 10 text

中間集計テーブルとバッチ化とりあえず突貫でMySQL 上に中間集計テーブルを作る。⼀部の集計をバッチ化するが、データ構造上アプリ毎にループで実⾏していた。

Slide 11

Slide 11 text

ナイーブなバッチの問題点顧客が増えれば線形で実⾏時間が伸び即破綻する。顧客が増えてもスケールでき、かつ顧客毎に集計更新に差が⽣じない様にする必要がある。安易にバッチ化するとこうなりがち。

Slide 12

Slide 12 text

fluentd & embulk & Bigquery Bigquery の採⽤データ転送のためにfluentd とembulk を利⽤それぞれのプラグインに何回かPR 出してたらコミット権を獲得

Slide 13

Slide 13 text

Bigquery の採⽤理由スキーマ設計を頑張りたくない分散キーとかソートキーとか異常なコストパフォーマンスまともなSQL に対応

Slide 14

Slide 14 text

fluentd 運⽤時の注意点データ転送量が多い時の注意点ブロッキングで詰まらない様にflush スレッド数を調整する⼗分なファイルストレージを⽤意する特にBigquery はAPI が良く死ぬ require_ack_response とsecondary output は基本的に必須でないとデータロストする secondary でエラーファイルをS3 に書き出すのは割と⼤丈夫によるエラーハンドルを設定どのレイヤーでどこまでデータが貯まって、どこまでの到達が保証できるのかを認識しておく事が重要。

Slide 15

Slide 15 text

Bigquery 採⽤後の構造

Slide 16

Slide 16 text

Bigquery で解決できたこと集計処理がめっちゃスケールする様になった当時から現在まででデータ量が数⼗倍ぐらいになったが、集計時間は⼤きく変化していない全ての顧客に同時に集計結果を出せる様になったただ、SQL 構築するのに、かなりの時間を費した。特にFunnel Analytics は超⾟かった。 ( ハードな集計SQL に興味がある⼈は後で直接質問を)

Slide 17

Slide 17 text

Bigquery では⾟いことユーザーが任意のタイミングで任意の条件でセグメンテーションし、短時間で結果を返すのが厳しい即時クエリの同時実⾏上限が存在するクラウドとリージョンを跨ぐデータ転送 Bigquery はクエリ課⾦利⽤されればされる程、Repro 側が損することになる当時は顧客毎にクエリ対象を分けられなかった現在はclustering key で多少カバーできそうしばらくは持つが、顧客の数が増えてくると破綻する。 ( また同じ問題…… 。)

Slide 18

Slide 18 text

Rukawa の開発 Bigquery 採⽤に伴いバッチの数が激増依存関係や並列実⾏可能かどうかを上⼿く調整する必要が出てきたワークフローエンジンrukawa を開発以前の発表資料 Ruby 製のシンプルなワークフローエンジンRukawa の紹介ワークフローエンジンRukawa と実装のサボり⽅

Slide 19

Slide 19 text

ユーザーセグメンテーションの裏側各条件をツリーとして表現し、Operator ノードで繋ぐ各ツリーのノードはSQL として解決可能になっているツリーを再帰処理しながらOperator がJOIN やIN 句を使ってクエリを結合する最終的に出⼒されたクエリをクエリエンジンに投げるこれらはRails のモデルとして表現されており、ERB を利⽤してSQL を構築している。つまり、モデルの中にERB のテンプレートがある

Slide 20

Slide 20 text

SELECT DISTINCT user_id FROM filtered_custom_event_histories WHERE <%= event_property_where_clause(and_properties, and_not_properties) %> こんな感じに解決可能なものを組み合わせる。

Slide 21

Slide 21 text

セグメンテーションツリーのイメージ SQL に解決しながらJOIN で折り畳んで、集合を組み合わせていく。

Slide 22

Slide 22 text

この辺りで⼤半の実⾏基盤をコンテナ化過去に喋ったり書いたりした記事があるのでそちらを参照。 production 環境でRails アプリをdocker コンテナとしてECS で運⽤するために考えたこと開発しやすいRails on Docker 環境の作り⽅サクっとAmazon ECS のクラスタを構築するためのterraform の設定 Docker コンテナ上でのassets precompile の扱い 2017 Rails アプリをECS で本番運⽤するためのStep by Step Docker 時代の分散RSpec 環境の作り⽅記事には書いてないがEmbulk on Fargate とかも ( これも詳細は質問や懇親会で)

Slide 23

Slide 23 text

Presto on EMR を採⽤クエリ数が増えてもコストが線形に増えない様に実際負荷が上がればコストは上がるけど AWS で完結する様にして、クエリレイテンシを下げ、アドホッククエリに対応する MySQL やAurora 、その他のデータストアに接続できるので、それらを組み合わせることができる

Slide 24

Slide 24 text

Presto とは Facebook が開発した分散SQL クエリエンジン。 Presto ⾃体はデータストアを持っていない。コーディネータがSQL を解釈し、様々なデータストアに対するコネクタがデータストアに合わせたリクエストに変換し並列でクエリを⾏う。最も良く使うのはhive connector で、Apache Hive のメタデータを利⽤してHDFS やS3 に並列でアクセスし⾼速にSQL を利⽤したSELECT が可能。複数のデータストアのテーブルをJOIN することもできる。

Slide 25

Slide 25 text

Hive とEmbulk によるデータ変換 Bigquery で集計したデータをEmbulk でS3 に転送 fluentd でS3 に蓄積したデータと合わせてHive でParquet に変換 Presto でクエリして柔軟な条件によるセグメンテーションを実現

Slide 26

Slide 26 text

Apache Parquet とはカラムナー( 列指向) フォーマットの⼀つ。 Google がBigquery ⽤に開発したDremel というフォーマットの論⽂を元にしている。似たフォーマットとしてORC がある。

Slide 27

Slide 27 text

カラムナフォマットのイメジ

Slide 28

Slide 28 text

なぜ列指向なのか⼤量のデータを抽出したり集計したりする時は、⾏ではなく列単位でデータを持っていた⽅が効率的に扱える。圧縮効率とか、特定カラムを全取得する場合等に有効

Slide 29

Slide 29 text

Presto 採⽤後の構造

Slide 30

Slide 30 text

Presto でも解決できなかったこと Parquet 変換にバッチが必要抽出条件に引っかかる様になるまでに時間がかかる更新が発⽣するデータの扱いが⾯倒基本追記オンリーなので重複排除等が必要 MySQL では読み書きのスケーラビリティが厳しい Presto で⼤量にデータ取得するとクソ遅い

Slide 31

Slide 31 text

Cassandra を採⽤する DynamoDB の論⽂を参考にしているNoSQL で完全な⾮中央集権構造が特徴。 Presto で元々サポートしている書き込みスケールしやすい⼤量に読み込むのは得意ではない台数がある程度あればMySQL よりはマシ実験してみてしばらく持つだろうと判断

Slide 32

Slide 32 text

Cassandra 採⽤後の構造

Slide 33

Slide 33 text

Presto & Cassandra & S3 リアルタイムで更新したいデータをワーカーで直接Cassandra に書き込む集計が必要なデータはBigquery で集計, S3 に転送しParquet に変換する Presto でCassandra のデータとParquet on S3 のデータを組み合わせるほとんどの規模の顧客のデータは1 分以内で返答可能数百万を越える規模のユーザ数でも数分以内に。

Slide 34

Slide 34 text

Cassandra でも解決できなかったこと余りにもデータ量が多いと読み込みクエリ負荷に耐えられないそのため⼀部のデータはリアルタイムに反映したいが対応できていない読み込み時のCPU 負荷が⾼いコストとスケールのバランスを⾒極める必要がある

Slide 35

Slide 35 text

未来のユーザーセグメンテーション Apache Kafka を導⼊データ取得効率を上げるためのクエリ最適化 Cassandra -> Apache Kudu? Apache Kudu ⾼速なデータの挿⼊・更新と列指向の参照を組み合わせた分散DB 最近、Presto も公式サポートした。熱い。

Slide 36

Slide 36 text

妄想上の構造

Slide 37

Slide 37 text

その他の課題マイクロサービス化サービスディスカバリスキーマ管理秘匿情報管理V2 ⾊々とやらねばならないことが。

Slide 38

Slide 38 text

こういう仕事がしてみたいという⽅絶賛募集中です！！ https://www.wantedly.com/projects/102039 https://www.wantedly.com/projects/44097