しゅみは人間の分析です

いらんことばかり考えます

マイクロサービス雑感

 マイクロサービスとは複雑さを分解することでスケーラビリティを確保する構成である。もちろん、複雑さを分解しても全体の複雑さは変わらない。人間にとっての複雑さであり、これは依存関係のコントロール、責務の整理である。責務への分割がまさにマイクロサービスである。これの規模が大きいので組織の話と関わる。スケーラビリティには量に関するスケーラビリティと複雑さに関するスケーラビリティがある。複雑さで律速されると、量のスケーラビリティの話まで展開ができない。複雑であるほど、スケールしにくくなる。シンプルであるとスケールしやすい。量の問題にできる。

 責務の単位へシステムを分割したことで、依存関係はどこへいったのか? 本質的なサブシステム間の依存関係は残ったままである。これに対して負荷がかかり、サービスがスケールすると、ボトルネックになる場所がシステム間でたらい回しにされる。チューニングをしていると、ボトルネックの箇所が変化していくあれである。依存関係はなくなっていないので、どうやっても負荷の影響は受けてしまうのだ。だが、サブシステムに分割していることで、サブシステムの責務の範囲内でRedisを新設し、サービス呼び出しをキャッシュできるかもしれないし、現実的なスロットリングのルールを協議できるかもしれない。

 もちろん、組織として彼の受け持つシステムの責務に閉じてしまい、サイロ化してしまうかもしれない。マイクロサービスの組織では、全体性を認識しながらシステム間プロトコルの調整をしなければならない。これを各システムの実装者に求めるのは、全体が小さいうちなら現実的だ。だが、全体が100人の組織になったらもはや専門の全体設計者が調停をやらないとスケールしなくなるのではないか。もちろん、ここまで大きなシステムを維持できているのであれば、その商業的な価値は高いものだろう。当然、その責務を帯びた視野の広い人間がいて然るべきだ。

 いろいろ考えたが、結論としてはつまらないものになる。古来よりシステム設計の勘所はずっと同じである。シンプルな部品で作る、それだけである。クラウドコンピューティングの力によって、サブシステムを作りやすくなったからマイクロサービスが登場してきたのだろうか。だが、誕生の経緯が何であれマイクロサービスの設計と、メンテナンスしやすくスケールしやすいソフトウェアの設計は同じ観点が求められる。全体性の認識と明確な責務*1への切り分けである。果たしてこれをできるようになるにはどうしたらよいのか。本質看取の能力は何によって磨かれるのか。

*1:明確な責務へ分けられると自動的にシンプルさが得られる