scant

scant

Be kindly

마이크로서비스 모델링 ② : 마이크로서비스 도출기법

Updated:

마이크로서비스 모델링 ② : 마이크로서비스 도출 기법

사실 소프트웨어 개발역사에서 모듈화의 중요성은 예전이나 지금이나 한결같다. 모듈화의 근본 가치는 어떻게 각각의 모듈을 기능적으로 응집성 있고(High Cohesion) , 기능이 다른 타 모듈간의 관계는 의존도를 낮출 것이냐(Low Coupling)하는 것이다.

따라서 마찬가지로 마이크로서비스 설계에서의 가장 중요한 관심사도 어떻게 응집성 있는 마이크로서비스를 도출하고 서비스 간의 의존도를 낮출 것인가 하는 점이다. 또한 추가로 그렇게 식별한 마이크로서비스의 내부구조의 각 요소들도 모듈화 되어야 한다. 즉 아래 그림과 같이 각 역할이 분명한 응집성 있고 서로 의존관계가 낮은 모듈들이 모여 마이크로서비스를 이루고 이 마이크로서비스는 타 서비스와 의존성이 낮아야 한다. 또 이 요소들은 모두 소프트, 유연해야 한다는 말이다. 앞서 다른 포스트에서 언급한 바와 같이 DDD의 전략적 설계와 전술적 설계가 이를 위한 적절한 가이드를 주고 있다.

모듈,서비스 모두 응집성은 높게 의존도는 낮게

마이크로서비스 도출 방법

마이크로서비스가 비지니스 변화 속도에 지원하며 독립적으로 변경 배포 되기 위해서는 각각의 마이크로서비스가 다른 서비스에 의존적이지 않게 도출되는 것이 중요하다. 따라서 시스템의 어떤 기능들을 묶어서 독립적인 마이크로서비스로 도출할 것인가를 결정하는 것이 매우 중요하다.

비즈니스 능력에 근거한 도출

마이크로서비스를 식별하는 가장 쉬운 방법은 경험적인 원칙을 적용하는 것이다. 크리스 리처드슨은 그의 책 [마이크로서비스 패턴]에서 비지니스 능력(capability) 에 따라 서비스로 식별할 수 있다고 한다. 또한 비즈니스 능력은 비지니스 가치를 생산하기 위해 하는 일이라고 정의하며 곧 조직이 하는 일이라고 말한다.

즉 각 도메인에서는 비지니스가 규정하는 일하는 방식과 조직,부서 체계가 이미 정의되어 있고, 이러한 부서들은 업무처리에서의 응집성을 가지고 있고 타 부서와의 의존도가 낮을 것이다. 이렇게 비지니스 부서가 가진 역할,능력을 체계적으로 분해 할 수 있는데 이를 보통 기능분해라고도 부른다. 기능 분해는 업무의 흐름에 따라 업무를 최상위에서 하위까지 대,중,소의 크기로 분리하고 수행하는 일들을 체계적으로 정렬한다. 이렇게 하면 보통 특정 부서가 수행하는 업무 역할과 비슷해 진다. 아래 그림과 같이 이를 기반으로 직관적으로 서비스를 식별할 수 있다. 어떤 레벨을 서비스로 식별해야 하는지 고민이 될 수도 있지만 쉽고 간단하게 도출할 수 있다.

비지니스 능력에 의한 서비스 도출

그렇지만 이런 방식은 전체적인 대략의 비즈니스를 이해 할 때는 유용하지만 서비스간의 관계나 서비스의 구체 기능과 연관된 서비스가 관리할 독립적인 데이터를 식별하기에 미흡하다.

DDD 컨텍스트 경계 기반 도출

비지니스 능력에 따른 서비스 도출 한계를 보완하기 위해 DDD의 전략적설계를 적용할 수 있다. 이전 마이크로서비스 개념에서 언급했다시피 마이크로서비스는 각각의 저장소를 독립적으로 보유하고 각 데이터는 다른 서비스의 직접 참조가 되어서는 안되는 특성이 있었다. 이런 특성이 기존 SOA방식과는 다르게 서비스를 독립적으로 수정, 배포할 수 있는 큰 무기가 되었다.

따라서 마이크로서비스 도출 시에 서비스가 소유권을 가진 데이터를 독립적으로 식별하는 것이 중요하다. 서비스가 보유한 기능에 의해 갭슐화되는 데이터의 파악이 필요한 것이다. 그렇지만 위의 기능 분해 방식은 서비스가 소유해야 할 데이터 식별에 적합하지 않고 기능과 데이터가 분리되고 하나의 통합 데이터가 여러 기능에서 사용되도록 모델링 되는 경향이 많았다.

그러나 DDD 는 문제 영역인 하위도메인마다 별도의 도메인 모델1을 정의한다. 도메인 모델은 각 업무에 특화된 유비쿼터스 언어로 정의되고 그 업무에 특화된 데이터로 구성된다.
이런 점이 독립적인팀이 자율적으로 마이크로서비스를 개발 운영하는 마이크로서비스 개념과 매우 잘 어울렸고 아래와 같이 컨텍스트 경계 중심으로 마이크로서비스를 도출하는 가이드를 주었다.

컨텍스트 경계를 통한 서비스 식별

DDD의 컨텍스트 경계 기반 도출 방법은 다음 포스팅에서 계속 설명하겠다.

마이크로서비스는 얼마나 작아야 하나? 마이크로서비스의 크기에 대해서 항상 이슈가 되고 있다. 많은 개발자들이 마이크로서비스를 무조건 작은 크기로 나누는 것이 바람직하다라는 경향이 있다. 그렇지만 마이크로서비스의 크기는 코드의 크기 같이 양(quantity)적으로 판단될 것이 아니라 전체 업무 맥락에서 질(quality)적으로 판단 되야 한다. 그렇다면 이런 질적 판단의 요소는 무엇일까? 질적 판단의 요소는 자율적으로 수행 가능한 업무의 단위, 개념의 일관성이나 기능의 응집성 등을 말하며 이는 비지니스 도메인에 따라 , 조직의 성숙도에 따라 상대적이다.

  1. 분리된 도메인 모델의 의해 다른 컨텍스트와 구별되는 경계를 ‘컨텍스트 경계’라 부른다.제거하고 중요한 일에 집중하는 방식이라 볼 수 있다. ↩

You May Also Enjoy