データパイプラインの CI/CD とソフトウェア工学

データパイプラインも、アプリケーションと同じくコードです。ジョブのスクリプト、、の定義、のテンプレートを、バージョン管理、テスト、ログ記録、といったソフトウェア工学の習慣で扱うと、変更を安全に、何度でも同じ手順で本番へ届けられます。

DEA では、ソフトウェアエンジニアリングのベストプラクティスをデータエンジニアリングに当てはめること、そして (データパイプラインの実装、テスト、デプロイ) を説明できることが問われます。

Point

CI = Continuous Integration (継続的インテグレーション) です。変更をこまめに統合し、そのたびに自動でビルドとテストを行います。
CD = Continuous Delivery / Deployment (継続的デリバリー / デプロイ) です。テストを通った変更を、自動で (または承認を経て) 本番へ届けます。
和訳
- Integration: 統合
- Weblio英和辞書「integration」

概要

データパイプラインのは、コードの変更をきっかけに、ビルド、テスト、デプロイを自動で流す仕組みです。

段階	AWS のサービス	内容
ソース	Git リポジトリ (GitHub などを AWS CodeConnections で接続、または AWS CodeCommit)	コードとテンプレートの版を管理します。
		ソース → ビルド → デプロイの各段階を順に自動で流します。
ビルドとテスト		`buildspec.yml` に従って、依存の導入、テスト、パッケージ化を実行します。
デプロイ	/ / 、AWS CodeDeploy	インフラとなどをデプロイします。

主要技術

①バージョン管理

のスクリプト、ファイル、、ステートマシンの定義、テンプレートは、すべて Git で管理します。

習慣	内容	効果
ブランチとプルリクエスト	機能ごとにブランチを作り、レビューを経てメインに統合します	誤りを本番前に見つけます。
コードとインフラを同じリポジトリで管理	Glue スクリプトと、それを動かす Glue ジョブの定義を一緒に管理します	どの版のコードがどの設定で動くかがそろいます。
タグとリリース	本番に出した版にタグを付けます	問題が出たら前の版へ戻せます。
大きなデータは Git に入れない	データそのものはに置き、Git にはコードと設定だけを入れます	リポジトリが重くなりません。S3 のでデータの版を管理します。

Glue Studio のジョブは、Git リポジトリ (GitHub、GitLab、Bitbucket、AWS CodeCommit) と連携してスクリプトをプッシュ・プルできます。

よく使う Git の操作は次のとおりです。

操作	内容	使いどころ
`git clone` / `git pull`	リポジトリを手元に複製する / 最新の変更を取り込む	作業を始める前に最新にそろえます。
`git branch` / `git switch`	ブランチを作る / 切り替える	機能ごとに作業を分け、メインを壊しません。
`git commit` / `git push`	変更を記録する / 共有のリポジトリへ送る	小さな単位で記録し、プルリクエストでレビューを受けます。
`git merge`	別のブランチの変更を統合する	レビュー済みのブランチをメインに取り込みます。
`git revert`	指定したコミットを打ち消す新しいコミットを作る	共有済みの履歴を書き換えずに、誤った変更を取り消します。
`git reset`	ブランチの先端を過去のコミットへ戻す	まだ共有していない手元の変更のやり直しに使います。共有済みの履歴に使って強制プッシュすると、他の人の履歴と食い違います。
`git tag`	コミットに名前 (例: v1.4.0) を付ける	本番に出した版を示し、戻す先を明確にします。
`.gitignore`	Git で管理しないファイルを指定する	認証情報のファイルや、ローカルで作った大きなデータを誤ってコミットしないようにします。

②テスト ⚠️ 頻出

データパイプラインのテストは、コードのテストとデータのテストの2つに分けて考えます。

テストの種類	確かめること	例
単体テスト	変換の関数が正しい結果を返すか	小さな入力データを用意し、日付の変換や重複除去の関数を pytest で検証します。
結合テスト	サービスをつないだときに動くか	検証環境でジョブを実行し、出力のテーブルをで確かめます。
データのテスト (品質チェック)	実データが期待どおりか	必須の列が空でないか、件数が急減していないかをのルールで確かめます (#57)。
スキーマのテスト	列の追加や型の変更で下流が壊れないか	期待するスキーマと比べます。
のテスト	テンプレートが正しいか	`cfn-lint` での検査、のアサーションでのテスト、変更セットの確認

Glue ジョブは、Glue のイメージやインタラクティブセッションを使って、ローカルや開発環境でテストできます。は sam local invoke でローカルで試せます。

③CodePipeline・CodeBuild・CodeDeploy

サービス	役割	データパイプラインでの使い方
	パイプライン全体の流れを定義し、段階を順に実行します	Git へのプッシュをきっかけに、テストと各環境へのデプロイを自動で流します。手動の承認アクションを本番の前に入れられます。
	マネージドのビルド環境でコマンドを実行します	`buildspec.yml` で、Python の依存の導入、pytest の実行、のビルド、スクリプトのへのアップロードを行います。
CodeDeploy	アプリケーションのデプロイを段階的に行います	関数の新しい版へ、トラフィックを段階的 (カナリア、線形) に移し、のが鳴ったら自動で戻します。

デプロイの方法としては、 (SAM・を含む) のアクションで、スタックを環境ごとに更新するのが基本です。

Point

Canary (カナリア) デプロイは、まず一部 (例: 10%) のトラフィックだけを新しい版に流し、問題がなければ残りを移す方法です。炭鉱でカナリアを先に入れて安全を確かめた故事に由来します。
Linear (線形) デプロイは、一定の間隔で一定の割合ずつ移す方法です。

④ログ記録とモニタリングを組み込む

本番のパイプラインが「静かに失敗する」のを防ぐため、ログとを最初から組み込みます。

習慣	内容
構造化ログ	形式で、ジョブ名、実行 ID、処理件数、エラーを出力します。で検索しやすくなります (#63)。
処理件数の	読み込んだ件数と書き込んだ件数をカスタムメトリクスとして送り、急減をで知らせます。
失敗の通知	ジョブの失敗をで受け、で通知します。
デプロイ後の確認	デプロイ後にスモークテスト (小さなデータで実行) を行います。
監査	誰がいつデプロイしたかは、の実行履歴とで追跡します。

試験対策

①判断マトリクス

問題文のキーワード	選ぶもの	理由
Git へのプッシュで、テストとデプロイを自動化	+	ソースからデプロイまでを自動で流します。
本番へ出す前に人の確認を入れたい	CodePipeline の手動承認アクション	承認されるまで次の段階を止めます。
変換ロジックが正しいかをデプロイ前に確かめたい	単体テスト (CodeBuild で pytest など)	小さな入力で関数を検証します。
実データの品質を本番の処理中に確かめたい	データのテスト ()	件数や空欄などを毎回の実行で検査します。
の新しい版を少しずつ本番に出したい	CodeDeploy のカナリア / 線形デプロイ	問題があればで自動的に戻します。
インフラの変更もレビューと履歴を残したい	を Git で管理し、パイプラインでデプロイ	手作業の変更をなくします。

②よくある誤答

本番のジョブのスクリプトをコンソールで直接編集すること。版の管理とレビューが失われます。
データの品質の検査を単体テストだけで済ませること。実データの変化は本番の処理中のチェックで見つけます。
大きなデータファイルを Git に入れること。データはに置き、版は S3 ので管理します。