Uber 의 Domain-Oriented Microservice Architecture

 

https://web.archive.org/web/20200803012939/https://eng.uber.com/microservice-architecture/

* 원글이 우버 엔지니어링 블로그에서 삭제되어서 임시로 Wayback Machine 링크로 교체해둡니다.

 

DOMA는 2200개의 마이크로서비스를 가진 우버가 MSA의 유연성을 유지하면서, 복잡도를 줄이기 위해 취한 방법

 

- DDD,SOA,OO,CA 등에서 가져와서 큰 조직의 대규모 분산시스템에 맞게 설계
- 꽤 오랜기간 MSA를 운영한 우버의 오랜 경험이 집약된 글

DOMA의 기본 원칙
1. Domain 단위로 마이크로서비스를 컬렉션으로 모음
2. Layer 라고 부르는 도메인 컬렉션을 만들어서, 각 레이어안에서는 종속성을 가질수 있도록 함 → Layer Design
3. 각 컬렉션에 대한 단일 진입점으로 깔끔한 인터페이스를 제공하는 Gateway 를 만듬
4. 각 도메인은 다른 도메인에 대해 독립적이어야 함. 하지만, 다른 도메인의 로직을 포함해야할 경우가 많으니 이를 잘 지원하는 Extension 아키텍처를 제공

 

---

※Uber의 구현

- Domains
ㅤ→ 논리적으로 그루핑된 하나이상의 마이크로서비스 모음.
ㅤ→ 도메인별로 서비스가 10개 이상이 있을수도 있고, 한개만 있을수도 있음
ㅤ→ 예) 지도 검색, 요금, 매칭플랫폼(라이더와 운전자) 등이 하나의 도메인
ㅤ→ 회사의 조직구조를 따르지는 않아서 Uber의 지도 관련 조직은 3개의 도메인, 80개의 마이크로서비스, 3개의 게이트웨이로 되어 있음

- Layer Design
ㅤ→ "어떤 서비스가 다른 서비스를 부를수 있을수 있나요?"에 대한 답
ㅤ→ "separation of concerns at scale" 또는 "dependency management at scale"
ㅤ→ Uber는 5개의 Layer로 구성

 

1. Infrastructure : 모든 조직이 쓸수 있는 기능. 스토리지/네트워킹 등

 

2. Business : 비즈니스 단위에서 쓸수 있는 기능. 특정 제품 카테고리나 Rides, Eats, Freight 등의 LOB(Line Of Business) 에 한정되지 않음

 

3. Product : 특정 제품 카테고리및 LOB에 연관 된 기능이지만, 여러 앱에서 같이 사용하는 "Request a ride" 같은 것도 가능

 

4. Presentation : 사용자 대상 어플리케이션 관련 기능들 ( 모바일 / 웹 )

 

5. Edge : 우버 서비스를 외부에 안전하게 공개하는 것. 모바일 어플리케이션과도 연계

 

- Gateways
→ 마이크로서비스의 API Gateway와 크게 다르지 않음. 다만, Domain 에 연결되는 단일 진입점(Single Entry-point)으로 생각

→ 내부에서 외부와의 단일 종속성을 가지게 되므로 마이그레이션,디스커버리,시스템 복잡성이 전반적으로 감소

 

- Extensions
→ 서비스의 구현을 변경하거나 안정성에 영향을 주지않고 도메인을 확장하는 메커니즘

 

1. Logic 확장 : Provider 또는 Plugin 패턴을 이용하여 서비스 로직을 확장

 

2. Data 확장 : 코어 데이터가 느는걸 방지하기 위해 임의의 데이터를 연결하는 메커니즘. Protobuf 의 Any 타입을 활용

 

3. Custom 확장 : 도메인에 맞게 각 팀이 알맞는 패턴으로 확장

온보딩 타임이 25~50% 줄어드는 효과
2200개의 마이크로서비스를 70개의 도메인으로 분리했음.

Uber에서 마이크로서비스의 반감기는 1.5년으로 계산되었음. 즉, 1.5년마다 마이크로서비스의 50%가 사라짐
게이트웨이가 없다면 이렇게 없어질때마다 마이그레이션 헬이 펼쳐짐.
우버에선 DOMA를 사용해서 설계된 플랫폼이 훨씬 확장이 쉽고, 유지보수가 용이한 것으로 입증.

 

---

다른 회사들을 위한 실용적 조언

- 스타트업 :

→ "MSA를 언제 채택해야 할까요?" "우리 조직에 쓸만할까요?" 라는 질문이 중요.

 

→ MSA는 많은 엔지니어가 있는 조직엔 운영상의 이점이 있지만, 복잡성을 증가시켜 기능을 더 어렵게 만들수 있음

 

→ 소규모 조직에서는 운영상 이점보다 아키텍처 복잡성의 증가만 가져올수도 있고, 비용이 더 들수도 있음.

 

→ 천천히 도입하는 것도 무리가 없으며, MSA로 가기로 했다면 "대규모 분산 프로그램" 으로 생각해서 마이크로 서비스간에 분리해야함.

 

→ 첫 마이크로서비스 들이 비즈니스의 핵심 기능을 설명할때 중요하고 오래 지속 될 것

- 중간 사이즈 회사 :

 

→ 회사가 여러팀으로 나눠지고, 플랫폼간 관심사 분기가 되기 시작하면 MSA가 더 유용해짐

 

→ 이 단계에서 마이크로서비스 간에 계층구조를 고려해볼 수 있고, 더 많은 서비스들이 사용하면서 종속성 관리가 중요해 짐

 

→ 아직 마이크로 서비스의 수는 많지 않으므로 클러스터링은 의미가 없을수 있지만, 도메인 지향적으로 생각하는 것은 유용

 

---

- 큰 회사 :
→ 대규모 엔지니어링 조직엔 수백의 엔지니어, 마이크로서비스 및 종속성이 있으므로 DOMA가 완전히 유용
→ 게이트웨이를 가진 도메인으로 쉽게 그룹화 할수 있고, 레거시를 리팩터링 또는 재작성 할때도 게이트웨이가 유용

Uber에서도 DOMA를 점차 많은 팀들이 도입하고 있음. ( Uber의 모든조직에서 60명정도가 같이 참여해서 2년간 만들었다고 )