はじめに

マイクロサービスごとに開発チームが存在せず、開発と運用が別チームになっているようなケースで、マイクロサービスを開発、運用する場合の考慮ポイントを考えてみたいと思います。

マイクロサービスの開発としては、正攻法として既存のモノリスをデカップリングしてマイクロサービスにする方法があると思いますが、本記事では最初からマイクロサービスとしてアプリケーションを開発する場合について考えたいと思います。

Amazonなどすでにマイクロサービスを開発運用している企業におけるマイクロサービスと開発、運用チームの関係性は以下のようなイメージです。

基本的に各マイクロサービスごとに開発運用チームが存在します。つまり、サービスと開発運用するチームは、1：1になります。

以下は、請負などで開発を他社に依頼するようなケースにおけるマイクロサービスと開発、運用チームの関係性のイメージです。

大規模なエンタープライズ企業においては、アプリケーション開発を内製せずにSIerなどに開発を依頼する場合があると思います。
そう言った場合は、サービスと開発運用するチームが、１：１にならないケースがあります。そう言ったケースにおいては、マイクロサービスの数が増えすぎると、運用が大変になるケースがあります。理由の１つとして、運用チームがマイクロサービスごとではなく、システム全体で一つになることが挙げられます。

マイクロサービスのメリット

2つ目のような組織体制であっても、もちろんマイクロサービスにおける、以下のようなメリットを享受できます。

スケールイン・アウトを効率的に行う
- モノリスであれば、一部機能だけより処理性能が必要になった場合も、必要のない機能も含めてスケールアウトすることになる
リリース時の影響の局所化
- 機能追加時に、機能がマイクロサービスとして別れていると影響を局所化できる。

2つ目のような組織体制の場合における考慮点

複数のマイクロサービスに対して変更が必要になった場合、マイクロサービスの数が多いと運用チームへの負荷が高くなる

ケース1 複数のマイクロサービスで同じ処理ロジックを実装しているケース

これは、そもそもマイクロサービスの切り方に問題があるか。。

ケース2 アプリケーションコンテナのベースイメージの変更

ケース3 アプリケーションコンテナごとに作成するCICDパイプラインの処理の追加、ビルド用またはテスト用のイメージの変更

具体的には、Cloud BuildなどCIサービスで使用するBase Imageの更新など。マイクロサービス数CIの再設定が必要になり、１つの運用チームで変更作業を実施するのは、運用負荷が高い。

その他

マイクロサービスとは直接関係ないが、開発と運用が別れていることにより、どこまでどのチームがやるかという責任境界の問題も発生する。