マイクロサービスという言葉はよく聞くし、なんとなく概念は理解しているつもり。
そう。
だいたいなんとなく理解しているつもりのことが多いし、理解しても言葉にするのは難しい。
そして、説明せよと言われて完全に網羅することはもっと難しい。
マイクロサービスの定義
Single purposeを満たさないとそれぞれのサービスは多くのことをやることになる．つまり複数のMonolithが存在することになる
Loose couplingを満たさないと一つのサービスの変更が他のサービスに影響を与えることになる．そのため（Microservices化のメリットである）素早く安全にリリースをすることができなくなる．密結合するとデータの不整合やデータロストなどが起こる
High cohesionを満たさないと分散Monolithになる．つまり一つの機能の開発のために複数のサービスを変更しないといけなくなる
この定義を見て連想するのは、SOLID原則のようなもので、いかに良い感じのコードを設計するかという話と似ている。アーキテクチャ、ソースコード、組織、こういうのは自己相似だったりパターン形成という話の絡みもありそう。
マイクロサービスの背景
背景を自分の関心のある範囲でまとめるとざっくりとこんな感じ。
- サービスは成長する
- サービスが成長すると、関わるエンジニアの人数も増えていく
- エンジニアの人数が増えていくとコードの変更量も増えていく
- リリースに含まれるコードの変更量が増えていく
良い感じの事業であればサービスも成長するし、組織も成長する。
なので、サービスが成長していけばぶち当たる状況ではありそう。
マイクロサービスが解決する課題
背景に引き続き。
- 大部分のコードは安全であるにも関わらず、一部のコードにバグが含まれている場合がある
- そういった場合にはリリースを巻き戻す可能性がある
- 一部のコードにバグが含まれていて、大部分のコードには影響がないにも関わらずリリースが巻き戻されてしまう
要は組織とサービスの形に合わせてより効率的にサービスと組織を成長させるために、リリースを効率的にしたいという理解。
マイクロサービスが提供する解決策
マイクロサービスはどうやって課題に対処するのかという話。
- サービスの成長に伴って、組織の構造は変わる
- 成長したサービスを適切な粒度に切り出す
- そこで、組織の構造の変化に合わせて、サービスをマッピングしていく
- チームとサービスがマッピングされる
- このサービスはMicroservicesの定義を満たしている
- サービスは1つのことに集中し、他のサービスへの依存が最小限になっている
- したがって、それぞれのチームは自律したタイミングでサービスへの変更をリリースできる
- そのリリースにバグが含まれていた場合でも他のサービスに影響を与えることは少ない
- こうしてMicroservicesによってリリースサイクルを最適化することができる
感想
- 概念的には理解できた。
- 事業、組織、サービスというレベルで見てみると確かに適切なタイミングでマイクロサービス化を検討することになりそう。
- それとは別に、チームレベルでマイクロサービスをどう実現するのかという話もある
- チームでどういうアーキテクチャを組むとか、チーム(サービス)間でどういう連携をするとか
今回はこの辺まで。