マイクロサービスを モノリスに戻して生産性が3倍になった話

エリート組織は1日以内のリードタイムと高頻度デプロイを実現するとする調査結果は広く知られています¹。たとえばDORAの年次レポートでは、アーキテクチャがチームの自律性を支えるほどソフトウェアデリバリーの指標が向上することが示され、形態そのものが目的ではないと示唆されています¹。また、Prime Videoのエンジニアリングブログでは、一部のワークロードをマイクロサービスからモノリスに統合した結果、コストを大幅削減した事例が公開されました²。複数の公開事例と現場の知見を突き合わせると、分割が常に正義とは限らず、境界の引き直しと運用コストの最適化が成果に直結するという当たり前の真実に行き着きます。この記事では、CTOの視点から、マイクロサービスをモノリスへ戻す判断が生産性向上に結びつき得る理由と、その実装のディテールを、運用指標の考え方とともに整理します。

生産性3倍の定義と、戻す決断に至るまで

まず「生産性3倍」という表現が何を意味し得るのかを明確にしておきます。現場で広く使われるのは、DORA指標（デプロイ頻度・変更のリードタイム・変更失敗率・平均復旧時間MTTR）をベースに、これらを正規化・加重合成したエンジニアリング生産性指標です¹。たとえば、四半期ごとに本番出荷した機能数、プルリクエストの作成から本番反映までのリードタイム、障害からの平均復旧時間（MTTR: Mean Time To Recovery）を合成し、トレンドを比較します。公開されたケーススタディでは、モジュラーモノリス化を経て「機能出荷が増える」「リードタイムが数十%短縮する」「MTTRが時間単位に収束する」「デプロイ頻度が日次レベルへ近づく」といった改善が報告されることがあります¹⁵。コスト面でも、プロセス数やネットワーク経路の削減がインフラコストの改善につながることがあり、特定のワークロードではPrime Videoのように大幅削減の報告もあります²。もちろん、これらは前提条件（ドメインの結合度、トラフィック特性、チーム体制など）に強く依存し、保証値ではありません。

決断の背景はシンプルです。成長期に速度を求めて機能単位でサービスが増え、最終的に数十〜百近いサービス、複数のリポジトリ、複数言語ランタイムというスプロールに至る、というのは珍しくありません。サービス間はgRPC（高速なRPCフレームワーク）やイベントで結合していても³、実態としてトランザクション整合性の要件が高い領域では、分割のメリットよりも認知負荷・運用摩擦・変更コストが上回りがちです⁵。オンコールの通知が夜間に連鎖し、変更一つに多チームの合意が必要になる。仕様が明確でも「誰がどこを直すか」の調整がボトルネックになる。こうした兆候が見えたら、業務上の境界づけを再評価し、同期的な整合性が要るコアドメインをモジュラーモノリスへ再統合する方針が有力になります。

なぜマイクロサービスが減速を招いたのか：境界とオーナーシップの歪み

よくある失敗は、技術選好ではなく境界の定義にあります。見かけ上はドメイン駆動設計（DDD）を採用していても、境界づけの単位が「部署」や「長期的なデータ所有権」ではなく、短期のロードマップや担当者の都合で決まってしまう。変更がコンテキストを横断するたびにイベントのやり取りが増え、完了の定義が各サービスのリリースに分散します。結果として、プロダクトマネージャーが定義した価値単位と、システムが提供する変更単位が一致せず、価値提供のリードタイムが伸びていく。ここに、テストのフレークや契約の破壊的変更が混ざると、デプロイ頻度は容易に後退してしまいます⁵。

運用面でも不整合が顕在化します。集中監視や可観測性（ログ・メトリクス・トレース）を整備していても、SLO（Service Level Objective: サービスレベル目標）を達成するための責任境界が不鮮明だと、障害対応が「誰が見るか」の議論から始まる⁵。データ整合性はサガ（分散トランザクションの補償パターン）で扱っていても、補償トランザクションの失敗時に複数チームの判断が必要になり、復旧時間が読めません⁵。結果として、安全に見える最小の変更を選びがちになり、価値の大きい変更が後回しになるというアンチパターンが定着します。振り返ると、原因は「マイクロサービスそのもの」ではなく、ドメインとガバナンスのずれが増幅された結果であることが多いのです。

モノリスでもスケールするための前提：モジュール性と契約の堅牢化

戻す決断は「一枚岩に戻す」ことではありません。プロセスは一つ、境界は明確という設計を徹底する必要があります。そこで、アプリケーションは単一のデプロイ単位に統合しつつ、内部は厳格なコンポーネント境界で分割します。各コンポーネントは明示的なファサードと依存方向のルールを持ち、静的解析で侵食を検出する仕組みを入れる。データベースは単一のPostgreSQLクラスタに統合しながらスキーマをコンテキスト単位で分離し、アプリ側ではトランザクションのスコープを明文化します。これにより、分散トランザクションや最終的整合性のための複雑な補償処理が不要となり、実装と運用の両面で変更コストを下げられます⁴。

モノリス回帰の実装戦略：止めずに寄せる、寄せながら計測する

移行はビッグバンではなく、現実的な安全策を積み上げます。最初に可観測性の統合から着手し、ログ・メトリクス・トレースの名前空間と属性をモノリス想定で揃える。次に、チャット頻度が高いサービス群から候補を選び、ソースコードとドメインモデルを並べて、境界交差の回数と粒度を定量化します。閾値を超える領域はモノレポに取り込み、既存サービスのAPIファサードを保持しつつ内部実装をライブラリ化して同一プロセスに同居させる。この段階では通信はまだネットワーク越しですが、計測を続け、エラーバジェット消費やレイテンシ（P95レイテンシ: 95パーセンタイルの応答時間）に問題がないことを確認してから、呼び出しを関数呼び出しに切り替えます。

データ移行では、書き込みの二重化とリードの段階的切り替えを採用します。まず既存サービスに対して、同一のコマンドを新スキーマへも適用するセーフライト期間を設け、差分と不整合を検出・修正する体制を作る。その後、読み取りは新スキーマ優先に切り替え、旧側をフォールバックにします。最終的に旧サービスをシャットダウンしても、API契約はゲートウェイで保持されるため、クライアントは変更不要です。外部公開APIは互換を維持し、内部の結合のみを段階的に内向きへ畳む、という手順にすることで、プロダクションの安定性を崩さずに進められます。

テスト戦略も変えます。契約テストは残しつつ、ビジネス機能単位の統合テストをモノリス上で厚くし、テストデータの固定化と再現性を重視します。トランザクション境界が明確になることで、疑似的な分散障害を再現しなくても、ローカルでほぼ同等の失敗モードを再現できるようになり、デバッグ時間が大きく圧縮されます。デプロイはトランクベース開発と段階的リリースを採用し、カナリア比率を小さく刻んでエラーバジェットの消費を監視します⁷。これらの運用手当てにより、移行期間中のSLO逸脱リスクを抑え込めます。

パフォーマンスと信頼性：数字で見えた副作用と改善

プロセス間通信を減らすことで、ホットパスのCPU時間やレイテンシが改善する傾向は、実験・研究でも示唆されています³⁴。オブザーバビリティは単純化され、トレースのスパン数は機能単位で少なくなり、原因特定の時間も短縮されがちです。懸念される単一プロセスのフェイルリスクは、プロセス分離ではなくセル分割で対処します⁸。単一モノリスの水平スケールとセルアーキテクチャを組み合わせ、障害はセル内に閉じ込める設計にすることで、システム全体のレジリエンスを維持します。スローダウンの兆候はSLOダッシュボードで検知し、スロットリングとバックプレッシャーをアプリ層に実装することで、過負荷時の劣化を計画的に制御できます。

組織設計とROI：技術判断を価値創出へつなげる

アーキテクチャの変更は組織の変更を伴います。チームはサービス単位のアラインメントから、ストリームアラインドなドメイン単位に再編するのが効果的です⁹。コードオーナーシップはモジュール単位で定義し、レビューポリシーはファサード境界をまたぐ場合にのみ複数承認を必須とする。これにより、最も多い「局所的な機能追加」のフローが細いガバナンスで通り、広範な変更だけが自然と可視化されます。プラットフォームは、ビルド・デプロイ・可観測性・データプラットフォームを提供する内製PaaSとしてまとめ、プロダクトチームはビジネス関数に集中できるようにする。CTO視点では、こうした整流化によりROIのトレーサビリティが高まり、機能出荷の増加とビジネス成果の相関が読みやすくなります。運用工数の削減とインフラコストの純減という二重の効果が見込める点も、投資判断を後押しします⁶。

トレードオフと限界：いつもモノリスが正解ではない

最後に、当然ながらモノリスは万能ではありません。レギュレーション上のデータ分離や、レイテンシ要件が超厳格なケース、チームの地理的分散が極端に大きい場合など、プロセスの分離が価値を持つ場面は確かに存在します。重要なのは、業務の連鎖が同期的かつ高頻度か、変更の最小単位がどこで価値に結びつくか、そして運用とガバナンスのコストをどれだけ支払えるかを、定量的に見極めること。ここを見誤らなければ、境界の再設計と統合は強力な選択肢になります⁵。

まとめ：分ける勇気より、戻す知性を

マイクロサービスは強力な道具ですが、道具は目的ではありません。ドメインの同期連鎖が濃い領域をモジュラーモノリスに再統合すると、デプロイ頻度やリードタイム、MTTR、運用コストといった合成指標で見た生産性が大きく伸びる可能性があります。鍵になったのは、サービスの数ではなく、境界の正しさと可観測性、そして段階的移行を支える地味な実装の工夫です。もし今、変更のたびに多チームの調整に追われ、アラートのノイズと不確実性が意思決定の足を引っ張っているなら、境界の再設計と統合の選択肢を、公開データと自組織の計測と共にテーブルに載せてみてください。あなたの組織にとっての最適な分割線は、きっと今とは違う場所に引けるはずです。次のスプリントで計測から始め、最もチャットが多いサービス同士を地図上で結び、ひとつのセルへ寄せる小さな実験を設計してみませんか。Web開発の速度は、分けた数ではなく、流れの良さで決まります。

参考文献

1. Google Cloud. Announcing the 2024 DORA report. https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report
2. Prime Video Tech. Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%. https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90
3. D. Vujovic et al. Interservice Communication Overhead in Microservices: HTTP vs gRPC. ResearchGate. https://www.researchgate.net/publication/392103353_Interservice_Communication_Overhead_in_Microservices_HTTP_vs_gRPC
4. A. Gan et al. Performance Comparison of Microservices and Monolithic Architectures. Applied Sciences 10(17):5797, 2020. https://www.mdpi.com/2076-3417/10/17/5797/htm
5. InfoQ. Reviewing Microservices Architecture: The Operational Complexity. https://www.infoq.com/articles/reviewing-microservices-architecture-operational-complexity/
6. Cerbos. Team collaboration and code ownership in microservices. https://www.cerbos.dev/blog/team-collaboration-and-code-ownership-microservices
7. Atlassian. Trunk-based development. https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development
8. AWS Builders Library. Cell-based architectures. https://aws.amazon.com/builders-library/cell-based-architecture/
9. Atlassian. DevOps frameworks: Team Topologies. https://www.atlassian.com/devops/frameworks/team-topologies