個人的な雑感想だが、ほとんどの会社・システムにおいてはマイクロサービスは過剰なアーキテクチャであり、モノリスからいきなりマイクロサービスアーキテクチャへ移行するのも、少し飛躍し過ぎだと過去の経験から感じている。
最近は業務上の都合もありマイクロサービス関連のインプットが多かったが、モノリスをいかに上手く作るかについてを知っておくべきだと最近思ったので、関連記事を適当に漁ってみた。
今回は以下3つのアーキテクチャについての記事を読んだ。
- Modular Monolith(モジュラーモノリス)
- Majestic Monolith(マジェスティックモノリス)
- Citadel Architecture(シタデルアーキテクチャ)
目次
Modular Monolith
Modular Monolithについては以下の記事でまとめているので、簡単な概要のみ。
Modular Monolithは、モノリスとしてアプリケーションを構築するが、アプリケーション内でドメインごとにモジュールとして分割し、各モジュール間独立性を担保を目指すものと理解している。
イメージついていない所はあるが、マイクロサービスだと独立したサービスとなるOrderやPaymentなどの単位がモジュールとなり、各モジュール同士は公開I/Fを通してのみリクエストする感じだと認識している。
各モジュール間を上手く設計し、依存関係を管理することが出来れば、後々のマイクロサービスアーキテクチャへの移行もスムーズになるのが、モノリスとマイクロサービスの中間として採用を検討する最大の理由だと思う。
Majestic Monolith
Majestic Monolithとは？だが、参考記事を読む限りは、いわゆるモノリスアプリケーションのイメージ。
記事内でも「誇りを持ってモノリスを選択しよう」と述べられてるので、Majestic(壮大)とつけているのかなと。
記事内では、基本的にはマイクロサービスというのは、AmazonやGoogle、あるいは何千人もの開発者を抱えるソフトウェア組織が、それだけの数の開発者、チームが独立して動ける環境を作るために必要な方法であり、ある程度の規模に達した際にたどり着くものであるため、ほとんどの会社、組織ではモノリスで十分だという事が書かれていて、これは同感する所。
技術的な話以外にも当てはまる内容として、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やらライブラリ経由で利用する何かがある構成は、普通な構成だと思うので、よくわかっていないだけの可能性はあるが、特に変わった事をやっている印象はないが、ほとんどの場合はMajestic Monolith or Citadel Architectureで十分という主張はまぁそうだろうねという感想。