はじめに
ほとんどのソフトウェア システムは モノリス として始まりますが、それは当然のことです。しかし、システムが成長し、チームが拡大し、要件が継続的に変化するにつれて、モノリス アーキテクチャは徐々にボトルネックになります。このレッスンは、ソフトウェア アーキテクチャの進化の過程全体と、マイクロサービス + マイクロ フロントエンド が複雑なシステムの目的地である理由を理解するのに役立ちます。
1. モノリス — 合理的な出発点
1.1 モノリスアーキテクチャとは何ですか?
モノリスは、アプリケーション全体が単一ユニットとして構築、デプロイ、拡張されるアーキテクチャです。すべてのモジュール (ユーザー、製品、注文など) は同じプロセスで実行され、同じデータベースを共有し、一緒にデプロイされます。
1.2 モノリスの利点
| 利点 | 説明 |
|---|---|
| シンプル | 開発、デバッグ、初期テストが簡単 |
| 展開が簡単 | 1 つのアーティファクトをデプロイするだけ |
| パフォーマンス | ネットワーク経由ではなく内部 (インプロセス) で関数を呼び出します。 |
| ACID トランザクション | モジュール間でトランザクションを簡単に実行 |
| リファクタリングが簡単 | 優れた IDE サポート、簡単な検索と名前変更 |
1.3 モノリスはいつ問題になるのですか?
システムが成長するにつれて、Monolith は ボトルネック に遭遇します。
開発について:
- コードベースが大きすぎるため、新しい開発者が理解するのに多くの時間が必要です
- ビルド時間は数十分に増加
- チーム間で競合を継続的にマージします
- 小さなバグがシステム全体をクラッシュさせる可能性があります
展開について:
- 1 つの小さな変更でアプリケーション全体をデプロイ
- リリースサイクルは続く(数週間/数ヶ月)
- 複雑なロールバック、全体的な影響
スケーリングについて:
- 1 つのモジュールだけがより多くのリソースを必要とする場合は、完全に拡張する必要があります
- 部品ごとに異なる技術を使用することはできません
経験則: 開発者が 5 人未満で、システムが複雑すぎない場合は、依然として Monolith が最良の選択です。
2. アーキテクチャ進化の旅
2.1 モノリス → SOA → マイクロサービス
Timeline:
2000s 2010s 2015+ 2020+
┌──────┐ ┌──────────┐ ┌──────────────┐ ┌───────────────────┐
│Monolith│ → │ SOA │ → │ Microservices│ → │ Microservices + │
│ │ │Services │ │ │ │ Micro Frontend │
└──────┘ └──────────┘ └──────────────┘ └───────────────────┘
2.2 SOA (サービス指向アーキテクチャ)
SOA は、Monolith をサービスに分離するための最初のステップです。ただし、SOA にはいくつかの制限があります。
- 集中型 ESB (Enterprise Service Bus) を使用 → 単一障害点
- サービスは 完全に独立していないことがよくあります (共有データベース、共有ライブラリ)
- 複雑なプロトコル (SOAP、WS-*)
2.3 マイクロサービス — SOA は正しく行われています
マイクロサービスは SOA の考え方を継承していますが、中心となる原則は次のとおりです。
┌──────────────────────────────────────────────────────┐
│ API GATEWAY │
└──────┬──────────┬──────────────┬─────────────────────┘
│ │ │
┌────┴────┐ ┌───┴────┐ ┌─────┴─────┐
│ User │ │Product │ │ Order │
│ Service │ │Service │ │ Service │
│ │ │ │ │ │
│ ┌─────┐ │ │┌─────┐ │ │ ┌──────┐ │
│ │ DB │ │ ││ DB │ │ │ │ DB │ │
│ └─────┘ │ │└─────┘ │ │ └──────┘ │
└─────────┘ └────────┘ └───────────┘
Mỗi service: Own database, Own deployment, Own team
SOA とマイクロサービスの比較:
| 基準 | SOA | マイクロサービス |
|---|---|---|
| コミュニケーション | ESB (集中型) | スマート エンドポイント、ダム パイプ |
| データ | 人気の共有DB | サービスごとのデータベース |
| サイズ | 非常に大きくなる可能性があります | 小さく、焦点を絞った |
| デプロイ | 通常は | を使用してデプロイされます。独立した展開 |
| テクノロジー | 通常は均一 | 多言語対応 |
3. フロントエンド モノリス — 無視されている問題
3.1 バックエンドは分離されましたが、フロントエンドはまだマージされています
多くの組織がバックエンドにマイクロサービスを採用していますが、フロントエンドは依然として 1 つの巨大な SPA アプリケーション (React/Angular/Vue モノリス) です。
3.2 フロントエンドモノリスの結果
- コード結合: すべてのチームが同じフロントエンド リポジトリに貢献します
- 技術ロックイン: フレームワークを段階的にアップグレードできない
- ビルドが遅い: バンドルのサイズが大きくなっています
- 展開のボトルネック: フロントエンド全体を展開する必要がある
- チームの依存関係: チーム A はチーム B がコードをマージするのを待ちます
3.3 マイクロ フロントエンド — ソリューション
┌─────────┐ ┌──────────┐ ┌─────────────┐
│ User │ │ Product │ │ Order │
│ MFE │ │ MFE │ │ MFE │
│ (React) │ │ (Vue) │ │ (React) │
└────┬────┘ └─────┬────┘ └──────┬──────┘
│ │ │
└─────────┬───┴──────────────┘
│
┌─────────┴──────────┐
│ SHELL / CONTAINER │
│ Application │
└────────┬────────────┘
│
┌─────────────┴────────────────────────┐
│ API GATEWAY │
└──────┬──────────┬──────────┬─────────┘
┌────┴────┐ ┌───┴────┐ ┌──┴────────┐
│User µS │ │Product │ │Order µS │
└─────────┘ └────────┘ └───────────┘
＃＃４．いつ切り替えるべきでしょうか？
4.1 信号にはマイクロサービスが必要
- チーム > 10 名 同じコードベースで作業
- リリースは別のチームによってブロックされています
- 不均一なスケーリング: 1 つのモジュールをスケーリングする必要がありますが、すべてのモジュールをスケーリングする必要があります
- テクノロジーのロックイン: 新しいテクノロジーを使用したいが使用できない
- 障害カスケード: 1 つのバグによりシステム全体がクラッシュします
4.2 信号にはマイクロ フロントエンドが必要
- 複数のチームが同じフロントエンド アプリで機能を開発
- フロントエンドのビルド時間 > 5 分
- 競合をマージ フロントエンドを頻繁に行う
- フレームワークをアップグレードしたいが、すべてを変更する必要があります
- 各 UI パーツの 独立したリリース
4.3 すべきでない場合は?
壊れていないものを直す必要はありません。
- 小規模チーム (開発者 5 名未満) → モノリスで十分
- MVP / スタートアップ → アーキテクチャよりも開発スピードが重要
- シンプルなシステム、わずかな変更 → オーバーエンジニアリング
- チームに十分な DevOps 経験がない → マイクロサービスにより運用が複雑になる
5. このシリーズの概要
5.1 学習ロードマップ
Phần 1-3: Backend Foundation → DDD, Service Design, Data Architecture
Phần 4-5: Micro Frontend → Architecture, Implementation, Design System
Phần 6: Integration Layer → BFF, API Gateway, GraphQL Federation
Phần 7-8: Quality & Deploy → Testing, CI/CD, Deployment Strategies
Phần 9: Production → Observability, Performance, Readiness
Phần 10: Real World → Case Study, Migration Guide
5.2 横断的なプロジェクト
シリーズ全体を通じて、完全な E コマース プラットフォームを設計します。
- 5 つのマイクロサービス: ユーザー、製品、カート、注文、支払い
- 5 つのマイクロ フロントエンド: ホームページ、製品詳細、カート、チェックアウト、アカウント
- 共有: 設計システム、認証、API ゲートウェイ
概要
| 建築 | いつ使用するか | 主なトレードオフ |
|---|---|---|
| モノリス | 小規模チーム、MVP、シンプルなシステム | 始めるのは簡単だが拡張するのは難しい |
| マイクロサービス | 大規模なチーム、独立して拡張する必要がある | 複雑な運用とデータ |
| マイクロ フロントエンド | 多くの FE チームは個別に展開する必要があります | バンドル サイズを増やすには、システム設計が必要です |
| フルスタック (MS + MFE) | 大規模な組織、複雑な製品 | 高い DevOps 成熟度が必要 |
続きを読む
- Martin Fowler — Microservices
- Martin Fowler — Micro Frontends
- microservices.io — Pattern Language
- micro-frontends.org