大きな業務システムを、小さなサービスに分けて更新しやすくしたい。しかし、注文、会員、支払いの処理が同じデータベースを使っていると、コードを分けてもデータを通じた依存は残ります。
マイクロサービスへ移行する際、何を一つのまとまりとして扱えばよいのでしょうか。OCP Korea Tech Day 2026のTwolinecloudによる講演は、「誰がどのデータを書き換えるか」を出発点に、分割後の処理まで追う方法を示しています。その例から、境界を決める前に確かめたい点を見ていきます。［1］
簡単にまとめると？
- テーブルを読む処理と書き換える処理を分け、複数の更新者が隠れていないか確認します。
- 境界を越える参照、データの結合、更新では、分割後に必要な設計が異なります。
- 途中で失敗したときの対応と、既存APIの利用者への影響まで追うと、移行単位を判断しやすくなります。
サービス名より、書き込み先を見る
講演では、業務を扱う範囲を表すBC（Bounded Context、境界づけられたコンテキスト）に、どのテーブルを対応させるかを検討します。その手掛かりが、サービスを行、テーブルを列にした図1の表です。Wは書き込み、Rは読み取りを表します。［1］
注文サービスは注文・明細テーブルを書き、支払いサービスは支払いテーブルを書きます。一方、BatchServiceの行にも、会員と注文へのWがあります。サービス名だけを見て担当を決めると、この共有更新を見落とします。
書き込み元が一つなら担当を考える手掛かりになり、複数なら、共有更新をどう整理するかが検討事項になります。読み取りだけで共有するデータも分けて見ます。表で見つかった関係を業務フローと照合することで、分割後も複数のサービスが同じデータを直接書き換える状態を、設計の段階で検討できます。［1］
つながりの種類によって、直し方が変わる
分割を考えるときは、外部キー（FK）による参照、複数テーブルを結ぶJOIN、一連の処理による複数領域への書き込みを区別します。
講演は、外部キーをID参照と問い合わせAPIへ置き換える方法や、JOINをAPIの組み合わせ・読み取り用モデルへ変える方法を挙げています。APIは、別のサービスに処理やデータを求める窓口です。問い合わせ先が増えれば、応答時間も設計し直す必要があります。データを別々に置くことに加え、従来の画面や処理をどう動かすかが課題になります。［1］
注文だけ進んだら、どう戻すか
注文と支払いを別サービスへ分けるときは、片方だけ進んだ場合の扱いも決めます。SAGAは、複数段階の処理と、失敗時に業務上のつじつまを合わせる補償処理を設計する考え方です。返金できる処理と、送信した事実を戻せないメールでは、対応が異なります。
講演が挙げる確認事項は、補償が業務上可能か、途中の状態を利用者へどう見せるか、補償に失敗したとき人がどう介入するか、の三つです。分割後の成功経路だけでなく、失敗した仕事の扱いまで含めて移行単位を考えます。［1］
APIを呼ぶ側まで、変更を追う
読み取り側にも影響があります。注文APIが会員テーブルをJOINして会員名や会員ランクを返していたとします。その直接参照をやめ、会員IDだけを返す設計へ変えるなら、呼び出す画面や連携システムにも変更が必要です。講演はこの例を示し、APIから実際のクエリまで根拠をたどって変更対象を列挙するよう求めています。［1］
移行候補を選ぶ際は、業務上の価値、境界を越える参照や共有更新の多さ、コードやテストの状態を合わせて見る。これが講演の提案です。書き込み元が一つでも、境界を越える参照や一連の処理が残れば独立運用できるとは限らず、共有更新の多い範囲は依存を整理してから、価値があり結合の弱い範囲から移す方針を示しています。まず一つの処理について、書き込み先、途中失敗への対応、APIの利用者を追ってみると、どこを分けられそうで、どこに再設計が必要かが具体的になります。［1］
参考資料
- Twolinecloud, A Methodology for Successfully Transforming Monolithic Systems into Cloud-Native Microservices Architectures, OCP Korea Tech Day 2026。原資料PDF 4・10–11・14–16・19頁。講演資料