💬

マイクロサービスではなくモジュラモノリスを採用した理由

2023/02/16に公開

はじめに

皆様こんにちは、株式会社プラハのAwataです。
今回は、直近の開発において、マイクロサービスを検討をしたがモジュラモノリスを採用した経緯を書いていこうと思います。
案件の詳細に興味がある方は、以前書いたリーダーの振り返り記事を読んで頂ければと思います。

※マイクロサービスやモジュラモノリスが何なのか?というそれぞれの詳細にはこの記事では触れませんのでご注意ください。

TL;DR

  • マイクロサービスは思ったよりも難しい
  • 組織的な問題がないならマイクロサービスはきっとまだ早い
  • 将来的にマイクロサービスにするかもしれないなら、モジュラモノリスがいいかもしれない

なぜマイクロサービスを検討したか

今回の案件では、既存システムとの連携が必須でしたが、既存システムのコードがかなり汚く、手を入れることが難しい状態でした。
そのため、既存システムのコードは極力触らずに新規サービスを開発したいと考えていました。

また、既存システムを将来的に作り直していく時のことも考えて、アーキテクチャを決める必要がありました。
将来的に既存システムをマイクロサービスとして分解していく可能性があるなら、今回の新規サービスもマイクロサービスとなるように作っておく必要がありました。
一方、既存システムをまたモノリスで作り直すような形にするのであれば、今回のシステムがその基盤となる可能性があるため、モノリスにしておく必要がありました。

このような経緯と社内から「マイクロサービスでやってみたい」という声もあったため、実現可能化も含めて検討することになりました。

マイクロサービスの検討のために何をしたか

先に書いた通り、ここでどのアーキテクチャを採用したとしても、将来にかなり大きな影響を与えることになります。
そのため、とても慎重に検討を重ねる必要がありました。

何はともあれ、本を読んでみる

自分はマイクロサービスやイベント駆動アーキテクチャなど、分散システムには昔から多少興味があったので、少しだけ知識はありました。
しかし、この決断をできるほどではないと思ったため、まずは以下の本を読みました。

どれも良い本で、マイクロサービスの概念や大変なポイントが書かれていて、かなり実装イメージが沸いてきました。

そして、実装イメージが沸くにつれて、このような懸念も生まれてきました。

これ、実装できるか?運用していけるか?

社内で意見を求めましたが、マイクロサービスの経験者が誰もおらず、具体的な大変さを理解している人はいませんでした。

社外の経験者に意見を求める

これはもう自分だけの力では到底解決できない問題だなと思ってきて、どうにか経験者の意見を聞きたい!と考えるようになりました。
そして、MeetyやQiitaのDevTalkを使って、マイクロサービスの経験者に意見を求めることにしました。

そこで、今の状況などを伝えたところ、どちらの方からも同じような意見を頂きました。

  • 組織的に問題がないのであれば、マイクロサービスはまだ早いと思う
  • 今の段階では、インフラまわりの運用が追いつかないと思う
  • 実装は頑張ればできるかもしれないが、サービスの拡大の際にスピードがネックになるかもしれない
  • マイクロサービス専門のチームを置いていたり、インフラ専門のチームを置いているような組織でもマイクロサービスを100%成功させることができていないくらい、難易度は高いものと理解した方が良い

やはり経験者の語る言葉は重みが違いました。
ここで、私はマイクロサービスはキッパリ諦めるべきだと決断しました。

モジュラモノリスが選ばれた理由

マイクロサービスは諦めましたが、将来的にマイクロサービスにする可能性は残しておきたいと考えていたところ、モジュラモノリスが最適なのではないかと考えるようになりました。
モジュラモノリスは、モノリスでありながら内部でモジュールを分けることで、モジュール同士を疎結合にすることができます。
また、データベースを1つにするかモジュールごとに作るかも自由に選択することができるため、今後の既存システムの分解を想定してもちょうど良いと感じました。
今回のモジュラモノリスでは、単一のデータベースで動作するようにしました。

まとめ

今回は私がどのような経緯でアーキテクチャを決めたのかを書きました。
社外の経験者に意見を求める動きは、自分でも良くできたなと思います。
同じように検討をしている方がいれば参考になればと思います。

GitHubで編集を提案
プラハのブログ

Discussion