1/ GitHub 元CTO「マイクロサービスにしたことがアーキテクチャ上の最大のミスだった」（※少しマニアックな内容ですが、個人的には面白いと感じたので載せます→）

門脇 敦司/ Atsushi @at_sushi_

1/ GitHub 元CTO「マイクロサービスにしたことがアーキテクチャ上の最大のミスだった」 （※少しマニアックな内容ですが、個人的には面白いと感じたので載せます→） twitter.com/jasoncwarner/s…

Jason Warner @jasoncwarner

I'm convinced that one of the biggest architectural mistakes of the past decade was going full microservice On a spectrum of monolith to microservices, I suggest the following: Monolith > apps > services > microservices So, some thoughts

2022-11-15 03:45:41

Jason Warner @jasoncwarner

I'm convinced that one of the biggest architectural mistakes of the past decade was going full microservice On a spectrum of monolith to microservices, I suggest the following: Monolith > apps > services > microservices So, some thoughts

門脇 敦司/ Atsushi @at_sushi_

2/ アーキテクチャの過去10年間における最大のミスの1つとして、完全にマイクロサービス化してしまったことがあります。 モノリスからマイクロサービスのオススメ度合いでいうと以下です。 Monolith > apps > services > microservices どういうことか説明します→

門脇 敦司/ Atsushi @at_sushi_

3/ まず、アーキテクチャは考え方であって、ルールではありません。 大規模な分散システムを構築したことがある人は知っていると思いますが、実際には完璧に機能するものなど無く、うまくやる必要があります。 また、ステージが重要です。5-50人の会社であれば、モノリス一択です。信じてください。

門脇 敦司/ Atsushi @at_sushi_

4/ もしあなたが1万人規模の会社でこれを読んでいるなら、おそらくこれらのアーキテクチャがある程度存在していると思いますが、今から私が言う事はは、これまでと違うかもしれません。 さて、まずは定義の話から。正確な定義があるわけではありませんので、

門脇 敦司/ Atsushi @at_sushi_

5/ それぞれの定義について、私はいつも以下のように考えています。 monolith - xyz.com apps - abc.xyz.com、コアな価値ごとに分かれている。数個までの場合こう呼ぶ。

門脇 敦司/ Atsushi @at_sushi_

6/ services -monolith/apps をサポートする。コアインフラ、多くの場所で必要とされる。アプリチームによって書かれていない場合もある（インフラチームが担当）。 microservices -数百行程度のコード、ちょっとした仕事、ライブラリ・SDKかも/であるべき

門脇 敦司/ Atsushi @at_sushi_

7/ 話を戻して、「なぜ」なのか、お話ししましょう。 私は基本的に以下のように考えています。 スピードとリスク A.エンジニアリングチーム全体が一つの大きなアプリ（Railsアプリのサイト全体と考える）の中で作業するメリットを話す方が、マイクロサービスのデメリットを考えるより簡単です。

門脇 敦司/ Atsushi @at_sushi_

8/ B. 分散システムは、成長するにつれて必要とされてきますが、それぞれが独自のリスクプロファイル（訳注：単体テストとかのこと？）を持つ何十、何百ものマイクロサービスを扱うことは、かなり難しいことです。 C. 完全にマイクロ化すると、無秩序を正すため、新しい概念を導入する必要があります。

門脇 敦司/ Atsushi @at_sushi_

9/ D.私の考えでは、オーダーメイドのインフラやマイクロサービスほど、技術負債になるものはありません。コードは負債ですが、サービスはもっと負債です。これを理解した上で、どうしても負債を作るなら、nice to haveではなく、最高にレバレッジが効くときにだけ、にするべきです。

門脇 敦司/ Atsushi @at_sushi_

10/ 分散システムに関わっているエンジニアは重複を避けようとしているのでしょう。 そのため、複数の場所で同じことが行われていたら、「これを取り出してマイクロサービスを作ろう」と考えます。

門脇 敦司/ Atsushi @at_sushi_

11/ 理論的にはOKです。そして、数十のインスタンスであれば、問題ありません。それが数十のマイクロサービスになるとやばいですし、もっとやばいのは巨大な企業内であらゆる垣根を越えて（例. Googleで全てに1つのカラーサービスを提供する）いる場合です。これは技術課題というより、組織課題です。

門脇 敦司/ Atsushi @at_sushi_

12/ 私が提示したものは、誤った二項対立のように思えるかもしれませんが、実際、マイクロサービスには明確な技術的課題だけでなく、それ以上に組織的な課題があることは分かっています。 そして、私が心配しているのは、この点です。

門脇 敦司/ Atsushi @at_sushi_

13/ 第一に、インフラは（異常に敏腕なCEOがいる会社でない限り）ほとんどの場合、優先順位が下がります。 第二に、サービスが多すぎると、所有権の問題や境界線の問題が発生する。 第三に、大量のマイクロサービスがあると、それに対処するために、さらに多くのツールを導入する必要が出てきます。

門脇 敦司/ Atsushi @at_sushi_

14/ 最も重要なのは、ライブラリやSDKなどになるはずのマイクロサービスが、 開発時のリスクになる場合がある点です。 たくさんのコードは確かにオーバーヘッドですが、たくさんのサービスは、顧客の感じるプロダクト/体験へのリスクです。どちらの手法もデメリットはありますが、その度合いは違います

門脇 敦司/ Atsushi @at_sushi_

15/ だから、基本的に以下を推奨します 1. できるだけ長くmonolithでいること 2. services化はインフラ側の要求があったときのみにして、アプリ側の要望では作らないこと 3. monolithから脱却する場合、大きめのappに分解すること 4. 新しいappが生まれるごとに、見えない壁ができると考えること

門脇 敦司/ Atsushi @at_sushi_

16/ 5.可能であれば、マイクロサービスではなくライブラリとして作る 「カラーサービスを導入した」という例は、私がサービスよりもライブラリを好む理由の極端な例として、よく使います。確かに極端な例ですが、典型的な例です。

門脇 敦司/ Atsushi @at_sushi_

17/ 「では、アマゾンやウーバーはどうなんだ？」と言われるかもしれません 1. 好きにやってみてください。私は、経験を述べているだけです。 2. アマゾンみたいにサービスを義務化して成功したことがあれなら、頑張れ 3. これらはルールというよりガイドラインです

門脇 敦司/ Atsushi @at_sushi_

18/ 世界中の90%の企業は、プライマリDBに対してDBのバックアップ、キャッシュ、プロキシを実行するモノリスで済ませるられると思っています。 惑星規模にどデカい10%の企業にとっては、この問題を解決するのは「art」の領域です。

門脇 敦司/ Atsushi @at_sushi_

19/ 分散システムと企業のスケールとの組み合わせはかなり複雑で、それをやったことがある人は非常に少ないため、それぞれの企業にピッタリハマる教訓を得ることは難しいです。それぞれの状況や事例が異なるからです。私がここで話しているのは、問題にどのようにアプローチするかについての考えです。

門脇 敦司/ Atsushi @at_sushi_

20/ そして、最後にもう一度。 Monolith > apps > services > microservices スケールのための基本手法： なるべく長く一つの大きな塊であれ。細かい過剰な修正はせず、成長に合わせ（たとえ急成長中でも）乗り越える。これは、組織と技術、両方のためです。 繰り返しですが、これは「art」です。

あまりる @amaril_ja

@at_sushi_ マイクロサービス化にもデメリットはあるはず…。と思っていましたので、そこがうまく言語化されたと感じました。 しかしGitHubにしてその様な結論になるとは、ちょっと意外です。

Ｋ一郎 (strnote.comの中の人) @keiichiroh

@at_sushi_ 反対の立場の主張の記事も見つけたので、併記として載せたほうがいいかなと（どちらに肩入れという意味ではないのでよろしく） infoq.com/presentations/… （翻訳）infoq.com/jp/articles/gi…