仮説が生まれるまでの背景
モジュラーモノリスからマイクロサービス化を検討する際に、
「なんだかリードタイムが伸びてきたな」「モジュール間の結合度を落としたいな」
などという、「定性的な理由のみで分割を計画したくない」という明確な意思があった。
自分の中での問い
「モジュラーモノリスからマイクロサービスへの移行を、勘や期待に頼らず、
データに基づいて低リスクで進めるための理想的な戦略はないのだろうか？」
という問いがありました。
仮説
そして、以下のように仮説を思いついた。
モジュラーモノリスの段階で適応度関数をすでに準備しておき、マイクロサービス化することを計画し始めた段階で、オブザーバビリティツールも導入したい。
これにより、テスト環境で仮にマイクロサービスとして分割しても、
適応度関数があることで、効果が思ったほど出ないようなアーキテクチャだったら弾いてくれるだろう。
オブザーバビリティツールがあることで、どういったインフラ上の問題があることで、適応度関数を通らないのか？といった分析もできるはずだ。
これをもとに、Geminiと壁打ちを繰り返した中で、得られた気付きを残します。
以下で提案する戦略は「計測」「仮説検証」「分析」という科学的なサイクルをアーキテクチャの進化に持ち込むものです。
1. 適応度関数による「客観的なベースライン」の確立
モジュラーモノリスの段階で適応度関数を用意する最大のメリットは、
移行前の「現在の実力値」を客観的に計測できる点にあります。
ベースラインの計測
「現在、注文モジュールと在庫モジュール間の処理は30msで完了している」といった具体的な数値を、適応度関数としてコード化しておきます。
客観的なゲートキーパー
テスト環境で在庫モジュールをマイクロサービスとして切り出した後、全く同じ適応度関数をすぐに実行します。
もし処理時間がネットワーク越しになり100msに悪化 した場合、適応度関数は失敗します。
これにより、「この分割方法はパフォーマンスを悪化させる」という事実を、デプロイ前に客観的に判断し、後から「マイクロサービス化しなきゃ良かった泣」という事態を事前予防します。
2. オブザーバビリティによる「原因の深掘り」
適応度関数は
「何が問題か」を教えてくれますが、「なぜ問題なのか」は教えてくれません。
そこでオブザーバビリティツールの提供してくれるデータが活躍します。
問題の可視化
上記の例で適応度関数が失敗した際、
オブザーバビリティツール（特に分散トレーシング）を見れば、
「処理時間100msのうち、70msがサービス間のネットワーク通信に使われている」といった
インフラ上の原因が一目瞭然
になります。
これがないと、アブダクションのよる原因究明は属人的でしょうね。
原因がデータで客観的に見えるのは、大変うれしい事です。
未知のリスクの発見
モノリス内では発生しなかった、
・ネットワークの信頼性
・データシリアライズのコスト
・サービスディスカバリの遅延
といった、マイクロサービス化特有の問題点を具体的に特定できます。
結論：最強のフィードバックループ
この2つを組み合わせることで、以下の強力なフィードバックループが完成します。
ADR運用と組み合わせて使うことで、マイクロサービス化の実行をより安全で確実なものにしてくれるはずです。
計測
適応度関数でアーキテクチャの健全性を計測する。
判断
期待通りでなければ、そのマイクロサービス化のアーキテクチャ案を棄却する。
分析
なぜ期待通りでなかったのか、オブザーバビリティツールで分析する。
改善
分析結果を元に、アーキテクチャや実装を改善し、再度計測する。
これは、マクロなアーキテクチャ変更という大きなリスクを伴う賭けを、小さく安全な実験の繰り返しに変えてくれます。