최적의 Microservice를 도출하는 방법

Cloud/MSA를 적용하는 프로젝트를 지원하다보면 우리가 개발할 시스템을 마이크로서비스를 어떤 기준으로 어떻게 마이크로서비스로 도출한 것인지 설명하고 설득해야하는 경우가 있다. 고객과 프로젝트 수행팀 사이, 이상적인 마이크로서비스와 현실적인 마이크로서비스 사이에서 최적의 마이크로서비스를 정의하는 것이 중요하다는 것이다. 최근 OOO 프로젝트에서 마이크로서비스를 식별했던 내용을 통해 최적의 마이크로서비스를 식별했던 사례를 바탕으로 설명하겠습니다.

정의된 Cloud 배포 모델과 서비스 유형

일단 본격적이 내용에 앞서 미리 알아야 하는 몇가지 개념에 대해 알야보자.

아래 테이블은 프로젝트의 요구사항을 만족시키기 위해 선택 가능한 Cloud 배포 모델 유형이다.

OO 프로젝트는 시스템 확장의 용이성과 안정성, 고 가용성 보장을 위해 Public, Private, Hybrid Cloud 중 이 프로젝트는 A사의 Public Cloud를 사용하기로 결정했고, IaaS, PaaS, SaaS의 서비스 유형 중 PaaS를 도입하기로 했다.

클라우드 서비스 유형에 대해 간단히 설명하면, 우리가 신택한 PaaS는 인프라와 플랫폼 영역을 클라우드 서비스를 제공 업체에서 서비스 형태로 제공하는 기능을 사용하고, 프로젝트에서는 애플리케이션과 데이터 영역만 구축하는 방식이다.

마이크로서비스 도출

1. 고객, 현업, 프로젝트 팀이 함께 이벤트 스토밍 워크샵을 통해 도출한 마이크로서비스

제일 먼저 반나절이란 시간을 할애해 고객, 현업 담당자, 그리고 프로젝트 팀 전체가 모여 이벤트 스토밍 워크샵을 진행했다.

워크샵을 통해 우리는 26개의 바운디드 컨텍스트를 도출할 수 있었다.

이 시스템의 주요 사용자는 역할별로 한정되어 있고, 비즈니스 수행을 위한 정형화된 프로세스를 고려해서 2~6개의 바운디드 컨텍스트를 묶어 하나의 마이크로서비스로 정의했다.

이렇게 이벤트 스토밍 워크샵 기법을 통해 마이크로서비스를 식별했다는 것은 비즈니스의 프로세스와 업무의 맥락 구분의 관점으로 마이크로서비스의 후보를 도출했다는 것이다. As-is시스템이 존재하는 이 프로젝트의 경우 비즈니스 프로세스, 업무 맥락의 구분만으로 마이크로서비스 식별에 추가로 고려할 것들이 있는지 고민하게 되었다.

2. As-is 시스템의 논리 ERD 분석을 통해 논리적인 기즌 분리 관점의 마이크로서비스 분리 가능성 검토

기존 시스템은 약 15년 된 매우 노후화된 시스템으로 기능 추가/개선을 위해 아키텍처의 변경없이 기존 구현된 코드에 계속해서 코드를 추가하고, 또 데이터베이스에 테이블과 컬럼을 추가했다가 삭제했다가를 반복해 왔다고 한다. 이 부분은 직접 분석한게 아니라 실제 기존 업무 분석한 각 업무 PL 분들의 얘기였다. 그리고 프로젝트 팀 내부적으로도 전체 시스템을 이해하고 있는 현업 담당자, 운영 담당자가 없고 또 시스템이 분석히가 어려울 만큼 노후화되어 있어서 새로운 방식의 적용에 고민이 많은 상태였다. 그래서 기존 시스템의 논리 ERD 분석을 통해 기존 시스템이 어떻게 모듈화 되어있는지 확인하고, 이 모듈별로 데이터의 분리가 가능한지 검토를 진행했다.

그림을 보면, 마이크로서비스의 사상에서 지양해야하는 공통(기준정보)기능을 하나의 마이크로서비스로 분리를 고려하였다.

이 시스템은 15년 동안 구조를 개선하지는 못했지만, 시스템의 운영, 관리, 개선을 위해 최적의 조직을 구성해서 시스템을 사용하고 있었다. 그래서 추가로 조직 관점에서의 검토를 진행하기로 했다.

3. 운영, 관리, 개선에 최적화 된 조직을 고려한 마이크로서비스 후보 검토

앞에서 비즈니스 프로세스, 업무 맥락 관점으로 마이크로서비스의 후보를 식별하고, 기존 시스템의 데이터 분석을 통해 이 후보 마이크로서비스 별로 데이터베이스를 분리하는 것이 가능한지 검토를 했다. 이 두 절차로도 마이크로서비스를 정의하기에 충분하다고 생각되지만 이 오래된 시스템의 운영과 관리, 개선을 위해 최적화된 조직 구성을 통해 시스템을 사용하고 있다는 것에 주목했다. 따라서 비즈니스 관점, 데이터 관점에서 식별한 마이크로서비스를 운영 효율성을 고려해서 조직 구성과 운영 관점에서 분리 적합성을 검토해 보았다.

Final. 비즈니스, 데이터, 조직을 고려한 마이크로서비스 정의

보통 신규 시스템 구축 프로젝트는 이벤트 스토밍 워크샵을 통해 바운디드 컨텍스트를 도출하고, 최종 마이크로서비스를 도출했다. 하지만 이 프로젝트는 심한(?) 노후화와 전체 시스템을 이해하는 현업/운영자의 부재, 프로젝트 리소스의 제한 등의 이유로 마이크로서비스를 이상적으로만 도출하는 것보다 최적의 마이크로서비스를 도출하는 것으로 방향을 잡았다. 현 운영 조직에서 운영하기 용이한, 기존 시스템의 논리적을 구분한 모듈과 데이터 변경의 최소화, 정해진 일정을 고려해서 아래와 같이 6개의 마이크로서비스로 구성하는 것을 제안했다.

정리

사실 너무 큰 사이즈의 서비스들로 상세 설계와 구현단계에서 Dependency와 Transaction 분석, DB Modeling을 통해 서비스의 분리를 검토하기로 했다. 아무리 좋은 기술, 솔루션도 꿰어야 보배, 즉 프로젝트 팀에서 구축하고 구성해야 하는데, 당연히 처음 접하는 기술들로 실패와 지연에 대한 두려움이 있을 수 있다. 그래서 Cloud/MSA를 성공적으로 적용하기 위해서 가장 중요한 것이 프로젝트 팀원의 의지라고 생각한다.

MSA에서는 마이크로서비스를 도출하는 것이 매우 중요하다. 서비스를 잘 분리해야 Cloud, MSA를 적용함으로써 누릴 수 있는 최대한의 해택을 얻을 수 있기 때문이다. 그렇기 때문에 무조건 작은 서비스, 무조건 서비스 별로 격리된 데이터베이스와 같이 무조건 적용하는 것이 아니라 비즈니스의 특성과 함께 데이터, 조직, 운영 계획 등을 복합적으로 고려해서 최적의 마이크로서비스를 정의하는 것이 중요하다고 생각한다.

감사합니다..