ZOZOTOWNのDWHをRedshiftからBigQueryにお
引越しした話とその後の話
株式会社ZOZOテクノロジーズ 開発部
塩崎健弘
株式会社ZOZOテクノロジーズ 開発部
塩崎 健弘
新卒で(株)VASILYに入社後、M&Aを経てZOZOテクノロジー
ズへ。最近のお仕事はデータ基盤の整理とか、メール・プッ
シュ配信基盤の整理とか。毎日エビオス飲んでます。
© ZOZO Technologies, Inc. https://zozo.jp/ ・ 日本最大級のファッションショッピングサイト / アプリ ・ 1,200以上のショップ、7,000以上のブランドの取り扱い （2019年3月末時点） ・ 常時73万点以上の商品アイテム数と毎日平均3,200点以上の新着 商 品を掲載 ・ 即日配送サービス ・ ギフトラッピングサービス ・ ツケ払い など 3
https://wear.jp/
・ 日本最大級のファッションコーディネートアプリ
・ 1,300万ダウンロード突破、コーディネート投稿総数は900万件 以上（ともに2019年5月末時点）
・ 全世界（App Store / Google Playが利用可能な全ての国）で ダウンロードが可能
© ZOZO Technologies, Inc. https://zozo.jp/pb/ ・ 「ZOZOSUIT」で計測した体型データをもとに、一人ひとりの 体型に合った「あなたサイズ」のアイテム ・「 究極のフィット感」を実現したベーシックアイテムを提供 ・ アイテム : Ｔシャツ / デニムパンツ / シャツ / ビジネススーツ / ネクタイ / ボーダーＴシャツ / 長袖クルーネックＴシャツ など 5
https://zozo.jp/zozosuit/ ・ 独自に開発した採寸用ボディースーツ ・ 全体に施されたドットマーカーをスマートフォンカメラで360度 撮影することで、体型データを計測 ・ 計測した体型データは、瞬時に3Dモデル化され、ZOZOTOWN アプリに保存。3Dモデルはあらゆる角度に動かすことができ、 体型を360度チェックすることが可能
© ZOZO Technologies, Inc. 7
目次
● デブサミで発表しました ○ Redshift時代のシステムの紹介 ○ 運用上の辛み ○ どう移行したか ○ インフラ紹介 ○ BigQueryでの問題とその対処 ● 移行後の継続的改善 ○ パッチワーク化したシステムの統合 ○ ETL→ELT ○ データ転送基盤のGCP移行 ○ Cloud Dataflowを使ったフルマネージドな構成 ○ オンプレ環境のDWHの移行 ● 今なら使える、引越し当時に欲しかった便利機能○ BigQuery Data Transfer Service ○ Google SheetsをExternal Tableに ○ Scheduled Query
デブサミで発表しました
ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話
© ZOZO Technologies, Inc.
「ZOZOTOWN DWH」でGoogle検索
9 https://speakerdeck.com/shiozaki/moving-zozotown-dwh-from-redshift-to-bigqueryデブサミのおさらい
© ZOZO Technologies, Inc.
Redshift時代のデータフロー図
11 OnPrem DBs
S3
Talend Open Studio で転送 Redshift Data Pileline DataLake DataWarehouse ・S3→Redshiftのデータ転送 ・その後の集計クエリの実行
当時S3・Redshiftに入れていたデータ
● ZOZOTOWNやWEARのマスタデータ
○ ユーザー情報 ○ 商品情報
○ 注文情報
● Google Analytics 360から取得したアクセスログ(Web・ネイティブアプリ)
● メールやプッシュの配信ログ
● 総テーブル数 > 100
● 総データサイズ > 10TB
BigQuery移行後は両方とも桁1つ分増えたけど、運 用コストはほぼ変化なし
© ZOZO Technologies, Inc.
Redshift時代のつらみ
13● 自分たちで管理する必要のあるものが多い
○ ノード数 ○ Distribution Key ○ Sort Key ○ ストレージの空き容量 ○ インデックスタイプ● これらをチューニングするノウハウが少なかった
● 各種の設定がコードベースで管理されていなかった
(これは完全に自分たちのせい) ※Redshiftが悪いというわけではなく、自分たちの使い方に合っていなかっただけどう移行したのか
OnPrem DBs
S3
Talend Open Studioで 転送
© ZOZO Technologies, Inc.
使用したツール紹介
15● Embulk
○ Treasure Data製のOSS ○ ETLツール ○ データの入力・加工・出力をする部分はプラグインとして提供 ○ 設定ファイルはYAMLで書かれている● Digdag
○ Treasure Data製のOSS ○ ワークフローエンジン ○ 大量のEmbulkのジョブを効率的に管理 ○ 設定ファイルはほぼYAMLで書かれている ○ シンプルな記法は好みが分かれる(個人的には好き)移行当時のインフラ紹介
OnPrem DBs Direct Connect S3 Talend Open Studio ・・・ Digdag Embulk GCS BigQuery© ZOZO Technologies, Inc.
BigQueryでの問題とその対処
17● データ保存料金跳ね上がり
○ 過去分のテーブルのスナップショットを長期間保存していた ○ 古すぎるスナップショットを自動削除するバッチを作成 ○ テーブル作成時に自動削除の設定をするほうがスマート [1]● クエリ料金跳ね上がり
○ 非常に縦長なログをスキャンしたら、数TBをスキャンしてしまった ○ partitioned tableの採用で対応 [2]● 本番に出すまで落ちるかどうか分からないクエリ
○ CircleCIでdry runすることでマージする前に気付けるように[1] BigQuery best practices: Optimizing storage (https://cloud.google.com/bigquery/docs/best-practices-storage)
色々大変だったけど、BigQueryにデータが揃いました。
めでたしめでたし。
© ZOZO Technologies, Inc.
色々大変だったけど、BigQueryにデータが揃いました。
めでたしめでたし。
俺たちの戦いはこれからだ！！
● BigQueryにデータを入れた「だけ」では何も価値を生み出さない
● データが揃ってからが本番
● AIなどの分野へのデータ活用
○ ZOZO画像検索でのMLOps実践とGKEインフラ アーキテクチャ [1] ○ 2019/08/26 類似アイテム検索機能のリリース [2]● データパイプラインを更に使いやすく(今回の話は主にこちら)
○ 速い・安い・安定を目指してデータパイプラインのアーキテクチャ改善 [1] https://techblog.zozo.com/entry/cloudnext19tokyo-imagesearch [2] https://press-tech.zozo.com/entry/20190826_zozotown© ZOZO Technologies, Inc. 21
AIなどの分野への活用
移行後の継続的な改善 (まだ道半ば)
● パッチワーク化したシステムの統合
● ETL→ELT
● オンプレで行っている集計処理のオフロード
● ETL基盤のインフラ移行
● Cloud Dataflowを使ってフルマネージド
© ZOZO Technologies, Inc. ● 3つのワークフロー・4つのチームに跨ったデータ連携処理 ● システムの継ぎ足しを重ねた結果のアーキテクチャ ● 基幹DBのテーブルをBigQueryに追加するまでの手続きが長い ● 障害時のリカバリー範囲がチームを跨る
パッチワーク化したシステムの統合
23 基幹DB 中間DB S3 BigQuery● 2つのワークフロー・1つのチームになるまでシステム統合済み
● 既存のワークフローとは別のワークフローを作りBigQueryで全件突合
● BigQueryの新しい機能を使いたい気持ちを抑えて、地道な改善を積み重ねた
© ZOZO Technologies, Inc.
ETL→ELT
25 ● ワークフロー統合の結果、いろんな箇所にあった変換処理(ETLのT)が一箇所に集まる ● いろんなツールが暗黙的にやっていた変換処理を再実装する必要が出た ○ 特殊文字の削除 ○ タイムスタンプのミリ秒切り捨て ● Embulkのfilter処理をすべてBigQuery側にオフロードして、処理の高速化をしたい Embulkが変換処理を実行 Embulkは変換処理をしない BigQueryが変換処理を実行 ETL ELTデータ転送基盤のGCP移行
● AWS→GCPのデータ転送コストがもったいない (約100USD / TB) ● AWSと同等のDigdagクラスターをGCPにも作成 ○ EC2→GCE、RDS→CloudSQL ● Google Interconnectでオンプレ・GCP間の専用線を用意 OnPrem 無駄な転送コスト© ZOZO Technologies, Inc.
Cloud Dataflowを使ったフルマネージドな構成
27
● Cloud Dataflow = Managed Apache Beam
● 日本で多く出回っている活用例はGCSやPub/Subからの読み出し ○ GCSやPub/SubからのデータをBigQueryにロード
● JDBCドライバーを使って、RDBMSからデータを読み出すことが出来るらしい [1] ● 他のワークフローエンジン(Digdag、Airflowなど)から呼び出すことも出来る
オンプレ環境のDWHの移行
● Redshift導入より前から使われていたDWHがオンプレ環境にある ○ PureData (Netezzaの後継機) ● プッシュ・メルマガなどの配信系のデータマートを作っている ● 保守・管理が辛いので、BigQueryに移行したい ● マイグレーションプロジェクト(2回戦目) ● [TODO: スライド公開時に消す] さっきアラート飛んできた😢
© ZOZO Technologies, Inc.
色々と弊社の事例紹介しましたが、
今も同じ方法を使うべきか？
NO
BigQueryは約週1回の頻度でRelease notesを更新してる
(2019年1月〜8月で35回)
© ZOZO Technologies, Inc.
今なら使える、引越し当時に欲しかった便利機能
31
● BigQuery Data Transfer Service
● Google SheetsをExternal Tableに
● Scheduled Query
BigQuery Data Transfer Service
● 様々なデータソースからBigQueryへのデータ転送を行ってくれるサービス
● S3やRedshiftのデータをBigQueryに転送可能
● 転送速度がやたら速い
○ 実測値で約10Gbps● 活用例
○ S3に保存されているログをAthenaではなくBigQueryで分析 ○ フィジビリティテストのためにRedshiftのデータをBigQueryに転送 ※ S3→インターネットの転送料金によるクラウド破産には注意 Transfer© ZOZO Technologies, Inc.
Google SheetsをExternal Tableに
33
● Google Sheetsに対してBigQueryからクエリを実行できる
● とあるデータをExcelで編集→S3にcsvとしてアップロード→BigQueryに転送している ● Google Sheetsに対して直にクエリを実行できれば運用負荷が下がる
Scheduled Query
● 特定の日時にクエリを自動実行し、結果をテーブルに吐き出し ● 簡単な日次集計ならこれでOK ● マイグレーション初期はいろんなワークフローを作る必要がある ○ 細かいところまで手が回らないので、一旦これで対応するのはあり ● 要件が複雑になったときにはカオスになりそうなので、用法用量を守りましょう© ZOZO Technologies, Inc.
