はじめに
こんにちは、atama plus 株式会社でデータエンジニアをしている kumewata です。
先日弊社で利用するデータ基盤のリアーキテクチャを行い、データ転送とオーケストレーションサービスの移行を実施しました。
今回は移行を進める中で工夫した点や、学んだ点について紹介します。
こんな人向け
- データ基盤の移行を検討している方
- Dataform の複数環境化を検討している方
データ基盤移行の背景
弊社では今までデータ転送基盤として TROCCO を利用してきましたが、分析環境が成長するにつれていくつかの課題が浮き彫りになってきました。特に、 データ転送処理やデータマートへの変換がコード管理できないことに対する負が大きくなってきました。また OLAP（Online Analytical Processing：オンライン分析処理）的な利用や機械学習への転用の話が出てき始め、データ基盤自体の開発環境の必要が増してきました。
これらの課題を解消するためいくつかのサービスを比較検討し、最終的には Kafka と Datastream の 2 つを移行先候補として絞り込みました。Kafka は高いスループットとリアルタイム処理が特徴ですが、設定が複雑で保守コストが高いというデメリットがありました。一方、Datastream は Google Cloud のマネージドサービスで、設定が簡単でスケーラビリティが高い点が魅力でした。
設定の簡単さと Google Cloud の他のサービスとの統合の容易さを決め手として、最終的に Datastream を採用すること決めました。
弊社のデータ基盤の変遷について、atama plus データ基盤アーキテクチャと利活用推進の歴史でより詳しく紹介しています。もしよければ読んでいただけると幸いです。
データ基盤移行前後の変更点
移行前は TROCCO でアプリケーション DB から BigQuery 上のデータレイク層へ転送した後、Dataform でウェアハウス/マート層への変換を行なっていました。
移行前（TROCCO 利用）
移行後は Datastream からミラー層を挟んだ後、Dataform でデータレイク/ウェアハウス/マート層への変換を行ないます。TROCCO と Datastream の間で生まれる転送後のスキーマ差分を吸収するためミラー層を設け、データレイク層の差分を吸収する処理を Dataform に任せました。
分析基盤のアウトプットがビジネスクリティカルな用途で使われている背景があり、Datastream への移行後もユーザーのクエリに変更が不要になることを重視しました。
移行後（Datastream 利用）
基盤を移行する準備
Datastream を導入する前準備として、既存のデータパイプラインの現状を把握することから始めました。今回はデータ転送部分の置き換えを行うため、特に既存データレイクや前後の接続処理について念入りに調査、検証を進めました。
変換処理の設計
事前検証のため開発環境に本番データをコピーした DB を用意し、実際のデータを用いて検証しました。変換処理の設計においては、まず TROCCO による転送パターンを洗い出し、全 6 パターン（全件洗い替え追記型、シャーディングテーブルの統合型、など）に対応する必要があることがわかりました。各パターンに対して適切なテーブル作成処理を導入し、型の不整合や不要なカラムの除去・変換など、途中で発見した課題を解決しました。
特に工夫した点として、TROCCO では複数ステップで実現していた転送処理を紐解き、Dataform でできるだけ 1 ステップの処理に置き換えました。これにより、移行の複雑さを軽減できました。変換処理の最適化は今後の課題としています。
スキーマ差分の洗い出し
TROCCO がデータレイク層に転送する全テーブルのカラムを比較し、Datastream の転送データと比較しました。この過程で、INTERVAL 型、JSON 型、DATE 型でのカラム型差分に対応し、不要なカラムやテーブルの除去も行いました。
この作業では INFORMATION_SCHEMA とスプレッドシートを活用して大半のテーブルに対して効率的に進めることができました。しかし一部のテーブルについては過去経緯を掘り下げた上での判断が必要なことがあり、こちらの調査検討の方に時間がかかりました。
ウェアハウス/マート用 Dataform 環境の前準備（既存リポジトリ）
移行に向けた前準備として、クエリがデフォルト設定の Google プロジェクトやデータセットを使うようにリファクタリングと修正を行いました。これによりオーケストレーションツール側で Dataform 処理の実行環境や対象リソースを切り替えられるようになり、データパイプラインが複数環境に対応できるようになりました。
移行がスムーズに進むよう、切り替えポイントを集約してワークフローの実行時に制御できるようにしました。これにより、移行当日にやるべき作業量を減らすことができました。
補足）Dataform では dataform.json という設定ファイルを元にデフォルトの対象リソースを指定できます。クエリ上で Google プロジェクトやデータセットを指定しなくても、デフォルト値をもとに対象リソースを解決してくれます。
# dataform.json の内容
{
"defaultSchema": "warehouse",
"assertionSchema": "dataform_assertions",
"warehouse": "bigquery",
"defaultDatabase": "google_project_id",
"defaultLocation": "US",
"vars": { // 切り替え用の変数
"defaultRawSchema": "...",
"isRawStreamedByDatastream": "true"
}
}
# 今回のデフォルト設定の場合、
# sqlx/js ファイル上のクエリで ref("hoge_table_name")と指定すると、
# コンパイル時に google_project_id.warehouse.hoge_table_name のように解決してくれる。
ミラーからデータレイクへの変換用 Dataform 環境を用意（新規リポジトリ）
TROCCO で転送していた全てのテーブルに対応する設定ファイルを作成し、こちらでも複数環境に対応しました。ファイルは基本的にスクリプトで自動生成し、個別対応のみ手動で実施しました。
前述したスキーマ差分チェックプロセスを流用し、導入後の Dataform 処理後の差分チェックも効率的に進めることができました。
移行方式検討
データレイクの利用者への影響を最小限にするため、移行をストラングラーフィグパターンに近い方式で進めることにしました。具体的には、並行稼働フェーズ、移行フェーズ、掃除フェーズに分けて進行しました。
フェーズごとの移行プロセスを示すフロー図。バックアッププランも用意
各フェーズごとに疑問や課題を洗い出し、検証や対応方針を決定しました。このタイミングで当日の移行に向けてコミュニケーションをとるべきステークホルダーも洗い出し、大まかなスケジュールと段取りを決めました。
参考：システム移行戦略「レガシーミミックパターン」＆「ストラングラーフィグパターン」とは？
ステークホルダーとのすり合わせ
BigQuery の利用状況を鑑み、ステークホルダーのごとに共有したい情報をドキュメント化して、背景共有とリスク確認を実施しました。各所から出た疑問点と回答も同じドキュメントに集約して残しました。
特にビジネスインパクトの大きい業務に対して、利用状況を考慮し、実施日を決定しました。また、移行前後で対象業務で使うクエリの実行結果チェックも行いました。
移行当日
以上のような準備を進め満を辞して移行日を迎えましたが、切り替え前のバックアップ（bq copy）が終わらないという問題が発生しました。見積もりしたところバックアップが一定のペースで進んだ場合、完了までに 17 時間かかることがわかりました（実際にテーブルサイズによらず安定して bq copy が進みました）。
そのため急遽計画を変更し、移行ステップを組み替えて遅延を抑制するように対応しました。ステークホルダーにも早めに状況共有し、即時業務調整をしていただきました。
翌日にはバックアップも終わり、移行作業に進むことができました。前準備の成果もあり、その後の作業はスムーズに終了しました。
後日談
移行後、データの不整合を発見してくれた営業メンバーがいました。出力したデータに違和感を覚え、クエリから原因を特定してレポートを上げてくれました。このおかげで移行作業に抜け漏れがあったことがわかり、助かりました。
また、Datastream の転送コストが思ったよりも高かったため、BigQuery のテーブル更新頻度（max_staleness）を最大遅延 15 分から 60 分に変更することになりました。
この値は Datastream の data_freshness (コンソール上では Staleness limit) で設定した値が入るのですが、作成済みテーブルの更新は直接 BigQuery 側で行う必要があるため注意が必要です。
この変更でコストを下げることができましたが、まだ削減余地があり今後の課題としています。
コスト削減対応前後のトレンド
まとめ
今回の移行プロジェクトはいくつかの課題と向き合いつつ、移行における利用者への影響を小さく抑えることができました。
個人的に初めてのデータ基盤移行でしたが、実施当日よりも前準備が重要で多岐に渡ること、作業を効率化した上で一部調査検討に時間がかかること、移行の影響を最小化するためのステークホルダーとの調整の進め方、など多くの学びがありました。
また移行で TROCCO の転送設定管理が Dataform でのコード管理に替わり、データ基盤更新のセルフサービス化が進みました。
プロダクトチームからデータ基盤へ新しいテーブル追加するハードルが下がったとフィードバックをいただけました。
今後は他プロダクトへの横展開や、まだ組み込めていない処理もワークフローに含めることで、一貫したパイプラインの安定性を目指します。
さらに、転送コストの削減にも取り組んでいきます。
最後に、現在 atama plus では多くの職種で採用を行なっております（データエンジニアも！）。
新しいサービスも立ち上がっているので一緒に盛り上げてくれる方、ぜひお話ししましょう！
Discussion