これはデータベースのバージョン管理と database-as-code (GitOps) を扱うシリーズ記事です。
- データベースバージョン管理とは？
- データベースバージョン管理、State ベースか Migration ベースか？
- Database as Code — 良いところ、悪いところ、見たくないところ (本記事)
- Database as Code のランドスケープ
- データベースバージョン管理のベストプラクティス
Database as Code に触れる前に、まずより一般的な概念である Configuration as Code (CaC) を整理しましょう。CaC とは、構成リソースをソースコードリポジトリで管理する運用です。代表的な構成リソースには次のようなものがあります。
- 計算 (VM)、ネットワーク (ロードバランサー) などのインフラ構成。これは HashiCorp Terraform や AWS CloudFormation のおかげで Infrastructure as Code (IaC) として広く知られている。
- 監視・アラート構成。
- アクセス制御ポリシー。
- GitHub Actions や GitLab CI のような Continuous Integration (CI) / Continuous Delivery (CD) のパイプライン構成。
- フィーチャーフラグ。
- そして本日のテーマ、データベーススキーマ — つまり Database as Code。
一部の構成リソース、たとえば HashiCorp Terraform でのインフラ管理や Prometheus での監視・アラート構成管理は、すでにコードリポジトリで管理することが事実上の標準になっています。
一方で、データベーススキーマのようなリソースをコードリポジトリで管理することは、まだそれほど普及していません。Database as Code はまだ Wikipedia ページすら持っていない、というのがその証左です。
アプリケーションコードと同じように、アプリケーションのデータベーススキーマを管理することは、ソフトウェア開発における日常的な活動です。データベーススキーマを進化させる運用について語るとき、大きく 3 つのやり方があります。
- データベースに直接接続して DDL 変更を行う。素早いがミスを起こしやすい。
- 開発者が DDL チケットを提出し、DBA がレビューするコンソールを持つ。レビュー承認後に該当データベースへ DDL を適用する。これは SQL レビューと呼ばれることがあり、UI コンソールベース。
- いわゆる database as code。データベーススキーマを GitLab/GitHub のようなバージョン管理システム (VCS) で管理する。スキーマ変更をしたい開発者は、DDL 文を含む新しいスキーママイグレーションファイルを作り、レビューに出す。レビューが承認された後、変更は自動的にデータベースへ適用される。自動化が無い場合は、1 番目のやり方と同じように手動で適用する。
良いところ
業界では Configuration as Code が UI ベースのアプローチより優れているというコンセンサスが形成されており、データベースを コードとして管理することも例外ではありません。我々の見立てでは、Database as Code には魅力的な利点が 3 つあります。
- 既存のコードリポジトリ基盤を活用し、重複作業を避けられる。コードのバージョニング/ブランチング、コード検索、コードレビュー、通知などの機能をタダで得られる。GitLab/GitHub のような製品はすでにこれらの領域に膨大な投資をしている。
- CI / CD の DevOps ワークフローと整合し、リポジトリに保存されたスキーママイグレーションファイルをリプレイすることでローカル/テスト用データベースの準備を自動化できる。
- リポジトリに保存されたデータベーススキーマファイルが単一の真実の源 (SSOT) になる。SSOT があれば、ドリフト検知や、本番 DB に接続せずにデータベーススキーマを解析するといった作業ができる (本番ネットワークは通常開発ネットワークから隔離されているため、そうでなければ難しい)。
悪いところ
正直なところ、純粋に技術的な観点では、Database as Code のアプローチに大きなマイナスはほとんどありません。
実際、Google のすべてのエンジニアリングチームはコードリポジトリでデータベーススキーマを管理しており、10 年以上にわたって良好に機能しています。
他のアプローチと比べて主な障壁は、依然として学習曲線と、ベストプラクティスを守るためのエンジニアリング規律です。公平に言えば、どんなプラクティスでも採用に Google レベルのエンジニアリングを要求するのは、いささか無理があります。
見たくないところ
Database as Code は紙の上では良く見えますが、現実にはより広い採用を阻む欠けたピースがいくつかあります。
初期セットアップが難しい
- 異なる環境の多数のデータベースを管理するために、マイグレーションファイルをどう整理するかをチームが決めなければならない。
- 提出されたマイグレーションファイルがスキーマ変更を引き起こす自動ワークフローを構築するには、OAuth で VCS インスタンスのルートアクセス権限を取得し、VCS プロジェクトに適切な Webhook を設定し、対象ディレクトリを監視する、といった作業が必要になる。さらに、ある環境ではスキーマ変更の自動適用を許可するなど、ルールをカスタマイズすることもある。
プロセスは遅くなり、継続的なポジティブフィードバックループが無い
データベースに直接変更を当てるのに比べ、Database as Code 経由で変更を適用するのは確実に時間がかかります。純粋な UI ベースの SQL レビュープロセスの方が便利に感じられることすらあります。一方で、VCS からバージョニングのような有用な機能が得られても、その本領を解き放つにはさらに作業が必要です。
- ドリフト検知のような機能は、コードリポジトリとデータベースサーバーの間に深い連携があってはじめて成立する。前者がコードのバージョン情報を、後者がスキーマ情報とスキーマバージョン履歴を保持する形だ。
- データベースとコードリポジトリの先には、協働開発ワークフローをモデル化する高水準の開発概念も必要で、それでようやく使いやすいソリューションになる。
- 真に自動化されたデータベース CI パイプラインを構築するには、マイグレーションスキーマファイルのリプレイだけでなく、テストデータの構築も必要になる。これは通常アプリケーションロジックとの統合を伴う。
運用に優しくないオープンソースデータベース
コア機能では MySQL も PostgreSQL も非常に有能なデータベースです。しかし、プロプライエタリなものに比べると運用面では必ずしも優しくありません。たとえば、いずれもスキーマバージョニングの組み込みサポートを持たず、それが周辺の良いツールを作る難易度を上げています。
Bytebase — チームのためのデータベーススキーマ管理、特に Database as Code を民主化する
Bytebase のチームはデータベース領域に 10 年以上携わり、Google Cloud SQL や Ant Group OceanBase で世界最大規模のデータベース群を管理してきました。Bytebase は、チームがアプリケーションデータベーススキーマ管理のより良いプラクティスを採用するうえでの障壁を取り除くために作られました。
- データベース関連のタスクで協働するためのウェブベースのコンソールを提供する。
- database as code をセットアップするための、ステップごとのポイント・アンド・クリックのウィザードを提供する (まだ迷っているなら、UI ベースの SQL レビューソリューションも提供している)。
- Project、Environment、Instance、Database のような一級モデルを設計し、データベーススキーマ管理の良いプラクティスを採用しやすくする。
- 実行状況や履歴、スキーママイグレーション履歴など、スキーマ変更に関連するすべてのアクティビティを表に出す。これによりユーザーはシステムを使うことで継続的なポジティブフィードバックを得られる。
紙幅の都合で触れられない機能は他にもあり、追加機能の開発も活発に進めています。現在の目標は、GitLab/GitHub がソースコード管理を民主化したのと同じように、アプリケーションデータベーススキーマ管理をチームに対して民主化することです。出発点として、現在最もよく使われているオープンソースデータベース 2 つ、MySQL から、続いて PostgreSQL に取り組んでいます。
参考文献
- Evolutionary Database Design — Pramod Sadalage と Martin Fowler が本テーマをより詳細に扱っています。