モノリスとマイクロサービスの間のアーキテクチャ(Modular MonolithとかMajestic MonolithとかCitadel Architectureとか)

何をもってマイクロサービスと呼ぶかにもよりますが、ほとんどの会社、システムにおいてはマイクロサービスは過剰なアーキテクチャであり、モノリスからいきなりマイクロサービスアーキテクチャへ移行するのも、少し飛躍し過ぎではないかなと思っています。
(マイクロサービスはほとんどの環境では過剰といった考えについてもちゃんと整理した上で改めてブログに書きたい)

例えば、今自分が携わっているPJでも、完全にモノリシックでは作らないが、マイクロサービスアーキテクチャと胸を張って言えるほど分散システムを頑張る理由もない状況です。

最近はマイクロサービス関連のinputを積極的にしていましたが、モノリスのすぐ次に当たるようなアーキテクチャについても知っておくべきだと思ったので、そのようなアーキテクチャについての記事をいくつか読んでまとめてみようと思います。

他にも色々なアーキテクチャが提唱されていると思うので、随時追加していこうと思いますが、ひとまず今回は3つのアーキテクチャについての記事を読んでみました。

  • Modular Monolith(モジュラーモノリス)
  • Majestic Monolith(マジェスティックモノリス)
  • Citadel Architecture(シタデルアーキテクチャ)

ここでアーキテクチャと呼んでいるのは、Clean ArchitecureやLayerd Architectureなど、コードレベルで語られるアーキテクチャではなく、システム全体を対象とするようなアーキテクチャを対象とします。
システム全体のアーキテクチャという表現が正しいかは微妙ですが、モノリスとかマイクロサービスとかと並べて比較する感じのイメージです。

目次


Modular Monolith

Modular Monolithについては以下の記事で色々まとめているので、この記事では簡単な概要だけにしますが、まさしくモノリスとマイクロサービスの間となるアーキテクチャで、モノリスとしてアプリケーションを構築しているが、アプリケーション内でドメインごとにモジュールとして分割し、各モジュール間の独立性を担保する事を目指すものです。
あまりイメージついていない所はありますが、マイクロサービスだと独立したサービスとなるOrderやPaymentなどの単位でモジュールとして切り、各モジュール同士は公開I/Fを通してのみリクエストする事で、後々のマイクロサービスアーキテクチャへの移行にも生きるのが、モノリスとマイクロサービスの中間として採用を検討する最大の理由かと思います。

Modular Monolith(モジュラーモノリス)の記事とか色々読んでみた


Majestic Monolith

まずMajestic Monolithとはですが、参考記事を読む限りは、いわゆるモノリスアプリケーションのイメージで良いかと思います。
記事内でも誇りを持ってモノリスを選択しようと述べられたりしているので、そういう意味合いでMajestic(壮大)という形容詞をつけているのかなと。

記事内では、基本的にはマイクロサービスというのは、AmazonやGoogle、あるいは何千人もの開発者を抱えるソフトウェア組織が、それだけの数の開発者、チームが独立して動ける環境を作るために必要な方法であり、ある程度の規模に達した際にたどり着くものであるため、ほとんどの会社、組織ではモノリスで十分だという事が書かれています。

技術的な話以外にも当てはまる内容として、50人の会社と5万人の会社では同じようには動かせない、桁違いに大きい組織では有用なパターンががあなたの会社で同じように有用であるとは限らない、といった内容が記述されていましたが、マイクロサービスが小さいチームでは不要という説明をする際に、人事やら評価やら様々な組織的な仕組みを、50人の会社と5万人の会社とでは全く異なる内容で運営するなら技術に関しても同じだ、というのはエンジニアでなくてもしっくり来る内容ではと思います。
(50人の会社と5万人の会社とで、どこでどれだけ差分があるのかは正直わかっていないですが...)

またMajestic Monolithの利点として、システムに関わる人々が、全体を理解していることを前提としているというものもあげられています。
小さなシステムが増えれば、知識や責任をサイロ化することは容易になりますが、それは特定のサービスについては〇〇に聞かないとといった状況を作ることに繋がるので、小さなチームでは不要/デメリットが大きいといった事かなと思います。
(実際Basecamp IDなどでそのような状況になったと記述されています)
まぁ単一のコードベースであっても、規模が大きくなるとオンボーディング等は難しくなると思いますし、結局特定の機能に詳しいのは〇〇さん、という状況は発生してしまうような気はします。

簡潔にまとめると、小さいチームの場合はマイクロサービスアーキテクチャを採用せずとも、モノリスで良いよねという、まぁそうだよねっていう話でした。
蛇足ですが、Facebookはモノリスを使ってるという記述があったので、これはこれはでどうなのか気になりますね。

参考


Citadel Architecture

Citadel Architectureは、マイクロサービスを運用していくのは辛いが、モノリスで構築しようにも、特殊な要件のため最適な技術スタックがモノリスアプリケーションで採用しているものとは異なる場合などが発生するようになった際に、モノリスアプリケーションとは別に特定の要件のためのシステム(記事内ではOutpostsと呼んでいる)を構築し、モノリスアプリケーションから利用するといったアーキテクチャです。

大多数のウェブアプリケーションは、最初はMajestic Monolithとして構築が行われ、ほとんどの場合はそれで十分であるが、いつの日か、組織が大規模になる、もしくはMajestic Monolithの技術スタックの範囲内では解決が容易では何らかの要件を抱える日が来るかもしれず、その場合の次のステップとしてのCitadel Architectureだと記事では述べています。

Majestic Monolithを中心に据えながらも、それぞれが責任の小さなサブセットを抽出する一連のOutpostsでそれをサポートし、Outpostsは、Majestic Monolithが、組織的な理由、パフォーマンスや実装の理由などで、特定の要件をオフロードすることを可能にするために存在しています。
また今トレンドとなっているマイクロサービスへの移行がやがて下火になり、トレンドが変わった際にはMajestic Monolithがマイクロサービス難民を待っている、といった記述もありますが、基本的にはマイクロサービスでなくとも、Majestic Monolith、アプリケーションが大当たりしたとしてもCitadel Architectureで対応できるといった感じの主張です。

記事の中では、Railsで構築されているアプリケーションで発生した特定の要件に対しては、Apache Kafkaが最適であると結論づけたが、システムの他の部分はモノリスのまま以前通りに動作させるために、Apache Kafkaを利用する処理に関してはOutpostsとして構築し, モノリスアプリケーションからOutpostsとのやりとりもgemを書いたことで、メインのアプリケーションはほぼそのままに、特定のニーズに最適な技術を居所的に採用したと記述されています。

基本モノリスだが、周辺にAPIやらライブラリ経由で利用する何かがある構成は、かなりありそう && 普通な構成だと思うので、自分がよくわかっていない可能性はありますが、特に変わった事をやっている印象はありません。
Citadel(要塞)という名前にも英語力の問題もあり、あまりピンとこないですが、モノリスだが周辺にも色々依存システムがあるような場合に、アーキテクチャ名だけを告げて伝わるのであれば楽なので名前があると便利ですね。   一番のポイントである、ほとんどの場合はMajestic Monolith or Citadel Architectureで十分というのも個人的にはその通りかなという気がします。

参考


終わりに

ひとまず気になってた記事を一通り読んでみました。
個人的にはモノリスとマイクロサービスの間にあるアーキテクチャがフィットする環境、会社が数としては一番多いのではと思ったりするので、今後もこの辺りは色々とインプット続けていきます。
またモノリスとマイクロサービスの間というよりは、マイクロサービスの次、というニュアンスで話されるアーキテクチャですが、マルチランタイム・マイクロサービスなど、他にも気になるアーキテクチャがあるので、これらに関しては改めて追記なり出来たらと思います。