【マイクロサービス】「データの整合性」の担保（サーガ）

普通にやればマイクロサービスはいろんなところにDBが乱立するのでデータ整合性が難しくなります。

2層コミット

分散データベースに対してそれぞれのDBにコミットしていき整合性を担保する古くからある手法です。

いきなりコミットするのではなく、DB1とDB2にコミットして良いか確認して良い言われたらコミットする方式。

デメリット

全体で同期的になってしまい稼働率が下がってしまうためマイクロサービスでは基本的にアンチパターンになります。

サーガ

マイクロサービスではこちらが主流です。3つのフェーズで実装していきます。

フェーズ

フェーズ1：補償可能トランザクション

ロールバック用の処理です。失敗する可能性があるので。つまり「正常処理用のAPI」と「ロールバック用のAPI」でAPIが二つ必要になります。

フェーズ2：ピポットトランザクション

ロールバックを要求するかの境界になります。

フェーズ3：再試行可能トランザクション

必ず成功するトランザクションになります。

サーガの協調

コレオグラフィ

各サービスが必要なイベント（トピック）をサブスクライブして協調する。

オーケストレーション

中央のコーディネーターが各サービスに対して指示をする。複雑なトランザクションの場合はこちらを利用する。

サーガの問題点

ACID特性の独立性（Isolation)を守ることができない。

大きく4つの問題がある。

用語	説明
ロストアップデート	他の更新処理を古いデータをもとに更新して更新したはずのデータを消失する。(例えば、AさんとBさんが同時に更新処理をしようとしたとして同時に読み出していて、書き込むときにAさんの書き込みが後から書き込むBさんの書き込みで上書きしてしまうような事象）
ダーティーリード	更新途中のデータを読み取ってしまい不整合が起きる。（Aさんが処理している途中のデータをBさんが読み出して更新した場合など。Aさんが後でロールバックすると不整合になる。）
ファジーリード	他の更新処理を古い情報をもとに上書きしてしまい、更新したはずのデータを消失する。
ファントムリード	サーガの読み取り操作において他のサーガが途中で動作するとタイミングによって異なる結果になる。

対策

RDBの「悲観ロック」、「楽観ロック」に相当する。

対策	説明
業務要件から判断	業務要件的に重要度が高くないので諦める。
値再読み込み	楽観ロック。書き込み時に値が異なっていたらロールバック。
セマンティックロック	悲観ロックに相当。セマフォを使って排他制御します。（例：DBに「状態」列を用意して「PENDING」、「DONE」などの状態を持たせる）