【Medium】Building CI/CD Pipelines for Data Applications at Snowflake
がく＠ちゅらデータエンジニア です。
※2022年9月よりちゅらデータ株式会社にJoinしました
データエンジニアリングな話題などをMediumで毎朝、サジェストされるんですが、これちゃんと読んでいかんとなーということで、読んだメモなどを残しておこうと思って書いて行こうと思います。
概要
今日はこちら
「SnowflakeでデータアプリケーションのCI/CDパイプラインを構築する」
2021年11月19日の記事、リーディングリストに入れたけど読んでなかったやつ
"継続的な改善は、遅れた完璧さよりも優れている" by マーク・トゥエイン
- なぜCI/CDパイプラインが必要か？
- CI/CDとは？
- 何をテストしているのか？
- CI/CDパイプラインをどのように導入したか？
- CI/CDを使うことで、どんなメリットがあったか？
なぜCI/CDパイプラインが必要なのか？
Snowflake社では、様々なデータチームが、アプリケーションをGithubのモノレポジトリで管理している。
以前は、コードをローカルでテストしていたので、小さなエラー（SyntacsErrorとか）が度々おきていた。
※ 手作業でやっていたので、ミスを完全に防ぐことができない！
継続的デプロイができないので、開発者はリリースを一日一回しかできなかった。
※ビッグバンリリースは避けたいよね・・・小さいリリースをより頻繁に安心してデプロイできたほうがいい
CI/CDとは？（継続的インテグレーションと継続的デプロイメント）
継続的インテグレーション（CI）は、開発者が1日に数回、コードを共有リポジトリに統合することを要求する開発プラクティスである。各チェックインは、自動ビルドによって検証され、チームは問題を早期に発見することができる。
"継続的インテグレーションはバグをなくすことはできないが、バグを見つけることと取り除くことを劇的に容易にする。"-マーティン・ファウラー
※あれ・・・CDって、継続的デリバリー？継続的デプロイメント？
継続的デプロイメントとは、自動化されたテストに合格したソフトウェアを本番環境にリリースすることです[2]。これは、基本的に早期リリースを提供し、ソフトウェア開発チームがユーザー要件に沿うよう支援するもの
何をテストしているのか？
- 構文エラー（Python, SQL）
- Linterとして、Pythonは、pylint、SQLにはSQLFluffを使用
- AirFlowワークフローの検証
- 循環的な依存関係がないか？
- 所有者
- Email-idと失敗時のメール送信
- 失敗した場合のon_failure_callback
- SLAチェック
- 実行タイムアウトチェック
CI/CDパイプラインをどのように導入したか？
CI実装にGitHub Actionsを使用、イベント駆動型で、PRなげたら即座に起動
LinterとDAG検証のチェックは、別GitHub Actionsで実行
AirflowのためのCI/CD
- ブランチを切って、PRを出す→失敗したら修正、通るまで繰り返す→テスト通ったらmasterブランチへマージ
- masterブランチは常に本番のコードと同期
SnowSQLコードのCI/CD
ここ数年、データエンジニアリングは、そのルーツであるSQLに戻りつつある。データエンジニアは、インフラ管理にはほとんど時間をかけていない。外部関数があるので、それを叩くだけのSnowSQLのコードばかりになっている。
Sqitch（オープンソースの変更管理アプリケーション）とJenkinsを用いてCI/CDシステムを実装している。
- SQLはSqitch Project管理したgithubへ、SQLLinterのチェックが走る
- コードがmasterにマージされると、WebhookトリガーでJenkins ServerでCDが走る
- Sqitchは、dockerコンテナ
- Snowflakeの認証情報は、hashhicorp vaultやJenkins credentialsなどで保存
（田代コメント）
Sqitchってのがあるのかぁ、知らなかった
SnowｆlakeのLabで、Schemachangeッテのあるらしいし、そちらを使ってるもんと思ってました。
結論
CI/CDを実装することで、失敗がめっちゃ減った♪
継続的な修正と進歩しないとだめ、ベスト盤はない！
こちらの記事は、Snowflakeで実装したパイプライン、CI/CDの好例！！（自画自賛）
Discussion