何をつくるか
dbt Cloudを利用してCICD環境を構築していきます。
DBはSnowflakeを利用します。
Snowflakeのロール設計
Snowflakeのロールの構成は下図の通りです。
Functional Role + Access Role
1. Functional Role + Access Roleとは
公式でも推奨しているFunctional Role と Access Roleのロール構成（※）としています。
※TerraformでFunctional Role と Access Roleの構成を実装した記事もあわせてご覧いただけると嬉しいです。
2. Access Role
DBを環境ごとに分けそれぞれのDBに充分な権限をもつロールを作成
| 環境 | ロール名 |
|---|---|
| 開発環境 | ACCESS_ROLE_FOR_ENV_DEV |
| ステージング環境 | ACCESS_ROLE_FOR_ENV_STG |
| 本環境 | ACCESS_ROLE_FOR_ENV_PRD |
3. Functional Role
開発部用のロールを作成しその中で、一般ユーザと管理者を分けてロールを作成
| ユーザ分類 | ロール名 |
|---|---|
| 一般ユーザ | FUNCTIONAL_ROLE_DIV_DEVELOP_USERS |
| 管理者 | FUNCTIONAL_ROLE_DIV_DEVELOP_MANAGERS |
4. ロールの継承とユーザへのアタッチ(Access Role -> Functional Role -> Users)
-
FUNCTIONAL_ROLE_DIV_DEVELOP_USERS
- 開発環境とステージング環境のDBを操作可能なAccess Roleを継承します
- USER_Aを一般ユーザと定義し、当該ロールをアタッチします
-
FUNCTIONAL_ROLE_DIV_DEVELOP_MANAGERS
- ACCESS_ROLE_FOR_ENV_PRDとFUNCTIONAL_ROLE_DIV_DEVELOP_USERSを継承することで、3つ全ての環境のDBにアクセス可能となります
- USER_Bを管理者ユーザと定義し、当該ロールをアタッチします
dbt CloudのEnvironmentとJobについて
作成するCICDジョブとデプロイ先の環境に関する構成図は下図の通りです。
dbt Cloudの概念整理
1. Environment type
Environmentは、DWH環境を切り替えるための概念です。
その中にはDevelopmentとDeploymentの二種類がありそれぞれの用途は下記の通りです。
| Environment Type | 利用用途 |
|---|---|
| Development | dbt Cloud IDEまたはdbt Cloud CLIでコマンドを実行する開発環境。 |
| Deployment | 定期実行やCICDジョブを実行するデプロイ先の環境 |
さらにDeployment Typeには次の3つのタイプが用意されており、後述のジョブ毎に用途を切り替えられます。
| Deployment Type | 利用用途 |
|---|---|
| General | 一般的な環境 |
| Staging | ステージング用の環境 |
| Production | 本番実行用の環境 |
図式化するとこのような感じ。
2. Job
ジョブを作成することで、スケジュールや特定のアクションをトリガーとしてコマンドを実行させることができます。
| Job Type | 利用用途 |
|---|---|
| Continious Integration Job（CI-Job） | ・新規のプルリクエストが開いたときに実行されるジョブを設定可能 ・変更を本番環境にマージする前に、新しいコードをビルドしてテストします |
| Merge Job（CD-Job） | ・プルリクエストをmainブランチにマージされたときにジョブがトリガー |
| Deploy Job | ・スケジュールまたはイベントによってトリガーされ、クラウド データ プラットフォーム内のプロジェクトに対して dbt コマンドを簡単に実行可能 |
図式化するとこのような感じ。
作る
ここではdbt cloud上に作成した環境とジョブについてみていきます。
1. Environments
下記に示すように3つ作成しました。
例えば、DB_PRDのEnvironmentsでは下図のように設定しています
- Environment typeがDeploymentでDeployment TypeがProductionとなります
1-1. connection
Environmentsで作成した3つの環境はそれぞれ、Snowflakeの開発、ステージング、本番用のDBとの接続情報を設定しています。
2. Job
ジョブの構成はステージング環境に実行するCIジョブと、本番環境に実行するCDジョブの2つです。
2-1. CI Job
キャプチャの通り、接続先の環境はステージングDBで、ジョブのトリガーはプルリクエストが作成されたタイミングとなっています。
2-2. CD Job
図の通り、接続先の環境は本番DBで、ジョブのトリガーはマージ処理が実行されたタイミングとなっています。
動かす
1. CI Job
dbt CloudのIDEからプルリクエストを出すと、GitHubの画面でdbt jobが実行されている表示が現れます。
成功か否かは、dbt CloudとGitHubの画面両方で確認できます。
1-1. 結果
SnowflakeのWebコンソールから、ステージング環境のDBに向けたクエリの実行結果を確認できます。
2. CD Job
マージ後、CD Jobが実行されます。
2-1. 結果
Snowflakeのコンソールからも本番DBに向けたクエリが実行されているのがわかります。
ちゃんと実行ユーザも切り替わっていますね。
最後に
CICD環境を手軽に構築・試すことができました。
手作業によるデプロイの手間とエラーを目の当たりにしてきた人間からすると、たったこれだけのCICD環境でも、そのメリットを存分に感じられる開発となりました。
運用に適した形でCI/CDそれぞれのjob（データテスト含む）をどう構成するか、についてはより知識を深めていきたいと思います。
スペシャルサンクス
dbt CloudのEnvironmentとjobに関する理解が深まりました！有難うございました。
公式リファレンス