マイクロサービスパターン読書メモ
pagosマイクロサービスパターン 実践的システムデザインのためのコード解説 - インプレスブックス https://book.impress.co.jp/books/1118101063
pagoschapter1
モノリシック地獄からの脱出
pagosモノリシックアーキテクチャ
概要
システムを1つの実行可能ファイルまたはデプロイ可能コンポーネントにまとめる
利点
- 開発しやすい
- 大きな変更を加えやすい
- テストしやすい
- デプロイしやすい
- スケーリングしやすい
これが時間経過(コードベースの拡大や開発チームのスケーリング)によってモノリスアーキテクチャの枠を超えていく
pagosモノリシック地獄
-
複雑なシステムに開発者が萎縮する
一人の開発者が全容を把握することができない
コードが複雑化することにより正しい書き換えができず更に複雑なコードになっていく
⇛気づけば巨大泥だんごに -
開発ペースが遅い
複雑なコードに開発者もIDEもスローダウンする
生産性が自ずと低下していく -
コミットから本番デプロイまでの道が長く険しい
継続的デプロイなど夢のまた夢
同じコードベースを多くの開発者が触るため変更を容易に取り込めない(コストがかかる)
機能ブランチを作成するとマージがえらいことになる
コードベースが複雑でコード変更が及ぼす影響の全容を把握しきれないためテストスイート全体を毎回実行、手動テストの負荷も高い
その上テストに失敗すればまた複雑なコードから原因を究明し変更を加えるという時間が発生する -
スケーリングが難しい
アプリケーションを構成するモジュール間でのリソース要件の矛盾が発生する
本来モジュールに合わせたサーバに各々デプロイするのが最善
こういったサーバ構成にすら悪影響(妥協)が発生する -
信頼性の高いモノリスを提供することの難しさ
アプリのサイズが大きすぎて徹底的なテストが不可能でありテスト容易性がない
全てのモジュールが同じプロセスにあるので障害の分離ができない(1モジュールがバグると全部落ちる) -
時代に陳腐化していくテクノロジスタックに縛り付けられる
コストが極端にかかり、リスキーなため最新のフレームワークや言語に移行できない
テクノロジをアップグレードする時間など無い