マイクロサービス vs モノリス:エンジニアリング文化を定義する意思決定

大いなる議論

10人のシニアエンジニアに「モノリスとマイクロサービスのどちらを構築すべきか」と尋ねれば、11通りの意見が返ってくるでしょう。ほとんどのエンジニアリング上の意思決定と同様、真実は文脈に深く依存します。

モノリスを理解する

モノリスとは、アプリケーションのすべてのコンポーネントが織り込まれた、単一の統一されたコードベースです。これは本質的に悪いことではありません。

適切に構造化されたモノリスの利点

• シンプルな開発体験: 単一のコードベース、単一のデプロイ、単一のデバッグコンテキスト
• ネットワークオーバーヘッドなし: 関数呼び出しはAPI呼び出しよりも無限に高速
• トランザクションが容易: 複数のデータドメインにまたがるACIDトランザクションが単純
• 小さなチーム: Kubernetesを運用するためのプラットフォームエンジニアリングチームは不要

「マイクロサービスから始めてはいけない。モノリスから始め、明確な理由がある時 — その時にのみ — サービスを切り出せ。」— マーティン・ファウラー、ThoughtWorks

マイクロサービスを理解する

マイクロサービスは、アプリケーションを小さく独立してデプロイ可能なサービスに分解し、それぞれが特定のビジネス機能を担当します。

マイクロサービスの利点

• 独立したスケーリング: 商品カタログをスケールさせずにチェックアウトサービスをスケールできる
• 技術的な柔軟性: 各サービスに適した言語とデータベースを使用できる
• チームの自律性: 異なるチームが異なるサービスを所有し、デプロイし、反復開発できる
• 障害の分離: あるサービスのバグがアプリケーション全体をダウンさせることはない

マイクロサービスの隠れたコスト

今やあなたが抱えることになる分散システムの問題:
├── ネットワークの信頼性(サービス同士の通信は必ず失敗する)
├── データの一貫性(ACIDトランザクションを失った)
├── サービスディスカバリー(サービスAはどうやってサービスBを見つけるか?)
├── 分散トレーシング(20個のサービスをまたいだデバッグは苦痛)
├── APIバージョニング(呼び出し元を壊さずに契約をどう更新するか?)
└── 運用の複雑性(これを管理するにはDevOpsの専門知識が必要)

意思決定のフレームワーク

自分自身にこれらの質問をしてみてください:

ストラングラーフィグパターン

モノリスを引き継ぎ、マイクロサービスへの移行が必要な場合、ストラングラーフィグパターンが最良の味方になります。

1. 特定の機能を処理する新しいサービスを構築する
2. ファサード/プロキシ経由で新しいサービスへトラフィックをルーティングする
3. 新しいサービスが安定したら、モノリスから古いコードを削除する
4. 次の機能について繰り返す

これにより、機能開発を何か月も停止させるビッグバン型の書き直しなしに、段階的に移行できます。

私たちの推奨

**適切に構造化されたモジュール式モノリスから始めましょう。**明確なドメイン境界、モジュール間のクリーンなAPI、優れたテストカバレッジに投資してください。モノリスでは解決できない、具体的で実証可能なスケーリングやチーム自律性の問題が生じた時、その時にサービスを切り出しましょう。

早すぎるタイミングでマイクロサービスに飛びついたチームは、複雑さだけを抱えて何のメリットも得られません。モノリスからの移行を長く拒み続けたチームは、スケールできなくなります。

解決策を選ぶ前に、自分がどの問題を解決しようとしているのかを知りましょう。