レガシーJavaモノリスからKotlinマイクロサービスへ：モダナイゼーション開発ノート

プロジェクト背景とモダナイゼーションの必要性

当社では10年以上稼働してきたJava EEモノリスを中心に、在庫管理や受注処理を担う大規模システムを運用していました。しかし、開発・テスト・デプロイの時間が増大し、新機能リリースに要する「費用」が高騰する一方で、市場の要望に迅速に対応できない状況が続いていました。加えて、システム全体を保守する「開発会社」による年間保守契約の相場が¥8,000,000を超え、自社の「予算」を圧迫していました。そこで、マイクロサービス化によって機能ごとの独立開発・スケールアウトを可能にし、CI/CDの高速化や運用コスト削減を実現するモダナイゼーションプロジェクトを立ち上げました。
本番稼働中のモノリスを止めずに移行するため、「発注」前のPoC（概念実証）では、在庫管理機能のみを切り出したKotlin＋KtorマイクロサービスをAWS Fargate上で動作させ、APIレスポンスタイムと可用性を測定。これにより「相場」感と実運用に即した性能要件を明確化し、モノリスからの段階的移行ロードマップを策定しました。

開発会社選定と予算・費用モデル

モダナイゼーションの成否を左右するのが、マイクロサービス移行の技術力を持つ「開発会社」の選び方です。選定時には以下のポイントを重視しました。

• マイクロサービス実績：Spring BootからKotlin移行の経験、AWS FargateやEKSでの運用実績

• CI/CD構築力：GitHub ActionsやJenkinsでの自動デプロイパイプライン構築経験

• インフラ自動化：Terraform／CloudFormationによるIaC（Infrastructure as Code）運用

• テスト自動化：Contract TestやIntegration Testを含むテスト戦略策定能力

• 運用保守体制：SREチームと連携したSLA設定、モニタリング／アラート設計ノウハウ

候補に挙がったA社は豊富なSpring実績があったものの、Kotlin経験が浅かったため、初期PoCでの生産性が懸念材料となりました。B社はKotlinネイティブチームを抱えており、PoC期間中にAPI応答時間を平均120ms→80msに改善。これを受けて、B社への「発注」を決定し、初期「予算」を¥3,500,000（50時間単価¥70,000設定）、本開発「費用」を¥12,000,000、保守フェーズ年間¥1,800,000と見積もりました。この見積書にはマイクロサービス10サービスポテンシャル分を含め、相場をもとにリスクマージンを加味しています。

移行アーキテクチャと技術検討

移行アーキテクチャでは、以下の要素を基本設計に盛り込みました。

• APIゲートウェイ：AWS API Gatewayでルーティングと認証を一元管理

• サービス間通信：gRPC＋Protocol Buffersで低レイテンシかつ型安全な呼出し

• データベース分割：在庫DBを独立し、PostgreSQL⇔MongoDBへのフェーズ移行を検討

• 認証認可：KeycloakをIDプロバイダとしてOAuth2／OpenID Connectを整備

• ログ＆メトリクス：Fluentd⇒Elasticsearch⇒KibanaのELKスタックとPrometheus＋Grafanaで可観測性設計

これらをPoCで検証した結果、API Gatewayのcold start問題はLambda Edgeキャッシュで緩和し、gRPC接続プール化で接続確立時間を20％短縮できました。また、Keycloak導入によりシングルサインオン対応が容易になり、クライアントサイドの認証実装工数を約30時間削減しました。
移行計画では、最初に在庫管理を切り出し、次に受注→配送と段階的にサービスを分割。本番データ移行用のスクリプトはFlywayでバージョン管理し、リリース時のデータ整合性トラブルをゼロに抑えました。

PoCフェーズと要件定義の教訓

PoCでは3週間で移行検証を完了し、当初想定していた70時間を実際には60時間で終え、技術的負債の洗い出しも行えました。具体的な教訓は以下のとおりです。

• ドメイン境界の曖昧さ：在庫と価格計算ロジックがモノリス内で密結合しており、分割前にドメインモデルを整理しないと追加「費用」が発生

• API設計の難易度：モノリスのRESTエンドポイントをそのままgRPC化すると、パラメータ設計不整合が多発

• データマイグレーション：リアルタイム同期よりバルクロード＋差分同期のほうがコスト最適

• テストデータ管理：モノリスとマイクロサービス間テスト環境のデータ差異でQA工数が10時間増加

これらを踏まえ、要件定義ではドメインモデル図を詳細化し、ストーリーポイント見積もりと共に優先度を明確化。RFPには必ず「API設計ドキュメント」「マイグレーション手順書」「テストデータ設計書」の提出を要件に含め、開発会社との認識齟齬を防ぐ体制を構築しました。

実装フェーズ：サービス分割とAPI移行

マイクロサービス化の実装は、まずモノリスから切り出す対象サービスを明確に定義することから始まりました。今回のプロジェクトでは在庫管理サービスを第1フェーズとし、Kotlin＋KtorでREST APIを再構築しました。API仕様はOpenAPI 3.0でドキュメント化し、既存モノリスからのパラメータ互換性を保つことでクライアント修正工数を最小限に抑えています。gRPCを検討しましたが、既存クライアントがREST前提だったため段階的移行とし、次フェーズでの検討課題としました。データベースはモノリスDBの在庫テーブルを輪切りにしてPostgreSQLの新インスタンスへレプリケーションを設定し、双方向同期を得てダウンタイムゼロを実現。マイグレーションスクリプトはFlywayでバージョン管理し、リハーサル環境での検証を6回以上繰り返してトラブルを回避しました。この段階で発生した追加「費用」は約¥300,000で、要件定義時に余裕を見込んでおいた「予算」の中に十分収まったため、最終的なTCO試算にも影響がありませんでした。

CI/CDとインフラ自動化

開発効率と品質を両立するため、CI/CDパイプライン構築は優先度高く設定しました。GitHub Actionsでプルリクエスト毎のLintチェック、ユニットテスト、Dockerイメージビルド、ステージング環境への自動デプロイを実装。インフラはTerraformでコード化し、AWS FargateおよびRDSインスタンスをIaC管理しています。デプロイはBlue/Green方式を採用し、ダウンタイムなしでのリリースが可能です。また、環境変数やシークレットはAWS Secrets Managerで一元管理し、ログはFluentd経由でElasticsearchに集約。ダッシュボードはKibanaとGrafanaを併用し、レスポンスタイムやエラー率を可視化しています。CI/CD構築工数は約120時間で、開発会社への「発注」費用は¥840,000。相場感としては¥600,000～¥1,000,000のレンジ内で適切でした。

テスト戦略と品質保証

サービス切り出し後はテスト戦略にも重点を置きました。ユニットテストはKotlinTest（Kotest）でビジネスロジックを網羅し、Integration TestではTestcontainersを用いて実DB連携を検証。API契約テストにはPostmanとNewmanを採用し、仕様変更時の回帰検証を自動化しました。さらに、Contract Test（Pact）でモノリス側と新サービス間のインターフェース整合性を確保。E2EテストはCypressを利用し、主要ユーザーフローをカバーしました。テスト自動化全体で約80時間を投入し、追加「費用」¥560,000。テスト工数を予算時点で8％上乗せ見積もりしていたため、大きな追加コストなく進められたのが教訓です。

本番リリースとローリングアップデート

本番リリースはステージングでの合格後、カナリアリリース方式で実施しました。5％のトラフィックを新サービスに流し、CloudWatchアラートでエラー率3％超過時に自動ロールバック。実際にキャッシュ設定ミスでエラーが一時増加しましたが、ロールバック機能とTerraformによる設定管理で20分以内に復旧できました。安定性確認後、残り95％のトラフィックを段階的に切り替え、最終的に1時間で完全移行を完了。DNS TTL短縮とカナリアリリースは発注時の「選び方」チェック項目に含めるべき重要な施策でした。

運用・監視とトラブルシューティング

リリース後は運用体制を整備し、SLAを「初動1時間、復旧8時間以内」と定義。運用チームにはPagerDutyを導入し、夜間休日のインシデント対応もカバー。Prometheusでメトリクス収集し、Grafanaダッシュボードでリアルタイム監視。エラー検出時はSlack通知で即時に共有し、過去6カ月で平均対応時間を60分→30分に短縮しました。また、インシデント後は必ずポストモーテムを実施し、原因分析レポートを定型化。これにより再発防止策を自動的に「開発会社」へフィードバックし、継続的改善を図っています。

保守契約とコスト最適化

保守契約はB社と年間¥1,800,000で締結し、保守項目をフェーズ別に明文化しました。月次でKPIレビューを行い、コスト対効果を評価。マイクロサービス10個を追加発注する場合でも、1サービスあたりの保守費用は¥150,000程度と、モノリス時代の相場（¥8,000,000超）から大幅に低減。今後も新サービスは同一保守契約内で対応できるため、年間「予算」の予測精度が向上し、無駄なコストを抑制できます。

成果測定とROI分析

移行後半年の成果をまとめると、以下の通りです。

• デプロイ工数：3週間→1週間に短縮（66％削減）

• 開発サイクル：新機能リリースまでの工数240時間→100時間（58％削減）

• インシデント対応時間：平均90分→30分（67％改善）

• 運用コスト：¥8,000,000→¥1,800,000（78％削減）

初期投資¥15,500,000（開発＋保守）に対し、年間効果¥6,200,000と非金銭的効果を加味し、ROIは約40％を達成。マネジメント層には「開発会社への発注判断」と「予算内でのモダナイゼーション成功」を高く評価され、追加プロジェクトへの予算獲得にもつながりました。

今後の拡張と学び

今後は以下を計画中です。

• イベント駆動アーキテクチャ：Kafka連携による非同期処理拡張

• サーバレス移行：一部バッチ処理をAWS Lambdaへオフロード

• 可観測性強化：OpenTelemetryでトレースとメトリクスを一元管理

• ヘッドレスCMS連携：Next.js＋GraphQLでコンテンツ管理を柔軟化

最大の教訓は、要件定義フェーズでのドメイン境界明確化とマイグレーション計画の精緻化です。これにより追加「費用」を抑え、相場感を超えた成果を実現できました。

ぜひ