マイクロサービスの神話
今回は『人月の神話』の「第2章 人月の神話」のパロディです。原文を比較しながら読むとより楽しめます
システムのリプレイス案件があった場合、自然(特に最近では)な対応としてマイクロサービスを採用することがある。
火に油を注ぐがごとく、この対応は事態を悪化、それもかなりひどくする。
火が大きくなればガソリンをもっと欲するように、悪循環はこうして始まり、結局大失敗に終わる。
マイクロサービスはアイデアとして、時間と人の制約を受けずに、設計者の頭の中で完成した形で生まれる。実現されるとき、時間と人の制約を受ける。
私たちのアイデアの不完全さや不整合性は、実現段階になって初めて明白になる。
多くのシステムにおいて運用は扱いにくいものだ。
運用の物理的制約(や法的制約)が、表現できるアイデアを束縛し、実現段階での予期せぬ困難を作り出す。
プログラマは純粋な思考から、マイクロサービスとそれについての非常に柔軟な表現を組み立てていく。
実現も難しいことはほとんどないと考えるようになって、そこから楽観主義が広まる。
しかし、私たちのアイデアに考慮漏れはつきものであり、思ってもいなかったコストが生じる。
単一のサービスにおいては、まさに計画どおり事が運ぶかもしれない。
しかし、マイクロサービスは複数のサービスから構成されており、そのほとんどが複雑に絡み合っている。
この場合、すべてのサービスがスムーズに連携できる確率となると、限りなくゼロに近くなるほど小さい。
システムの運用においてマイクロサービスは、疑うべき危険な神話なのだ。
サービスの数と可用性が交換可能になるのは各サービス間でコミュニケーション(意思疎通)を図らなくても、仕事が分担できる場合だけである。
人が少なくてサービス担当を分担できない場合、サービスを増やすという対策は運用上、何の効果も生まない。
分担はできるがサービス間でのコミュニケーションが必要な仕事においては、コミュニケーションに図る労力を、こなすべき仕事量に追加しなければならない。
したがって、サービスを分割してもお粗末な結果しか得られないだろう。
サービスを分割することで増える負担は、純粋な作業量増加および相互コミュニケーションの2つの部分からなる。
各サービスは、技術スタック、インフラ、運用手順、ドメイン知識それぞれについて絶えず一つのシステムとしての独立性が求められる。
これらの実態は分断されてしまうから、負担の増加分はサービス数に合わせて線形に変化する。
相互連携となるとさらにひどい。
仕様の各部分がサービス間ごとに調整されなければならないから、そのための労力は、サービスがn個あれば、n(n - 1)/2に比例する。サービスが3つなら、それぞれの相互連携が2つのときの3倍、4つなら6倍必要になる。
さらに、もしその分割された各サービスが共同で問題解決にあたるための仕様策定が必要になると、自体は一層ひどくなる。
連携を図るために追加される労力は、一つのサービスの場合と違い、より困難な状況をもたらす。
ソフトウェア構築は、本来システム的な作業──複雑な相互関係における作業の遂行──であり、コミュニケーションを図るための労力は大きく、分担によってもたらされた各サービスの疎結合性はすぐエントロピーの餌食となってしまう。
だから、サービスを分割することが、システムのレガシー化を加速させることはあっても、減速させることはないのである。