20年稼働の保険契約管理システムの段階的モダナイズ
保険会社C社の契約管理システムは、20年前に構築したJavaモノリスで、約250万行、画面800本、夜間バッチ1,200本からなる。リリースは年2回で、1回の変更に対し影響調査だけで3週間、回帰テストに2か月を要している。開発は3社のベンダに委託し、常駐要員は40名、設計書は一部にしか存在せず、業務ルールの多くはプログラム中に埋め込まれている。経営層は「新商品を3か月で投入したい」としており、競合は2週間で投入している。システム部はクラウド移行とマイクロサービス化を組み合わせた刷新を構想しているが、予算は3年で12億円、中断できない業務が多く、全面停止は年1回の年末年始の3日間のみ可能である。可用性は99.9%、ピーク時のトランザクションは毎秒300件である。直近3年の障害は、バッチ間のデータ受け渡しの不整合が4割を占めている。
1. マイクロサービス化に先立って着手すべきことを、リスクの観点から3つ挙げよ。
Read the worked answer
- 現状の可視化（依存関係と変更のホットスポット）：設計書が一部しかなく、業務ルールがコードに埋まっている状態で分割すると、切り出した先で同じルールが二重実装される。まず画面・バッチ・テーブルの依存関係を機械的に抽出し、変更頻度と障害履歴を重ねて「触ると危ない箇所」を特定する。障害の4割がバッチ間のデータ受け渡しにあるという事実は、境界の候補を考える最良の手がかりになる。
- テストとリリースの自動化：マイクロサービス化は独立したデプロイを増やす施策であり、回帰テスト2か月のままではサービスごとの頻繁なリリースは成立しない。テスト自動化、CI/CD、環境の即時払い出しを先行して整える。
- 可観測性と運用手順の整備：分散すると1つの処理が複数サービスをまたぎ、障害調査は難しくなる。トレーシング、相関ID、ログ集約を先に入れる。また3社のベンダの責任分界をサービス単位に引き直す契約上の整理も必要になる。
予算12億円・停止は年1回3日という制約下では、一括リプレースは非現実的であり、上記の土台づくりに初年度を使う判断が妥当である。
2. 分割境界の決め方と、移行方式（ストラングラーパターン）の具体化について述べよ。
Read the worked answer
境界の決め方
- 業務能力（契約引受、請求、収納、保全、支払）とデータ所有権で切る。同一トランザクションで同時に更新されるものは同一サービスに残す。分散トランザクションを持ち込むと、現在の障害原因であるデータ不整合が悪化する。
- バッチ1,200本は「即時性が要る処理」と「夜間にまとめてよい処理」に分け、前者をAPI化し、後者は当面そのまま残す。
- 優先順位は、変更頻度が高く独立性の高い領域から。新商品投入のリードタイム短縮が経営目的である以上、商品定義・見積・引受の周辺が最初の候補になる。
移行方式
- 年末年始の停止期間に、APIゲートウェイと新フロントを入れ替える。このとき旧モノリスはAPIの裏に残す。
- 画面単位・機能単位で新旧を振り分け（ルーティング）、新サービスが安定したら旧機能を停止する。ロールバックはルーティングを戻すだけで済む形にしておく。
- データはサービスごとに所有させ、他サービスからは直接テーブル参照させずAPI経由にする。
- 各段階で性能・可用性の非機能要件（毎秒300件、99.9%）を検証してから次へ進む。
3. 新旧が並存する移行期間中のデータ整合性をどう設計するか述べよ。
Read the worked answer
原則：二重書き込みをさせない。 新旧両方にアプリから書くと、どちらかが失敗したときにどちらが正しいか決められなくなる。
具体策
- 所有者を一意に決める：移行期間中も、各データの正は必ず一方に置く。旧から新へは変更データ捕捉（CDC）やイベントで一方向に同期する。
- 結果整合の範囲を業務と合意する：参照系は数秒の遅れを許容、契約の確定や金額確定は即時、帳票は翌日など、データ種別ごとに許容遅延を決めて文書化する。ここを決めずに設計を進めると、現場で二重確認が発生して生産性が落ちる。
- 冪等性と再送：イベントには一意キーを付け、再送しても二重計上しない構造にする。失敗はデッドレターキューに退避し、再処理手順を運用に組み込む。
- 突合の自動化：夜間に件数・金額・主要項目の新旧比較を行い、差異を翌朝までに検出する。差異が出た場合の調査手順と、業務側への連絡フローも決める。
- 補償処理：サービスをまたぐ処理が途中で失敗した場合に、取消・再実行で整合を戻す設計をあらかじめ用意する。