1章 モノリシック地獄からの脱出
- モノリシック地獄
- マイクロサービスアーキテクチャの基本的な考え方
- マイクロサービスアーキテクチャの利点・欠点
- パターン言語とマイクロサービスアーキテクチャパターン
- マイクロサービスアーキテクチャと組織
モノリシック地獄
- 最初は、綺麗に設計できていれば開発もスムーズだけど、大きくなるにつれてそうもいかなくなる
- 変更の影響範囲が分からなくなるので、開発が遅くなる
- 一つのコードベースだと、常に不安定で、ビルドが通らない
- 自動テストをやっていても、テストに時間がかかる
- （垂直）スケーリングしづらい
- CPUが必要なモジュールもあれば、メモリが必要なモジュールもあるので
マイクロサービスアーキテクチャの基本的な考え方
-
スケールキューブという考え方がある
- X軸：いわゆる水平スケーリング
- Z軸：パーティショニングによるスケーリング
- Y軸：機能分割によるスケーリング
-
マイクロサービスアーキテクチャは、Y軸によるスケーリングを実現する
-
SOAの特徴
- ESBありきの重量級プロトコルを採用する
- グローバルデータモデル
-
SOAは、一つのドメインモデルを、複数プロセスで実現する感じか？プロセスが別れていても密結合な印象を受ける
-
ドメイン自体を分割するマイクロサービスアーキテクチャとは、結構違うのかもしれない
マイクロサービスアーキテクチャの利点・欠点
-
利点：ここのサービスが小さく自立しているので、開発しやすい、テストしやすい、デプロイしやすい、個別にスケーリングできる、障害が分離できる、テクノロジスタックを変えられる
-
欠点：分割方法を見つけるのが難しい、分散システム自体が難しい（部分的に死んでる場合がある、サービスまたがりのトランザクションが使えない、結合テストしづらい）、サービス間の依存関係を考慮したデプロイが必要、マイクロサービスアーキテクチャを使うべきか否かの判断が難しい
-
いつマイクロサービスアーキテクチャを採用すべきか
- 最初はモノリシックで初めて、ある程度大きくなったらマイクロサービスアーキテクチャに切り替えるのがよいのこと
- 個人的には、一度、モノリシックで開発の流れができてしまったらそう簡単には変えられないのでは？と思う
- 13章で、モノリシックをマイクロサービスアーキテクチャにリファクタリングする方法を紹介する予定
パターン言語とマイクロサービスアーキテクチャパターン
-
パターン：繰り返し発生する問題に対する解決方法。利点だけでなく、欠点や新たな問題も記述されていることが重要
-
パターンの関係性：先行・後続の関係、汎化・特化の関係、代替関係など
-
パターン言語：パターンのコレクションと、パターンの間の関係性をまとめたもの
-
マイクロサービスパターンの分類
- 結構な数があるので、ある程度の分類はある。しかしそれほど厳密ではない
マイクロサービスアーキテクチャと組織
- コンウェイの法則：ソフトウェアアーキテクチャは、組織を反映させたものにしかならない
- 逆コンウェイの法則：目指すべきアーキテクチャに合わせた組織を作れば、おのずとアーキテクチャも実現される
- ウォーターフォールよりもScrumなどのアジャイルなプロセスと、継続的デリバリを取り入れるとよい
- マイクロサービスを採用するのもの最終的には人なので、人間の感情がうまくトランジションできるようにマネージメントが必要
感想
- マイクロサービスアーキテクチャというこの大掛かりな仕組みを果たして、どうやったら取り入れることができるだろうか？
- 著者がいうように最初はモノリスではじめて、途中からマイクロサービスというのはあまり現実的な気がしない
- 結局、最初からマイクロサービスアーキテクチャで、かつ、最初からある程度の開発速度になるようにしないとダメな気がする