タイミーでテックリードをしている @euglena1215 です。

最近、Majestic Monolith と Citadel というアーキテクチャ・考え方を知ったのですが、あまり国内では認知度が高くないように感じたので紹介してみたいと思います。

Majestic Monolith

Majestic Monolith の出典は Ruby on Rails の作者である DHH のブログです。2016年に書かれていてすごい。

正確な内容は出典を参照していただくとして、ここでは自分の解釈をまとめてみます。

世間では「モノリスアーキテクチャ」は劣ったアーキテクチャのような評価を受け、「マイクロサービスアーキテクチャ」が優れているような評価を受ける。
Amazon や Google、あるいは何千人もの開発者がいるような会社にとってはマイクロサービスアーキテクチャは素晴らしいアーキテクチャだが、「成功している企業で効果があったのだから、我々にも効果があるはずだ」と思い込んで小さな会社がマイクロサービスアーキテクチャを目指すのは間違い。
巨大な一握りの会社以外はモノリスを受け入れ、意図を持ってモノリスを雄大(majestic)に設計しよう。

モノリス自体が悪いと捉えてしまうと、それを解決するためにはモノリスから脱する以外の道はありません。モノリスをまず肯定することによって、初めて自分たちが抱えている様々な技術的課題の輪郭が見えてきます。

もちろんその中にはモノリスを分けなければ解決できない課題もあると思いますが、そうでないものも含まれていると思います。まずモノリスを肯定することによって、様々な技術的課題の解像度を高めることができる示唆に富んだ考え方だと感じています。

Citadel

こちらも出典は Ruby on Rails の作者である DHH のブログです。2020年に書かれています。

多くのケースで Majestic Monolith はうまく機能するが、パフォーマンスや可用性の問題でモノリスでは対処が難しい課題が出てくることもある。
その際の次のステップは Citadel。Citadel とは、モノリス（Citadel = 城塞）を中央に据えて周辺に必要に応じてモノリスを補完するようなサービス（Outpost = 前哨基地）を配置する考え方。
Outpost としてモノリスとは異なる特性（パフォーマンス上の問題を対処、組織上、実装上など理由は様々）のサービスが提供できれば、アプリケーションの残りの部分は Majestic Monolith として提供し続けられる。

計らずもこの構成になっているプロダクトは多いのではないのでしょうか。タイミーのそのうちの1つです。

Citadel という名前をつけたことで、別物だと感じていた他プロダクトの構成にも共通点を見出せるようになった気がします。DHH の命名の妙だと言わざるを得ません。

ソフトウェアアーキテクチャの文脈でよく登場するモノリス・マイクロサービス・モジュラモノリスといった分類は、あくまで「こういった状態のシステムはこのような特性を持っている」というカタログでしかありません。

理解し把握しておく分にはとても有用ですが、「（ここに任意のアーキテクチャ名が入る）化」をしたから我々が直面している様々な技術的課題が解決できるかというと、なかなか難しい面もあるかと思います。

ですが、DHH の提唱する Majestic Monolith にも Citadel にも、現場で起きている事象（問題）に対してどのように対処をしていくかという地に足のついた指針のようなものを感じました。

隣の芝生は青いということわざがあるように、自分たちが選択していないアーキテクチャが良く見えてしまうのは人間の性だと思います。Majestic Monolith, Citadel を胸に誘惑に負けないよう努力し続けたいと思いました。

明日は @MoneyForest の「OpenTelemetryで環境ごとにObservability Backend（Jaeger、Datadog）を切り替えてエンジョイしてみたよ」です。お楽しみに！