モノリスからマイクロサービスへ
モノリスからマイクロサービスへ
持論(読む前に書いたもの)
- 最適なアーキテクチャの選択は「規模」によるなぁと
- 規模が小さければ、影響範囲の観測も、コードの見通しもそんなに悪くない
- その場合、モノリスでもいいし、ある程度の規模まではマイクロサービスがメンテの邪魔(コスト)になる可能性もある
- 初期の段階でそのシステムの「規模の成長性」を読めたら良いのだけれど
- 熟練のカンとリスク許容度が必要
- その「しんどさ」から逃れたすぎて、WF＆モノリス信者が誕生し、逆に「そこに押し込もう」とシステムの成長を阻害or歪める阻害要因となりがち
- 前提として「複雑なものはいくら整理してもある程度複雑」である
- 整理により「緩和」はできても、劇的な「解決」はできない
- コンピュータシステムの技術の力では「複雑化」はできても「解決」はできない
- 一見「複雑なものが複雑でなくなった！」みたいな状態にもって行けたとしても、それは「コード化する際に変質させた(からコードがシンプルになった)」という状況であり、別の形のコストを払うことになっている…ことが多い
- 例えば、メタファーの導入により単純化はされたが「ドメイン知識+メタファーの知識」が必要になり、メンテに必要な知識がより高度になったり
- 譬えば、一見短く少ないコードになっているが、記号化が進んだだけで読めない＆かけない＝メンテ不能、だったり
- 変質した概念のコードを追加・更新していくのは、多少冗長に見えても「世の事象をそのまんま表されたコード」をメンテするより、長期的目線で見ればコストが高い(心労を考えてもしんどい
- 構造やアーキテクチャで解決できるのは、デプロイやリリース手続きなどの「周辺コスト」と「周辺スピード」である
- 「新たなビジネスの機能を追加したい」などの「ドメイン的要求」は、開発者たちは正面に捉えて毎度学ばねばならないし、そこの開発スピードを上げてくれるものではない
- ただし、優れた構造・アーキテクチャは「それ以外の考え事(ノイズ)をへらしてくれる)」ので、間接的にリリーススピードは上がる
- というか、我々デベロッパーは「そのために雇われている」「(本来)それしかやらんでいいが期待のはず」なので、その環境整えが済んでからがスタートラインのはずなんだが…
- マイクロサービスに関しては「境界設計」「可用性考慮」の矯正ギプス的側面があり、デベロッパーにより多くのことを考えさせる利点がある
- 構造やアーキテクチャの選定・変更にて起こせることは「ボトルネックの移動」である
- 本来の「ドメイン領域の複雑性」を解決してくれるものではない
- どのアーキテクチャを選んでも、何かが解決できたわけでなく、トレードオフである
- モノリスなら、整合性取るのはある程度楽だが、アトミックにデプロイするのでリリースが一大事となり遅い
- マイクロサービスなら逆で、部分リリースが細やかにできるのでリリーススピードは早いが、整合性取りが大変になる
- 仮に「機能間での結合テストが難しくリリーススピードが遅かったモノリスシステム」があったとして、リリーススピードを上げる目的でマイクロサービス化するという方策を取った場合、同じ結果を得る場合はその効果は無い
- むしろ「機能間の結合テストのコストが上がる」ことが多く、同じ品質維持のためにはリリーススピードが落ちる可能性があり、曲解し見かけ上の成功にこだわり「リリーススピードだけを上げる」ようなことをした場合、バグが置きまくって大惨事orリリース不能がありえる
- 結局「結合テストがデプロイしてからのシステム間テストになる」ので課題やトータルコストは変わっておらず「ボトルネックの移動」と言っている
- 結局、メンテナンシビリティやリリーススピードを考える際に大事なものは「境界設計」と「ベースラインバージョン管理設計」に尽きる…と思う
- 境界設計は「どの単位で区切るか」の設計
- プログラム単位で行けばパッケージやモジュール、ドメインで行けばドメイン境界、マイクロサービスで行けばサービス単位
- より「論理的に独立できる単位」を考えられるか、がキモになり、その設計の価値はマイクロサービスに代表される近代ソフトウェア設計において重要性をマスばかり
- ベースラインバージョン管理は、「区切った単位を横並びで揃えた”グランドバージョン”的なものの定義とその管理・運用方法の設計」である
- モジュールA:1.2.0, B:1.3.2, これらを横並びの組み合わせでテスト済みの組み合わせをベースライン:1.0.1とする、みたいな概念
- 主に構成管理で用いられる概念だが、正式名称はちゃんとあるのかも？
- マイクロサービスには必須だが、優れたモノリスでも昔からやっていること
- 例えば、jar/DLLでモジュール分割しているところ(本書におけるモジュラーモノリス)では必要な技術であったし
- これができているなら、モノリスだろうがマイクロサービスだろうが、困らない
- ので、より「問題解決に最適化できるほう」をえらびゃいい
blog comments powered by