[조대협 대용량 아키텍처] 마이크로 서비스 아키텍처와 거버넌스 모델(+ 진화형 모델, DDD)

거버넌스 모델

거버넌스(Governance)란 개발 조직의 구조나 프로세스를 정의한 것으로, 일반적으로 중앙 집중 성향을 가진 조직에서 표준 프로세스와 가이드를 이용하여 전체 팀을 운용하는 모델로 사용된다.

이때 위의 모델을 중앙 집중형 거버넌스 모델이라고 하며, 같은 프로세스를 공유하기에 유지보수가 쉬우며 팀원들의 교체가 편리하다는 장점이 있다.

 

하지만, 현대의 개발시에는 많은 오픈소스들이 발달 되었고, 선택할 기술들이 많아졌으며, 요구 사항에 맞추어 효율성 측면을 고려한다면 각각 경우에 맞추어 최적화된 기술을 사용하는 것이 좋을 수 있다.

이 경우에는 중항 집중형 거버넌스 모델에서는 하나를 적용하기 위해서는 모든 개발팀을 교육하고 운영 준비를 맞추어 해야하기 때문에 효율성이 떨어지게 된다.

 

분산형 거버넌스 모델(De-centalized Governance Model)

위의 문제점을 해결하기 위해 나온 모델이 분산형 거버넌스 모델이다. 이는 각 팀별로 프로세스와 기술을 선택할 수 있는 권한을 주는 모델이다. 분산형 거버넌스 모델을 수행하는 팀은 다음과 같은 특징이 있어야 한다.

Cross Functional Team

기존의 팀들은 역할별로 나뉘어 구분되었다. 기획, UX, 개발, 인프라 운영 등으로 나누는 것이 기존의 팀 모델이다.

Cross Function Team 모델은 하나의 팀에 기획, UX, 개발, 운영 등의 시스템을 개발하는 데 필요한 모든 역할을 구성하여 운용되는 모델로 각 서비스별로 Cross Function Team이 구성되어 움직인다.

 

출처 : https://perfectial.com/blog/make-a-cross-functional-team-work/

위의 경우는 서비스 기획에서부터 빠르게 설계, 개발, 운영을 할수 있에되어 다른 팀에 대한 의존성도 없어지며, 서비스 개발을 빠르게 할 수있다는 장점이 있다.

 

DevOps(Deveplpment + Operation)

위처럼 기술에 대한 독립성을 가지는 가장 효율적인 방법은 구현뿐만 아니라 운영또한 직접 할 수 있는 팀을 구성하는 것이다. 

따라서 개발과 운영을 하나의 조직에 합쳐 놓은 구조를 DevOps라고 한다. 

 

DevOps팀은 개발과 운영이 독립된 상황에서 오는 의사소통의 문제를 해결할 수 있으며, 운영시 발생하는 문제 또한 빠르게 개선할 수 있는 모델이다.

DevOps의 발생 배경은 운영팀의 역할인 인프라 운영이 클라우드의 도입으로 간단해져 개발자가 네트워크와 서버 설정이 가능해졌기 때문이다. 하지만 DevOps는 높은 수준의 팀 성숙도가 필요하며, 충분한 준비가 되어있지 않다면 고려를 해야할 부분이 많다.

 

Alignment

위의 분산형 거버넌스 모델을 수행하기전 주의해야 할 것이 있다. 바로 Alignment라는 개념인데, Alignment는 각 팀간의 커뮤니케이션 방법과 프로세스 등의 최소한의 기술적인 수준을 맞추는 과정을 말한다.

 

쉽게 말해 전체 팀들은 나아가야 할 방향과 비즈니스의 밸류, 팀간의 커뮤니케이션 방법, 전체 시스템의 구조를 이해한 후에 효율적으로 팀을 운영하는 과정이 필요하다는 것이다.

 

---

진화형 모델

마이크로 서비스 아키텍처를 이해 하면, 유연한 아키텍처의 구조와 대용량 웹 서비스를 지원할 수 있는 등 많은 장점을 활용하기 위해 마이크로 서비스 아키텍처의 도입을 고려할 수 있다.

하지만, 마이크로 서비스 아키텍처로 제대로 된 시스템을 개발 하기 위해서는 운영하는 팀에 대해 높은 성숙도가 동반되어야 한다.

 

따라서, 모노리틱 시스템부터 시작하여 점차 마이크로 서비스 아키텍처 형태로 진화시키는 구조도 좋은 모델이 될 수 있다.

위와 같은 방식의 모델을 진화형 모델이라고 하며, 많은 기업들이 이와 같은 방법을 사용하였더,

트위터 또한 모니리틱 구조에서 팀의 구조를 점차 변환하였고, 이베이 또한 진화형 모델을 적용하였다.

 

Domain Driven Development

DDD(Domain Driven Development)는 대부분의 프로젝트에서 구성원 자체가 현재 프로젝트의 목적, 현황, 다지안, 업무, 각자의 역할 등 프로젝트에 대한 컨텍스트의 이해 부족에서 오는 많은 문제들을 해소하기 위해 시작된 개념이다.

 

DDD는 다음과 같은 과정을 거친다.

메인 모델의 작성

먼저 구축하려고 하는 시스템이 하는 비즈니스 업무를 파악하는 것이 첫번째이다. 실제로 비즈니스가 흘러가는 것에 대한 다이어그램 모델을 작성하여 표현한다. 이때 다이어 그램은 어떤 모델을 사용하던 상관이 없지만 업무 전문가와 개발팀간의 의사소통을 할 수 있게 만들어 져야 한다. 또한, 모델 작성시에 사용하는 언어(지칭)는 업무 전문가와 모델링을 하는 사람들간의 통일이 필요하다.(필요시 용어 사전을 사용하여 명확한 개념정의)

 

모델의 분리

전체적인 메인 모델이 작성되었다면 도메인 모델을 세부 모델로 분리한다. 큰 모델을 이용하여 세부 흐름과 구체적인 계획을 작성하면 모델 자체의 크기가 커지기 때문에 그 내용일 이해하는 것이 더 어려워진다.

 

모델을 분리할 때, 가장 중요한 것은 메인 모델과의 추적성을 부여하는 것이 중요하다. 추적성을 부여하는 것은 상위모델의 모듈이 어떤 모델로 분리 되어있는지 명시하는 것인데 DDD에서는 Context Map이라는 방법을 사용한다. Context Map은 넘버링을 기반으로 모델 추적성을 부여하는 것인데 이를 통해 상위 모델이 하위 모델로 전이되는 과정을 표현하기가 쉬워진다.

 

하위 모델 간의 공통 모듈 처리

하위 모델 간에는 공통으로 사용하는 모듈이 있을 수 있다, 이 모듈은 두 개의 프로젝트에서 모두 사용되기에 변경이 있을시에 두 시스템에 모두 영향을 줄 수 있다.

DDD에서는 이러한 공유되는 모델을 공유 커널이라고 말하며, 연관되는 공유 커널에 대해서는 연관된 팀이 함께 설계하고 변경에 대해서 서로 합의를 하도록 안내한다. 하지만 사실상 실제 프로젝트에서는 적용하기가 어렵다.

 

따라서 다개 이상 모듈의 의존성의 오류 방지를 위해서 CI(Continuous Intergration)을 권장한다. 따라서 두개 이상의 팀들은 CI를 통해서 모듈에 대한 공통 처리를 할 수 있다.