【TECH BLOG】オンプレDWHをBigQueryに移行した話

はじめに

こんにちは。MA部MA施策・運用改善チームの辻岡です。MA部では、ZOZOTOWNのメルマガ・アプリPUSH通知などの配信・分析等の用途で約数十TBのデータを運用しています。今回は長年MAのデータ基盤として利用してきたオンプレDWHをBigQueryに移行したおはなしをします。

この記事はこんな方におすすめ

オンプレDWHからBigQuery移行を検討・実施してる方
ジョブ・スケジューラ、ETLツールの移行を検討・実施してる方

概要

オンプレDWHからBigQuery移行する前後の構成イメージを元に、今回の移行の話について概要を説明します。

次の図が移行前の構成図です。オンプレ環境のWindowsサーバ上でジョブ・スケジューリングと実行を基盤処理として、データウェアハウス（以後オンプレDWH）に対してデータ生成や外部システムとの連携をしていました。

今回、以下を目的にオンプレDWHを廃止してBigQueryにデータを集約しました。

分析効率化
更なる発展性の向上
オンプレDWHの運用負荷を下げる

その後、移行スコープを検討した結果、オンプレDWHの移行だけではなくオンプレDWHに直接関連するオンプレWindowsサーバ上の処理全てをGCPへ移行することにしました。

既存のオンプレ基盤処理のままオンプレDWHだけ移行した場合、BigQueryへの接続すら既存のライブラリでは困難な状態でした。よって、オンプレDWHの移行だけではなくオンプレ基盤処理を一緒に移行する方が、安全かつ効率的に移行できると考えました。そこで、以下のように移行を進めることにしました。

移行した結果がこちらです。2022年1月に移行しました。

なんということでしょう。オンプレDWHをBigQueryに移行するだけでなく、オンプレ環境をまるっとGCPに移すことでとてもシンプルな構成に様変わりしました。

次は、移行前の課題と解決策についてお話しします。

オンプレDWHについて

オンプレDWHはメルマガなど各種配信用のデータやその実績データを格納しており、約10年もの間MAのデータ基盤として利用されてきました。

課題

オンプレDWHでは、社内外含めて当該DWHに関する情報不足かつ独特な運用のため、保守・運用負荷が高い状態でした。さらにクエリの並行数には制限があるため、分析者が気軽にDWHにクエリを実行できない課題がありました。

解決策：BigQueryへ移行

そこで、移行先としてBigQueryを選択しました。著名かつクエリの並列実行が可能な数も（slot数に応じた遅延はあれど）いくらでも増やせるBigQueryは先の課題を解決してくれます。また、全体的なデータ基盤として既にBigQueryが採用されていたため、BigQueryへデータ集約することにしました。

オンプレ基盤処理について

オンプレDWHをメインのデータソースとする基盤処理がありました。基盤処理は、Javaを使ったSQLの実行処理やメール配信SaaSへのリクエスト、ファイル生成処理等をオンプレ環境のWindowsサーバ上で行っていました。

課題

オンプレ基盤処理では、古いバージョンのライブラリを使った処理が複数存在し、環境に関しても開発と本番で分離がされていませんでした。また既存のオンプレWindows環境を含めて知見者も不足している状態でした。この基盤でBigQueryへ移行すると接続方法ですらボトルネックになり、開発効率も下げるリスクがありました。さらに、オンプレ環境への接続都合により、リリース時は必ず手動でのデプロイ作業が入っていました。

解決策：Digdag on GKEへ移行

課題の解決策として、GKE上に作成したDigdagへ移行することを選択しました。オンプレ基盤処理でも既にワークフローツールが使われており、既存の基盤をやめるにしても類似の機能が必要でした。MAでは既に別の処理でDigdagを利用しており運用経験や知見が豊富だったこともあり、Digdag on GKEという統一したバッチ処理基盤を作ることにしました。

クラウド移行する場合GCPを使うことは予め決まっていたのですが、GKEを使う事でよりスケールが楽な状態になりました。

例えば、ファイル連携処理の中でそれなりに大きいファイルの文字コード変換や加工によってリソースを消費する処理がありました。ですが、KubernetesCommandExecutorのおかげで他のtaskへの影響はなく、taskに対してpodのリソース設定するだけで問題なく実装できました。他にもたくさん恩恵を受けていますので以下のテックブログをぜひご覧ください。

楽々スケール Digdag on GKE Autopilot の紹介とその運用Tips - ZOZO TECH BLOG

こんにちは、MA基盤チームの田島です。私達のチームでは複数のワークフローエンジンを利用し、メールやLINEなどへの配信を含むバッチ処理を行っていました。今回それらのワークフローエンジンをすべてDigdagに統一しました。そして実行環境としてGKEのAutopilot環境を選択したことにより、柔軟にスケールするバッチ処理基盤を実現しましたのでそれについて紹介します。 ...

https://techblog.zozo.com/entry/digdag-on-gke-autopilot

また、GitHub Actionsを利用してリリースを自動化しました。