DOMA - 구현
이전 장에서는 우버에서 MSA(Microservice Architecture)를 도입하면서 겪었던 문제를 알아보고 이러한 문제를 해결하기 위해 새롭게 등장한 개념인 DOMA(Domain-Oriented Microservice Architecture)에 대해서 알아보았다. 이번 장에서는 DOMA의 구성요소에 대해서 자세하게 알아보고 우버가 어떠한 방식으로 DOMA를 구현하였는지에 대해서 알아본다.
도메인(Domain)
처음 도메인을 설계하게 되면 하나의 도메인에는 몇개의 마이크로서비스가 포함되어야 하는지에 대한 의문이 생길 수 있다. 우버에서 작성한 문서에서도 이러한 질문에는 답변을 해주지 않으며 그 이유는 도메인의 성격에 따라 수십개의 서비스가 포함될 수 있고 극히 작은 도메인은 하나의 서비스만 포함할 수도 있다. 서비스의 갯수가 중요한 것이 아니라 중요한 점은 각 컬렉션의 논리적 역할에 대해 신중하게 생각하는 것이다. 우버 지도 서비스의 경우 3개의 각각 다른 API 게이트웨이 뒤에 80개의 마이크로서비스가 3개의 도메인으로 나뉘어져 있다.
레이어 디자인(Layer Design)
레이어 디자인은 서비스 종속성 전반에 걸쳐 장애의 전파 반경과 서비스의 특징에 대해 생각하는 메커니즘을 설명한다. 레이어 디자인은 “어떤 서비스가 다른 서비스를 부를 수 있는가?”라는 질문에 답한다. DOMA 에서 레이어 디자인은 “규모에 따른 관심 분리”나 “규모에 따른 종속성 관리”로 생각할 수 있다. 도메인이 최하위 계층에서 최상위 계층으로 이동함에 따라 중단 시 더 적은 수의 서비스에 영향을 미치고 구체적인 기능에 집중된다. 반면 가장 아래 레이어의 기능은 종속 항목이 더 많아 결과적으로 장애의 전파 반경이 넓고 일반적인 비즈니스 기능의 집합을 나타내는 경향이 있다.
예를 들면 상위 계층은 모바일 기능과 같이 특정 사용자의 경험을 다루며, 하위 계층은 계정 관리 또는 시장 방문과 같은 일반화된 비즈니스 기능으로 생각할 수 있다. 레이어는 그 아래의 레이어에만 의존하기 때문에 장애의 반경 및 도메인 통합에 유리한 부분이 있다.
우버의 경우 일반화된 라이더 서비스 또는 운전자의 특정 기능 서비스로 상위 레이어에서 도메인이 시작된다. 하지만 요구 사항이 발전함에 따라 결국 점점 더 많은 기능을 포함하게 되어 레이어의 하단부로 내려오게 된다. 이렇게 자연스럽게 서비스는 더 많은 비즈니스 로직과 종속성을 가지게 된다.
우버는 아래와 같이 총 5가지의 계층을 설정하였다.
- 인프라 계층: 스토리지 또는 네트워킹과 같은 기능을 제공하며 모든 엔지니어링 조직이 사용할 수 있다.
- 비즈니스 계층: Rides, Eats, Freight와 같은 특정 제품 카테고리 또는 LoB(Line of Business)와 같은 우버가 사용할 수 있는 기능을 제공한다.
- 제품 계층: 특정 제품 카테고리 또는 LoB와 관련된 기능을 제공한다. 여러 대면 애플리케이션(예 모바일)에서 사용되는 “탑승 요청”로직과 같은 불가지론적인 기능을 제공한다.
- 프레젠테이션 계층: 소비자 대면 애플리케이션(모바일/웹) 내에 존재하거나 직접적으로 관련된 기능을 제공한다.
- 엣지 계층: 우버 서비스를 외부에 안전하게 노출하며 모바일 애플리케이션도 인식한다.
각 후속 레이어는 점점 더 구체적인 기능을 나타내며 레이어 내의 기능에 의존하는 구성 요소가 점점 작아진다.
게이트웨이
“Gateway API”라는 용어는 마이크로서비스 아키텍처 내에서 널리 확립된 개념이며 게이트웨이 도메인이라고 부른다. 이 계층은 기본 서비스 모음에 대한 단일 진입점인 부분을 제외하면 다른 서비스와의 큰 차이는 없다. 다만 API 설계가 잘 이루어져야 성공적으로 게이트웨이 도메인을 구축할 수 있다.
위의 이미지는 게이트웨이 상위 수준의 다이어그램이다. 여러 서비스, 데이터 테이블, ETL 파이프라인 등 도메인의 내부 세부 정보를 추상화하여 외부로 노출하지 않고 RPC API, 메시징 이벤트 및 쿼리와 같은 인터페이스만 다른 도메인에 노출시킨다. 업스트림 소비자는 단일 서비스에서만 작동하므로 게이트웨이는 도메인 내에 존재할 수 있는 여러 다운스트림 서비스에 대한 종속성과 달리 업스트림 서비스가 단일 종속성을 취함으로써 추후 마이그레이션, 검색 가능성 및 시스템 복잡성의 전반적인 감소 측면에서 수많은 이점을 제공한다. 한 문장으로 정의하면 게이트웨이는 마이크로서비스의 모음 측면에서 원하는 모든 작업을 수행할 수 있는 인터페이스다.
확장(Extensions)
확장은 도메인을 확장하는 메커니즘을 의미한다. 확장의 기본 정의는 서비스의 실제 구현을 변경하지 않고 전반적인 안정성에 영항을 주지 않고 기본 서비스의 기능을 확장하는 메커니즘을 제공한다는 것이다. (SOLID의 Open-Closed Principle(계방-폐쇄 원칙)인 확장에는 열려있고 변경에는 닫혀있다.는 원칙과 유사하다.) 우버는 논리 확장과 데이터 확장이라는 두 가지 확장 모델을 제공한다. 확장 개념을 통해 서로 독립적으로 작업할 수 있는 여러 팀으로 아키텍처를 확장할 수 있다.
- 논리 확장(Logic Extensions)
논리 확장은 서비스의 기본 논리를 확장하기 위한 메커니즘을 제공한다. 서비스별로 정의된 인터페이스와 함께 제공자 또는 플러그인 패턴의 변형을 사용한다. 이러한 패턴을 통해 서비스를 확장하려는 팀은 기본 플랫폼의 핵심 코드를 수정하지 않고도 인터페이스 기반 방식으로 확장 로직을 구현할 수 있다.
예를 들어, 운전자가 온라인 상태가 될때 안전 검사, 규정 준수와 같은 다양한 검사를 각각 다른 개발팀이 소유하고 있는 서비스에서 수행하게 된다. 이러한 기능을 완벽하게 구현하는 한 가지 방법은 각 팀이 동일한 끝점에서 논리를 작성하도록 하는 것이지만 복잡성을 유발할 수 있기 때문에 각 검사에는 완전히 관련이 없는 맞춤형 논리가 필요하다.
논리 확장의 경우 각 확장이 미리 정의된 요청 유형 및 응답을 준수할 것으로 기대하는 인터페이스를 정의한다. 각 팀은 이 논리의 실행을 담당할 확장을 등록한다. 이 경우 단순히 드라이버에 대한 약간의 컨텍스트를 취하고 드라이버가 온라인 상태가 될 수 있는지 여부를 의미하는 Boolean 타입의 변수를 확인한다.
말이 복잡한 것 같지만 정리해보면 간단한 의미다. 운전자가 온라인 상태가 될 때 A서버, B서버, C서버에 세 개의 요청을 보내야 한다. 이러한 경우 하나의 요청이 세가지 요청을 모두 처리하여 결과를 클라이언트로 반환한다는 의미가 된다. 결국 클라이언트는 한 번의 요청에 원하는 결과를 얻게 된다.
- 데이터 확장(Data Extensions)
데이터 확장은 핵심 플랫폼 데이터 모델이 비대해지는 것을 피하기 위해 임의의 데이터를 인터페이스에 연결하는 메커니즘을 의미한다. 데이터 확장의 경우 팀이 요청에 임의의 데이터를 추가할 수 있도록 Protobuf의 Any 기능을 활용한다. 서비스는 종종 이 데이터를 저장하거나 논리 확장에 전달하여 핵심 플랫폼이 이 임의의 컨텍스트를 역직렬화(데이터의 구조를 알고 Deserialize)할 책임이 사라진다.
논리 및 데이터 확장 외에도 우버의 많은 팀은 해당 도메인에 적합한 자체 확장 패턴을 도입하였다.
이익(Benefits)
우버의 거의 모든 도메인은 어느 정도 DOMA의 영향을 받았다. 지난 한 해 동안 다양한 비즈니스 라인 각각에 대해 일반화된 논리를 제공하는 우버의 비즈니스 계층에 주로 초점을 맞추었다.
- 제품 및 플랫폼
DOMA는 우버의 제품 및 플랫폼 팀 간의 합의의 결과였으며 플랫폼 지원 비용은 대부분 큰 폭으로 감소하였다. 또한 개발팀의 개발속도가 전반적으로 크게 향샹되었다. 예를 들어, 확장 아키텍처의 초기 플랫폼 소비자는 소비자를 위한 코드 검토, 계획 및 학습 곡선에 대한 시간이 단축된 아키텍처를 채택하여 새로운 기능의 우선 순위를 지정하고 새로운 기능을 통합하는 시간을 3일에서 3시간으로 단축하게 되었다.
- 복잡성 감소
이전에는 제품 팀이 도메인을 활용하기 위해 수많은 다운스트림 서비스를 호출해야 했지만 이제는 단 하나의 서비스만 호출해도 원하는 결과를 얻게 되어 온보딩 시간을 25 ~ 50% 단축할 수 있게 되었다. 또한 2200개의 수많은 마이크로서비스를 70개의 도메인으로 분류할 수 있게 되었다.
- 향후 마이그레이션
우버는 마이크로서비스의 반감기가 1.5년이라고 계산하였고 이것은 1.5년마다 마이크로서비스의 50%가 이탈한다는 것을 의미한다. 만약 게이트웨이가 없다면 변경의 결과로 MSA가 “마이그레이션 지옥”에 빠지기 쉽다. 끊임없이 변화하는 마이크로서비스에는 지속적으로 업스트림 마이그레이션이 필요하고 게이트웨이를 통해 각 팀은 기본 도메인 서비스에 대한 종속성을 피할 수 있다. 즉, 업스트림 마이그레이션을 강제하지 않고도 해당 서비스를 변경할 수 있다는 의미다.
- 새로운 비즈니스 라인 및 제품
DOMA를 사용하여 설계된 플랫폼은 훨씬 더 확장 가능하고 유지 관리하기 쉬운 것으로 입증되었다.
DOMA를 채택한 우버의 대부분의 팀은 새로운 비즈니스 라인을 지원하는 데 비용이 너무 많이 들었기 때문이다.
실용적인 조언
우버에서는 DOMA를 채택하려는 회사를 위해 몇 가지 실용적인 조언을 제공한다. 기본 원칙은 성숙하게 설계된 MSA가 적시에 올바른 방향으로 움직이는 데서 비롯된다는 것이다. 실제로 전체 MSA에 대해 진정한 “다시 쓰기”가 불가능하다.
결과적으로 우리는 하향식 또는 일회성 아키텍처가 아니라 궁극적으로 올바르게 성장할 수 있도록 발전시키는 것으로 생각하며 이는 역동적이고 진보적인 과정이다.
- 스타트업
“언제 MSA를 채택해야 하는가?” 또는 “이것이 우리 조직에 의미가 있는가?”라는 질문이 있다. 우리는 지금까지 살펴본 것과 같이 MSA는 많은 엔지니어가 있는 조직에 운영상의 이점을 제공하지만 이는 기능을 구축하기 더 어렵게 만들 수 있는 복잡성이 증가한다.
규모가 작은 회사에서는 운영상의 장점이 아키텍처의 복잡성의 증가를 상쇄하지 못하는 경우가 발생할 수 있다. 또한 MSA 구축을 위해 전용 플랫폼이 필요한 경우가 많은데 이는 초기 단계 회사에서는 예산이 부족하거나 우선순위로 볼 때 차선책이 될 수 있다.
이러한 점 때문에 MSA 도입을 아예 보류하는 것은 합리적이지 않다. 조직이 마이크로서비스를 채택하기로 선택한 경우 “대규모 분산 애플리케이션으로서의 MSA” 비유와 구축하려는 MSA간의 문제 분리에 대해 생각해야 한다. 또한 최초의 MSA가 비즈니스의 핵심 로직을 가지고 있기 때문에 가장 중요하고 가장 오래 지속된다.
- 중소기업
회사가 여러 팀으로 구성된 중간 규모의 회사가 되서 다양한 기능과 플랫폼 간의 명확한 관심사 분리가 흐릿해지면 MSA는 더욱 분명하게 유용해진다. 이 단계에서 MSA간의 계층 구조에 대해 생각할 수 있으며 일부 서비스가 운영에 더욱 중요해지기 시작하고 점점 더 많은 팀이 이에 의존함에 따라 종속성 관리가 더욱 중요해질 수 있다. 회사의 규모가 작다면 MSA의 수가 매우 작기 때문에 함께 클러스터링 하는 것은 의미가 없을 수 있지만 DOMA 구현 맥락에서 도메인은 단일 서비스를 포함할 수 있으므로 “도메인 지향” 방식으로 생각하는 것이 여전히 유용할 수 있다는 점에 유의해야 한다.
- 대기업
대규모 엔지니어링 조직에는 수백 명의 엔지니어 및 MSA와 수많은 종속성이 있을 수 있다. 이 시점에는 DOMA 도입을 적극적으로 검토해야 한다. 게이트웨이가 앞에 있는 도메인으로 쉽게 그룹화할 수 있는 MSA 클러스터가 존재할 것이다. 레거시 서비스를 리팩토링하거나 다시 작성한 다음 마이그레이션해야 하는 경우가 종종 있다. 이는 게이트웨이가 이미 있는 경우 마이그레이션 용이성 측면에서 가치있는 작업이 될 것이다.
특정 기능 또는 기능 그룹화에 대한 “제품” 서비스로 작동하는 일부 서비스에서 명확한 계층 구조가 중요해질 것이다. 다른 서비스는 점점 더 여러 제품을 지원하고 “플랫폼”으로 간주될 것이다. 이 단계에서는 플랫폼 팀의 운영 부담과 시스템 전체의 발안정성을 피하기 위해 임의의 제품 로직을 플랫폼에서 분리하는 것이 중요하다.
우버의 경우 아직까지도 적극적으로 DOMA를 발전시키고 있다. DOMA의 중요한 통찰력은 MSA가 실제로 하나의 대규모 분산 프로그램이며 모든 소프트웨어에 적용할 동일한 원칙을 진화에 적용할 수 있다는 것이다. DOMA는 실제로 이러한 원칙에 대해 생각을 하기 위한 접근 방식일 뿐이다.
지금까지 우버가 어떠한 방식으로 DOMA를 도입하게 되었는지에 대해서 알아보았다.
참고한 치료
'Infrastructure > Microservice' 카테고리의 다른 글
| [MSA] DOMA 개념 (0) | 2022.09.23 |
|---|---|
| [MSA] Communication (0) | 2022.09.22 |
