データベースを取り替えることはあるか？ごく稀にあるが、だいぶめんどくさい

ほとんどのウェブアプリケーションは異なるデータベースへの置き換えが発生する前に寿命を迎えると思われるものの、ごく稀にデータベースを移行する必要が生じる。この記事ではそんなプロジェクトについて語っていこう。

しばらく前に書いた記事 には、ウェブアプリケーションがデータベースを取り替えることはないという記述があるが、部分的であれ全てを取っ替えるのであれ、寿命の長いアプリケーションではたまにそんな機会が発生する。そんなのときにどんなことが面倒なのだろうか？

俯瞰的な視点から入っていこう。アーキテクチャの観点からは、完全に新しいデータベースに移行するまでに古いデータベースにデータをレプリケーションする必要が発生することがある。ドメインが扱いやすい粒度で分割されていれば良いが、大抵の場合そんなことはなく移行したテーブルを参照する機能がしばらく残ってしまう。これくらいならマシだが、がっつりと共有データベースパターンになっていることもある。

技術的な詳細は省略するが、ロジカルレプリケーションはメッセージング機構が必要になり、この時点でプログラミングが面倒だが、トランザクションの整合性を保つための工夫が必要になる。テーブルのカラムにユニーク制約があるとさらに面倒だ。こういった開発は素早くコードを書けて、コードリーティングの能力に長けていて、複数サービスに跨るソフトウェア開発に慣れていて、トランザクションを考慮ひた適切な設計ができるソフトウェア開発者が必須になる。ただ、そのことを理解している組織はほんと一握りのようだが… ^[1]

細部に注目すると、移行対象のアプリケーションのソースコードが整理されているとは言い難いことがある。SQLとDAOが一体化してビジネスロジックを実装していたり、あるテーブルに関係する機能の範囲が広すぎたりして、かなり手を付けにくい状態になっていることがある。
リファクタリングしようにも安全な移行が難しいことがあり、最終的には新しく実装を書いて、いきなり完全移行はリスキーなのでフィーチャーフラグでちまちまと移行する羽目になる。

ざっくりと書いてみたが、とにかく腕力で解決する必要があり、なるべくやりたくないような気がするが、やらないとビジネスが立ち行かなくなる状況もあるだろうから、普段から整理しておくのが大切だ、という結論になってしまう。とはいえクリーンアーキテクチャを採用していればRepositoryの実装を挿げ替えてデータベースを移行できるわけではないことに留意しておく必要がある。

脚注

1. 人材の稀少さだけでなく、データベース移行が必要な規模のシステムに応じた人事制度が必要になることも理解している必要があるように思う。アメリカのソフトウェア企業が似たり寄ったりなキャリアラダーを採用していることを観察する必要がある。Spotifyは "Spotifyモデル "を使っていないことを知らずにSpotifyモデルのような制度にしてはならない。