ZOZOTOWNのDWHをRedshiftからBigQueryにお 引越しした話とその後の話 株式会社ZOZOテクノロジーズ 開発部 塩崎健弘 Copyright ZOZO Technologies, Inc.

Transcription

1 ZOZOTOWNのDWHをRedshiftからBigQueryにお 引越しした話とその後の話 株式会社ZOZOテクノロジーズ 開発部 塩崎健弘 Copyright

2 株式会社ZOZOテクノロジーズ 開発部 塩崎 健弘 新卒で(株)VASILYに入社後 M&Aを経てZOZOテクノロジー ズへ 最近のお仕事はデータ基盤の整理とか メール プッ シュ配信基盤の整理とか 毎日エビオス飲んでます 2

3 日本最大級のファッションショッピングサイト / アプリ 1,200以上のショップ 7,000以上のブランドの取り扱い 2019年3月末時点 常時73万点以上の商品アイテム数と毎日平均3,200点以上の新着 商 品を掲載 即日配送サービス ギフトラッピングサービス ツケ払い など 3

4 日本最大級のファッションコーディネートアプリ 1,300万ダウンロード突破 コーディネート投稿総数は900万件 以上 ともに2019年5月末時点 全世界 App Store / Google Playが利用可能な全ての国 で ダウンロードが可能 200万人以上のフォロワーを持つユーザー WEARISTA も誕生 4

5 ZOZOSUIT で計測した体型データをもとに 一人ひとりの 体型に合った あなたサイズ のアイテム 究極のフィット感 を実現したベーシックアイテムを提供 アイテム : Ｔシャツ / デニムパンツ / シャツ / ビジネススーツ / ネクタイ / ボーダーＴシャツ / 長袖クルーネックＴシャツ など 5

6 独自に開発した採寸用ボディースーツ 全体に施されたドットマーカーをスマートフォンカメラで360度 撮影することで 体型データを計測 計測した体型データは 瞬時に3Dモデル化され ZOZOTOWN アプリに保存 3Dモデルはあらゆる角度に動かすことができ 体型を360度チェックすることが可能 6

7 目次 デブサミで発表しました Redshift時代のシステムの紹介 運用上の辛み どう移行したか インフラ紹介 BigQueryでの問題とその対処 移行後の継続的改善 パッチワーク化したシステムの統合 ETL ELT データ転送基盤のGCP移行 Cloud Dataflowを使ったフルマネージドな構成 オンプレ環境のDWHの移行 今なら使える 引越し当時に欲しかった便利機能 BigQuery Data Transfer Service Google SheetsをExternal Tableに Scheduled Query まとめ 7

8 デブサミで発表しました ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話 8

9 ZOZOTOWN DWH でGoogle検索 9

10 デブサミのおさらい Redshift BigQuery 10

11 Redshift時代のデータフロー図 DataWarehouse DataLake OnPrem DBs Talend Open Studio で転送 S3 Redshift Data Pileline S3 Redshiftのデータ転送 その後の集計クエリの実行 11

12 当時S3 Redshiftに入れていたデータ ZOZOTOWNやWEARのマスタデータ ユーザー情報 商品情報 注文情報 Google Analytics 360から取得したアクセスログ(Web ネイティブアプリ) メールやプッシュの配信ログ 総テーブル数 > 100 総データサイズ > 10TB BigQuery移行後は両方とも桁1つ分増えたけど 運 用コストはほぼ変化なし 12

13 Redshift時代のつらみ 自分たちで管理する必要のあるものが多い ノード数 Distribution Key Sort Key ストレージの空き容量 インデックスタイプ これらをチューニングするノウハウが少なかった 各種の設定がコードベースで管理されていなかった (これは完全に自分たちのせい) Redshiftが悪いというわけではなく 自分たちの使い方に合っていなかっただけ 13

14 どう移行したのか OnPrem DBs Talend Open Studioで 転送 S3 Redshift S3のデータを日次でBigQueryに転送 BigQuery 14

15 使用したツール紹介 Embulk Treasure Data製のOSS ETLツール データの入力 加工 出力をする部分はプラグインとして提供 設定ファイルはYAMLで書かれている Digdag Treasure Data製のOSS ワークフローエンジン 大量のEmbulkのジョブを効率的に管理 設定ファイルはほぼYAMLで書かれている シンプルな記法は好みが分かれる(個人的には好き) 15

16 移行当時のインフラ紹介 OnPrem DBs Direct Connect S3 Talend Open Studio GCS Digdag Embulk BigQuery 16

17 BigQueryでの問題とその対処 データ保存料金跳ね上がり 過去分のテーブルのスナップショットを長期間保存していた 古すぎるスナップショットを自動削除するバッチを作成 テーブル作成時に自動削除の設定をするほうがスマート [1] クエリ料金跳ね上がり 非常に縦長なログをスキャンしたら 数TBをスキャンしてしまった partitioned tableの採用で対応 [2] 本番に出すまで落ちるかどうか分からないクエリ CircleCIでdry runすることでマージする前に気付けるように [1] BigQuery best practices: Optimizing storage ( [2] Introduction to partitioned tables ( 17

18 色々大変だったけど BigQueryにデータが揃いました めでたしめでたし 18

19 色々大変だったけど BigQueryにデータが揃いました めでたしめでたし 19

20 俺たちの戦いはこれからだ BigQueryにデータを入れた だけ では何も価値を生み出さない データが揃ってからが本番 AIなどの分野へのデータ活用 ZOZO画像検索でのMLOps実践とGKEインフラ アーキテクチャ [1] 2019/08/26 類似アイテム検索機能のリリース [2] データパイプラインを更に使いやすく(今回の話は主にこちら) 速い 安い 安定を目指してデータパイプラインのアーキテクチャ改善 [1] [2] 20

21 AIなどの分野への活用 先日 画像検索機能をリリースしました 21

22 移行後の継続的な改善 (まだ道半ば) パッチワーク化したシステムの統合 ETL ELT オンプレで行っている集計処理のオフロード ETL基盤のインフラ移行 Cloud Dataflowを使ってフルマネージド 22

23 パッチワーク化したシステムの統合 3つのワークフロー 4つのチームに跨ったデータ連携処理 システムの継ぎ足しを重ねた結果のアーキテクチャ 基幹DBのテーブルをBigQueryに追加するまでの手続きが長い 障害時のリカバリー範囲がチームを跨る 基幹DB 中間DB S3 BigQuery 23

24 パッチワーク化したシステムの統合 2つのワークフロー 1つのチームになるまでシステム統合済み 既存のワークフローとは別のワークフローを作りBigQueryで全件突合 BigQueryの新しい機能を使いたい気持ちを抑えて 地道な改善を積み重ねた 基幹DB 中間DB BigQuery 24

25 ETL ELT ワークフロー統合の結果 いろんな箇所にあった変換処理(ETLのT)が一箇所に集まる いろんなツールが暗黙的にやっていた変換処理を再実装する必要が出た 特殊文字の削除 タイムスタンプのミリ秒切り捨て Embulkのfilter処理をすべてBigQuery側にオフロードして 処理の高速化をしたい Embulkが変換処理を実行 Embulkは変換処理をしない BigQueryが変換処理を実行 ETL ELT 25

26 データ転送基盤のGCP移行 AWS GCPのデータ転送コストがもったいない (約100USD / TB) AWSと同等のDigdagクラスターをGCPにも作成 EC2 GCE RDS CloudSQL Google Interconnectでオンプレ GCP間の専用線を用意 無駄な転送コスト OnPrem 26

27 Cloud Dataflowを使ったフルマネージドな構成 Cloud Dataflow = Managed Apache Beam 日本で多く出回っている活用例はGCSやPub/Subからの読み出し GCSやPub/SubからのデータをBigQueryにロード JDBCドライバーを使って RDBMSからデータを読み出すことが出来るらしい [1] 他のワークフローエンジン(Digdag Airflowなど)から呼び出すことも出来る [1] Java Database Connectivity (JDBC) to BigQuery( 27

28 オンプレ環境のDWHの移行 Redshift導入より前から使われていたDWHがオンプレ環境にある PureData (Netezzaの後継機) プッシュ メルマガなどの配信系のデータマートを作っている 保守 管理が辛いので BigQueryに移行したい マイグレーションプロジェクト(2回戦目) [TODO: スライド公開時に消す] さっきアラート飛んできた 28

29 色々と弊社の事例紹介しましたが 今も同じ方法を使うべきか 29

30 NO BigQueryは約週1回の頻度でRelease notesを更新してる (2019年1月 8月で35回) 30

31 今なら使える 引越し当時に欲しかった便利機能 BigQuery Data Transfer Service Google SheetsをExternal Tableに Scheduled Query 今年に入ってから便利機能が急に増えた気がする 31

32 BigQuery Data Transfer Service 様々なデータソースからBigQueryへのデータ転送を行ってくれるサービス S3やRedshiftのデータをBigQueryに転送可能 転送速度がやたら速い 実測値で約10Gbps 活用例 S3に保存されているログをAthenaではなくBigQueryで分析 フィジビリティテストのためにRedshiftのデータをBigQueryに転送 S3 インターネットの転送料金によるクラウド破産には注意 Transfer 32

33 Google SheetsをExternal Tableに Google Sheetsに対してBigQueryからクエリを実行できる とあるデータをExcelで編集 S3にcsvとしてアップロード BigQueryに転送している Google Sheetsに対して直にクエリを実行できれば運用負荷が下がる 8月のアップデートでクエリを実行できる範囲が広がり 更に使いやすくなった 33

34 Scheduled Query 特定の日時にクエリを自動実行し 結果をテーブルに吐き出し 簡単な日次集計ならこれでOK マイグレーション初期はいろんなワークフローを作る必要がある 細かいところまで手が回らないので 一旦これで対応するのはあり 要件が複雑になったときにはカオスになりそうなので 用法用量を守りましょう 34

35 まとめ RedshiftをBigQueryにマイグレーションしました マイグレーション完了 = BigQuery活用のスタートラインに立っただけ 今マイグレーションするなら 積極的に便利機能を使いましょう BigQueryのポテンシャルを引き出すためにやりたいことがいっぱい 人が足りない 35

36