
ふつうのデータ基盤移行 - Part 5. IaC と CI/CD 編
このポストについて データ基盤移行について書いていくシリーズです。 シリーズ一覧はこちらから。 前回 Part 4. AI ワークフローで移行作業効率化編では移行するための苦労と効率化について書きました。 今回はがらっと変わって IaC と CI/CD について書きます。 スコープ 今回は開発寄りの話です。 データ基盤の構築にあたり Terraform を使って IaC (Infrastructure as Code) を実現し、さらにそれに基づいて GitHub Actions による CI/CD (Continuous Integration & Continuous Derivery) 環境を作ったという話をしていきます。 IaC で作りたいアーキテクチャは AWS 上の Databricks 環境とその周辺です。 アーキテクチャについて詳しくは Part 3. アーキテクチャ編などをご参照ください。 だいたい以下の図のような話です。 お気持ち表明 こんにちは、初手で絶対に CI/CD 環境を構築するマンです。 初手で絶対に CI/CD 環境を構築するマンは、初手で絶対に CI/CD 環境を構築するぞ!という強い気持ちを持っています。 Databricks 上にデータ基盤を構築するにあたり、他社事例でインフラ構築を自動化していないケースを見たこともあります。 しかし我々のチームでは PoC 終了後の構築最初期から IaC としてインフラをコード化し、それを CI/CD の仕組みで自動でデプロイすることを決めていました。 次のような理由からです。 リリースの数だけ自動化のリターンがあるので、最初から自動化しておくのが最もリターンが大きい チームにはジュニアなメンバーもおり、手動の運用はオペミスや production, staging などの環境差発生のリスクが大きい 社内で Terraform や GitHub Actions などがよく使われており、導入できる下地があった まだ Databricks にそこまで慣れていない導入初期にこれらの仕組みを入れるのはそれなりにたいへんです。 しかしそのたいへんさ以上のメリットがあると判断しました。 ...