マイクロサービスのビッグバンリリース問題
マイクロサービス開発でありがちな問題
巨大プロジェクトをマイクロサービスアーキテクチャで、複数のチームで開発していると、マイクロサービスが制御できないほど多くなる。サービスがいくつあって、それぞれのサービスが何の役割で動いていて、サービス間の依存関係がどうなっているのか、全体を把握するのが非常に困難になる。このような状況になると、モノリシックなアーキテクチャが抱えている問題と同種の問題を引き起こす可能性がある。
モノリシックアプリケーションは、
デプロイと検証に膨大な工数がかかる
ビッグバン方式のリリースになる
リリース手順が複雑になりがち
とある小さな機能のリリースであっても入念な品質検証が必要
などの課題があった。
マイクロサービスの場合はどうだろう。例えば、プロダクトのメジャーバージョンアップのためにマイクロサービスを一斉にリリースするようなケースは要注意だ。マイクロサービス群のビッグバンリリースも十分に起こり得る。このとき、マイクロサービス間の依存関係が複雑になっていたり、リリースの順序が必要であったり、いくつかのマニュアルオペレーションがあったりすると、相当な事前計画が練られていない限りは事故が起こる可能性が高い。
要するに、マイクロサービスのプラクティスから外れてしまったときから、マイクロサービスの恩恵が少なくなり、モノリスに似た対応が必要になってくる。
マイクロサービスをやっている人は恐らく全員、ビッグバンリリースは本意ではないはず。マイクロサービスの原則として、サービスごとに細かくリリースできることに意味があるから。ただ、大企業などでありがちなプロセスだが、リリースのための承認フローが重たかったり、リリースするものはすべてセキュリティテストを実施せよ、といった状況になると厄介で、細かいリリースが難しかったりする。メジャーアップデートの日が決まっているようなケースでは、リリース日まで細かい修正が積み重なることもあるだろう。
ソリューションはあるか?
組織のルールが足かせになっている場合、組織のルールや文化、プロセスを変えていくしかない。
技術的な解決方法もあり、セキュリティテストをCIに組み込むとか、サービスメッシュの導入を検討するなど、いくつかの可能性は存在する。ただ、根本解決はマイクロサービスの原則に従うことができるように業務プロセスを改善すべきなのは自明だ。
間違っても、マイクロサービスアーキテクチャを止めよう、などというバカげた判断にならないようにすべき。