소개

마이크로서비스마다 개발팀이 존재하지 않고, 개발과 운용이 다른 팀이 되고 있는 경우로, 마이크로서비스를 개발, 운용하는 경우의 고려 포인트를 생각해 보고 싶습니다.

마이크로서비스의 개발로서는, 정공법으로서 기존의 모노리스를 디커플링해 마이크로서비스로 하는 방법이 있다고 생각합니다만, 본 기사에서는 처음부터 마이크로서비스로서 어플리케이션을 개발하는 경우에 대해서 생각하고 싶습니다.

Amazon 등 이미 마이크로 서비스를 개발 운용하고 있는 기업에서 마이크로 서비스와 개발, 운영 팀의 관계성은 다음과 같은 이미지입니다.


기본적으로 각 마이크로서비스마다 개발 운영팀이 존재합니다. 즉, 서비스 및 개발 운영하는 팀은 1:1입니다.

다음은 계약 등으로 개발을 타사에 의뢰하는 경우의 마이크로서비스와 개발, 운영팀의 관계성의 이미지입니다.


대규모 엔터프라이즈 기업에서는 애플리케이션 개발을 내제하지 않고 SIer 등에 개발을 의뢰하는 경우가 있다고 생각합니다.
그렇게 말했을 경우는, 서비스와 개발 운용하는 팀이, 1:1이 되지 않는 경우가 있습니다. 그렇게 말한 경우에는 마이크로서비스의 수가 너무 많으면 운용이 어려워지는 경우가 있습니다. 그 이유 중 하나는 운영 팀이 마이크로 서비스가 아닌 시스템 전체에서 하나가 될 수 있다는 것입니다.

마이크로서비스의 장점

두 번째와 같은 조직 체제라도 물론 마이크로서비스에서 다음과 같은 이점을 누릴 수 있습니다.
- 스케일 인 아웃을 효율적으로 수행
- 모노리스라면, 일부 기능만 보다 처리 성능이 필요하게 된 경우도, 필요가 없는 기능도 포함해 스케일 아웃하게 된다
- 출시 시 영향의 국소화
- 기능 추가 시 기능이 마이크로서비스로 헤어지면 영향을 국소화할 수 있다.

두 번째와 같은 조직 체제의 경우 고려 사항

여러 마이크로서비스에 대한 변경이 필요한 경우, 마이크로서비스 수가 많으면 운영팀에 대한 부하가 높아진다.

사례 1 여러 마이크로서비스에서 동일한 처리 로직을 구현하는 사례

이것은 원래 마이크로 서비스를 자르는 방법에 문제가 있습니까? .

사례 2 애플리케이션 컨테이너의 기본 이미지 변경

사례 3 각 응용 프로그램 컨테이너에 대해 만들 CICD 파이프라인 처리 추가, 빌드 또는 테스트를 위한 이미지 변경

구체적으로는 Cloud Build 등 CI 서비스에서 사용하는 Base Image 업데이트 등. 마이크로서비스 수 CI의 재설정이 필요해지고, 하나의 운용 팀에서 변경 작업을 실시하는 것은 운용 부하가 높다.

기타

마이크로서비스와는 직접 관계는 없지만, 개발과 운용이 헤어지고 있는 것으로, 어디까지 어느 팀이 할까라는 책임 경계의 문제도 발생한다.