Database as Code のランドスケープ

これはデータベースのバージョン管理と database-as-code (GitOps) を扱うシリーズ記事です。

1. データベースバージョン管理とは？
2. データベースバージョン管理、State ベースか Migration ベースか？
3. Database as Code — 良いところ、悪いところ、見たくないところ
4. Database as Code のランドスケープ (本記事)
5. データベースバージョン管理のベストプラクティス

データベーススキーマ変更をコード化する (いわゆるスキーママイグレーションの) アイデアは新しいものではありません。多くのエンジニアリングチームが Liquibase / Flyway を使ってこの運用を採り入れてきました。同時に、Database as Code (DaC) を業界全体で採り入れる動きが加速しているのも事実で、既存プレイヤーに挑む革新的なプロダクトもいくつか登場しています。

本記事では、Database as Code のランドスケープにおける現在地を概観し、この領域の現状と今後のトレンドについての視点を共有します。

概観#

ゲートキーパー#

Liquibase#

2006 年に始まった Liquibase は、おそらくこの領域で最もよく知られたプロダクトです。フォーラムでデータベーススキーマ変更の助言を求めると、Liquibase に言及する返信を必ずと言っていいほど目にします。

Liquibase はオープンソースプロジェクトであり、商用提供を行う企業でもあります。会社はかつて Datical と呼ばれており、ブランドを統一するために Liquibase に改名されました (賢明な判断です)。 Liquibase の主要プロダクトは Java ベースの CLI です。CLI を介して、開発チームはデータベーススキーママイグレーションを CI/CD ワークフローに統合できます。Java アプリケーションでは Liquibase をライブラリとして利用することもでき、起動時に該当するスキーママイグレーションを適用するためにアプリケーションが Liquibase ライブラリを組み込むのが一般的です。

Liquibase ではスキーママイグレーションの単位が Change Set にカプセル化されています。歴史と Java ルーツのためか、最も一般的な記述形式は XML です (YAML と JSON のサポートは後から追加されました)。

適切なアノテーションを付ければ、生 SQL もサポートされます。

Liquibase は Migration ベースです。対象データベーススキーマの最終状態ではなく、増分の変更を記録します。

最近では Liquibase は HUB を導入しました。これは有償顧客向けの情報ポータルで、データベース変更アクティビティをリアルタイムに表示・整理・監視できます。

Flyway#

Flyway は多くの点で Liquibase に似ています。長い歴史と大規模な顧客基盤を持つオープンソースプロジェクトで、コアプロダクトは CLI と Java ライブラリです。Flyway も最近 Hub という名のウェブポータルを発表しました。

Flyway の商用エンティティは、買収を通じて Redgate になりました。ブランディングは少し混乱を招くかもしれませんが、同時にオープンソースと商用提供の境界線にもなっています。Flyway はよりカジュアルなブランドトーンを纏っています。

Flyway のウェブサイトは、洗練されたグラデーションを多用する新興 DevTools 企業ほど派手ではありません。基本的な UI の余白の問題すら見つかります。それでも Flyway は、見た目より中身が大事という古典的な好例で、ドキュメントの分かりやすさで頭一つ抜けています。

Liquibase と Flyway は接戦です。違いは主にポジショニングにあります。Liquibase はエンタープライズ顧客向け、Flyway は開発者にとってよりとっつきやすい印象です。

Sqitch#

Sqitch も古くからあるオープンソースプロジェクトです。Sqitch は CLI のみで UI はありません。Java ベースの Liquibase/Flyway と異なり、Perl で開発されています。

Perl を選んだことだけが面白い点ではありません。Sqitch はデータベーススキーマ変更の管理について独自の設計思想を持っています。Liquibase も Flyway も、ファイル命名規約でスキーママイグレーションの挙動を制御します (設定より規約)。

一方で Sqitch は明示的なアプローチを採ります。下の例では、スキーママイグレーションを appschema という名前で命名する必要があります。

後で appschema に依存する別のマイグレーションを適用したい場合は、--requires を指定します。

Sqitch はスキーマ変更デプロイのためのユニークな tag および bundle コマンドも提供しており、スキーマデプロイをアプリケーション開発のライフサイクルに組み込む自由度をチームに与えます。

新星たち#

Atlas#

Atlas は最近登場した新しいデータベーススキーママイグレーションツールです。既存ツールの良いところを取り入れています。

• Liquibase / Flyway / Sqitch と同様に主に CLI に焦点を当てつつ、スキーマを可視化する軽量な UI も持つ。
• Prisma と同様に、データベーススキーマを定義するための独自 DSL を設計している。当初は Prisma と同じ State ベースを採用していたが、Migration ベースも追加したようだ。

• HashiCorp Terraform にも強く影響を受けており、Go を使い、独自 DSL を発明している。Hacker News では Terraform for Database Migrations としてデビューしたほど。

Atlas の現状の主軸は CLI です。Liquibase / Flyway のような既存 CLI ツールと並べると、モダンなプログラミング言語 (Java ではなく Go) の採用と、Terraform や Prisma などからの学びを取り込んでいるという強みがあります。

ORM たち#

データベーススキーママイグレーションはアプリケーション開発の不可欠な要素です。当然ながら、人気のアプリケーションフレームワークや ORM はスキーママイグレーション機能を内蔵しています。

• Ruby on Rails Active Record Migrations (Ruby)
• Django Migrations (Python)
• MyBatis Migrations (Java)
• GORM Migrations (Go)

データベーススキーママイグレーションはバックエンドのカテゴリに属しますが、最近のもっとも目立つイノベーションは、フロントエンドルーツの ORM である Prisma から来ています。

Prisma#

Node.js は、フロントエンドエンジニアがフルスタックアプリケーションを構築するパンドラの箱を開きました。パンドラの箱と呼ぶのは、繁栄と混沌の両方を持ち込んだからです。フルスタックアプリケーションは 3 つのピースから構成されます。

1. コード (ステートレスな部分)。
2. データ (ステートフルな部分)。
3. コードとデータをどうつなぐか。

サステナブルなフルスタックアプリケーションを作りたい一般的なフロントエンドエンジニアにとって、TypeScript / Express.js はコードの問題を解いてくれます。MongoDB のような NoSQL データベースはデータの問題を解いてくれます。Prisma は最後の問題、コードとデータをつなぐ部分を狙っています。

フロントエンドエンジニアにとって、ユーザビリティとアクセシビリティはとりわけ重要です。彼らは完璧なピクセルと HCI に慣れており、SQL を組み立てることには長けていません。データベーススキーマ管理の敷居を下げるために、Prisma は専用の DSL を設計しています。

この DSL は State ベース (宣言的) のアプローチを採り、対象データベーススキーマの最終状態を記述します — 増分の変更ではありません。これは Liquibase / Flyway / Sqitch と異なる点です。

Prisma はインテグレーションと開発ワークフローにも大きく投資しています。

バックエンド ORM たちと違い、Prisma は新鮮なアプローチを取り、アプリケーション開発ライフサイクル全体を通じてデータベースのデータとスキーマを管理する、より包括的な視点を提供します。

製品ラインナップを見れば、その野心が ORM とスキーママイグレーションツールにとどまらないことが容易に分かります。

データベース#

ここまでに紹介したツールはどれも多様なデータベースシステムで動きます。Database as Code の応用はデータベース非依存ですが、開発者体験を主要な差別化要因として打ち出す新しいデータベースシステムも登場しています。この開発者中心の視点や、ブランチ/クローンといった機能は Database as Code の発想と一致します。

PlanetScale#

PlanetScale はかつて Vitess のホスティングサービスでした。昨年、開発者ワークフローへピボットしました。ウェブサイトには Vitess の名残がまだ見つかるかもしれませんが、新しいマテリアルの大半は、ブランチング、オンラインスキーマ変更、最近導入された rewind のようなデータベース開発ワークフロー機能について語っています。

Prisma の節で触れたとおり、フルスタックアプリケーションは 3 つの柱から成ります。

1. コード (ステートレスな部分)。
2. データ (ステートフルな部分)。
3. コードとデータをどうつなぐか。

データの部分では、MongoDB が人気の選択肢です。普及度ではなく使いやすさで選ばれています。一方で、ユーザー情報、注文、課金のようなミッションクリティカルなアプリケーションデータをホストするには、依然として SQL ベースのリレーショナルデータベースを選びたくなります。PlanetScale は MySQL をベースに、Vitess のスケーラビリティで強化し、PlanetScale の素晴らしいプロダクトチームによって使いやすさが磨かれています。これらの特性により、PlanetScale は魅力的な選択肢になっています。SQL データベースの利点をすべて保ちながら、開発者体験を犠牲にしない — 両方の良いところを兼ね備えているように見えます。

Neon#

Neon もちょうど発表された別のオープンソースデータベースです。

ハイレベルでは PlanetScale と多くの共通点を持ちます — サーバーレス、開発者生産性、フルマネージド。

主な違いは技術スタックにあります。

• Neon は PostgreSQL 陣営、PlanetScale は MySQL ベース。
• PlanetScale は高度なデータベース機能を提供するために Vitess を活用しているが、Vitess 自身は MySQL サーバーノード上のミドルウェア。Neon はより踏み込んだアプローチを取り、目指す機能を提供するために専用のストレージレイヤーを作っている。

スタック全体をより制御できる分、Neon にはより高いポテンシャルがあるかもしれません。Neon と PlanetScale が今後どう進化していくかは、非常に興味深いところです。 MySQL と PostgreSQL の愛憎関係は終わりがありません。素の MySQL vs PostgreSQL から始まり、分散データベースの TiDB vs CockroachDB、クラウドデータベースの AWS Aurora vs GCP AlloyDB、そして今は開発者中心のデータベースである PlanetScale vs Neon。

ミスフィットたち#

Dolt#

Dolt は独自のユニークな立ち位置にあります。ウェブサイトでは、Git ライクなバージョン管理を備えたデータベースシステムと説明されています。

Dolt は他のデータベースシステムとは大きく異なり、Git のセマンティクスを内蔵したエンジンを構築しています。これは諸刃の剣で、一方では望ましい Git の特性をもたらしますが、もう一方では典型的な OLTP ワークロードの最適化に難題を突きつけます。

Dolt はデータベースとコードの境界を曖昧にすることで、Database as Code に対してかなり大胆な一手を打ちました。現状は「Git のセマンティクスをデータベースへ持ち込む」と位置づけていますが、その逆 — 「データベースのセマンティクスを Git へ持ち込む」 — も同じくらい、あるいはそれ以上に機能するでしょうか。多くのアプリケーションは、すでに Git を唯一のデータストアとして使っています。

Bytebase#

Bytebase は 2021 年 1 月に始まったオープンソースプロジェクトです。先述のプロダクトたちといくつかの特性を共有しています。

• Liquibase / Flyway / Sqitch と同様に、Bytebase はデータベーススキーマ変更の適用に Migration ベースを採用している。
• Prisma と同様に、Bytebase はデータベース開発活動 (スキーマ、データ変更、SQL クエリ) を行うための完全なウェブ UI を提供する。
• Atlas と同様に、Bytebase はモダンな技術スタックを採用しており、Java ではなく Go を使う。
• PlanetScale / Neon と同様に、Bytebase は開発者体験に注力する。一例が VCS 連携で、Bytebase はポイント・アンド・クリックのウィザードで VCS を設定できる (Vercel / Netlify でコードリポジトリを連携するのと同じ体験):

Bytebase は何でも屋であり、チームコラボレーションの達人です。

• 単独の開発チームが Bytebase ワークスペースを立て、データベース開発活動を管理できる。
• DBA やプラットフォームチームも Bytebase ワークスペースを立て、組織全体のすべてのプロダクトチームに使ってもらえる。
• ネイティブな VCS 連携により、コードとデータベースの開発を一緒にスムーズに進められる。 Jira や GitLab / GitHub のようなシステムを思わせる Project や Issue という概念を備えている。

複数の環境にまたがるマルチテナントアプリケーションのデータベース変更を管理するための Tenant、Environment という概念もあります。

Bytebase は組織全体でスキーマ標準を強制するためのスキーマレビューポリシーも内蔵しています。

Bytebase は、データベース開発の側面を管理するための GitLab / GitHub の対応物として構想されています。チームコラボレーションのための Database DevSecOps ソリューションとして位置づけられています。

他ツールとの比較は次の通りです。

*Bytebase は Migration ベースを採用しているが、マイグレーションの前後でスキーマスナップショットを記録する。これにより、ドリフト検知のような State ベースの利点も一部享受できる。

まとめ#

Database as Code のアイデアは新しいものではありませんが、ここ 2 年でトレンドとイノベーションが大きく加速しています。

• GitLab、GitHub のような商用企業が Git ベースの DevOps 基盤に重い投資を続けている。
• HashiCorp のような商用企業が Git の基盤を活用し、Terraform のような革新的なプロダクトを作っている。Terraform の成功が GitOps ワークフローを普及させ、業界の発想をポイント・アンド・クリックのシステムからコードベースのシステムへと変えた。
• オープンソースエコシステムの拡大。偶然にも、この領域のプロダクトはどれもオープンソースプロジェクト、もしくはその派生だ。

• 現状を覆す新しいビルディングブロックが生まれている。
  • V8 JavaScript エンジンと Node.js の登場により、フロントエンドエンジニアがデータベースと直接やり取りする扉が開いた。フロントエンドエンジニアの群れは、開発者体験に高い水準を要求する。
  • 実用的な設計とクラウド時代の波に乗り、Go はメインストリーム言語となり、バックエンドアプリケーションを Java で作るという常識に挑戦している。とくにクラウドネイティブ時代では、Go が市場を席巻している。Java ベースのプログラムをデプロイするには JVM のインストールが必要だが、Go では不要。Go を採用するだけで、Bytebase や Atlas のようなツールは Liquibase / Flyway に対する競争優位を得る。言語自身がもたらす開発生産性の向上は言うまでもない。
• データベース市場は非常に成熟しているとはいえ、無視できないほど魅力的でもある。次の Snowflake になるのは、すべてのデータベース実務家の壮大な夢だ。新しいデータベースシステムが作られ、ハードルは年々上がっている。コアなデータベース能力と性能はもはや前提で、差別化のためには開発者体験で競うことになる。

象徴的な進化的データベース設計 (Evolutionary Database Design) は 2016 年に書かれました。「Database as Code」というフレーズは登場しませんが、その記事はそれ以前の 10 年で蓄積された Database as Code 実践の知見をまとめています。

その記事は、規模の大きな DBA チームが珍しくなるトレンドも予測していました。今日でも、本気のエンジニアリングチームの多くは依然として DBA の専門知識を必要とする一方、データベースとのやり取りは開発者の日常業務にもなりました。

データベース開発をめぐる力学は時とともに変化し、より良い開発者体験と効率的な開発者ワークフローの追求は、これまで以上に切実になっています。

これを乗りこなすには、データベースシステム、データベースツール、業界のマインドセットの間で繊細な舞踏が必要です。Database as Code はその重要なピースであり、この領域を作るタイミングとしてこれ以上ない時期です。