DBリファクタリングについて

26Pは現状です。

f:id:Soudai:20180525103435p:plain

MySQLって書いてますが本番はAurora1を使っています。以降、このDBを 現行DB と呼びます。ここではオミカレとみんなの婚活はWebサービス名です。つまり2つのサービスから現行DBを見ていますし、機能によっては現行DBの同じテーブルを参照・更新・削除などを行います。この2つ以外にも社内システムなどでこの現行DBは利用されており、メインのテーブルを変更すると影響範囲が広い状態です。このようなモノリスな状態は世の中では悪の権化のように言われますがスタートアップが取る戦略としては悪くないと思っています。なぜならばRDSは会社の運用で考えると激安ですが個人の支払いと考えると安くなく、オミカレもサービス開始当初は社長のポケットマネーで運用されていたわけですし、インフラコストを抑えることは重要な課題でした。しかしながら時は経ち、サービスが大きくなるとこの状態は気軽な変更を許さない状況になります。特に主要なテーブルは多くのサービスが参照しているのでALTERを流すのは職人芸になりますし、マスタ系に長時間テーブルの共有ロックを取るようなSELECTを流すとサービス障害の呼び水になります。なのでこの状態から脱していくために現在進めているのが下記です。

f:id:Soudai:20180525105034p:plain

右側にあるPostgreSQLのバージョンは10でRDSで運用されています。これを以降は 新DB と呼びます。現行DBから新DBのデータはリアルタイムで行っています。 MySQLならレプリケーションでいいのですが異種DBなのでここはAWS DMSを活用しています。他にもOracle GoldenGateも調べましたがRDSに移すと決めたのでAWS DMSを採用しています。現行DBから新DBには同じスキーマ構造（テーブル構造）でコピーします。その際に新DB側にINSERT・UPDATEなどのEventをトリガーに更に自分たちが使いたい新テーブル構造にコピーしています。つまり新DB側には現行DBにあるスキーマとリファクタリング後の形である新スキーマがあります。 WebAPIはこの新スキーマを参照します。しかしWebAPIは新DBに書き込むと現行DBを参照しているシステムに影響があるため、現行DBに書き込みを行います。するとDMS経由でコピーされ、トリガー経由で新DBの新スキーマに反映されるという流れです。こうやって少しずつ既存のDBアクセスをWebAPIに寄せていき、最終的にはリファクタリングされたDBに切り替えていこうというのが主旨です。

この手法のメリット・デメリット

メリットは次のような点です。

停止時間を極小化できる
既存の仕組みを残したまま、アグレッシブにリファクタリング
カナリアリリースのような感じ少しずつ切り換えていける
新規開発が既存の仕組みに与える影響が少ない
既存からの切り換えはリポジトリパターンなどを使えばブルーグリーンデプロイメントっぽく参照先を切り替えるだけに出来る

このように本番の仕組みの影響範囲を小さく出来るのがメリットです。しかしながら大きなデメリットもあります。

ローカルの開発環境で再現できない
今まではVagrantでVMを一つ立ち上げるだけで済んでた
関係するシステムが多いので開発環境を用意する手順が多い
AWSに開発環境を作る場合も手順が多く、1人１環境を用意するのが大変
DMS経由のコピーに遅延が発生した時の考慮が難しい
リファクタリングが終わるまで、AWSに依存する
例えばDMSの仕様変更とか食らうと死ぬ可能性がある

特に開発フローに与える影響はめちゃめちゃ大きいです。ですのでDMSに依存した状態をずっと続けることは難しいのここからはスピード勝負だなと思っています。

なぜPostgreSQLに移行するのか

色んな理由がありますが決め手はリファクタリングの時に書くトリガーの柔軟性とストアドです。 PostgreSQLは PL/pgsql 以外にも PL/perl を始めとした代表的な言語で書く仕組みがあります。当初は PL/Python で書こうと思っていたのですがRDSがサポートしていなかったため、 PL/v8(JavaScript) を採用しています。