なぜ私たちはモジュラーモノリスに戻ったのか
ソフトウェアチームは戦略を変えつつあります。多くのチームが、アプリケーションをマイクロサービスに分割することに何年も費やしてきました。しかし今、彼らはそれらの断片を再び一つにまとめようとしています。彼らが構築しているのは、かつての乱雑なモノリスではありません。「モジュラーモノリス」です。
マイクロサービスは隠れたコストを生み出します。分散システムは膨大な複雑さを加えます。多くのチームがマイクロサービスを採用するのは、スケールが必要だからではなく、流行に乗っているからです。もしチームが小規模であれば、マイクロサービスは開発の足を引っ張っている可能性があります。
モジュラーモノリスは、両方の利点を兼ね備えています。デプロイ可能なユニットとしては一つに保たれますが、コードは厳格なモジュールに整理されています。分散システムを運用する高いコストをかけることなく、明確な境界線を確保できます。
2つのアプローチを比較してみましょう：
• デプロイ: モノリスは1つのユニットを使用します。マイクロサービスは多数を使用します。 • 境界: モノリスは厳格なコードルールを使用します。マイクロサービスはネットワークを使用します。 • 通信: モノリスは単純な関数呼び出しを使用します。マイクロサービスはネットワーク呼び出しを使用します。 • オーバーヘッド: モノリスは運用コストが低いです。マイクロサービスはコストが高くなります。
どのような場合にモジュラーモノリスを選ぶべきでしょうか？
- チームのエンジニアが50人未満である。
- クラウドインフラストラクチャのコストを削減する必要がある。
- デバッグとテストを簡素化したい。
- 結局のところ、サービスをまとめてデプロイする必要があることが多い。
すでに実在の企業がこれを実践しています。Shopifyは、数百万のマーチャントを管理するためにモジュラーアプローチを採用しています。Amazon Prime Videoは、特定のワークロードをマイクロサービスからモノリスへと戻しました。その結果、インフラコストを90%削減することに成功しました。
小規模なチームであれば、Netflixのような規模を目指して構築しないでください。まずはモジュラーな構成から始めましょう。サービスを切り出すのは、データによって本当に必要だと証明された時だけにしてください。
集約が必要かどうかを判断するために、このチェックリストを活用してください：
- 機能開発よりも、サービス間の接続のデバッグに時間を費やしていませんか？
- クラウドの請求額がユーザー数の増加よりも速く増えていませんか？
- 多くのサービスに対して、DevOpsエンジニアが5人未満ではありませんか？
- バグを見つけるために、エンジニアが3つ以上のサービスにわたって1つのリクエストを追跡していませんか？
「はい」と答えた場合、モジュラーモノリスへの移行が正しい選択である可能性が高いです。
オプションの学習コミュニティ: https://t.me/GyaanSetuAi