10日前

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

123
門脇 敦司 @at_sushi_

株式会社ナレッジセンス CEO ← 東大 | プロダクト好きのための投稿

門脇 敦司 @at_sushi_

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

2022-11-16 09:20:18

元ツイはこちら

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
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:18
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:19
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:20
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:22
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:23
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:24
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:25
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:27
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:28
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:29
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:30
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:32
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:33
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:34
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:35
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:36
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:38
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:39
門脇 敦司 @at_sushi_

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

2022-11-16 09:20:40
あまりる @amaril_ja

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

2022-11-17 08:08:09
K一郎 (strnote.comの中の人) @keiichiroh

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

2022-11-17 08:54:27
\ Tgから毎日100名様にお好きなポイントプレゼント /

コメント

フック @ohayou828 8日前
思考停止でマイクロ採用するのも、これだけ見でモノリスままで良いと判断するのもどちらも愚かで、結局自分たちの提供したい価値を達成するのに最も適してるアーキを突き詰めて考えるしかないかと
0
Hacchi @2mocccck 8日前
誰にでもわかりやすい典型的なマイクロサービスの失敗例でいうと、すべての(マイクロ)サービスが個別にlog4j2でログを吐いていた、みたいな状況とかかな。いくつもあるサービスのログ出力を全部改修しないとならない。モノリスなシステムなら1つのシステムの改修で済むのに。どんなアーキテクチャにも得意不得意、トレードオフになっている部分があるから、盲目的な採用はよろしくない。
1
kisahara @kisahara1 8日前
場合によるとしか言えない
1
doragrenin @doragrenin 8日前
2mocccck 出力を変えるというよりログを収集して回る別の仕組みを作ることになるね。というかそこら辺は標準化してからマイクロサービス化しないといけない。
0
cyphergoodluck @cyphergoodluck 8日前
2mocccck doragrenin 純粋関数型プログラミング脳なハッカーがマイクロサービス内の内部エラーも値の一つとして返すようにやったりしたけどそれはそれでジュニアの常人には理解しづらくなるという結果に。
0
cyphergoodluck @cyphergoodluck 8日前
ohayou828 機能的凝集と言われた時に「機能ってビジネス依存ですよね?」としかならないのと似ている気がする。
2
doragrenin @doragrenin 8日前
cyphergoodluck やり方は一つじゃないと思うけど、エラーログは形式を標準化して(syslog等)テキストファイルでどこかに出しておくのが一般的だと思う。後はログ収集マイクロサービスを作って回収する感じか。内部エラーを返すだけだと、呼び出したアプリは分かるけど後から追いかけるのが大変。呼び出したアプリがログを吐くなら結局のところログ処理が必要になるしな。
0
V層もどき@秋例大祭た31ab @desuga_NlkL5EiN 8日前
ひとつの塊では問題が複雑過ぎて解決できないから分割するわけで、分割対象が大量かつ多様なら、それらを把握・制御するという別の問題を抱え込むことになるわけで……。
1
V層もどき@秋例大祭た31ab @desuga_NlkL5EiN 8日前
「システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう」というのがコンウェイの法則として知られてますけど、まあ、組織が成立しているならシステムも成立しそう、というのはあるわけで、ひとつの落ち着きどころではあるんでしょうね。
0
ヴィス @2vis 7日前
集約型か分散型かってのはシステム的に永遠に課題。 でも、ファスト教養じゃないけど、みんなわかりやすい答えが欲しいんだろうなぁ。 マイクロサービスでアジャイルが鉄板!みたいな。
0
犬だよ @yaju5123 7日前
desuga_NlkL5EiN この辺、インフラのレイヤでもNWセグメントや基盤(場合によってはSaasやVM単位)が乱立するのと似てますね。 分際するとシステム毎のリリースの速度は上がりますけど、①セキュリティ対策 ②変更・構成管理 ③担当者引き継ぎ この辺が難航するのはアプリもインフラも同じ感じっぽい。
1
お空キレイキレイ @747_bold 7日前
集約の方が将来的に負債が少ない 今はまだその実感がわいているのが一部の企業なだけな気がする マイクロサービスは将来への等価交換と思ったほうがいい
0