2026年10月21日水曜日

モノリスからマイクロサービスまで｜アーキテクチャ設計思想・流行りの歴史 - - YouTube動画の紹介と、解説

モノリスからマイクロサービスまで｜アーキテクチャ設計思想・流行りの歴史

エンジニア転職チャンネル【RUNTEQ公式】
チャンネル登録者数 9.43万人
回視聴
2026/10/20 #RUNTEQ #ランテック #エンジニア転職チャンネル
『マイクロサービスが最強！』…それ、本当に合ってますか？👀 難しそうなアーキテクチャの基本も、背景を知ればスッキリ理解できちゃいます！ この動画ではモノリスからクリーンアーキテクチャまで、外側と内側のシステム設計の歴史と最新トレンドをわかりやすく解説✨ 「結局どう設計すればいいの？」と迷う方は必見！開発をスムーズにするヒントがここに💡 Web系開発企業への転職に強い 超実践型エンジニア育成スクールRUNTEQ ▼設計思想ヒストリーガイド https://claude.ai/artifact/WEYgD7C2g9... ▼【公式LINE限定セミナー・イベント】 友だち追加で転職・学習に役立つ情報や限定コンテンツをGET！ https://line-ops.runteq.jp/r/kxB7uPds ▼【エンジニア転職・IT業界へのキャリアチェンジ】 未経験からエンジニア転職を目指すなら、超実践型プログラミングスクールRUNTEQ 無料カウンセリングでお気軽にキャリア相談！ https://runteq.jp/?utm_source=youtube... 今なら「専門実践教育訓練給付金」でお得に受講！ ▼【現役エンジニアのスキルアップ・キャリアアップ】 AI時代に戦えるエンジニアに。キャリア相談はRUNTEQへ！ https://runteq.jp/?utm_source=youtube... ▼【実務につながるClaude Code活用（実践研修）】 その仕事、AIに任せてみませんか？エンジニアでなくてもClaude Codeで叶う業務効率化。 Claude Codeコース（個人向け）：https://runteq.jp/claude-code/?utm_so... Claude Code実践研修（法人向け）：https://www.runteq.co.jp/claude-code-... ▼【企業のAI活用・導入支援】 AI（Claude Code）導入コンサル・エンジニア研修・AI駆動開発内製化のご相談はRUNTEQへ。 https://business.runteq.jp/?utm_sourc... 【出演者】 菊本久寿（ X： / hisaju01 ） 株式会社RUNTEQ代表取締役社長。 日本のスタートアップエコシステムを技術と教育の両面から牽引するエンジニア起業家。 SIerを経て、ngi group（現：ユナイテッド）では技術部長としてアドテクノロジー開発を主導。フリーランス時代には、数多くの有名スタートアップにCTOや技術顧問として参画し、黎明期からその成長を支えた。 2014年に株式会社スタートアップテクノロジーを設立し、新規事業の技術開発に特化したプロフェッショナル集団を率いる。日本のエンジニア不足という課題を解決すべく、2019年に開校したプログラミングスクール「RUNTEQ」は、比較検証サイトマイベストで「プログラミングスクールおすすめ人気ランキング」4年連続No.1（2025年時点）を獲得。 【目次】 00:27 本日のテーマ 00:46 外側・内側の違い 01:34 モノリスアーキテクチャ 01:57 モノリスの問題点 02:26 SOA 05:22 マイクロサービス 05:29 Netflixについて 07:30 Chaos Monkey 09:28 マイクロサービス問題点 09:51 ①モジュラーモノリス 10:44 ②サービスベースドアーキテクチャ 12:25 内側の話 12:29 MVC 13:08 DDD 13:46 ヘキサゴナル 14:18 クリーンアーキテクチャ 15:31 まとめ #RUNTEQ #ランテック #エンジニア転職チャンネル #エンジニア #エンジニア未経験 #エンジニア転職 #転職 #エンジニア採用 #プログラミング #プログラミング初心者 #プログラミングスクール #ITエンジニア #AIエンジニア #AI開発 #Ruby #rubyonrails #python #アーキテクチャ #マイクロサービス #システム設計
この動画は、「アーキテクチャは流行で選ぶものではなく、なぜその設計思想が生まれたのかを理解しよう」というメッセージが一番重要です。 特にRUNTEQの菊本さんは、2000年代からスタートアップや受託開発を経験してきた人なので、「歴史を知ること」を重視した解説になっています。 以下、動画の内容に雑学や業界の裏話を交えながら説明します。

① 外側の設計と内側の設計

動画でも最初に説明されていますが、 アーキテクチャには大きく2種類あります。 外側
  • サービスをどう分割するか
  • サーバーをどう配置するか
  • システム全体の構造
内側
  • コードをどう整理するか
  • ビジネスロジックをどう書くか
  • 保守しやすい設計
これは新人が混同しやすいポイントです。 例えば 
マイクロサービス
    ↓
その中身が
    MVC
    DDD
    クリーンアーキテクチャ
という組み合わせも普通です。 つまり マイクロサービス = クリーンアーキテクチャ ではありません。

② モノリス

昔はほぼ全部モノリスでした。 
ユーザー
   ↓

Webサーバー

・会員
・注文
・決済
・商品
・管理画面

全部一つ
Rails Laravel Django この辺は全部モノリスが得意です。

なぜ昔はモノリスだったのか

理由は単純で サーバーが高かったから。 2005年頃は 
1サーバー
100万円
なんて珍しくありません。 だから 「全部一台に詰め込もう」 となります。

モノリスのメリット

  • 作るのが速い
  • デバッグしやすい
  • データベースが一つ
  • テストしやすい
今でも スタートアップの初期は 9割くらいモノリス です。 ここは動画でも強調されています。

③ SOA

ここは若い人は知らない人も多いです。 SOA (Service Oriented Architecture) 2000年代中頃に流行りました。 当時 企業は 
人事
会計
物流
販売

全部別システム
でした。 それを 
Webサービス化

APIで繋ぐ
という考え方です。

なぜSOAは流行らなくなった？

SOAP XML ESB Enterprise Service Bus など とにかく重かった。 企業向けなので 
仕様書100ページ
なんて普通でした。 現在のREST APIとはかなり違います。

④ Netflixが世界を変えた

動画でもかなり時間を割いています。 実は Netflixは マイクロサービスを発明したわけではありません。 世界中に広めた会社です。

なぜNetflixだったのか

Netflixは ある日 大量アクセスで サーバーが頻繁に落ちました。 昔はDVDレンタル会社でしたが 動画配信になってから アクセス量が桁違いになります。 そこで AmazonのAWSへ移行。 さらに 
全部小さく分割
しました。 例えば 
ログイン

作品検索

レコメンド

課金

視聴履歴
全部別サービス。

⑤ Chaos Monkey

これは業界でも有名です。 Netflixが作った Chaos Monkey 名前が最高ですよね（笑） 何をするかというと 
本番サーバーを
勝手に落とす
です。 え？ と思いますよね。
理由は 「落ちても動く設計」 を強制するため。 つまり 
サーバーA死亡

↓

サーバーBへ切替
これが本当にできるか 毎日テストする。 かなり狂気じみていますが、 GoogleやAmazonなども「障害は必ず起きる」という前提で設計する文化があり、障害耐性を高める考え方として広まりました。

⑥ マイクロサービスの落とし穴

ここが最近のトレンドです。 数年前 世界中が 
マイクロサービス最強！
と言っていました。 しかし 実際には 運用が地獄。 例えば 
50サービス
あると ログを見るだけで大変。
例えば注文処理 
注文API

↓

在庫API

↓

配送API

↓

決済API

↓

メールAPI
どこで止まった？ 探すだけで数時間。
だから最近は 分けすぎた という反省があります。

⑦ モジュラーモノリス

今かなり人気です。 考え方は 
見た目は一つ

中だけ分離
注文

商品

会員

↓

コードだけ分ける
デプロイは一回。 データベースも一つ。 でも コードは綺麗。
最近のスタートアップでは かなり採用されています。 理由は 十分速いから。

⑧ サービスベースドアーキテクチャ

動画でも紹介されています。 これは 
5〜10個くらい

適度に分ける
という考え。 極端な 100サービス みたいなことはしない。 実務では かなり現実的です。

⑨ MVC

ここから内側。 MVCは Rails人気のおかげで 日本では非常に有名です。 
Model

View

Controller
初心者向け。 理解しやすい。 だから今でも現役。

⑩ DDD

DDD Domain Driven Design ここは誤解が多いです。 DDDは 設計手法というより 業務理解の方法論です。 例えば 病院なら 医師 看護師 患者 診察 予約 全部言葉を統一します。 これを **ユビキタス言語（Ubiquitous Language）**と呼びます。 実際の現場では、「この『顧客』って法人？個人？契約者？利用者？」のような言葉のズレがバグや仕様漏れにつながることがよくあります。

⑪ ヘキサゴナルアーキテクチャ

別名 Ports & Adapters これは 
DB

Web

外部API
を交換しやすくする設計です。 つまり 
MySQL

↓

PostgreSQL
へ変更しても 中身を変えない。

⑫ クリーンアーキテクチャ

これは Robert C. Martin（通称 Uncle Bob）が提唱した考え方です。 有名なのが 
依存方向

↓

全部内側
ルール。 ビジネスロジックは Railsにも Springにも 依存しない。 だから フレームワークを交換できる。

ただし

業界では クリーンアーキテクチャを そのまま採用する会社は 実は少ないです。 理由は 少し大げさだから。 必要以上にファイルが増え 
Controller

UseCase

Interactor

Presenter

Gateway

Repository

Entity
など 小規模開発では 逆に遅くなることもあります。 そのため、多くの現場では考え方だけを取り入れ、プロジェクト規模に合わせて簡略化するケースが多いです。

⑬ 最近（2025〜2026年）の流れ

ここは動画では軽く触れる程度ですが、業界全体では次のような傾向があります。
  • まずはモジュラーモノリスで始める
  • 本当に必要な部分だけサービス分割する
  • DDDの考え方で業務を整理する
  • AI（Claude Code、Copilotなど）を活用しやすいように、責務が明確で読みやすいコードを書く
AIがコード生成やレビューを支援する時代になり、細かく分かれすぎた複雑な構成よりも、「人にもAIにも理解しやすい構造」が評価される場面が増えています。

この動画の本質

この動画が一番伝えたいのは、
アーキテクチャには「最強」は存在せず、時代の課題を解決するために生まれたものだ、ということです。
  • 小さなサービスなら、シンプルなモノリスが最も効率的なことが多い。
  • チームや利用者が増え、運用上の課題が出てきたら、モジュラーモノリスやサービス分割を検討する。
  • コードの内部設計では、MVC・DDD・クリーンアーキテクチャなどを「目的に応じて」組み合わせる。
経験豊富なエンジニアほど「流行っているから採用する」のではなく、「今のプロダクトや組織の課題を解決できるか」という視点でアーキテクチャを選びます。そこが、この動画の一番実践的で価値のあるメッセージと言えるでしょう。

エンジニア転職チャンネル（RUNTEQ公式）の動画「モノリスからマイクロサービスまで｜アーキテクチャ設計思想・流行りの歴史」について、IT業界の裏話や興味深い雑学を交えて詳しく解説します！

🏛️ 1. はじめに：アーキテクチャは「外側」と「内側」の2つに分けて考える

アーキテクチャという言葉は一括りにされがちですが、本質的には以下の2つに大別されます。

  • 外側のアーキテクチャ（アプリケーション・システムの分割単位）： インフラやデプロイ単位として、サービス全体をどう切り分けるか（モノリス、マイクロサービスなど）。

  • 内側のアーキテクチャ（コード・クラス構造の設計）： クラスファイルやデータの持ち方、依存関係をどう整理するか（MVC、DDD、クリーンアーキテクチャなど）。

歴史やトレンドを整理する上でも、この「外と内」の視点を持つことが非常に重要です。

🌐 2. 外側（システム・デプロイ単位）の歴史とトレンド

① モノリス（Monolith Architecture） [01:34]

  • 概要: 全ての機能やコードが「1つの巨大なアプリケーション・サーバー」にまとめられている構成（例：初期のRuby on Railsアプリなど）。

  • 歴史と雑学: すべてのシステム開発はここからスタートします。シンプルで作りやすい反面、サービスが巨大化（Amazon級の規模）すると、デプロイ（本番反映）の失敗による影響範囲が計り知れず、修正に何時間もかかる「恐怖の塊」になってしまいます。

② SOA（Service-Oriented Architecture：サービス指向アーキテクチャ） [02:26]

  • 概要: 2000年前後にガートナー社などが提唱。社内のバラバラなシステムを「サービス」という単位で切り分け、互いに連携させようという発想。

  • 裏話・雑学: 当時のIT業界では、すべての通信を仲介する巨大な連携基盤（ESB：Enterprise Service Bus）を導入するのが大流行しました。しかし、IBMなどの大手ベンダーが売るこのESB製品は非常に高額で、設定やミドルウェアの運用が複雑怪奇でした。「導入は大変なのに思ったほど楽にならない」という痛い失敗を多くの企業が経験し、ビジネス寄りの思惑（大手が儲かる仕組み）が強すぎた歴史があります。

  • 例外の成功例: 奇しくもこのSOAの思想を先取りして大成功を収めたのがAmazonです。1995年に1台のサーバーから始まった同社は、2001年頃にはすでにサービス単位での分割（150種類以上のサブサービス、顧客数6,000万人規模）を実践していました [04:33]。

③ マイクロサービス（Microservices） [05:24]

  • 概要: サービスを極限まで小さく分割し、データベースも含めて完全に独立させるアーキテクチャ。

  • 歴史とエピソード:

    • 引っ張ったのはNetflixです [05:29]。2008年8月、Netflixは単一のリレーショナルデータベースが壊れる大事故を起こし、DVDの発送が3日間ストップしてしまいました。これを機に「一部が壊れても全体が止まらない仕組み」へ舵を切ります [06:04]。

    • 当時は動画配信ではなくDVDの郵送レンタル会社だったNetflixですが、2009年からAWSへの移行とシステムの細分化を開始し [06:36]、2016年1月に1,000以上のサービスへの分割を完了しました [08:14]。

    • カオスモンキーの誕生: 「障害は起きるもの」としてシステムを設計するため、本番環境のサーバーをわざとランダムに落として耐性をテストする狂気のツール「カオスモンキー」がNetflixから生み出されました [07:31]。

    • 命名の背景: こうした現場の試行錯誤が実を結んだ後の2014年、著名エンジニアのマーティン・ファウラー氏らが「マイクロサービス」という言葉で体系化・命名し、世界中に爆発的なブームが巻き起こりました [08:44]。

④ 最近のトレンド：「いいとこ取り」への揺り戻し [09:41]

マイクロサービスは強力ですが、「リポジトリが分かれすぎて管理が複雑」「開発コストが跳ね上がる」という課題があります。そのため、現在は以下のような「いいとこ取り」が模索されています。

  • モジュラモノリス（Modular Monolith）: インフラやデプロイはモノリスのまま、コードベースの内部をドメインごとにきっちり境界で区切る手法 [10:03]。巨大なRailsアプリで知られるShopifyなどがこの道を選び、綺麗に進化させています [10:14]。

  • サービスベースドアーキテクチャ（Service-Based Architecture）: マイクロサービスほど細かく分けず、ざっくりとした機能単位（例：ログイン機能、登録機能など）で分けつつ、裏側のデータベースなどは共通化する現実的な落とし所 [10:46]。

🧱 3. 内側（コード・設計思想）の歴史とトレンド

① MVC（Model-View-Controller） [12:29]

  • 歴史: 1978年にトリグ・リンスカウ氏がプログラミング言語「Smalltalk」向けに考案 [12:35]。

  • 背景: 50年近く前の発想でありながら、現在もRuby on Railsなどの主要フレームワークの根底に生き続けている、歴史的傑作のパターンです [12:51]。

② DDD（Domain-Driven Design：ドメイン駆動設計） [13:08]

  • 歴史: 2003年にエリック・エヴァンス氏が提唱 [13:13]。

  • 背景: 「注文をキャンセルする」といった、現場のビジネス現場で実際に使われている言葉（ユビキタス言語）をそのままコードの構造に落とし込んでいく考え方 [13:21]。銀行や保険など、業務ロジックが極めて複雑なドメインで真価を発揮します。

③ ヘキサゴナルアーキテクチャ（Ports & Adapters） [13:46]

  • 歴史: 2005年にアリスト・コバン氏が提唱 [13:49]。

  • 背景: アプリケーションの中心（ビジネスロジック）を、UIやデータベースといった外部の都合から切り離し、どちらも後から自由に取り替えられるように守る（六角形の図で表現される）思想です [14:03]。

④ クリーンアーキテクチャ（Clean Architecture） [14:18]

  • 歴史: 2012年頃に提唱・整理された、現在のデファクトスタンダード。

  • 背景: ヘキサゴナルやDDDの考え方をさらに洗練させ、「依存の方向は常に外側から内側へ」という原則を徹底したもの [14:38]。一番外側に「変わりやすいもの（UI、フレームワーク、DB）」を置き、一番中心には「絶対に変わらないビジネスルール」を配置します [14:48]。

💡 4. まとめ：全体を貫く共通の思想とAI時代の現在地

動画の終盤で語られている通り、外側の歴史も内側の歴史も、根底にある思想は一貫しています。

  • 外側: 「システム全体が共倒れするのを防ぐため、あえて切り離したり、耐性を持たせる」 [15:50]

  • 内側: 「変化の激しい外部環境から、ビジネスの核心（コアロジック）を守る」 [16:01]

そして現在は、AIの普及によって開発スピードが圧倒的に爆発した反面、コードの「技術的負債」も溜まりやすい時代になっています [16:18]。だからこそ、「どの部分を守るべきか」「どこを割り切るべきか」という設計思想の本質を理解しておくことが、エンジニアにとってますます重要になっています。

この動画は、RUNTEQ公式の「エンジニア転職チャンネル」で2026年10月20日に公開されたもの。菊本久寿さん（RUNTEQ代表）が、**外側（システム全体の分割・デプロイ単位）と内側（コード内部の構造・依存関係）**の2軸で、アーキテクチャの歴史と流行をざっくり整理しています。

「マイクロサービスが最強！」という神話を一旦崩して、「結局どう設計すればいいの？」という実務寄りの視点に持っていく構成が、転職・学習層向けに上手いです。

以下、動画の流れに沿って解説しつつ、雑学と業界の裏話を交えます。

外側と内側の違い（動画 00:46〜）

アーキテクチャを語るとき、多くの人は「モノリスかマイクロサービスか」という外側の話に終始しがちです。でも実際には、**外側（どう分けるか・どうデプロイするか）と内側（コードの中でどう責務を分けるか）**は別物です。

  • 外側：デプロイ単位、チームの独立性、障害の波及範囲、スケーリングの単位
  • 内側：MVC、DDD、ヘキサゴナル、クリーンアーキテクチャなどの「コードの書き方・依存の方向」

この2つを混同すると、「マイクロサービスにしたのに中身がスパゲッティ」みたいな悲劇が起きます。業界ではよくある話です。

外側の歴史：モノリス → SOA → マイクロサービス → 揺り戻し

1. モノリスアーキテクチャ（01:34〜）

全部が1つのアプリケーションに詰まった状態。シンプルで最初は最強です。

問題点が出てくるのは規模が大きくなってから。コードベースが肥大化し、変更の影響範囲が読めなくなり、デプロイが怖くなる。いわゆる「Big Ball of Mud（大きな泥だんご）」状態。1990年代後半から指摘されていた古典的な問題です。

2. SOA（Service-Oriented Architecture）（02:26〜）

2000年代の企業システムで流行した「サービス指向」。機能をサービスに分け、ESB（Enterprise Service Bus）という共通バスでつなぐ思想。

雑学・業界話：SOAは「再利用性」と「レガシー統合」を強く意識していました。ただし、ESBが中央集権的になりすぎて、結局ボトルネックになるケースが多かった。「サービスに分けたのに、バスが単一障害点」という皮肉がよく語られます。マイクロサービスはこの反省から「バスを薄く、サービスを独立に」という方向に振ったもの、という見方ができます。

3. マイクロサービスとNetflix（05:22〜）

2010年代前半から爆発的に流行。James LewisとMartin Fowlerの2014年の記事が火付け役になりました。

Netflixが象徴的です。DVD配送からストリーミングへ移行する過程で、自前のデータセンターからAWSへ移行し、数百のマイクロサービスに分解していきました。

業界の名物エピソード：Chaos Monkey（07:30〜） Netflixが作った「ランダムに本番インスタンスを殺すツール」です。 理由はシンプルで、「障害は必ず起きる。だったら、起きてほしい時間（営業時間）に意図的に起こして、復旧力を鍛えよう」という発想。 2008年に自社データセンターでデータベース障害が起きて3日間ほぼ止まった経験が、この過激なアプローチの原点だと言われています。 後に「Simian Army」という一群のツールになり、Chaos Kong（リージョン全体を落とす）まで登場しました。カオスエンジニアリングという分野の原点です。 「障害を怖がるな、むしろ味方にしろ」というNetflixの文化が、ここによく表れています。

4. マイクロサービスの問題点と揺り戻し（09:28〜）

独立デプロイやスケーラビリティのメリットの裏で、

  • 分散トランザクションの難しさ
  • 運用・監視コストの爆発
  • サービス間のネットワーク遅延
  • テスト環境の複雑化

などが顕在化。「マイクロサービス疲れ」が起き始めました。

動画ではその対策として2つ挙げられています：

  • ① モジュラーモノリス（09:51〜） 見た目は1つのモノリスだが、内部をモジュール境界できっちり区切る。ネットワークを挟まず、プロセス内で呼ぶのでシンプル。将来マイクロサービスに切り出しやすい「準備されたモノリス」として、ここ数年特に評価が高まっています。
  • ② サービスベースドアーキテクチャ（10:44〜） マイクロサービスほど細かくせず、ある程度まとまった「サービス」単位で分ける中間形態。実務ではこの辺の「ちょうどいい粒度」を探るケースが増えています。

業界の空気感（2020年代後半〜）： 「最初からマイクロサービスで始めるな。まずモノリス（できればモジュラー）で始めて、本当に必要になった部分だけ切り出せ」というのが、Martin Fowler自身も含めて主流の意見になっています。Segmentが140以上のマイクロサービスからモノリスに回帰した話などは、典型例としてよく引き合いに出されます。

内側の話（12:25〜）

外側をどうするかに関わらず、コードの中身の構造も進化してきました。

  • MVC（12:29〜）：古典。ViewとModelをControllerでつなぐ。シンプルだが、ビジネスロジックが肥大化しやすい。
  • DDD（Domain-Driven Design）（13:08〜）：業務ドメインを中心にモデリングする思想。境界づけられたコンテキストなどの概念が、後のマイクロサービス分割にも影響を与えました。
  • ヘキサゴナルアーキテクチャ（Ports and Adapters）（13:46〜）：ドメインを中心に置き、外側の技術（DB、UI、外部API）をアダプターでつなぐ。依存の方向を内側に向ける。
  • クリーンアーキテクチャ（14:18〜）：Robert C. Martin（Uncle Bob）が整理したもの。依存関係のルールをより厳密にしたもので、ヘキサゴナルの進化形・体系化版とも言えます。

これらは「外側をマイクロサービスにしても、内側がぐちゃぐちゃだと意味がない」という現実を反映しています。

まとめのニュアンス（15:31〜）

動画全体のメッセージは、だいたいこうです：

  • 「流行っているから」で選ぶな
  • チーム規模・ドメインの成熟度・運用能力に合わせて選べ
  • 外側を分ける前に、内側のモジュール境界をきちんと作っておくのが大事
  • モジュラーモノリスは、今かなりバランスの取れた選択肢になっている

雑学的な補足： アーキテクチャの流行は、だいたい「前のスタイルの限界を解決しようとして次が生まれ、その次の限界でまた揺り戻しが起きる」というサイクルを繰り返しています。モノリスの限界 → SOA → マイクロサービス → モジュラーモノリス、という流れは、まさにその典型です。

実務で「うちはマイクロサービスにすべきか？」と聞かれたら、まず「チームは何人？ ドメイン境界は安定してる？ 運用できる人はいる？」と聞き返すのが、最近の賢いエンジニアの定番対応になりつつあります。

必要なら、動画で触れられている各アーキテクチャの「向いているケース／向いていないケース」をもう少し深掘りします。

動画の本文(字幕)は見られず、概要欄の目次と私の知識をもとにした解説です。実際の動画の話と細部が違う可能性はありますが、流れはほぼ同じはずです。

全体像:「外側」と「内側」の設計

動画は設計を2つの視点で分けています。

  • 外側: システム全体をどう分割して配置するか(モノリス → SOA → マイクロサービス → 揺り戻し)
  • 内側: 1つのアプリの中のコードをどう整理するか(MVC → DDD → ヘキサゴナル → クリーンアーキテクチャ)

どちらも「変更に強くしたい」「チームが大きくなっても開発を止めたくない」という同じ悩みへの答えで、規模が違うだけです。

外側の歴史

モノリス 1つのアプリに全機能を詰め込む構成です。小さいうちは、デプロイも調査も簡単で最強です。ただ、規模が大きくなると「1行直したら全体を再デプロイ」「どこを触ると壊れるか誰も分からない」状態になります。

SOA(2000年代) 機能をサービス単位に分けて連携させる発想です。ただ、当時はサービス間の連携に重量級のESB(企業サービスバス)やSOAP/XMLを使うことが多く、「重い、複雑、ベンダー主導」と評判を落としました。

雑学として有名なのが、2002年頃のAmazonです。ジェフ・ベゾスが「全チームは機能をAPIとして公開せよ。守らない者はクビ」という趣旨のメールを送ったという逸話があります。元Amazon・Googleのスティーブ・イェギーの有名な投稿で広まった話で、AWS誕生の土台になったとも言われます。

マイクロサービスとNetflix Netflixは2008年に大規模なDB障害で数日間DVD出荷が止まり、「単一障害点を作らない」ためにAWSへ移行し、サービスを細かく分割しました。ここから生まれたのがChaos Monkeyで、本番環境のサーバーをわざとランダムに落とし、「落ちても平気な設計」を強制します。「障害は起きるもの」という前提に立つ発想は、今のSREやカオスエンジニアリングにつながっています。

用語自体は2011年頃のワークショップで使われ始め、2014年にマーティン・ファウラーらの記事で広く知られるようになりました。

マイクロサービスの落とし穴

  • サービス間通信、分散トランザクション、監視、デプロイ基盤など運用が一気に難しくなる
  • 分け方を間違えると、サービスが密結合のまま分散した「分散モノリス」になる
  • 組織の構造がそのまま設計に出る(コンウェイの法則)ので、Netflixのような大組織でないと割に合わない

有名な事例が、Amazon Prime Videoが2023年に、ある監視サービスをマイクロサービスからモノリスに戻してコストを約9割削減したという公開記事です。Segmentも2018年に似た事例を出しています。

現実解としての2つの選択肢

  1. モジュラーモノリス: デプロイは1つのまま、内部をモジュールで厳密に分ける。Shopifyが有名で、Railsの作者DHHの「Majestic Monolith(威風堂々のモノリス)」もこの系譜です。
  2. サービスベースドアーキテクチャ: マイクロサービスほど細かくせず、数個の大きめのサービスに分ける中間案です。

内側の歴史

  • MVC: 1979年、ゼロックスのパロアルト研究所でトリグヴェ・ライネスが考案しました(Smalltalk)。45年以上前の考え方がRailsなどに今も生きています。Railsでは「Fat Model」問題がよく起きます。
  • DDD: 2003年のエリック・エヴァンスの青本が元です。「技術ではなく業務(ドメイン)を中心に設計する」考え方で、実はマイクロサービスの「どこで切るか」の基準(境界づけられたコンテキスト)としても使われます。
  • ヘキサゴナル: 2005年、アリスター・コーバーンが提唱しました。中心に業務ロジックを置き、DBや外部APIなどとの接点を「ポート&アダプター」にします。六角形なのは「入口が複数ある」ことを表すためだけで、6という数に意味はありません。
  • クリーンアーキテクチャ: 2012年にUncle Bob(ロバート・C・マーティン)が提唱しました。ヘキサゴナルやオニオンなどの共通点を整理したもので、核心は「依存の向きは外から内だけ」というルールです。同心円の図は有名ですが、本質はこの一点です。

まとめ

  • 「マイクロサービスが最強」は誤解で、組織規模や課題に合った選択が正解
  • 迷ったらまずモノリス、必要になったらモジュラーモノリスで境界を磨き、本当に必要なところだけ分離するのが現実的
  • 外側の分割と内側の整理は**同じ原則(関心の分離・依存の向き・境界)**でつながっている

新人エンジニアや転職を考える人は、流行りの名前を覚えるより「なぜそれが生まれたか」の背景を知っておく方が、面接でも実務でも役立ちます。特定のパート(Chaos Monkeyの仕組み、クリーンアーキテクチャのRailsでの実践など)を掘り下げることもできます。

投稿者 時刻:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)