MSA(Micro Service Architecture) 서비스 사이즈에 대한 고찰

최근 public cloud 가 흥하고 EKS 같은 container orchestration 서비스가 PaaS 환경으로 서비스 되면서 너도나도 MSA 를 부르짓는다.

AWS 같은 cloud platform 업자들은 마케팅 측면에서 매출을 올릴수 있는 좋은 기회를 잡은듯 하고 전산기획업무 담당자들은 이참에 MSA 라는 것을 사용하여 시스템을 개발 또는 개선 하려고 예산을 올리는 좋은 기회를 잡은듯 하다.

문제는 실제로 해당 업무를 직접 수행해야 하는 개발자 또는 설계자들은 도대체 MSA 가 뭔지 아무도 명확하게 설명해 주지 않으면서 무작정 하라고 하니 거부감이 들수 밖에 없다.

쉽게 접근해 보자. MSA 는 풀어서 얘기하면 "마이크로 서비스를 위한 아키텍처" 이다. 여기서 중요한 키워드 두개는 마이크로서비스와 아키텍처 이다.

1. 마이크로서비스란, 말 그대로 작게 쪼개진 서비스를 얘기한다. 가끔 MSA 를 한다고 하면서 자신들이 생각하는 마이크로서비스는 그렇게 작지 않은 중간정도 규모라는 정신 나간 사이비들이 있는데, 그건 말 그대로 미디엄서비스 이지 마이크로서비스가 아니다.

마이크로서비스는 말 그대로 가능한 작게 쪼갠 서비스이다. 그럼 왜 쪼개는가? 그 해답은 두번째 키워드인 아키텍처에 있다.

2. 아키텍처란, 쉽게 얘기하면 품질속성 - 성능, 보안, 가변성, 확장성, 유지보수성, 사용성 등 을 의미한다.

 

구글검색을 예로 들어 보자.

구글의 검색 기능은 단순히 검색 기능만 제공한다. 순수한 Function Point 측면에서 보면 정말 간단한 기능이고 별로 설명할 것도 없다.

하지만 아키텍처의 측면에서 구글검색은 엄청난 성능, 보안, 확장성, 연결성, 가변성 등을 요구한다.

즉, "서비스는 마이크로 한데 아키텍처가 일반적이지 않은 넘사벽이다." 여기서 MSA 의 범위가 구분된다.

 

쇼핑몰 시스템을 신규로 개발한다고 하자. 평상시에 상품검색, 상품등록, 상품정보수정, 배송조회, 결제 등은 굳이 별도의 아키텍처로 나눌 필요는 없다. 하나의 아키텍처 범위로 묶어서 개발하면 된다.

하지만 해당 쇼핑몰은 1년에 한번 블랙프라이데이 같은 행사를 하고 이때 트래픽은 평소의 100배를 가볍게 넘긴다고 하면 이 행사 시점의 아키텍처는 평소와는 완전히 다른 아키텍처를 가져야만 한다. 특히, 상품검색은 특히 많은 부하를 받을 것이고 높은 성능을 요구받을 것이다.

그렇다면 해당 시점에 상품검색만 MSA 로 분리해서 별도로 운영할 수 있게 하는 방법을 고려해 볼수 있다. (보통 이러한 디자인 패턴을 CQRS 패턴이라 한다.)

결국, MSA 는 아키텍처 성질이 다른 서비스를 분리하는 기법이고, 이러한 서비스를 분리할 때 가능한 작게 분리(크게 분리하면 그냥 두개의 별도 시스템이 만들어진다) 하는 것을 의미한다.

또한 응용하자면 MSA + Non-MSA 시스템을 동시에 아키텍처링 할수도 있게 된다. 즉, MSA를 한다고 모든 서비스들을 다 작게 쪼개서 아키텍처를 분리해야 되는 것도 아니다.

결과적으로 MSA 에 너무 스트레스 받지 말자. 이벤트나 행사시점에 전체 시스템 용량을 다 늘려서 서버를 늘리고 대역폭을 늘리고 하지 말고 필요한 기능들 몇개만 쪼개서 확장성과 가변성 높은 시스템을 만들 수 있다면 MSA 를 적용했다고 말할 수 있다.

좀 더 MSA 범위산정에 대한 이론적인 지식이 필요하다면 DDD(Domain Driven Design) 도서를 참고하여 Contenxt Boundary 에 대한 고민을 해보는 것을 추천한다.