마이크로서비스 아키텍처의 기준과 DB 분리

개요

최근 3년 사이 마이크로서비스 아키텍처의 급격한 유행에 따라 많은 프로젝트에서 MSA로의 전환을 시도하고 있으며, 성공적으로 전환한 케이스가 있는 반면, 실패한 경우도 종종 발생하고 있다. 포스팅의 시작점에서 우리가 말하는 성공적인 마이크로서비스 전환 사례란 무엇인지에 대해 알아보도록 하자.

마이크로서비스 아키텍처의 성공기준

• RESTFul API가 적용된 프로젝트
• 독립적인 배포가 가능하도록 결합도를 낮춘 프로젝트
• 클라우드가 적용된 확장성, 가용성이 확보된 프로젝트
• 자동화된 배포 체계가 갖추어진 프로젝트
• DevOps 조직 체계를 적용한 프로젝트
• ......

마이크로서비스로의 전환이 진행중인 또는 완료된 프로젝트 사례들을 살펴보면 위와 같은 공통의 목표를 달성해 내고자 했을 것이다.
다만, 이와 같은 기술 지향적 목표 수립만으로는 MSA 프로젝트를 온전히 성공해 낼수는 없으며, 성공적으로 전환하기 위해서는 다음과 같은 기준을 수립하는 것이 중요하다.
"마이크로서비스 아키텍처는 그간 IT를 이끌어온 아키텍처 사상들의 Pain Point들을 수집하고 이를 어떻게 해소해 낼 것인가에 집중한 아키텍처 사상이며, 고객의 니즈를 신속하게 적용하기 위해 여러 기술셋들을 선택적으로 적용한 아키텍처이다. 성공적으로 전환한 프로젝트는 바로 이를 달성한 프로젝트라 할 수 있다."
중요한 점은 마이크로서비스 아키텍처는 기술셋에 의존된 설계 방식이 아닌 반대로 목표를 수립하고 달성하기 위해 기술셋을 선택하는 방식으로 접근해야 한다는 것이다. 이와 같은 접근 방식이 있어야 다양한 오픈소스 소프트웨어의 적용여부를 검토하고 프로젝트에 적합한 개발방식 등을 선택해 낼 수 있을 것이다.
특히 수많은 기술셋과 오픈소스를 선택해 나가는 과정에서 DB의 선택과 분리는 독립배포, 결합도 약화, 장애 차단 등 여러 측면에서 프로젝트 성공여부를 결정할 수 있는 핵심 고려사항이라 할 수 있다.

MSA와 DB 분리 기준

"마이크로서비스 아키텍처를 적용하기 위해서는 서비스 별로 DB를 반드시 쪼개야 하나?"
마이크로서비스에서 데이터가 갖는 의미는 굉장히 크다. 사실상 MSA의 성공 여부를 판단하는 기준이 데이터에 달려 있다고 해도 과언이 아니다. 대부분의 MSA 개발 방법들은 데이터 처리에 관련이 있으며, 데이터의 분할 방식에 따라 영향도가 커질 수도 작아 질수도 있다.
기존 모놀리식 어플리케이션이 마이크로서비스로 변화하는 과정에서 어플리케이션은 화면, 백엔드, 데이터로 세분화 된다. 대체로 MVC 구조에 익숙한 모놀리식 어플리케이션과 다르게 View 영역이 하나의 마이크로서비스로 분리되며, Persistent 영역은 마이크로서비스 별 독립된 데이터베이스로 구성된다. 때로는 화면에서 직접 조회가 가능한 데이터베이스도 존재한다.

모놀리식 어플리케이션에서 마이크로서비스 아키텍처로의 전환은 BIG BANG 방식으로 전환하는 TOP DOWN 방식을 여전히 선호하는 것이 국내 프로젝트의 실정이지만, 아키텍처 사상의 변화는 커버넌스 측면은 물론 어플리케이션의 구조적인 변화가 크게 발생하기 때문에 옳바른 전환 방식이라 할 수 없다.
리스크를 최소화하며 마이크로서비스로 전환해 나가기위해서는 백엔드 → 데이터베이스(데이터) → 프론트엔드 순으로 점진적인 변화를 가져가는 것이 효과적이다.
먼저 백엔드 어플리케이션을 마이크로서비스로 전환하는 과정에 대해 간단히 살펴보자.
"아키텍트는 서비스 단위를 결정하기 위해 Bounded Context를 적용하여 서비스 범위를 정의하고, 그 기준에 따라 서비스가 결정되면, 서비스간 인터페이스 방식을 결정하며, 인터페이스를 위한 기술셋을 선택한다. 개발자는 API를 식별하고, 인터페이스에 필요한 기술요소들을 활용하여 개발한다."
이때 마이크로서비스 전환이 시작되는 시점부터 반드시 데이터베이스를 분리해야 하는가? 라는 질문이 있을 수 있다. 결론부터 말하자면 반드시 초기부터 데이터를 구분할 필요는 없다. 물론 장기적인 관점에서 바라보았을때, 점진적 이행이 가능한 형태로 데이터베이스를 분리해 나가는 것은 중요하지만, 초기 마이크로서비스 아키텍처를 적용하여 프로젝트를 시작하는 시점에서 데이터베이스를 분리하는 것은 위험도가 굉장히 높아 질뿐 아니라, 프로젝트 실패시 부담해야할 리스크 역시 커질 수 있다.
MSA 방법론, 모델링, 분석/설계, 개발, 테스트, 이행을 거치며, 마이크로서비스의 단위는 유동적으로 변화할 수 있다. 어플리케이션 영역(화면, 백엔드)에서는 변화에 따라 대응 개발하기 용이하지만, 데이터의 재배치, 테이블의 재설계는 어플리케이션 전체에 영향을 끼칠 수 있는 영역으로 재설계가 용이하지 않고 데이터의 변화에 따라 어플리케이션 구조 변화에 큰 영향을 주게된다. 따라서 Persistent의 경우 백엔드 서비스의 전환이 완료되거나, 안정화 된 이후에 설계하는 것이 좋고, 특히나 빅뱅방식의 전환은 지양해야 한다.

MSA로의 전환을 이야기할때, MINISERVICE가 함께 등장하는 이유 역시 이와 같으며, 성공적인 전환을 위해 프로젝트는 장기간 점진적인 변화 구조를 가져가는 것이 무엇보다 중요하다.
지금부터는 본격적으로 DB가 분리된 마이크로서비스와 서비스만 분리된 마이크로서비스 간의 차이점을 알아보고, 점진적이행을 위해 고려되어야 할 부분에 대해 알아보도록 하자.

아키텍처의 변화

제일 먼저 살펴보아야 할 부분은 바로 아키텍처의 변화 측면이다. 데이터베이스의 분리는 인프라 아키텍처, 어플리케이션 아키텍처 측면에서 커다란 변화를 불러일으킨다. 이를 하나씩 살펴보도록 하자.

인프라 아키텍처

인프라 아키텍처 측면에서 가장 고려되어야 할 부분은 바로 구조의 변화 측면이다.

각 마이크로서비스 별로 독립적인 데이터베이스를 구성할 경우 아래와 같은 사항에 주의해야 한다.

• 비용 : 데이터베이스의 물리적 노드 증가에 따른 비용 증가. 오픈소스 DB를 사용할 경우 구축/운영 인력 증가.
• 성능 : 호출 홉 증가에 따른 성능 저하. 데이터 전송에 따른 성능 저하.
• 인력 : 기술셋 확장에 따른 지원인력 증가.
• 모델링 : 마이크로서비스 인터페이스 모델링, 데이터베이스 모델링(테이블 분할 설계/데이터 오너쉽 정의 등)

어플리케이션 아키텍처

어플리케이션 아키텍처 측면에서 가장 고려해야 할 부분은 바로 서비스 간 데이터의 동기화 측면이다.

각 마이크로서비스 별로 독립적인 데이터베이스를 구성할 경우 아래와 같은 사항에 주의해야 한다.

• 조인쿼리 : 모놀리식 어플리케이션 내 조인쿼리에 대응하기 위한 동기/비동기 처리 호출 설계.
• 트랜잭션관리 : 분산트랜잭션 관리를 위한 이벤트 처리 설계.
• 보상트랜잭션 : 데이터 복구를 위한 Saga 패턴 설계
• API 증가 : 데이터 호출 증가에 따른 API 설계.
• 배치 : 배치 아키텍처 설계를 위한 데이터 통합 방안 설계.

개발의 변화

앞서 정의한 인프라/아키텍처의 변화는 그 지향점을 명확히 파악하고 대체할 수 있다. 물론 비용/시간/일정/인력의 변화를 감수한다면 말이다. 그러나, 개발의 경우 DB의 분리로부터 어떠한 영향이 발생할 것인지 파악하는 것은 굉장히 어려운 일이다.
분석/설계를 진행하며, API 목록을 도출하고, 동기/비동기 서비스로 구분하여 어플리케이션 구조를 개선해야 나가야 한다. 인터페이스의 증가에 따른 비용/일정 그리고 무엇보다 리스크를 감내해야 하고 데이터베이스 분리에 따른 테이블/테이터 설계 측면에서도 고려해야 한다.
무엇보다 단일 데이터베이스의 조인쿼리에 대해 API Composition, CQRS 테이블 생성 특히 보상 트랜잭션에 대한 설계 등은 단순히 개발 본수의 증가만을 이야기 하는 것이 아니라, 개발자가 설계에 참여하여 개발의 방향성을 결정해야 하는 문제들도 당면하게 된다. 물론 DevOps 조직이 갖춰진 플랫폼 기업의 경우 이미 그렇게 진행되고 있겠지만, 대부분의 SI 프로젝트를 발주하는 기업들의 경우 조직의 변화가 갖추어졌을리 만무하다.
또한, 테이블 재설계는 물론 데이터 오너쉽 정의, 배치처리 업무, 서비스 연관도 분할, MSA 비 대상 서비스와의 결합도 약화, 인터페이스 개발, 비즈니스 개선, 프로세스 개선 등 개발에서 확장된 업무들이 개발자의 역할로 부여 받게 된다.
이로 인해 개발자는 정확한 공수 산정 및 개발에 필요한 기술셋, 일정 등을 사전에 파악하기 어려워 무엇보다 개발 PL의 역할이 중요해진다.

결론

마이크로서비스 아키텍처를 설명하는 기술셋에서 DB의 분리는 비즈니스 요건에 따라 명확히 구분하고 접근해야 한다. 무조건 모든 서비스를 분리하는 것은 인프라 측면, 어플리케이션 측면에서 많은 기회비용을 지불해야 하기 때문이다.
비즈니스 요구사항 중 서비스 독립성/확장성이 강조되는 경우 요소 별 투입되는 아키텍처 기반 비용을 감안하여 분리 가능여부를 결정해야 한다. 초기 거론한것 처럼 점진적 이행을 위해 기반 환경을 구성하고 리스크 감소 차원에서 데이터베이스 분리는 서비스 별 점진적으로 확대해 나가는 것이 올바른 방향이라 할 수 있다.
간혹 마이크로서비스 당 하나의 데이터베이스를 반드시 구성해야 한다는 강박관념으로부터 마이크로서비스를 설계하는 경우가 있다. 데이터베이스를 구분하는 것은 단순히 물리적인 공간을 구분하는 것이 아닌 데이터의 정합성, 연속성을 보장하기 위해 많은 노력과 비용이 발생하는 아키텍처 패턴임을 명심해야 한다. 불필요하게 보상 트랜잭션 처리하고, 비동기 서비스를 호출하는 것은 결과적으로 이행/오픈/유지보수 전 과정에 걸쳐 추가적인 Effort를 발생시키는 일임에는 분명한 사실이다.
그럼에도 불구하고 결합도를 낮추고 신속한 배포가 가능하다는 점에서 DB의 분리를 통해 얻을 수 있는 장점 또한 굉장히 크다. DB 분리를 통해 얻을 수 있는 장점과 기회비용을 판단하여 비즈니스 요구사항을 달성하기 위해 점진적인 이행 로드맵을 수립해나감으로써 성공적인 MSA 전환 사례를 만드는것이 무엇보다 중요하다는 점을 기억하고 이번 포스팅을 마치고자 한다.