[펌]Uber Domain O Microservices
Uber Domain-Oriented Microservice Arch.
영문 원본 : https://web.archive.org/web/20200803012939/https://eng.uber.com/microservice-architecture/
번역 원본 : https://news.hada.io/topic?id=2581&utm_source=weekly&utm_medium=email&utm_campaign=202032
DOMA ( Domain-Oriented Microservice Architecture) 는 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년간 만들었다고 )
