データベーススキーマ移行のための CI/CD パイプラインの作り方

アプリケーションコードには 20 年前から CI/CD があります。データベースにはほとんどありませんでした。スキーマ移行のための CI/CD パイプラインはそのギャップを埋めます。データベース変更をアプリケーションコードと同じパイプライン上に乗せるのです。マイグレーションスクリプトは Git に置く。CI でリンティングとレビューを走らせる。デプロイはステージを通って進める。

本記事ではこのアプローチをエンドツーエンドで追います。パイプラインが何をゲートするのか、何を外に残すのか、適合するツールは何か。

パイプラインが行うこと#

あらゆる変更が同じ道を通ります。検証し、プロモートし、承認し、記録する。この順番で 4 つの動詞です。

検証#

SQL レビューがプルリクエスト上で走ります。構文エラー、欠けたインデックス、安全でない操作、命名ルール違反は、すべてマージ前に捕捉されます。ルールセットは環境横断で適用され、厳しさが環境ごとに変わります。本番ではフルセットを、dev ではサブセットを実行します。

プロモート#

マイグレーションが dev に適用されます。次に staging。そして本番。各ステージで、同じスクリプトが段階的により本番に近いデータに対して走ります。失敗するとチェーンが止まります。

承認#

ステージ間に承認ゲートが置かれます。ルーチン変更は dev と staging に自動でプロモートされます。本番向けの DDL は人を待ちます。承認者は SQL、検証結果、ロールアウト計画を 1 つのレコードで確認します。3 つの Slack スレッドに散らばっているのではなく。

記録#

適用されたあらゆるマイグレーションが、バージョン、環境、実行者、タイムスタンプとともにログに残ります。環境間のスキーマは自動的に比較されます。ドリフト、つまりパイプラインの外で行われた変更は、アラートを引き起こします。

パイプラインを通る 1 つの変更#

動詞は抽象的なので、具体例を 1 つ。ある開発者が、1200 万行の users テーブルに NULL 許可カラムを追加します。

プルリクエスト。 マイグレーションがコミットされます。

-- V042__add_user_email_verified_column.sql
ALTER TABLE users ADD COLUMN email_verified BOOLEAN DEFAULT NULL;

CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_users_email_verified
ON users(email_verified) WHERE email_verified = FALSE;

SQL レビューが 2 点を指摘します。インデックス作成は本番規模で約 10 分かかる。部分インデックスの WHERE 句はインデックスを小さく保つ反面、カーディナリティを歪める。

dev。 マイグレーションは 1 万行のデータベースに 2 秒で適用されます。インテグレーションテストは通過。

staging。 本番に近いボリューム。マイグレーションは 8 分かかります。インデックス構築中、レプリケーション遅延が 45 秒まで跳ねます。QA がアプリケーションが新しい NULL 許可カラムを正しく扱えることを検証。

本番。 DBA は staging が綺麗に完了したのを見て承認します。デプロイは低トラフィック帯で実行。マイグレーションは 11 分かかります。データベース側の確認が取れた後にアプリケーションがデプロイされます。

パイプラインはすべてのステップを記録します。各環境がそれぞれの監査証跡を持ちます。マイグレーションスクリプトは 4 環境すべてで同じ 1 本です。

インデックス戦略はエンジンによって異なります。PostgreSQL は CREATE INDEX CONCURRENTLY を使います。MySQL は ALGORITHM=INPLACE を使い、エンジンがテーブルをコピーしてしまうケースでは gh-ost や pt-online-schema-change にフォールバックします。戦略を選ぶのは開発者。その選択がレビューを通ることを強制するのがパイプラインです。

どこで止まるのか#

ここがほとんどのパイプライン売り込みが飛ばす部分です。パイプラインがゲートするのは、ただ 1 つのクラスの作業です。計画的でバージョン管理されたスキーマ変更。データベースの作業の多くは、その境界の外に落ちます。

• アドホック操作。緊急のホットフィックス、単発のデータパッチ、インシデント中の ANALYZE。どれもプルリクエストとして始まりません。
• クレデンシャル管理。データベースのクレデンシャルは PAM、あるいは開発者のラップトップに置かれます。パイプラインはサービス ID として動作し、開発者として動くわけではありません。
• 読み取りパスの活動。クエリ、エクスポート、アドホックな調査はマイグレーションログには現れません。
• マージの先のポリシー。命名ルールやロック粒度のチェックは PR レビュー時に走ります。マージされた後、実行時に再チェックするものはありません。

端的に言えば、パイプラインがゲートするのは計画的な変更です。データベースに触れるすべてをゲートするわけではありません。そうでないふりをすると、チームはいずれ不意を突かれます。

適合するツール#

パイプラインのコア機構をカバーするオープンソースツールは 3 つあります。

• Liquibase と Flyway は CLI ファーストのマイグレーションランナーです。チェンジログからマイグレーションを適用し、適用済みを追跡し、任意の CI システムと統合できます。どちらも Java ベース。
• Bytebase は Web GUI と GitOps。SQL レビュー、承認、ステージプロモーションを組み込み済み。単一の Go バイナリ。

CLI ファーストのチームは Liquibase か Flyway を使い、パイプラインを自分でオーケストレーションします。パイプラインが組み上がった状態で欲しいチームは Bytebase を使います。

どこに着地するか#

CI/CD パイプラインはデータベース自動化の 6 段階におけるレベル 3 です。計画的スキーマ変更について、開発者から DBA への手作業の引き継ぎを取り除きます。それだけでも、労力に見合う価値があります。

すべてのチームにフルパイプラインが必要というわけではありません。読み取り専用の分析データベース、使い捨ての開発環境、小規模チーム (10 データベース未満、開発者 5 人未満) は、バージョン管理 + CLI ランナーで運用できます。チームとデータベース数が増えてきたところでパイプラインを追加します。

そのギャップを埋めるのがレベル 4 のプラットフォームです。アドホック操作、クレデンシャル、読み取りパスの活動、マージ後のポリシー。パイプライン主導のアプローチは、チームが構築できる最強の L3 です。L4 ではありません。そしてその違いを知ることこそが、すべての肝です。