順調だったスタートアップがMSAを導入し、6か月で潰れかけた話

最近、海外の技術ブログで話題になった "Microservices Killed Our Startup. Monoliths Would’ve Saved Us" という記事を読んだのですが、内容があまりにも痛烈で、それでいて強く共感できたので要約して共有します。

最新技術を無条件に導入することが、どれほど危険かを示す良い「失敗ノート」のように感じます。

---

1. 事の発端: 「うちもNetflixみたいにやりましょう」

• 状況: シード投資で $2.5M を調達し、月間売上は 40% 成長、ユーザーは 5万人。Rails のモノリスで非常にうまく回っていたスタートアップ。
• 問題の始まり: リードアーキテクトが現れ、「スケーラビリティ (Scalability)」を掲げて MSA への移行を提案。
• 理屈: 「今の構造は結合度が高すぎる。Netflix や Uber を見てみろ。自分たちも彼らのようになるなら、マイクロサービスに行くべきだ」
• 現実: 開発者 4人、DevOps 1人のチームで Netflix アーキテクチャを導入することを決定。

2. 地獄の6か月（MSA導入タイムライン）

[1か月目: ハネムーン]

• 通知サービスの分離に成功。「ほら！ うまくいってるだろ？」と自画自賛。
• しかし、デプロイ時間の増加、リポジトリの増加など、前兆はすでに始まっていた。

[2〜3か月目: 亀裂の始まり]

• 課金 (Billing) サービスを分離。これがユーザー、在庫、注文サービスとすべて結びついていた。
• 結果: ネットワークレイテンシにより応答速度が 200ms → 800ms に低下。1つのサービスが落ちると全体が止まる連鎖障害が発生。

[4〜5か月目: 分散トランザクションの悪夢]

• モノリスなら DB トランザクション1つで済んでいたことが、分散環境では Saga パターン の導入にまで発展。
• 在庫は減ったのに決済は失敗し、ロールバックはもつれ……データ不整合によって CS が殺到。
• 単純なカラムを1つ追加するだけでも 6つのサービスを触る必要があり、2時間で終わる作業が3日かかるように。

[6か月目: チーム崩壊]

• 開発者たちは機能開発ではなく、インフラ管理にすべての時間を費やすようになる。
• インフラ費用は $3,000 → $12,000 に増加（4倍に急増）。
• 中核開発者が退職（「私はプロダクトを作りに来たのであって、一日中 Kubernetes を触るために来たわけじゃない」）

3. 決断: 「私たちはNetflixではない」

アーキテクトはなおも「Service Mesh を導入し、監視ツールを増やそう」と主張しましたが、筆者はついに爆発します。

> 「私たちはNetflixじゃない！ Netflix にはエンジニアが500人いるが、うちは4人なんだ！」

結局アーキテクトは退職し、チームは モノリスへの回帰 (Rollback) を決断します。

4. モノリスへの復帰、そして復活

• 8週間かけて、コードを再びモノリスへ統合。
• 結果:
• 機能リリース速度が回復（月 4件 → 20件）
• 応答速度は 220ms で安定
• インフラ費用が減少
• 何よりも 開発者の幸福度が上昇

5. 核心の教訓（この記事の結論）

1. MSA は『技術的な問題』ではなく、『組織的な問題』を解決するための道具だ。

• 開発者が 50人以上いて互いに足を踏み合うようになったとき、デプロイ周期があまりに違うときに使うものだ。

2. Netflix / Google はあなたのロールモデルではない。

• 彼らも最初はモノリスだった。規模が大きくなったから変えたのであって、最初からそうだったわけではない。

3. 複雑性は税金だ。

• サービスが増えるたびに、管理コストは複利で増えていく。

4. ネットワーク呼び出しは無料ではない。

• メモリ内の関数呼び出し（ナノ秒）とネットワーク呼び出し（ミリ秒）では、次元がまったく違う。

---

一行要約:
「モノリスは敵ではない。悪いアーキテクチャが敵だ。4人のチームなら、どうか素直にモノリスを使え。」

[ahwjdekf]

さあ、これでMSA狂信者たちが押し寄せてきます

[aer0700]

ネットワーク呼び出しはタダではない、というのはその通りですね。関数呼び出しとAPIコールは明らかに別物です。

[bungker]

私はプロダクトを作りに来たのであって、一日中 Kubernetes をいじりに来たわけじゃない —> これは私が聞いた中で最もバカげた発言ですね

[hohemian]

なぜですか？ k8sが目的のためのk8sをやっている状況では、その通りの話のように思えますが？

[roxie]

bungker さんのコメントが好きで一つずつ押して見ているのですが、これだけは共感できませんね。うーん、補足説明をしていただけますか

[passerby]

中身のないAI記事ですね。だから最近はMediumをほとんど見ません。

[mhj5730]

4人で作ったサービスなら、MSAに分割する理由はないように思いますね。

[moderato]

MSAをやるなら、組織もMSAに合わせないといけませんね...

[ifmkl]

下の要約では、4番が言いたい要点なのではないかと思います。あと、全体的に内容そのものには共感できます。

[bsh998]

うーん…何かおかしい気がします。
この記事、AIで書かれたようですね。

[baeba]

私も最近よく感じることですが..
多くのブログの記事は、本人の経験 + AIの助けを借りて
書いているのではないかと推測しています。
あまりにも文章が論理的で、読みやすく書かれているので。

[bsh998]

私が言いたかったのは、あまりにもAIっぽく、参考資料もないので、このような文章は共有しないでほしいという意見です。

[baeba]

Hacker News に投稿された記事です。私が投稿する記事の大半は Hacker News に掲載された内容です。

https://news.ycombinator.com/item?id=46469845

おっしゃる通りです……。Hacker News の参照元を載せるようにしますね。

[baeba]

1) 文章の信頼性への疑い: マーケティング/AI生成物っぽい臭いがする

要旨

• 「これ、教訓劇みたいに出来すぎている」→ HNが好みそうな“道徳劇”向けに最適化された文章では、という疑いが出ていた
• 本文に有料資料へのリンクがベタベタ貼られていて、「結局セールス記事ではないのか」という声が強かった
• リストの多用や絵文字っぽい文体が、「AI slop（雑に量産されたAIコンテンツ）」のシグナルだという指摘

痛烈な引用（翻訳）

「全体がリンク先の有料資料を売るために作られたように見える。リストだらけでAI slopっぽさがある。」
（原文: Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.）

ひとこと評

• 「内容の正否以前に、売り込み臭 + AI臭が強すぎる」が最初の反応だった。

---

2) リーダーシップ/アーキテクト批判: 問題は技術ではなく『意思決定構造』だった

要旨

• 「4人チームにアーキテクト？」という時点で、すでにおかしいという反応が多かった
• 特に コードを書かないアーキテクト/分離されたDevOps役割 を「ボトルネック + 履歴書最適化」と見る視点が強かった
• マイクロサービスそのものではなく、「誰も責任を持ってデプロイ/運用/火消しをしない構造」が会社を危うくした、というトーン

痛烈な引用（翻訳）

「実際に何も実装しないのに“ルール”だの“パターン”だのを決めるアーキテクトは、ほぼ常に悪手だ。とにかく出荷に集中しろ。コードを10行も書かない人間が意思決定を独占すると失敗する。」
（原文: Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...）

ひとこと評

• 「MSAが問題なのではなく、決定権はあるのに責任はない役割設計 が問題だった」という見方がかなり強かった。

---

3) ビジネス観点: スタートアップ失敗の原因は本当にMSAだったのか？

要旨

• 「アーキテクチャのせいで失敗した」というフレーミング自体を信じていないコメントもあった
• 核心は、PMF/需要/顧客ロックイン が弱ければ、どんなスタックでも失敗しうるという主張
• 特に「2日遅くなっただけで顧客がすぐ離れる？」のようなディテールから、もともとの製品価値が弱かったのではと突っ込まれていた
• さらに記事内部の矛盾も指摘された。「MSAがスタートアップを殺した」と言いながら結論は「生き残った？」で、物語を盛っているのではという疑い

痛烈な引用（翻訳）

「スタートアップを殺したのは、人々が欲しがらない製品を作ったことだろう。PythonかGoかでスタートアップが死んだと言うのと同じくらい筋が通らない。」
（原文: Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...）

ひとこと評

• 「アーキテクチャは言い訳で、本当の原因は市場/製品/キャッシュフロー かもしれない」という見方は確かに存在した。

---

4) 技術的洞察: モノリス vs MSA の経験ベースの助言（本当に役立つ部分）

要旨

• 「MSAには固定費（運用の複雑さ）という税金がある」→ 小さなチームには致命傷になりうる、という体験談が多数
• 重要キーワード: Premature distribution（早すぎる分散）, モジュラーモノリス/Modulith, 「境界（boundary）は“稼いで”得ろ」
• MSAが必要になる条件も現実的に示されていた: チーム規模が大きくなり、衝突/デプロイ/組織面の問題が実際に表面化したとき
• 一方で性能やスケーリングの問題は、たいてい「MSAで解決」ではなく、まずアルゴリズム/ボトルネック/シャーディング/パーティショニングを見るべきだという助言もあった

痛烈な引用（翻訳）

「スタートアップを殺したのはマイクロサービスではなく、『早すぎる分散』だ。本物の境界が生まれる前に分割してしまい、レイテンシと調整コストだけを払うことになった。モジュラーモノリスから始めて、境界を稼ぎ取ってから切り出すべきだ。」
（原文: Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.）

ひとこと評

• コミュニティが実際に共感した教訓はこれだった。
  「モノリスで始めて、境界が“自然に”生まれたときだけサービスを分離しろ。」

---

コミュニティ総評ひとこと

「私たちはNetflixではない」には大半が同意していたが、同時に「この文章自体が“Netflix病”を売り込むための物語（=マーケティング/AI）かもしれない」という疑いも強かった。