DBの寿命はアプリより長い！ 長生きするDBに必要な設計とリファクタリングを実践から学ぶ

NoSQLは「Not only SQL」のことで、RDBMS以外の全てを指しますので、対象はとても広い範囲に及びます。それを踏まえた上で、RDBMSとNoSQLをどのように使い分けると良いのでしょうか。

まず、忘れてはいけないこととして、RDBMSとNoSQLは排他ではなく、共存できる存在です。ですので、どのミドルウェアを使うかはケースバイケースです。

それはもちろんRDBMSの種類によっても違います。大規模なリードレプリカが必要なケースなど、MySQLが良い場面もあります。業務フローが複雑で制約が欲しいときにはPostgreSQLを使うこともあるでしょう。大規模なECサイトや決済システムはOracle DBの主戦場です。

このようにRDBMSだけでも使い分けがありますが、NoSQLはこれらRDBMSの苦手なところを埋めてくれる存在です。つまり、RDBMSが苦手なことをNoSQLにやらせるべき、というのが使い分けのコツです。

そこで、先程のデータモデリングが重要になります。ツリーやグラフなどリレーショナルモデル以外のデータモデルは、RDBMSが苦手としていますから、NoSQLを検討しても良いでしょう。

さらに論理設計・物理設計と落とし込んだとき、RDBMSのトランザクションが不要だったり、参照や更新がヘビーだったりするなら、別のデータストアを検討したくなります。大規模な更新をさばくような環境では、次のようなアーキテクチャの例があります。

このようにRDBMSとNoSQLが共存して、お互いに得意なところを生かすことが大切です。

最初からNoSQLを使うべきか

これは先程の例の通りケースバイケースですが、積極的に採用すべきか？ というと悩ましいところです。

利用するデータストアの種類が増えれば増えるほどシステムは複雑になりますし、開発環境の用意が大変になります。これは、スタートアップのスピード感を殺してしまう原因に十分なります。ローンチして当たるかどうかもわからないWebサービスでは、最初から重厚なデータストア層を作っても無駄になるかもしれません。

そこで論理設計時にそれも踏まえた上で、RDBMSにやらせる判断もアリです。そういうときに効いてくるのが、JSON型やCTE（再帰クエリ）といったRDBMSの機能です。NoSQLが使いたいとき、RDBMSの機能で十分な対応ができないか、一度は検討してみてください。

ただし注意が必要なことですが、RDBMSで表現できたとしても、苦手なことは変わりません。リレーショナルモデルの設計のレールを踏み外していることを意識するようにしましょう。その上で、小規模なところなどでまずRDBMSの機能を使って実装することは、ビジネス判断としてよくある話です。

このように多くのシステムでRDBMSが採用される理由の1つは、トランザクション以外にもRDBMSだけで多くのシステムを構築することができるからです。この特性を生かして、素早くサービスを構築していきましょう。

ローンチは長いDBの旅の始まり

ここまで理論と理想の話をしてきましたが、実際の現場では簡単なことではないとおっしゃる方もいるでしょう。実際に、妥協点をどこに置くかの判断は非常に難しく、正解はありません。

RDBMSに関するまとめとしては、以下の4点を必ず守ってください。その方が良い結果になります。

• データモデリングをしっかりと、最初に行う
• 正規化を行う
• 制約を活用する
• RDBMSの飛び道具にいきなり頼らない

冒頭にも述べたとおり、初期設計はその後のサービスの改善に大きな影響を与えます。そのためにも、これらの点を常に意識するようにしましょう。

1から100に成長した今、戦っていること

初期設計がうまくいっても、その後の積み重ねがうまくいくとは限りません。また最初はスピードを優先して作った設計が後々に課題、いわゆる技術的負債になることもあります。

サービスがある程度成長してくると、このような課題に対して向き合う必要があります。その際に必要なことがデータベースリファクタリングです。2017年のbuildersconでも、データベースのリファクタリングについて登壇しました。

RDBアンチパターン リファクタリング - builderscon tokyo 2017

ここでは実際に上記を踏まえた上で、今まさに私が行っているデータベースリファクタリングについてご紹介します。

データベースの不吉な匂い

データベースのリファクタリングの対象を見極める必要があります。例えば、名著『データベースリファクタリング』（Addison-Wesley Professional、2006、日本語版は絶版）では、次のような項目はリファクタリングの対象と記載されています。

• 複数の目的に使われるカラム
  • レコードの属性に合わせて値の意味が変わるカラム
  • 会員だと入会日、スタッフだと入社日とするなど
• 複数の目的に使われるテーブル
  • カラムの場合と同様に1つのテーブルが複数の意味を持つ
  • Usersテーブルに会員、管理者、事業者などが混在しているなど
• 冗長なデータ
  • 非正規化など
  • 生年月日と年齢カラムがあった場合、1年経ったときに年齢カラムが事実からずれてデータの整合性が取れなくなる。
• カラムの多すぎるテーブル
  • memo1、memo2、memo3...memo99 など
  • 複数のエンティティの責務を束ねている可能性がある
• 行の多すぎるテーブル
  • データを削除しないテーブル
  • 削除が怖いために論理削除で対応するなど
  • 本当にデータの行数が大きくなるテーブルならパーティションなどを検討する
• 「スマート」カラム
  • データの中にビジネスロジックなど、データ以上の意味を持っているもの
  • 9から始まるidは管理者、1から始まるidはユーザーなど
• 変更の恐怖
  • データベースの変更やデータの更新によって、アプリケーションが壊れるのでは？ という恐怖があって手を付けれない状態

これらの箇所を見つけたとき、重要なのは技術的負債を回収する必要はあるか？ を確認することです。

技術的負債には、ビジネス的な価値のあるチーズと、完全なる負債の腐った牛乳があります。どちらも異臭を放っていたとしても、それに対するアプローチは大きく変わります。

データベースリファクタリングは手間も時間もかかるため、だからこそ見つけた際には次の点を検討しましょう。

1. リファクタリングの意味はあるか？
2. 作業に応じたの効果はあるか？
3. 今やるべきか？

例えば、カラムの名前が不適切だったとします。名前を正しくしたいが、多くのアプリケーションコードを修正する必要があるときに費用対効果がある場面は少ないでしょう。

それに対してデータの不整合が頻発し、問い合わせ対応に追われている状況なら、データの制約の追加などは工数が掛かっても取り組むべき課題です。このように不吉な匂いを嗅ぎ分け、適切な優先順位をつけていくことが大切です。

リファクタリングのための準備

データベースリファクタリングをやると決めた場合、戦う前の準備が必要です。

まずリファクタリングの方向性を決める必要があります。自分がやりたいリファクタリングは何なのか？ をしっかり決めましょう。主なデータベースリファクタリングの分類は次のとおりです。

• 構造 …… テーブルやViewの定義
• データ品質 …… データの値
• 参照整合性 …… テーブルの関連性
• メソッド …… ストアドプロシージャー
• 変更 …… テーブルやカラムの追加
• アーキテクチャ …… アプリとのインターフェイス

分類がはっきりし、対象を選定して移行期間が決まれば、次に必要なタスクは実際にリファクタリングするための準備で、大きく2つあります。

• テストとモニタリングを揃える
• リリース戦略を決める

特にテストやモニタリングが不十分では、リファクタリング中に発生した問題に対応していくとき、無策で戦うことになります。データベース障害は即サービス障害ですから、事前に準備をしっかり整えておきましょう。

準備が整えば、あとは粛々と小さくリファクタリングを繰り返していくのみです。時間はかかりますが、結果は必ずついてきます。

細かい点は、前述したbuilderscon 2017の登壇内容で説明していますので、ぜひ見ていただければと思います。

壮大なるデータベースリファクタリング

ここまで読んだ読書の皆さんは「実際のデータベースリファクタリングしている話が知りたい」と感じていると思います。そこで、私が実際にデータベースリファクタリングを行っている内容を、前述の話を踏まえて説明していきます。

現状を把握する

オミカレのデータベースは、2011年にサービスがローンチされて以来、例に漏れず追加追加で成長してきました。また、兄弟サービスの「みんなの婚活」などからも参照されており、まさにマルチアプリケーションの状態です。

しかし、ところどころで制約が不十分だったり、パフォーマンスの都合で非正規化されていたりで、データの不整合に悩まされていました。特に、婚活パーティをつかさどるpartyテーブルが肥大化しており、多くの場所に依存し、そしてパフォーマンスのボトルネックになっていました。

これは完全にデータベースの不吉な匂いを放っています。そこで、データベースリファクタリングを行っていくことを決めました。

方針を決める

実際にデータベースをリファクタリングする際の方針はいくつか考えられますが、今回は2つの方針を検討しました。

1. 特定のタイミングでリファクタリング後の状態に切り替える
2. リファクタリング後の状態と前の状態を作り、両方に更新を行う

1は、移行計画をしっかり組めばウォーターフォール型で進めることができるので効率的ですし、対応が一度で完了します。しかし、オミカレ以外のサービスでもDBを参照していますし、オミカレの新規開発を止めることはできません。

そこで、今回は2の方針を選択し、時間はかかるが確実に進めていくことにしました。データベースリファクタリングは小さいスコープで進めていくことが成功の秘訣だからです。

データベースリファクタリングの手法

手法としては、下記の図のようにデータベースをコピーし、コピー先でテーブルを適切に再設計したテーブル構造に割り振るようにしました。これにより、既存のシステムは全く影響を受けません。

そして、切り替え方は、参照を抽象化するためREST APIを用意し、参照・更新をAPI経由にすることで、モデル層のリファクタリングとDB移行を段階的に行うことにしました。

ここで重要な判断は、移行先のRDBMSとして元のAmazon AuroraのベースであるMySQLではなく、PostgreSQLを採用したことです。理由は2つあります。

1つ目は、古いデータ構造から新しいデータ構造に変更する部分を、トリガーが担っていることです。Aurora 1系のベースになっているMySQL 5.6は、1つのテーブルの1つのイベントに1つのトリガーしか設定できません。通常の範囲であればそれで必要十分といえるのですが、今回はかなりの大規模なリファクタリングになりました。

実際にpartyテーブルは、1つのテーブルから5個以上に分割しています。そうなると、1つのトリガーで全て対応するには責務が大きすぎます。

MySQL 5.7やMySQL 8、Aurora 2系も検討しましたが、トリガーの柔軟性ではPostgreSQLが優れていたため、個数に制限のないPostgreSQLを採用しました。

しかし、現状はAuroraを使っているため、PostgreSQLには異種DB間の移行が必要になります。異種DB間移行ツールをいくつか検討した結果、AWS Database Migration Service（以下、DMS）を採用しました。

DMSでは、異種DB間でもリアルタイムに、まるで非同期レプリケーションしているかのように連携できるため、サービスを止めることなく移行が可能になります。また、コスト面でもDMSで利用するインスタンスサイズのみと、他のツールより圧倒的にメリットがありました。

以上の結果から、現在は次のような構成になっています。

もう1つの理由は、慣れているプログラミング言語でストアドファンクションを書けるという点で、次のブログ記事でも説明しているようにpl/v8（JavaScript）を採用しています。

DBリファクタリングをやっているって話 - そーだいなるらくがき帳

この状態で、APIを作るところまでは既存のサービスは全く影響を受けません。ある程度APIを作って、APIの結果と既存の結果のdiffを見ることで、振る舞いのテストをすることもできます。参照の切り替えもAPI単位で行うことができ、ロールバックも簡単に行うことができるため、小さく始めることに適しています。

異種DB間移行については、実担当の id:ikkitang1211がブログにまとめているので参考にしてください。

PostgreSQL Conference Japan 2018 に参加&異種DB移行プロジェクトについて登壇させて頂いた。 - お？意外といけるやん！

データベースリファクタリングの進捗

実際に上記の方法で準備を始めて、現在7カ月が経っています。メリットである既存サービスに影響を与えないこと、API化することでデータストア層を抽象化できることが功を奏して、順調に移行しています。

もっとも現状のスケジュールでは、完全に移行できるのは2019年4月を目処にしていますので、1年計画となります。また、移行して終わりではなく、移行後も新たなデータベースリファクタリングは始まります。なぜなら、データは移行中も移行後も成長し続けるからです。

これからも戦い続けるエンジニアへ

ここまで読んでいただきましたが、いかがでしたか？ データベースリファクタリングは、その影響範囲の広さから苦労も多く、その割にはビジネス的なメリットが少ないと言われることが多いところです。新機能の追加の優先順位を高くすることで、どうしても後回しにされがちなタスクですが、いつかは向き合う必要があります。

データベースの問題は、時間が経てば経つほどデータベース自体の成長とともに大きくなっていきます。だからこそ、誰かが覚悟を持って取り組んで行く必要があります。そして、その誰かはそのサービスに触れているあなた自身です。

私の尊敬するエンジニアの言葉を引用します。

手を動かしたものだけが世界を変える by id:onishi

この言葉は真理だと思っています。あなたのサービスを育て、変えていくのはあなたのその手に委ねられているのです。この記事を見た皆さんも、これを機に自分たちのデータベースをぜひ見直してみてください。

曽根 壮大（そね・たけとも） @soudai1025 / soudai

株式会社オミカレ副社長兼CTO。数々の業務システム、Webサービスなどの開発・運用を担当し、2017年に株式会社はてなでサービス監視サービス「Mackerel」のCRE（Customer Reliability Engineer）を経て現職。コミュニティでは、Microsoft MVPをはじめ、日本PostgreSQLユーザー会の理事として勉強会の開催を担当し、各地で登壇している。builderscon 2017、YAPC::Kansaiなどのイベントでベストスピーカーを受賞し、分かりやすく実践的な内容のトークに定評がある。他に、岡山Python勉強会を主催し、オープンラボ備後にも所属。『Software Design』誌で、データベースに関する連載「RDBアンチパターン」などを執筆。
ブログ：そーだいなるらくがき帳