Google Cloudデータ基盤 構成管理の反省と改善

2024年4月に行われたKDDI・Supershipによる勉強会にて、Supership プロダクト開発本部 アドテクノロジーセンターの今村が講演した際のスライドです。

Supershipでは一緒に働くSuperな仲間を大募集中です！募集職種など採用情報は下記よりご参照ください。
https://supership.jp/recruit/

■講演タイトル：
Google Cloudデータ基盤 構成管理の反省と改善
■アジェンダ：
「ScaleOut DSP」におけるデータ基盤を、オンプレでの運用からGoogle Cloudを用いた運用へ移行する際の課題や改善策をスケーラビリティやアクセス管理などの観点からお話しします。
■登壇者：
Supership プロダクト開発本部 アドテクノロジーセンター
今村 豊

Transcript

1. Google Cloud データ基盤 構成管理の反省と改善 2024.04.11 1
2. 自己紹介 今村 豊 (いまむら ゆたか) Supership プロダクト開発本部 アドテクノロジーセンター ScaleOut DSP のデータ基盤や広告配信基盤の SRE 業務など浅く広く担当しています。 2
3. 話したいこと Terraform でデータ基盤の構成を管理する時は、、、 state を分割して管理すること。 開発時の素早いフィードバックを得ることができる。 Terragrunt で統合して運用すること。 分割した state の依存性を宣言的にまとめて運用できる。 3
4. データ基盤の構成管理 データ基盤を構成管理する場合、以下の要求に答えた構成管 理手法を設計する必要がある。 1. オブジェクト管理のスケーラビリティ 2. 分類の一貫性 3. アクセス管理の複雑性 4
5. オブジェクト管理のスケーラビリティ データは増える。テーブル、ビューはニーズの増加とともに増えやすい。 この増加に対して IaC の開発スピードを落とさないようにしたい。 DWH 要求1 5 DWH 6ヶ月後
6. 要求2 分類の一貫性 テーブルやビューなどの大量のオブジェクトをグループ化して整理し把握するためにラベルやタグといっ た機構を用いる。 ラベルやタグを一貫したポリシーによって付与できる必要がある。 6 DWH データオーナー データスチュワード 生成元プロダクト 機密レベル etc. ラベル付与
7. 要求3 アクセス管理の複雑性 データと利用者の関係は多対多。 この関係に対して権限を割り当てるため関連付けは複雑化しやすい。 7 管理者権限 参照権限 参照権限 編集権限
8. オンプレデータ基盤 8
9. オンプレデータ基盤の課題 ScaleOut DSP 広告配信ログとユーザ情報を格納した Hadoop 基盤 実データ 約 2.5 PB 各種中間データを含めると約 450 件ほど の Hive テーブルを収容している。 9
10. オンプレデータ基盤の課題 デプロイは bash スクリプトなどを使って開発者のマシンから実行 • 独自の bash スクリプト。 • ローカルから手動実行。 • デプロイログはローカルに残るのみ。 • Slackにログをコピペして共有する。 • ローカルに unstaged changes があると余計な差分が入る。 10 SFTP でジョブサーバにファイル転送 スクリプト実行
11. オンプレデータ基盤の課題 テーブル定義は全てDDLにまとめられている • Hive データベースごとに CREATE DATABASE ~ CREATE TABLE が 1ファイルにまとまっている。 • スキーマ変更は別途 ALTER TABLE する必要がある。 • 手動実行。 11
12. オンプレデータ基盤の評価 1. オブジェクト管理のスケーラビリティ: ✗ DDL を手動で実行するため大量のオブジェクトを管理・開発するには限界がある。 手動のためミスも起きやすい。 2. 分類の一貫性: ✗ 個別のテーブルやビューの DDL をベタ書きで管理しており、一貫したポリシーを各オブジェクトに反映 させる手段がない。 3. アクセス管理の複雑性: ✗ HDFS レベルのディレクトリアクセス権限が手動で付与されているのみ。 一覧性もなく現状の把握が難しい。 12
13. Google Cloud 移行 13
14. Terraform の導入 14 Google Cloud 上の構成には Terraform を用いる方針とした。 大きな機能のまとまり＆変更サイクルの違いごとに terraform state ( 以降 state ) を分離した。 サービスアカウント構成 データセット構成 パイプライン構成 IAM Cloud Storage BigQuery Dataproc Cloud Composer
15. オンプレ問題の改善 パイプラインの実装は bash スクリプトを使って開発者のマシンから実行 ↓ Terraform + GitHub Actions + Cloud Composer GitHub Actions から terraform apply で ETL 用のワークフロー定義やクエリファイルを GCS bucket に アップロード。すると Cloud Composer の Airflow 環境に同期される。 15 Cloud Composer Cloud Storage 実行 パイプライン ファイルアップロード アップロードファイル 同期 一気にモダナイズが進んだ！
16. オンプレ問題の改善 テーブル定義は全て DDL にまとめられている ↓ テーブル別に YAML ファイルを作り各種メタデータを記載 • テーブルやビューを全て YAML ファイルとして定義することでデータとして扱えるように。 • YAML ファイルを入力とした terraform モジュールが個別の Hive DDL ファイルを GCS Bucket に 出力し、一方で BigQuery の外部テーブルを定義する。 16 YAML Cloud Storage BigQuery 設定データ読み込み DDL ファイル アップロード 外部テーブル作成 Hive テーブルを BigQuery からも参照で きるように。
17. YAMLファイル定義例 • 基本的なメタデータを記述。 • Hive DDL はそのままテキスト データとして扱う。 テーブルの分類に必要なラベルやそ の他の設定情報などを DDL と合わ せて記述・管理できるようにはなっ た。 が、Hive DDL はそのままベタ書 き。。。 17 kind: Entry type: HiveTable name: test_table database: test_database bigquery_table: { enabled: false } ddl: | CREATE TABLE `test_database.test_table`( `id` integer, `name` string) ここに DDL をそのまま書いている。 テーブルの構造を他のプログラムから解 析しにくい。
18. 残課題 Terraform で Hive テーブルのス キーマを差分更新することはできな い あくまでも DDL を YAML の中に埋め込んでいるだけなので、 カラムの追加削除を Terraform として認識できない。 Terraform で生成した DDL ファイルを Dataproc ジョブで実 行するのみ。 terraform plan/apply が遅い Terraform で管理される 450 テーブルが 1 つの state に記録 される。 terraform plan だけで 29 秒。。。 18
19. ScaleOut Google Cloud データ基盤の評価 1. オブジェクト管理のスケーラビリティ: △ Terraform によりデータをまとめて管理できるようになったが、terraform plan がデータの増加ととも に徐々に遅くなる。 2. 分類の一貫性: ✗ 実質 Hive DDL をベタ書きした運用はそのまま残っておりオンプレと根本的な変化はない。 YAML によって多少のメタデータを管理可能にはなったものの。。。 3. アクセス管理の複雑性: △ Hive テーブルのデータが配置されたGCS bucketレベルの IAM 制御を行えるようにはなった。 が、Hive データベースや Hive テーブルなどの論理的な単位に対する制御は未だできず。 19
20. 新規データ基盤 20
21. 新規データ基盤 たまたま機会があって別の広告配信プラットフォームのデータ基盤の初期構築に携わった。 ScaleOut で未解決だった前述の課題の解法を小規模に試せ るチャンス！ 21
22. 新規データ基盤における改善 Terraform で Hive テーブルのスキーマを差分更新することはできない ↓ BigQuery をメイン DWH にする Terraform で BigQuery データセット、テーブル、ビューを自然に構成できる。 クラウド DWH の恩恵を最大限に享受できる。 Google Cloud 上で Hive ベースのデータ管理を大規模かつ円滑に行うのはやはり難しいと痛感。 オンプレの Hadoop 基盤をクラウドに移行する場合は必ず移行先クラウドのメイン DWH への移行も計画 ＆事前検証することを推奨。 22
23. 新規データ基盤における改善 terraform plan/apply が遅い ↓ state を細分化 state を BigQuery データセットごとに分割するようにした。 • 変更の影響範囲を局所化できる。 • state が小さいので開発時の terraform plan が高速化しフィードバックが素早く得られる。 23 VPCネットワーク Cloud Composer BigQuery データセットA BigQuery データセットB BigQuery データセットC サービスアカウント
24. 新たな課題 state を細分化することによる弊害もある。 細分化された state 同士の依存関係をケアしながら Terraform 運用をする必要がある。 これを解決するために Terragrunt を導入した。 24
25. Terragrunt 機能＆効用 Terragrunt は Terraform のラッパーとして動作し以下のようなユースケースをサポートする。 • 分割された state 同士の依存関係を設定として記述する。 • 分割された state の依存関係をもとにまとめて terraform 操作が行える。 • 分割された state に繰り返し定義が必要な設定内容を集約定義してスッキリ書ける。 (Don’t Repeat Yourself) Terragrunt の導入により state を細分化したことのデメリットを極小化できるようになった。 25 dependency "vpc_network" { config_path = "../vpc_network" } include "root" { path = find_in_parent_folders() } 依存関係を HCL で記述 terraform の周辺設定を include して再利用
26. 新データ基盤の評価 1. オブジェクト管理のスケーラビリティ: ◯ state を分離したことで開発時の Terraform 操作は高速化。 2. 分類の一貫性: ◯ BigQuery オブジェクトに対して Terraform から一貫した分類ラベル (タグ) を付与できるようになっ た。 3. アクセス管理の複雑性: △ BigQuery IAM 機能を使って Terraform からまとめて管理できた。 ただしデータセット別に state が分かれているために一覧性はよくない。 26
27. 残った課題 とにかく Google Cloud に移行した ScaleOut データ基盤をなんとかしたい。 • ScaleOut の Google Cloud へ Terragrunt の運用知見をフィードバック。 • ScaleOut も早く BigQuery メインへ移行する。 • アクセス制御の棚卸しを円滑にするための仕組みづくり。(一覧性を補完) 27
28. まとめ Google Cloud でデータ基盤構築するのは、 (あたりまえだが) やはり BigQuery 無しでは厳しい。 しかしそこさえクリアすれば、 • Terraform • Terragrunt といった IaC ツールを駆使することで大規模データ管理を達成しつつ円滑な運用 が可能になる。 28
29. EoP 29