モノリスからマイクロサービスに至る過程でよくある分散モノリスをどのように分割していくか。
いくつかアプローチを考えたので整理してみた。
1. 内部通信
たぶん一番よくあるやつ。RPCやHTTPリクエストなどでアプリケーション間の通信を行う。
この場合には必ずしもアプリケーション毎に固有のDBを持つ必要はない。
しかし、この設計ではAP1の可用性がAP2の可用性に実質依存しているため、AP2がAP1の障害点となってしまっている。データベース自体は分離できているものの、サービス毎の可用性は低い。
2. イベント駆動
キューやPub/Subなどを利用して非同期的にデータを受け取り、逐次的にサービス毎の固有DBにデータを永続化していくパターン。内部通信とは異なり、別のサービスの可用性に影響を受けない。
しかし一方で、すでに稼働中のアプリケーションにサービスインする場合、異なるサービスのデータが必要であれば予めデータマイグレーションなどを行っておく必要がある。したがって、サービス間のデータ整合性を保つためにはトラフィックが多いタイミングでのサービスインを避けるなど、リリースのタイミングに気を使う必要がある。
3. 内部通信+イベント
イベント駆動で逐次的に固有のDBへデータの永続化を行いつつ、データが存在しない場合には内部通信でデータの問い合わせを行う。
例えばAP1のサービス上にデータが存在しない場合の具体的なフローは以下。
一度永続化が完了すれば、あとはイベント駆動のフローに乗せることができるため、イベント駆動で問題となるサービスインのタイミングも気にする必要がない。また、内部通信だけの場合と比べて可用性も担保できる。しかし一方で、データの更新をどのタイミングで行うかが課題になる。