DOMA - 이론
이번 장에서는 Uber(이하 우버)의 DOMA(Domain-Oriented Microservice Architecture, 도메인 지향 마이크로서비스 아키텍처)에 대해서 알아보도록 한다.
2010년대에 들어서 독립 배포의 형태의 유연성, 명확한 소유권, 시스템 안정성 개선등 과 같은 MSA(Microservice Architecture)의 장점 때문에 수많은 기업들이 MSA(Microservice Architecture)를 도입하기 시작하였다. 하지만 얼마 지나지 않아 서비스의 복잡도가 증가하여 오히려 사소한 기능도 개발하기 힘들어진다는 등 여러 MSA의 단점을 가지고 비판하기 시작하였다.
우버는 이러한 MSA의 형태를 유지하면서 단점인 복잡성을 줄이기 위해서 새로운 개념인 DOMA를 서비스에 도입하기 시작하였다. DOMA의 목표는 MSA와 관련된 유연성을 유지하면서 전반적인 시스템의 복잡성을 줄이려는 조직에게 방법을 제공하는 것이다.
MSA(Micorservice Architecture)
MSA는 전통적인 SOA(Service Oriented Architecture, 서비스 지향 아키텍처)와 전혀 다른 개념이 아닌 확장된 개념이라고 할 수 있다. 2000년대 초반의 서비스는 커다란 하나의 서비스였지만 MSA는 단위별로 나뉘어진 여러개의 서비스로 이루어져 각각 다른 서비스를 위해 호출을 위한 인터페이스를 제공하고 서로를 호출하기 위해 RPC(Remote Procedure Call, 원격 프로시저 호출)을 사용한다.
기존 모놀로식 방식의 서비스는 모듈간의 통신을 위해 네트워크를 통하지 않고 프로세스 내에서 직접 호출하였다. 하지만 MSA의 경우 모듈들이 각각 다른 서비스로 이루어져 호스팅되어 있기 때문에 다른 서비스를 호출하기 위해서는 네트워크 통신을 해야한다. 이러한 특징때문에 네트워크 I/O를 위한 시간과 직렬와/역직렬화(Serialize/Deserialize)를 위한 시간이 추가로 필요하게 된다.
어떻게보면 치명적일 수 있는 이러한 단점을 감수하면서도 많은 기업들이 MSA를 도입하려는 이유는 독립적인 배포 및 확장이다. 모놀로식 구조의 서비스는 사소한 기능을 업데이트 하기 위해서 커다란 하나의 서비스가 재배포 되어야 한다. 하지만 MSA의 경우 해당 기능을 담당하는 작은 서비스 하나만 배포되면 되기 때문에 시스템 전체가 중단되는 위험을 감수하지 않아도 된다. 무엇보다 서비스 하나하나가 규모가 작기 때문에 배포 속도 또한 빠르다.
결론적으로 조직은 성능을 희생하면서 운영상의 유연함을 위해서 MSA를 도입하고 있다.
우버의 MSA와 한계
우버의 경우 2012-2013년도 쯤에는 커다란 2개의 모놀로식 서비스로 구성되어 있었다. 하지만 서비스가 커질만큼 커지면서 아래와 같은 문제들이 발생하였고 MSA를 도입하게 되었다.
- 낮은 가용성: 모놀로식 기반의 단일 시스템은 한 번에 모든 시스템이 다운될 수 있다.
- 높은 배포 비용: 한 번에 배포되는 코드의 양이 많기 때문에 배포에 필요한 시간이 많이 소요되며 급하게 서비스를 롤백해야 하는 경우에도 빠르게 대처할 수 없다.
- 힘든 모듈화: 직역을 하면 “우려의 분리 분량”이 된다. 하나의 커다란 서비스가 되면서 역할이 모호해지고 모듈간의 경계가 뚜렸하지 않아서 유지보수에 어려움이 있다.
- 비효율적 배포: 위의 문제들이 복합적으로 합쳐져서 하나의 팀간의 자율도가 낮아지고 결합도가 높아져 서비스의 독립적인 배포가 불가능하다.
우버는 위의 단점들을 보완할 수 있는 MSA를 도입하였고 목표하는 것은 아래와 같다.
- 높은 가용성: 단일 마이크로서비스는 전체 시스템을 중단하지 않고 배포될 수 있기 때문에 전반적인 시스템의 안정성이 높아진다.
- 고수준의 모듈화: 여러 마이크로서비스는 각각 자신이 실행되는 목표가 명확하기 때문에 “이 서비스가 존재하는 이유는 무엇인가?”라는 질문에 명확하게 답변할 수 있다.
- 코드의 소유: 어떤 팀이 어떤 서비스를 담당하는지 뚜렷하게 나뉘어지기 때문에 팀 또는 조직 수준에서 소유되어 더 빠른 성장을 가능하게 한다.
- 효율적인 배포: 서비스가 독립적으로 실행되기 때문에 개발자들은 원하는 시점에 자신이 담당하는 서비스만 독립적으로 배포할 수 있다.
기존 모놀로식 구조의 단점을 해결하면서 MSA를 도입한 우버지만 회사의 규모가 기하급수적으로 커지면서 서비스의 복잡도가 크게 증가하는 문제가 발생하기 시작하였다. MSA를 사용하면 각 서비스의 기능은 언제든지 변경될 수 있고 예기치않게 동작을 멈추어 블랙박스가 될 수 있다.
또한 많은 서비스가 서로를 호출하기 때문에 서비스 간의 종속성 및 의존성을 파악하는 것은 매우 어려울 수 있다. 아래의 이미지는 우버에서 픽업 문제를 디버깅하기 위해 총 12개의 팀이 50개가 넘는 서비스를 디버깅 해야 했던 상황을 보여주고 있다.
서비스 간의 의존성은 단일 종속성에서 멈추지 않고 자신이 종속되어 있는 서비스가 다른 서비스에 종속되어 있는 N번째 종속성으로 인해 서비스간에 통신할 때 통신 시간이 급증할 수 있고 몇번째 종속된 서비스에서 문제가 발생하였는지 디버깅하기 어려울 수 있다.
디버깅 뿐만 아니라 간단한 기능을 구현하기 위해서도 여러 서비스에서 작업을 해야하는 경우가 많기 때문에 간단한 기능을 위해 많은 팀의 협업이 필요하다. 만약 자신이 담당하고 있는 서비스의 배포를 위해 다른 팀에서 소유하고 있는 서비스의 데이터 모델을 수정하게 되면 서비스의 소유권이 모놀로식 구조처럼 없어지게 되어 결국 네트워크로 통신하는 모놀로식 구조가 될 수 있기 때문에 주의해야 한다.
위의 그림을 확인해보면 우버에서도 처음 MSA를 도입하였을 때 서비스의 소유권을 확실하게 하지 않아서 간단한 통합을 위해 10개의 서비스가 수정되어야 하는 상황이 발생하였다. 이러한 상황때문에 개발 생산성은 낮아지고 서비스 소유자가 명확해지지 않았으며 더 고통스러운 마이그레이션이 발생하게 된다.
DOMA(Domain-Oriented Microservice Architecture)
마이크로서비스를 I/O 바운드 라이브러리로, “마이크로서비스 아키텍처”를 대규모 분산 애플리케이션으로 생각할 수 있다면 잘 이해된 아키텍처를 사용하여 코드를 구성할 수 있다.
DOMA는 Domain-Driven Design, Clean Architecture, Service-Oriented Architecture와 같이 코드를 구성하는 방법에서 파생된다. 우버는 DOMA를 “대규모 조직의 대규모 분산 시스템에서 확립된 설계 원칙을 활용하는 비교적 새로운 방법인 경우에만 혁신적이라고 생각한다.”라고 얘기하고 있다.
DOMA와 관련된 핵심 원칙 및 용어는 아래와 같다.
- 단일 마이크로서비스를 지향하는 대신 관련된 마이크로서비스 모음을 지향하며 이러한 도메인을 호출한다.
- 레이어라고 부르는 도메인 컬렉션을 추가로 생성한다. 도메인이 속한 계층은 해당 도메인 내의 마이크로서비스가 수행할 수 있는 종속성을 설정하고 이것을 레이어 디자인이라고 부른다.
- 컬렉션에 대한 단일 진입점으로 취급하는 도메인에 대한 깨끗한 인터페이스를 제공하고 게이트웨이를 호출한다.
- 마지막으로 각 도메인은 다른 도메인에 대해 불가지론적(어떤 대상에 대해서 그 진위나 실존의 여부를 현재로서는 알 수 없다고 보는 철학적 관점)이어야 한다. 종종 다른 팀의 도메인에 논리를 포함해야 하므로 도메인 내에서 잘 정의된 확장 지점을 지원하는 확장 아키텍처를 제공한다.
정리하면, DOMA는 체계적인 아키텍처, 도메인 게이트웨이 및 미리 정의된 확장점을 제공함으로써 마이크로서비스 아키텍처를 복잡한 것에서 이해 가능한 것으로, 즉 유연하고 재사용 가능하며 계층화된 구성요서의 구조화된 집합으로 변환하려고 한다.
지금까지 우버가 MSA를 도입하면서 어떠한 문제를 겪었고 이러한 문제를 해결하기 위한 새로운 개념인 DOMA에 대해서 알아보았다. 다음 장에서는 우버가 어떠한 방식으로 DOMA를 도입하였는지에 대해서 알아보도록 한다.
참고한 자료
'Infrastructure > Microservice' 카테고리의 다른 글
| [MSA] DOMA 구현 (0) | 2022.09.23 |
|---|---|
| [MSA] Communication (0) | 2022.09.22 |
