- "Monolith > apps > services > microservices"
- まず第一に、これはルールではなく、あくまで私の考えだということ。大規模な分散システムを構築したことがある人なら、実際にはそのままでは機能せず、適応が必要だと分かっている
- 第二に、段階が重要
- 5〜50人の会社なら、 просто Monolithで進めるべき
- 1万人規模の会社なら、上のものをすべて持っているはず。ただ、以前とは変わった考え方について話してみると…
まずは定義から
- monolith - xyz.com
- apps - abc.xyz.com
- services - アプリ/モノリスを支えるもの。中核インフラ、中核コンプライアンス機能であり、アプリチームが書かないこともある（インフラ側で保守運用）
- microserivces - 数百行のコードで、ほとんどが使い捨て。ライブラリまたはSDKであり得るし、そうあるべき
Why ? : 基本的には "Speed & Risk" のため
- #1 開発チーム全体が1つの巨大アプリ（サイト全体がRailsアプリだと考えてみてほしい）で開発するほうが簡単
- #2 成長すると必然的に持つことになる分散システムは、それ自体が、危険な何百ものマイクロサービスがなくてもすでに推論が難しい
- #3 完全にマイクロへ振り切るなら、無秩序な拡張を処理するための新しい概念を導入しなければならない
- #4 カスタムメイドのインフラサービスやマイクロサービスは、負債という概念の極端な形。コードも負債だが、サービスはその極端なバージョン。これが何を意味するか考えてほしい。レバレッジポイントにすべき
- 分散システムのエンジニアは重複を嫌うので、何かが複数箇所で行われていると「これを切り出してマイクロサービスにしよう」と考えがち
- 理論上はそれで正しく、10個や20個程度までは問題ない。しかし数十個を超えたり、大規模企業をまたいで使われるようになると、それは技術の問題ではなく組織の問題になる
- 私の話は誤った二分法のように感じられるかもしれないが、実際にはマイクロサービスには技術的な課題があり、さらに多くの組織的な問題もある
私が懸念しているのは
- #1 （IT出身のCEOが率いているような例外を除けば）インフラは常に優先順位の後回しにされる
- #2 サービスが多すぎると、一般にオーナーシップや境界の問題が生じる
- #3 無数のマイクロサービスを扱うために、さらに多くのツールを導入することになる
- #4 最も重要なのは、ライブラリやSDKであるべきだった各マイクロサービスが、本番環境にリスクをもたらすこと
一般的に私が勧めるのは
- #1 可能な限り長くMonolithを維持する
- #2 サービスはインフラに必要なものから始め、アプリ開発側から始めない
- #3 モノリスを分割する必要があるなら、小さなサービスではなく大きなアプリへと分解する
- #4 それぞれの新しいアプリを、社内の仮想的な壁だと考える
- #5 可能ならマイクロサービスよりライブラリを優先する
13件のコメント
最後の部分の懸念と提言には共感します。
実際、会社の規模やサービスの規模も似たような文脈ですし、分割せざるを得ない瞬間はいずれ来るので、それに前もって備える卓越した判断が必要なのだろうと感じました。
会社の規模ではなく、システムの規模によって決まるべきではないのか？ それとも、私が MSA を誤解していたのだろうか？
上のコメントの中にある
マイクロサービスの問題ではなく、無分別なサービス拡張のほうが問題ではないでしょうか？
という意見にはひとまず同意しますし、会社が大きくなるほどデプロイの問題やブランチ管理のようなモノリス自体の欠点があまりにも明確に表れてくるため、コストと生産性の間のトレードオフをうまく選ぶ必要がありそうですね
とても良い文章ですね。ありがとうございます。
デザインパターン重要性論争？ と似たようなものだと思います。
デザインパターンというのは、さまざまな問題を解決する過程で導き出されたコードパターンですが……
あくまで状況に合わせて、必要に応じて応用・適用すべきものなのに……
模範解答であるかのように、デザインパターンが必須だとして没頭する人たちが時々いますね……
最近のMSA関連でも似たような感じで、とにかくMSA一択……という人が増えている気がします。
ニワトリが先か卵が先か、という話のように思えます。
マイクロサービスそのものの問題ではなく、無分別なサービス拡張が問題なのではないでしょうか？
適切なバランスが重要だと思います。
マイクロサービスに移行すると、新機能 = 新しいマイクロサービスという発想に行き着きがちなため、
管理がますます難しくなるのではないかと思います。
以前、Segmentの技術ブログに掲載されていた「Goodbye Microservices」という記事を思い出します。
SegmentもCDPであり、非常に多くのデータをリアルタイムで処理しているにもかかわらず、MicroservicesからMonolith構造へ移行し、その理由などをブログにまとめていました。この記事ともある程度通じる部分があると思います :)
https://segment.com/blog/goodbye-microservices/
おおむね私の考えと一致しています。
弊社の開発者は5人なので、まだしばらくはモノリス（Ruby on Rails）を志向するのが適切だと思います。
上の記事のように、50人以上が同時に開発するプロジェクトになったら、そのときは2つ目のモノリスを開発することになる気がします。
5〜50人規模の会社なら、そのままMonolithで進めましょう << これは開発者数ではなく、総構成人数のことですよね？
会社の規模のことを言っているようですね〜
可能ならできるだけ長くモノリスを維持する < ものすごく共感します。分離していくことで保守コストが増えるのが大きいです
MSAがドグマ化していくことへの反動としての文章だと思われ、その点で意味があるように思います。