SnowflakeのCI/CDフローを整備した話 1 クリエイティブサーベイ株式会社 プロダクト本部 開発部 ⼤澤 秀⼀ 2024.05.08 GENBA #3 〜DREの現場〜

⼤澤 秀⼀（Ohsawa Shuichi） 2015年にSansan株式会社へ⼊社、 名刺データ化システムのインフラ運⽤、CI/CD基盤の改善、 AWS/GCPのマルチクラウド、クラウドコスト最適化業務に従事。 途中からデータエンジニアチームリーダーとして 全社横断のデータ分析基盤の構築を⾏った後に、 2024年1⽉からグループ会社のクリエイティブサーベイに出向し SREとデータ基盤の両⽅を担当している。 @ohsawa0515 @ohsawa0515 クリエイティブサーベイ株式会社 プロダクト本部 開発部 SRE Amazon Web Servicesコスト最適化⼊⾨ （インプレスR&D）

Confidential © CREATIVE SURVEY 概要 主要株主 許認可 会社概要 会社名：クリエイティブサーベイ株式会社 設 ⽴：2014年7⽉ 代表取締役：⽯野 真吾 Sansan株式会社 、株式会社フォーデジット プライバシーマーク（Pマーク）取得 国際規格ISO27001（ISMS）取得 Salesforce 正規パートナー 2017 Red Herring Asia Top 100 Winners 選出 Confidential © CREATIVE SURVEY 3

Confidential © CREATIVE SURVEY お客様の⽤途や利⽤シーンに合わせて2つの製品ラインナップを提供しています。 あらゆる顧客接点で 営業機会を逃さない 顧客とブランドの つながりを強くする 提供サービス

Confidential © CREATIVE SURVEY ● 背景 ● CI/CDフローの全体構成 ● Terraformのディレクトリ構成や実装について ● まとめ アジェンダ 5

Confidential © CREATIVE SURVEY データ基盤のアーキテクチャ図 6

Confidential © CREATIVE SURVEY 今⽇話す範囲 7

Confidential © CREATIVE SURVEY CI/CDフローのBefore/After 8 ● GitHub Actions（GHA） + Terraformの デプロイパイプラインはできていた（※） ● 課題 ○ 本番環境しかコード化されていない ○ ⼀部のリソースはTerraformに未反映 ○ SnowflakeのGUI‧クエリで変更を加えた後に terraform importする運⽤ ● 少⼈数での運⽤なので問題なかったが、 データエンジニア以外のエンジニアも データ基盤に変更を加える可能性がある ※ Github Actions + Terraformを使ったSnowflakeリソース管理のCI/CDパイプラインの構築（Zenn） ● 本番/ステージング/開発環境をコード管理 ● 本番/ステージング環境はGHAからterraform apply ● Terraformへのインポートとリファクタリング ○ Terraform管理されていないリソースはimport ○ 複数環境に対応するためTerraformモジュール化 ● CI部分を強化 ○ GitHub Pull Request（PR）作成時に 本番/ステージング環境にterraform plan ○ plan結果をPRコメントに記載 Before After

Confidential © CREATIVE SURVEY CI/CDフロー 〜開発〜 9 ● Snowflakeは本番/ステージング/開発の3環境 ○ 開発環境は開発者が⾃由に変更を加えることができる ○ Role/WarehouseはTerraformによる管理 ● AWSは本番/ステージングの2環境 ● mainブランチへのPR作成後 ○ AWS‧Snowflakeの本番/ステージング環境に terraform plan ○ plan結果がPRコメントに記載 ● PRマージ後、AWS‧Snowflakeステージング環境にapply

Confidential © CREATIVE SURVEY CI/CDフロー 〜リリース〜 10 ● GitHubのリリース機能を利⽤ ○ 新しいリリースのバージョン番号のタグを作成、 Publish ○ リリースノートとしてリリース履歴が残る ● AWS‧Snowflake本番環境にterraform apply

Confidential © CREATIVE SURVEY Terraformのディレクトリ構成や実装について 11 terraform ├── aws │ ├── modules │ │ ├── apigateway │ │ …… │ ├── prod │ └── stg └── snowflake ├── modules │ ├── database │ │ ├── main.tf │ │ ├── outputs.tf │ │ ├── provider.tf │ │ └── variables.tf │ ├── file_format │ ├── procedure │ …… ├── prod │ ├── main.tf │ ├── provider.tf │ └── variables.tf ├── stg └── dev ● terraformディレクトリ以下にAWSとSnowflakeで分ける ● 環境名ディレクトリ(dev/stg/prod)には、環境ごとに異なる設定値やプロバイダを定義 ● modulesディレクトリ以下にリソースを定義している ● Snowflakeではリソース作成時にロール指定が必要なため、エイリアスを利⽤ ● テーブル、ビュー以外のSnowflakeリソースをTerraformで管理 ○ テーブル、ビューはdbt管理 provider "snowflake" { alias = "default" role = "TERRAFORM" warehouse = "TERRAFORM_WH" } provider "snowflake" { alias = "useradmin" role = "USERADMIN" warehouse = "TERRAFORM_WH" } provider "snowflake" { alias = "securityadmin" role = "SECURITYADMIN" warehouse = "TERRAFORM_WH" } provider "snowflake" { alias = "sysadmin" role = "SYSADMIN" warehouse = "TERRAFORM_WH" } # main.tfでモジュール呼び出す処理 module "xxxxxxx" { source = "../modules/xxxxxxx" providers = { snowflake = snowflake.default snowflake.useradmin = snowflake.useradmin snowflake.securityadmin = snowflake.securityadmin snowflake.sysadmin = snowflake.sysadmin } } # モジュール内 resource "snowflake_role" "foo" { # SECURITYADMINロールを指定 provider = snowflake.securityadmin name = "foo" } resource "snowflake_warehouse" "bar" { # SYSADMINロールを指定 provider = snowflake.sysadmin name = "bar" }

Confidential © CREATIVE SURVEY ● クリエイティブサーベイにおけるデータ基盤（AWS/Snowflake）のCI/CDフローを紹介 ● PR作成時にterraform plan結果を記載することでレビューしやすくなる ● リソース変更をGHAに寄せることで、実装者（データエンジニア/開発エンジニア）は強い権限を持たずに 開発できる ● GitHub Releaseにリリース履歴が残っているため、いつ誰がリリースしたのかが分かる 今後 ● CI/CDフローにdbtを組み込む ○ 本番環境しか利⽤できていないため、ステージング環境でも利⽤できるようにする ● ワークフローツールの導⼊ ○ Aurora MySQLからのデータ取り込みとdbt実⾏がひとつのパイプラインで実⾏できるようにする まとめ 12

13