Miniservices : MSA에 대한 현실적 대안

마이크로 서비스가 현재 프로덕트를 만들때 가장 인기 있는 트렌드 중 하나라는데 이견이 없습니다. 하지만 모든 상황에서 마이크로 서비스가 적합한지에 대해서는 의문이 듭니다.

제가 블로그에 그동안 많이 언급했던 마이크로 서비스 아키텍처에 대해 마틴 파울러는 다음의 조건을 충족해야 한다고 언급합니다.

하지만, 현실은 만만치 않습니다. Legacy가 있는 경우에는 더욱 그렇습니다.

오늘 소개하려고 하는 미니 서비스는 “마이크로 서비스 그룹이 작은 패턴으로 모인 것”과 같습니다.

위의 그림에 미니 서비스가 중간에 위치한 것을 알 수 있습니다. 흔히들 모놀리스는 레거시라고 하며, 마이크로 서비스는 복잡하고 어렵다라고 합니다.

미니서비스 아키텍처는 여러 책임과 공유 데이터 저장소가 있는 아키텍처입니다. 서비스와 구현 세부 정보가 완전히 분리된 마이크로서비스와 달리 미니서비스는 라이브러리와 데이터베이스를 공유할 수 있습니다.

미니서비스 아키텍처 특징

관련 서비스는 동일한 데이터베이스를 공유할 수 있습니다.
- 서로 관련된 모듈이 데이터베이스를 공유할 수 있습니다. 예를 들어서 미니서비스는 이미지 처리, 이미지 렌더링 또는 애플리케이션에 대한 기타 관련 기능을 포함한 여러 기능을 수행할 수 있습니다.
서비스 간 통신은 REST API를 통해 이루어집니다.
관련 서비스는 배포에 사용되는 코드베이스 및 인프라를 공유할 수 있습니다.

미니서비스는 확장성, 내결함성 및 견고성을 포함한 마이크로서비스 아키텍처의 모든 이점을 상속합니다.

종단간 테스트는 단일 서비스와 관련된 종속 항목 수로 인해 미니서비스에서는 어려울 수 있습니다. 그렇기에 효율적인 오류 처리 관련하여 복잡성을 증가 시킬 수 있습니다.

미니서비스는 데이터 저장 및 인프라 공유를 허용한다는 점에서 마이크로서비스와 다릅니다. 미니서비스는 마이크로서비스에 대한 보다 실용적인 접근 방식으로 꾸준히 추진력을 얻고 있습니다.

각 아키텍처별로 장점과 한계가 존재하기에 아키텍처를 선택전 철저하게 분석 및 조사를 하는 것이 중요합니다.

이런 상황에서 우리가 행복해지는 무엇일까요? 다음은 레거시가 존재하는 상황에서 미니서비스 아키텍처를 선택해야 하는 이유입니다.

미니서비스는 재사용 가능한 코드를 생성하기가 수월합니다. 미니서비스는 프로젝트가 제공해야 하는 모든 도메인간 기능에 쉽게 접근할 수 있도록 합니다. Shared 방식을 활용하기에 모든 서비스가 항상 최신 버전의 기능을 참조합니다. copy-past 코드가 없습니다.

기존 모놀리스는 경량화하는데 초점을 두고 있기에 우리가 구축하는 애플리케이션의 아키텍처를 관리하는데 이보다 좋은 방법은 없습니다.

애플리케이션 아키텍처는 코드 표준을 생각하고, 구성하고, 적용하는 프로세스로 진행됩니다. 아래의 다이어그램은 다계층 코드 구조를 보여줍니다. domain1은 추가 기능을 위해 domain2의 컨트롤러를 호출합니다.

미니서비스를 올바르게 수행하려면, 합당한 경우에만 커플링을 식별해야 합니다.

모든 서비스는 애플리케이션 수준에서 “결합”됩니다. 마이크로서비스처럼 도메인 사이를 이동시 네트워크 트래픽을 걱정할 필요가 없습니다. 아키텍처 구조에 스며들었던 대기열도 발생하지 않습니다.

각 미니서비스를 독립적으로 배포하여 탄력적으로 만들 수 도 있지만, 그것이 필요한것인지 고민할 필요가 있습니다.

단일 프로젝트 또는 도메인에 대한 모든 미니서비스를 로컬에서 쉽게 실행 할 수 있습니다. 로그는 쉽게 통합되고 캡쳐되기에 기본적인 디버깅을 수월하게 할 수 있습니다.

Network Hop이 적을 수록 대기 시간이 줄어들며, 성능이 향상됩니다. 미니서비스는 코드 기반으로 미니서비스간 통신을 허락하거나 혹은 네트워크를 통해 통신을 하도록 선택할 수 있습니다. 어느 방식을 선택하던 런타임을 줄일 수 있는 옵션이 존재합니다.

각 마이크로서비스별 별도의 데이터베이스를 두는 것이 효율적일지 고민해봐야할 문제입니다. 데이터베이스를 중앙 집중화해도 문제가 없다면, 이렇게 진행하는 것도 방법입니다.

이렇게 하게 될 경우에는 코딩 표준, 원칙, 좋은 코드 작성이 핵심입니다.

“미니”의 기본 목표와 원칙은 필요한 비즈니스 로직의 양을 최소화 하지만, 분리되는 형태의 아키텍처에 충실하다는 것입니다. 또한 코드를 쉽게 재사용할 수 있는 기능이 제공됩니다.

미니서비스를 올바르게 수행하려면, 합당한 경우에만 커플링을 식별해야 합니다.

마이크로서비스와 미니서비스는 분리될 수 있습니다. 미니서비스로 구축하고 진행하다가 특정 서비스의 경우 마이크로서비스로 분리가 가능합니다. 이미 앞써서 코드 표준을 지켰기에., 미니서비스와 연동에 대한 부분만 네트워크 접근 방식으로 변경하면 됩니다.

미니서비스는 대부분의 서비스가 매우 느슨하게 결합되는 경향이 있는 애플리케이션에 적합합니다. 마이크로서비스가 원하는 아키텍처라고 해도 미니서비스로 시작하는 것이 프로젝트를 위한 더 나은 출발점이 될 수 있습니다.

자, 우리팀은 어떤 선택을 할까요? 정리되면 공유하도록 하겠습니다.

References: