この動画は単なる「アーキテクチャ入門」ではなく、
なぜ業界はモノリス → SOA → マイクロサービス → モジュラーモノリスへと揺れ戻しているのか
という、ソフトウェア設計の「流行の歴史」を語る動画です。
特に面白いのは、
- 外側(システム全体の構造)
- 内側(プログラム内部の構造)
を分けて説明している点です。
これは文学で言えば、
を分けて考えるのに似ています。
第一章 モノリスの時代
2000年代前半くらいまで、
ほぼ全てのWebサービスはモノリスでした。
モノリス(Monolith)とは
巨大な一枚岩
という意味です。
例えば
全部を一つの巨大アプリに詰め込む。
Webサーバー
↓
巨大アプリ
↓
DB
という構造。
実はこれは悪くありません。
むしろ
小さい組織なら最強
です。
雑学1
YouTubeもFacebookも最初はモノリス
意外に思われるかもしれませんが、
巨大IT企業も最初はほぼ全部モノリスです。
理由は簡単。
マイクロサービスより遥かに開発が速い。
スタートアップでは
「綺麗な設計」
より
「今週リリースできるか」
のほうが重要です。
第二章 SOAの登場
モノリスが巨大化すると問題が出ます。
例えば
注文機能を修正したい
↓
全体テスト必要
↓
リリース失敗
↓
全部止まる
そこで登場したのが
SOA (Service Oriented Architecture)
です。
サービス単位で分ける。
注文サービス
顧客サービス
決済サービス
みたいな考え方。
ただし、
SOAは今でいうマイクロサービスほど細かくありません。
雑学2
SOAは企業システム文化の産物
SOAを推進していたのは
IBM Oracle SAP
などの巨大企業。
そのため
XML SOAP
などの非常に重厚な規格を使っていました。
若いエンジニアが見ると
「なんでこんな面倒なことしてたの?」
と思いますが、
当時の企業システムでは標準化が非常に重要だったのです。
第三章 Netflixとマイクロサービス革命
ここで伝説が登場します。
Netflixです。
動画にも出てきますね。
実はNetflixは2008年頃の大障害で苦しみました。
その後、
AWSへ移行しながら
巨大モノリスを分割。
そこで生まれたのが有名な
マイクロサービスアーキテクチャ。
認証サービス
検索サービス
推薦サービス
配信サービス
全部別々。
Chaos Monkeyとは何か
動画にも出てきた
Chaos Monkey
これは業界ではかなり有名です。
普通は
「サーバーは壊れない前提」
で設計します。
Netflixは逆。
必ず壊れる前提で作る
という思想。
そこで
Chaos Monkey
というプログラムを作り、
本番環境のサーバーをランダムに停止させました。
普通の会社なら怒られます。
しかしNetflixは
「落ちても動くシステム」
を作るためにわざと壊した。
これがカオスエンジニアリング文化の始まりです。
雑学3
宇宙開発と似ている
Chaos Monkeyの発想は
航空宇宙工学に近いです。
ロケット開発では
安心のために壊す。
エンジニアリングの世界では
信頼性の高いものほど
徹底的に壊されます。
第四章 マイクロサービスの幻想
2015年頃から起きたこと。
業界全体が
「マイクロサービス最強!」
と言い始めました。
しかし現実は違いました。
マイクロサービスを導入すると
開発者は
新たに
- API設計
- 分散トランザクション
- ネットワーク障害
- サービス監視
- Kubernetes
- CI/CD
などを理解しないといけない。
つまり
本来の業務ロジック以外の難しさ
が爆増します。
業界あるある
若手エンジニア
「マイクロサービスやりたい!」
ベテランCTO
「まだ早い」
という会話が本当にあります。
理由は
組織が10人なのに
Google並みの構造を導入しても意味がないから。
第五章 モジュラーモノリスへの回帰
近年注目されているのが
モジュラーモノリス。
これは非常に面白い流れです。
考え方は
デプロイは一つ
コードは分割
です。
つまり
注文モジュール
顧客モジュール
決済モジュール
と分離しながら、
実行ファイルは一つ。
言い換えると
マイクロサービスの思想だけ借りる
のです。
これが最近の実務ではかなり人気。
なぜ流行りが戻ったのか
ソフトウェア業界には
不思議な歴史があります。
集中 ↓ 分散 ↓ 再集中
を何度も繰り返す。
実はコンピュータ業界全体がそうです。
1960年代
メインフレーム
↓
1980年代
クライアントサーバー
↓
2000年代
Web
↓
2010年代
クラウド
↓
2020年代
AIクラウド集中
歴史は振り子運動です。
アーキテクチャも同じ。
後半の「内側」の話
ここから動画は
MVC DDD ヘキサゴナル クリーンアーキテクチャ
へ進みます。
これは
システム全体ではなく
プログラム内部をどう整理するか
という話です。
MVC
最古参。
Model
View
Controller
RailsやLaravelで有名。
初心者には分かりやすい。
しかし巨大化すると辛くなる。
DDD
Domain Driven Design
エリック・エヴァンスの名著から始まりました。
重要なのは
コードではなく
業務知識を中心に考える
という点。
実はこれは文学好きの人には面白い思想です。
登場人物ではなく、
物語世界(ドメイン)を先に作る感覚に近い。
ヘキサゴナル
Ports and Adapters
とも呼ばれます。
特徴は
データベースやUIを交換可能にすること。
つまり
ビジネスロジック
↑ ↓
DB
Web
API
CLI
が独立する。
クリーンアーキテクチャ
ロバート・マーチン(Uncle Bob)。
有名な同心円構造。
哲学は一つ。
依存方向を内側へ向けろ
です。
ビジネスルールは永続化技術に依存するな。
という考え。
この動画の最大のメッセージ
15分の歴史を一言で要約すると
「流行のアーキテクチャを選ぶな。自分たちの組織に合うものを選べ」
です。
業界では
Netflixの成功例だけが語られがちです。
しかし実際には、
社員20人の会社と
社員数万人のNetflixでは
問題そのものが違う。
だから
- 小規模ならモノリス
- 成長したらモジュラーモノリス
- 本当に必要になったらマイクロサービス
という段階的進化が、多くの現場では現実的です。
あなたはGMP/MPFRやWebAssemblyのような比較的専門的なソフトウェアに関心がありますが、その世界でも事情は似ています。
高精度計算ライブラリのような強い整合性が必要な領域では、むしろ巨大なモノリス型ライブラリ(GMP、MPFR、LLVMなど)のほうが成功例が多いのです。計算精度や性能を最優先すると、「サービスを分ける」より「一つの整合した世界を保つ」ことの価値が大きいからです。
技術史を眺めると、
モノリス → マイクロサービス
は進化の一本道ではなく、
「分割したい欲望」と「複雑さを減らしたい欲望」の終わらない綱引き
なのだ、と見ると、この動画の面白さがさらに見えてきます。