はじめに: ROI を定量化した実際の移行
このシリーズの最後の記事では、 詳細なケーススタディ: 12 のマイクロサービスからモジュール式モノリスに移行したヨーロッパのフィンテック スタートアップの物語 4ヶ月以内に。移行の理由、実行フェーズ、結果を分析します。 数値化され、教訓が得られます。すべての数値は現実的であり、経験に基づいています この分野における同様の移民の集合体。
このケーススタディは、マイクロサービスからモジュラーモノリスへの移行が 1 つのステップではないことを示しています 戻ってきましたが、 戦略的ステップ 大幅な節約を生み出すことができ、 エンジニアリングチームの生産性を向上させます。
この記事で学べること
- コンテキスト: スタートアップのストーリーと 12 のマイクロサービスへの道のり
- 問題点: コスト、複雑さ、導入時間、MTTR
- 決定: モジュラーモノリスが選ばれた理由
- 移行の 4 つのフェーズ: タイムラインとチーム構造
- 最終的なアーキテクチャ: 5 つの境界付きコンテキスト、Spring Boot、PostgreSQL
- 結果: 定量化された ROI を含む前後のメトリクス
- 学んだ教訓: 何が効果的で、何を避けるべきか
- ビジネスへの影響: コスト、生産性、チームの満足度
コンテキスト: モノリスから 12 のマイクロサービスまで
ペイフロー (仮名) は、2019 年に設立されたフィンテック スタートアップです。 ヨーロッパの中小企業向けの支払い管理プラットフォーム。チームの開発者は 4 人から 22 人に増加しました 3 年間で、アーキテクチャもそれに応じて進化しました。
建築進化のタイムライン
- 2019-2020: Spring Boot の初期モノリス。 4 人の開発者、実用的な MVP、製品マーケット フィットを達成
- 2020-2021：急成長。開発者は12名。コードベース内の最初の競合の問題。決定: マイクロサービスを採用する
- 2021-2022: マイクロサービスへの移行。 12のサービスを抽出しました。 Kubernetes、サービス メッシュ、API ゲートウェイ。チームは 22 人の開発者に成長
- 2022～2023年: 複雑さが爆発します。インフラストラクチャのコストは 6 倍。 MTTRが増加します。展開時間は 5 分から 45 分です。チームは時間の 60% を運用に費やします
12 のマイクロサービス
PayFlow のマイクロサービス アーキテクチャは次のもので構成されていました。
- ユーザーサービス: 認証、プロファイル、オンボーディング
- 決済サービス: 決済処理、ゲートウェイ統合
- 請求書サービス: 請求書の作成と管理
- 通知サービス：メール、SMS、プッシュ通知
- レポートサービス: ダッシュボード、分析、エクスポート
- サブスクリプションサービス: プラン、定期請求
- マーチャントサービス: 加盟店管理、KYC
- トランザクションサービス: トランザクションログ、調整
- Webhookサービス: 入出力 Webhook 管理
- 構成サービス: 集中設定
- ゲートウェイサービス: APIゲートウェイ、レート制限
- 監査サービス: 監査ログ、コンプライアンス
問題点: マイクロサービスが機能しなかった理由
2023 年までに、この状況は持続不可能になりました。定量化された問題は次のとおりです。
インフラストラクチャのコスト
- Kubernetes クラスター: 3 マスター ノード + 9 ワーカー = 4,200 ドル/月
- データベース: 6 PostgreSQL (RDS) インスタンス = 2,400 ドル/月
- メッセージブローカー: RabbitMQ クラスター = $600/月
- サービスメッシュ: Istio + モニタリング = 月額 800 ドル
- ロギング/モニタリング: データドッグ = 1,500 ドル/月
- トータルインフラストラクチャー: $9,500/月 (114,000ドル/年)
運用指標 (以前)
- デプロイ時間: 45 分 (すべてのサービスを含む完全なパイプライン)
- 導入頻度：週2～3回（要調整）
- MTTR：4.2時間（分散デバッグ、ログ集計）
- インシデント/月: 8-12 (ネットワークの問題、タイムアウト、連鎖的な障害)
- 稼働時間: エンジニアリング時間の 60% が運用とメンテナンスに費やされます
- オンボーディング: 新規開発者の場合は 6 ～ 8 週間
決定: なぜモジュラーモノリスなのか
CTO は アーキテクチャ決定記録 (ADR) 評価したチーム 3 つのオプション:
- マイクロサービスを継続する プラットフォームエンジニアリングへの投資
- 従来のモノリスに統合
- モジュラーモノリスへの移行
// Architecture Decision Record (ADR)
// ADR-2023-07: Migration to Modular Monolith
// Status: ACCEPTED
// Date: 2023-07-15
// Decision Makers: CTO, VP Engineering, 3 Tech Leads
// Context:
// - 12 microservices, 22 developers
// - $114K/year infrastructure cost
// - 60% engineering time on operations
// - MTTR 4.2 hours, 10 incidents/month
// Decision: Migrate to Modular Monolith
// Reasons:
// 1. Team size (22) does not justify 12 independent services
// 2. Traffic patterns do not require independent scaling
// 3. Strong consistency needed for payment processing
// 4. Operational overhead unsustainable
// 5. Modular monolith preserves extraction option
// Expected Outcomes:
// - Infrastructure cost: -60% to -70%
// - Deploy time: -80%
// - MTTR: -60% to -70%
// - Engineering productivity: +40% to +50%
// - Onboarding time: -50%
移行の 4 つのフェーズ
フェーズ 1: 分析と計画 (第 1 ～ 2 週目)
チームは 2 日間のイベント ストーミングを実施し、次のことを特定しました 5 有界 コンテキスト ナチュラル (12 サービスから 5 モジュールへの統合):
- 身元: ユーザー + マーチャント + 監査 (3 つの統合サービス)
- 支払い: 決済 + トランザクション + サブスクリプション (3 つの統合サービス)
- 請求する：請求書+レポート（2つの統合サービス）
- コミュニケーション: 通知 + Webhook (2 つの統合サービス)
- プラットフォーム: Config + Gateway (2 つの統合サービス)
フェーズ 2: セットアップと最初のモジュール (3 ～ 6 週目)
チームは Spring Modulith を使用して新しい Spring Boot プロジェクトを作成し、最初のプロジェクトを移行しました 概念実証としてのモジュール (アイデンティティ)。最初のモジュールの移行には 4 週間かかりました インフラストラクチャの設定、設計規則、パターンが含まれているため 参考。
フェーズ 3: コア モジュールの移行 (第 7 ～ 12 週)
残りの 4 つのモジュールは 2 つのチームによって並行して移行されました。支払いとステータスモジュール トランザクションの一貫性と PCI-DSS 準拠の要件にとって最も複雑です。
フェーズ 4: 安定化とカットオーバー (第 13 ～ 16 週)
過去 4 週間は、集中的なテスト、データ移行、カットオーバーに費やされました。 トラフィックが古いシステムから新しいシステムに徐々に移行します。
最終的なアーキテクチャ
// Struttura del Modular Monolith finale
// com.payflow/
// ├── identity/
// │ ├── api/
// │ │ ├── IdentityModuleApi.java
// │ │ ├── UserDto.java
// │ │ ├── MerchantDto.java
// │ │ └── UserRegisteredEvent.java
// │ └── internal/
// │ ├── user/ (ex User Service)
// │ ├── merchant/ (ex Merchant Service)
// │ └── audit/ (ex Audit Service)
// ├── payment/
// │ ├── api/
// │ │ ├── PaymentModuleApi.java
// │ │ ├── PaymentDto.java
// │ │ └── PaymentCompletedEvent.java
// │ └── internal/
// │ ├── processing/ (ex Payment Service)
// │ ├── transaction/ (ex Transaction Service)
// │ └── subscription/ (ex Subscription Service)
// ├── billing/
// │ ├── api/
// │ │ └── BillingModuleApi.java
// │ └── internal/
// │ ├── invoice/ (ex Invoice Service)
// │ └── reporting/ (ex Reporting Service)
// ├── communication/
// │ ├── api/
// │ │ └── CommunicationModuleApi.java
// │ └── internal/
// │ ├── notification/ (ex Notification Service)
// │ └── webhook/ (ex Webhook Service)
// └── platform/
// ├── api/
// │ └── PlatformModuleApi.java
// └── internal/
// ├── config/ (ex Config Service)
// └── gateway/ (ex Gateway Service)
// Stack tecnologico:
// - Spring Boot 3.2 + Spring Modulith
// - PostgreSQL (schema condiviso con prefissi per modulo)
// - RabbitMQ (mantenuto per eventi cross-module critici)
// - Spring Events (per eventi in-process)
結果: 前後のメトリクス
移行完了から 3 か月後に測定された結果は次のとおりです。
インフラストラクチャのコスト
- 前に: $9,500/月 (12 サービス、6 データベース、複雑な Kubernetes)
- After: $3,300/月 (アプリ インスタンス 4 つ、データベース 1 つ、RabbitMQ 1 つ)
- 貯蓄: -65% (年間 74,400 ドルの節約)
導入パフォーマンス
- デプロイ時間以前：45分
- デプロイ時間以降：8分
- 改善: -82%
- デプロイ頻度 以前: 2-3/週
- デプロイ頻度の変更後: 2-3/日
信頼性
- 前MTTR：4.2時間
- MTTR後：1.3時間
- 改善: -69%
- インシデント/月前：10
- インシデント/月後：3
- 改善: -70%
チームの生産性
- 稼働時間変更前: 60% の確率で
- 稼働時間以降: 25% の確率で
- 機能の提供: +45% スプリントごとに完了した機能の数
- オンボーディングの前: 6-8週間
- オンボーディング後の: 2-3週間
全体的なROI
移行のコスト: 4 か月 x 4 人の開発者 = 約 160,000 ドルのコスト エンジニアリング。 年間節約額: インフラストラクチャ + 増額で 74,400 ドル 生産性は年間約 200,000 ドルに相当します。 初年度のROI: プロジェクト 8 か月以内に元が取れました。
学んだ教訓
何がうまくいったのか
- イベントストーミング：最初の 2 日間がその後のすべての決定を導きました。最小限の投資で大きな利益
- ばね弾性率: 境界検証テストは初日から境界違反を検出し、アーキテクチャの後退を防止します
- 増分移行: 一度に 1 つのモジュールを移行することで、チームはプロセス全体を通じて機能の開発を続けることができました。
- プレフィックス付きの共有スキーマ：データ移行が大幅に簡素化されました。複雑な ETL やデータベース間の同期は不要
- トランザクション送信ボックス: 重要なイベント (支払い) の場合、送信ボックス パターンにより、分散トランザクションの複雑さなしに信頼性が確保されました。
違ったやり方をしていればよかったこと
- 移行前にさらに E2E テストを行う：既存のテストスイートでは不十分でした。移行中にテストを作成する必要があり、プロセスが遅くなりました
- まずはDevOpsチームを巻き込む: DevOps チームはフェーズ 4 の後半から参加しました。廃止措置の計画を立てるためにフェーズ 1 から参加すべきでした。
- アーキテクチャ上の決定を文書化する: ADR は遅れて書き込まれました。すべての決定を文書化することは、将来のチームに役立ちます
ビジネスへの影響
技術的な指標を超えて、移行はビジネスに目に見える影響を与えました。
- 市場投入までの時間: 新機能は 2 倍の速さでリリースされます
- チームの満足度: エンジニアリング チームの NPS スコアは 32 から 71 になりました
- 人材募集: オンボーディング時間の短縮により、新しい開発者のオンボーディングが容易になりました
- 稼働時間: インシデントの減少により、SLA が 99.5% から 99.9% に向上しました。
シリーズの完結編
この 8 つの記事シリーズで、私たちは完全な旅をしてきました。 マイクロサービスの危機、モジュラーモノリスの原則を通じて、実際の移行まで 定量化されたケーススタディとともに。覚えておくべき重要なポイント:
- マイクロサービスが常に答えになるとは限りません: 導入には多大なコストがかかります
- モジュール式モノリスは、操作の簡素化と論理的なモジュール性を組み合わせています。
- DDD と境界付きコンテキストは、正しい境界を定義するために不可欠です
- 移行は段階的、安全、元に戻せる
- 結果は定量化可能です: コストが 65%、導入時間が 80%、生産性が 45% 増加
- モジュラーモノリスはエンドポイントではありません。データが保証する場合、モジュールはマイクロサービスとして抽出できます。
最後のメッセージ
最高のアーキテクチャとは、最も複雑でもファッショナブルでもありません。 本当の問題を解決します あなたのチームとあなたのビジネスの 最小限のオーバーヘッド 必要。ほとんどの組織では、 モジュラーモノリスは、シンプルさとモジュール性の間の最適なポイントを表します。 シンプルに始めて測定し、データが必要な場合にのみ複雑にしてください。