106 ー 5 章進化的データ 以前のバージョンに戻ることなしに、必要な時点のデータベースを構築できるという ことがある。先の例で言えば、 1 から 95 までのビルドを行うことでバージョン 95 を 復元するということだ。第二に、なぜ前に進むことと後ろに進むことの 2 つの正し さを維持しないといけないのだろうかということがある。自信を持って UNDO 機能 をサポートするには、開発者はそのコードをテストする必要があるが、それは時には テストの負担を倍増させることになってしまう。第三に、包括的な UNDO 機能を構 築することで、難しい課題が生じるということがある。例えば、マイグレーションに よってテープルが削除されていたとする。マイグレーションスクリプトはどのように UNDO 操作時に全てのデータを復元するのだろうか。 いったんマイグレーションを実行したら、そのマイグレーションを編集したり 削除したりすべきではない。変更は複式簿記を手本にしている。例えば、開発者 の Danielle が例 5 - 2 のマイグレーションをプロジェクトの 24 回目のマイグレー ションとして実行したとする。その後、彼女は dateofbirth が結局必要ではないと いうことに気が付いた。 24 回目のマイグレーションを単純に取り除けば、テープル の最終形からカラムは無くなる。しかし、 Danielle がマイグレーションを実行し、 dateofbirth カラムが存在すると想定されていた間に書かれたコードは、何らかの理 由でプロジェクトが途中の時点に戻る必要がある場合 ( バグの修正など ) には機能し なくなる。代わりに、不要になったカラムを削除するために、カラムを削除する新し いマイグレーションを実行する。 それぞれのマイグレーションを全体の一部とみなすことによって、データベース管 理者と開発者は共にデータベースマイグレーションによりスキーマとコードの漸進的 な変更を管理できるようになる。そして、データベースの変更をデブロイメントパイ プラインのフィードバックループに組み込むことで、開発者はより多くの自動化と早 期の検証をプロジェクトの構築サイクルに含めることができる。 5 工 2 共有データベ - ス統合 よくある統合パターンである共有データベース統合す 1 について取り上げよう。共有 データベース統合は、図 5 - 1 に示すように リレーショナルデータベースをデータ共 有の仕組みとして使うパターンだ。 http://www.enterpriseintegrationpatterns.com/patterns/messaging/SharedDataBaseIntegration.html

5. ] 進化的なデータベース設計 さな差分スクリプトを書く。 例 5 - 1 単純なテータベースマイグレーション CREATE TABLE customer ( lastname VARCHAR(60) firstname VARCHAR(60) , id BIGINT GENERATED BY DEFAULT AS IDENTITY (START WITH 1 ) PRIMARY KEY, い 05 マイグレーションツールは、例 5 - 1 に示すような SQL スニペットを、開発用の データベースインスタンスに自動的に適用する。もし、開発者が誕生日を追加するの を忘れていたことに後から気が付いたとする。そのときには、彼らは元のマイグレー ションを編集するのではなくて、例 5 - 2 に示すように、現在のデータベーススキーマ をさらに変更する新しいマイグレーションを作成する。 例 5 - 2 マイグレーションを使って既存のテーブルに誕生日を追加する ALTER TABLE customer ADD COLUMN dateofbirth DATETIME; ALTER TABLE customer DROP COLUMN dateofbirth; 例 5 - 2 では、開発者は現在のスキーマを変更して新しいカラムを追加している。マ イグレーションツールの中には、 UNDO 機能を備えているものもある。 UNDO をサ ポートすることで、開発者はスキーマのバージョンを前後に簡単に移動できる。例 えば、プロジェクトがソースコードリポジトリのバージョン 101 にあり、バージョ ン 95 に戻る必要があるとする。ソースコードであれば、開発者はバージョン管理か らバージョン 95 をチェックアウトするだけでよい。しかし、データベーススキーマ がコードのバージョン 95 用として適切かどうかはどう保証できるだろうか。もし UNDO 機能を持ったマイグレーションツールを使っているなら、彼らはスキーマを バージョン 95 に後戻りする方に「 UNDO 」することで、各マイグレーションを順番 に適用して目的のバージョンへと戻すことができる。 しかし、ほとんどのチームは次に示す 3 つの理由から UNDO 機能を構築すること から手を引いてきた。第一に、全てのマイグレーションが存在するのなら、開発者は

104 ー 5 章進化的データ 5.1 .1 スキ - マを進化させる アーキテクトは、どのようにして、リレーショナルデータベースのような従来の ツールを使用しつつも進化を支えるシステムを構築できるだろうか。データベース設 計を進化させる鍵は、コードとともにスキーマを進化させることにある。継続的デリ バリーは、サイロ化された従来のデータを現代のソフトウェアプロジェクトが持つ継 続的なフィードバックループへどう適合させるか、という問題に取り組んでいる。開 発者はソースコードを処理するのと同じゃり方でデータベース構造も処理しなくては ならない。すなわち、テストして、バージョン管理して、漸進的に進むのだ。 テストする DBA と開発者は、安定性を確保するためにデータベーススキーマの変更を厳密 にテストする必要がある。開発者がオプジェクトリレーショナルマッパー (ORM) のようなデータマッピングッールを使う場合、そのマッピングがスキーマと同期 していることを保証するため、適応度関数の追加を検討する必要がある。 バージョン管理する 開発者と DBA は、データベーススキーマを利用コードとともにバージョン管理 する必要がある。ソースコードとデータベーススキーマは共生している。どちら かなしには機能しない。必然的に結合されたこれら 2 つを人為的に引き離すこと は、不必要な非効率を引き起こす。 漸進的に進む データベーススキーマの変更は、ソースコードの変更が積み上がるのと同様に増 えるはずだ。したがって、それはシステムが進化するにつれ、漸進的に増えてい くことになる。そのため、現代の開発プラクティスでは、データベーススキーマ の手動更新を避け、代わりに自動のマイグレーションツールが使用される。 スキーマを進化させるには、マイグレーションツールか伐に皿つ。 マイグレーショ ンツールを使うことで、開発者 ( もしくは DBA) は、データベースに対する小さく 漸進的な変更を作り、それらをデブロイメントパイプラインの一部として自動的に適 用していける。マイグレーションツールの性能は多岐にわたっており、単純なコマン ドラインツールから、ちょっとした IDE と言えるほど高度なものまで幅広く存在し ている。スキーマを変更する必要があるときには、開発者は例 5 - 1 に示すような、小