レッスン6 - アーキテクチャパターンの分類
ご提示いただいた動画「Lesson 6 - Classifying Architecture Patterns(アーキテクチャパターンの分類)」を日本語で要約し、IT業界の背景知識や雑学を交えて詳しく解説します。
この動画では、世の中に数多く存在するアーキテクチャ(マイクロサービス、モノリス、イベント駆動など)を、どのように整理して理解すべきかという「分類の指針」が示されています。
1. 動画の要約:究極の二択「モノリスか、分散か」
リチャーズ氏は、アーキテクチャを分類する最も重要で明確な境界線(シーム)は、**「モノリシック(単一構成)」か「分散(ディストリビューテッド)」**かであると述べています。
① モノリシック・アーキテクチャ
-
特徴: 全ての機能が一つのデプロイ単位(1つのファイルや実行体)にまとまっている。
-
例: レイヤードアーキテクチャ、マイクロカーネル(プラグイン型)、モジュラーモノリス。
-
メリット: メソッド呼び出しが高速(マイクロ秒単位)、トランザクション管理(ACID)が容易、デバッグが単純。
② 分散アーキテクチャ
-
特徴: 機能がネットワーク越しに通信する複数のデプロイ単位に分かれている。
-
例: マイクロサービス、イベント駆動型(EDA)、スペースベース(クラウド型)、サービスベース。
-
課題: ネットワークを介するため、以下の5つの「分散の代償」を考慮する必要があります。
2. 業界話と雑学:アーキテクトの苦悩
「数学は嘘をつかない」レイテンシの現実 [05:14]
リチャーズ氏は「T remote(リモート時間)は常に T local(ローカル時間)より大きい」と断言しています。
-
業界話: マイクロサービスを導入した結果、一つの画面を表示するのに裏側で10回以上のサービス間通信が発生し、動作が極端に重くなる「チャッティ(おしゃべりな)インターフェース」という失敗事例がよくあります。Googleで検索しても自分の環境の遅延は分かりません。実測がすべてです。
ACIDからBASEへ:データの正しさの定義が変わる
-
雑学: 従来のデータベース(ACID)は「書き込んだ瞬間に全員が同じデータを見る」ことを保証しますが、分散システム(BASE)では「今はズレているかもしれないが、最終的には合う(結果整合性)」という考え方をとります。
-
業界あるある: 銀行振込で「残高が即座に反映されないが、数秒後には正しくなる」のは、このBASEの考え方に基づいています。これを受け入れられるかどうかが、分散アーキテクチャを採用できるかの大きな分かれ道になります。
「マイクロサービス vs SOA」の分類 [08:41]
動画の最後で、リチャーズ氏が執筆した無料の電子書籍について触れられています。
-
補足: 2010年代後半、「何でもかんでもマイクロサービスにすれば良い」という風潮がありましたが、リチャーズ氏はこの動画のように「まずはモノリスか分散かのコストを天秤にかけるべきだ」と警鐘を鳴らし続けています。
3. 解説のまとめ
この動画の教えは、**「流行りの言葉(マイクロサービス等)に飛びつく前に、そのアーキテクチャが『モノリス』か『分散』かを見極め、分散に伴う5つの苦労を背負う覚悟があるかを自問せよ」**という点に集約されます。
[08:03] あたりで語られているように、この5つの課題を理解することこそが、適切なアーキテクチャを選択するための第一歩となります。
参照動画:Lesson 6 - Classifying Architecture Patterns

ご提示いただいたGeminiの回答は、マーク・リチャーズ氏の「Lesson 6 - Classifying Architecture Patterns」(2018年2月26日公開、約9分30秒)の内容を非常に正確にまとめています。 この動画は「Software Architecture Monday」シリーズの転換点で、「アーキテクチャをどう分類するか」という根本的な問いを投げかけ、「モノリス vs 分散」というシンプルかつ強力な軸を提示した名講義です。 (動画URL:https://www.youtube.com/watch?v=Ic6q7S48Mho 視聴回数約2.9万超)
ここでは、要約を補完・2026年現在の視点でアップデートしつつ、最新のトレンド(モジュラーモノリス復活、分散の新落とし穴など)、日本企業の実務あるある、雑学・落とし穴を交えて深掘り解説します。
1. 動画の核心:アーキテクチャ分類の究極の二択「モノリスか分散か」(補完版)
リチャーズ氏は、世の中の数多くのスタイル(レイヤード、マイクロサービス、EDA、SOAなど)を「モノリシック(Monolithic)」 と 「分散(Distributed)」 の2つに大分類することを推奨しています。
- モノリシック・アーキテクチャ
- 特徴:1つのデプロイ単位(WAR、JAR、EXEなど)。全ての機能が同じプロセス内で動く。
- サブスタイル:レイヤード(Layered)、ヘキサゴナル、マイクロカーネル(プラグイン型)、モジュラーモノリス(Modular Monolith)。
- メリット:
- 通信がメソッド呼び出し → 超高速(μs単位)。
- ACIDトランザクションが簡単(DBレベルで完結)。
- デバッグ・テストが単純。
- デメリット:スケールしにくい、変更が全システムに波及しやすい。
- 分散アーキテクチャ
- 特徴:複数デプロイ単位がネットワークで通信(REST、gRPC、メッセージングなど)。
- サブスタイル:マイクロサービス、サービスベース、イベント駆動(EDA)、スペースベース、サーバーレス、SOAなど。
- 最大のポイント:分散の5つの代償(Challenges / Fallacies関連) を必ず背負うこと [03:02〜07:35]。
- コントラクト(Contract):API仕様・バージョン管理・後方互換性が必須。
- 可用性・応答性:相手サービスがダウン/遅延時のフォールバック・サーキットブレーカー・タイムアウト必須。
- レイテンシ(Latency):ネットワーク遅延は避けられない(「T remote > T local」は数学的事実)。
- セキュリティ:各エンドポイントで認証・認可・暗号化が必要(ゼロトラスト)。
- トランザクション:ACIDではなくBASE(Basically Available, Soft state, Eventual consistency)へ移行。分散トランザクション(2PC)は非推奨。
動画の結論 [08:03〜]:「流行りに流されず、まずモノリスか分散かを決め、分散を選ぶならこの5つの苦労を本当に受け入れられるか?」 を自問せよ。
2. 2026年現在の進化と現実(日本企業目線)
- モジュラーモノリスが大復活 2018年当時は「マイクロサービス一択!」の風潮が強かったが、2026年現在は「モジュラーモノリス(Modular Monolith)」 が「現実解」として再評価。
- ThoughtWorks Radar Vol.33 (2025年11月):Modular Monolith Trial → Adopt へ移行中。
- 理由:分散の5代償を背負わず、ドメイン駆動設計(DDD)でモジュール分割 → 将来的にマイクロサービスへ移行しやすい。
- 日本企業例:メルカリ・PayPayの初期はモジュラーモノリスでスケール → 必要部分だけマイクロサービス化。
- 分散の「新3大落とし穴」(リチャーズ氏の最近の拡張) 元の8 Fallacies of Distributed Computing(ネットワークは信頼できる、レイテンシゼロなど)に加え、2025年にリチャーズ氏+Neal Fordが「新3 Fallacies」を提唱(Lesson 209など)。
- Versioning is easy(バージョン管理は簡単)→ 実際は破壊的変更の地獄。
- Compensating updates always work(補償トランザクションは常に成功)→ Sagaパターンでも失敗する。
- Observability is optional(可観測性はオプション)→ 必須(OTel必須)。 → 動画の5代償にこれらが加わり、分散のコストはさらに高くなった。
- ACID vs BASEの実務分岐点
- ACID必須:金融コア(振込即時反映)、在庫即時引当 → モノリスorモジュラーモノリス推奨。
- BASEでOK:ユーザー行動ログ、推薦システム、検索インデックス → 分散(Kafka + イベントソーシング)。
- 日本あるある:「銀行アプリなのにBASEで残高遅延」 → ユーザー激怒 → 急遽モノリスに戻す失敗事例。
- チャッティインターフェースの死亡事故 動画のレイテンシ指摘通り、マイクロサービスで「1画面に10〜20回のサービスコール」が発生 → 画面表示5秒超え。 → BFF(Backend for Frontend)やGraphQLでまとめるのが2026年の定番対策。
3. 業界雑学・あるある(2026年視点)
- 「モノリスは悪」神話の崩壊 2010年代後半のマイクロサービスブームで「モノリス=レガシー」とされたが、2026年は「適切なサイズのモノリスが最強」という現実路線。 Sam Newmanの言葉「If you can't build a well-structured monolith, what makes you think microservices is the answer?」が今も引用されまくり。
- リチャーズ氏の電子書籍 [08:41頃] 動画で触れられている無料eBook(Software Architecture Patterns)は今もO'Reillyで無料公開中。第2版(2024-2025更新)ではmonolithic vs distributedの章が強化され、architecture styles vs patternsの区別も明確に。
- 日本企業の実態
- 大手SIer・金融:まだモノリス中心(分散の5代償を恐れて)。
- メガベンチャー(楽天・LINE):ハイブリッド(コアはモジュラーモノリス、周辺はマイクロサービス)。
- スタートアップ:最初から分散 → 後悔してモジュラーモノリスに戻す「振り子現象」多発。
まとめ(アーキテクトに贈る一言)
リチャーズ氏のLesson 6は、「アーキテクチャ選択の最初のフィルター」です。
- モノリス:シンプル・高速・ACID → まずはここから。
- 分散:スケール・独立デプロイ → だが5つの代償 + 新3 Fallaciesを背負う覚悟が必要。
今日からできること:
- 自分のシステムを「モノリスか分散か」で分類してみる。
- 分散を選ぶ場合、「レイテンシ実測」「コントラクトバージョン管理」「Observability必須」の3つをチェックリスト化。
- 迷ったらモジュラーモノリスからスタート(2026年の勝ちパターン)。
動画は短いのにインパクト大。Lesson 6を起点に、Fallaciesシリーズ(Lesson 18, 209など)を見進めると、分散の「本当の怖さ」が体感できます。
ぜひ自分のプロジェクトに当てはめて「この5代償、払える?」と自問してみてください!(次回はLesson 7以降も解説可能です)
0 件のコメント:
コメントを投稿