MSA(Micro Service Architecture) 찍먹

MSA(Micro Service Architecture) 란?

• 모놀리식 아키텍처는 하나의 어플리케이션에 모든 비즈니스 로직이 구현되어 있는 거대한 서비스 덩어리라면, 마이크로서비스 아키텍처는 작고 독립적인 어플리케이션들의 집합으로 구현되어 있는 구조입니다.
• 모놀리식 아키텍처로 구현된 서비스가 점점 거대해지고 서비스 요구 사항이 다양하고 복잡해지면서 하나의 거대한 서비스를 적절하게 쪼개고 분산시켜 마이크로서비스 아키텍처로 나아가는 사례가 많이 있습니다.
• 제가 이번에 하게 된 프로젝트 역시 거대한 레거시 프로젝트를 MSA 아키텍처로 바꿔야 하는데요. 프로젝트에 대한 이해도를 높이고자 모놀리식 아키텍처에 비해 MSA가 갖는 특징은 무엇이며, 모놀리식으로 구현된 아키텍처를 적절하게 쪼개는 것이 무엇을 의미하는지를 알아보고자 합니다.

 

적절하게 어떻게...? 서비스 분리의 기준

• 모놀리식 아키텍처를 따르는 서비스는 보통 MVC 패턴에 기초하여 객체지향 관점에 따라 구현되어있습니다. 각각의 도메인(객체)들이 서로 상호작용하며 얽혀있는 것이며 이러한 거대한 상호작용이 하나의 서비스를 이루고 있는 것입니다.

Bounded-context

• Bounded-context는 비즈니스 도메인별로 나누어 설계하는 방식인 DDD(Doman Driven Design) 에서 나오는 개념입니다.
• context가 특정한 비즈니스 문제 영역이라면 bounded-context는 의미적으로 동일한 context의 범위를 나타낸 것입니다. MSA는 거대한 서비스를 bounded-context 단위로 쪼개어진 아키텍처인 것이죠.

• 쇼핑몰 서비스를 예로 들면, 옷을 구매하는 행위에 대해서 옷의 색상이 무엇인지, 사이즈는 얼마인지 재고가 얼마나 남았는지와 같은 옷 자체에 대한 정보에 집중할 수도 있고 결제가 제대로 진행 되었는지, 포인트가 사용 되었는지 와 같이 결제에 대한 정보에 집중을 할 수도 있을 것입니다.
• 이처럼 사용자는 옷을 구매했지만 바라보는 시각에 따라 데이터에 대한 해석이 달라지는데 이러한 맥락(context)을 구분하는 것이 bounded-context 인 것입니다.
• 위 사례를 MSA 아키텍처에 적용한다면, 옷 자체에 대한 정보를 저장하는 부분과 결제에 대한 부분은 서로 다른 서비스로 보고 구분하여 독립적으로 운영을 하게 되겠죠?!

 

왜 MSA를 도입해야 하는가?

• 기존의 레거시 서비스 잘 돌아가고 있다면 굳이 많은 비용과 수고를 들여서 MSA를 도입해야 할 이유가 있을까요?
• 보통은 어떠한 문제를 해결하기에 모놀리식 아키텍처가 적절하지 않기 때문에 MSA를 도입하는 경우가 많을 것입니다.
• 유명한 도입 사례로는 배달의 민족 서비스가 있는데요!

• 배달의 민족 서비스는 매우 거대하고 복잡해서 각각의 서비스들이 서로 얽혀있었습니다. 때문에 어느 하나의 서비스에 장애가 발생하면 사이드이펙트로 모든 시스템이 중단이 될 수 있는 구조였죠.
• 리뷰 서비스에 장애가 있는데 그것 때문에 주문조차 되지 않는다면 제대로 된 서비스라고 볼 수가 없을 것입니다.

 

MSA 장점

향상된 모듈성

• MSA는 특정 기준으로 서비스들을 분리합니다. 각각의 서비스 모듈들은 독립적으로 운영이 되기 때문에 어느 하나의 서비스에서 장애가 발생한다면 그 장애가 전체 시스템으로 확장될 가능성이 적습니다.
• 또한 각각의 모듈들을 확장하거나 수정하는 등의 유연함도 갖출 수 있죠.

기술 스택의 유연함

• 서비스를 독립적으로 배포하고 서비스간 통신은 API로 하기 때문에 각각의 서비스별로 다른 기술 스택을 적용시킬 수 있습니다.

배포와 유지보수에 유리

• 모놀리식 아키텍처로 구현된 서비스는 어느 한 군데의 변화가 있어도 전체 서비스가 함께 배포되어야 합니다. 그러나 MSA는 독립적이기 때문에 서비스별로 개별 배포가 가능하고 이로 인해 서비스가 중단되지 않을 수 있으며 배포가 가볍기 때문에 요구 사항에 신속하게 대응하기도 유리합니다.

 

MSA 단점

• 그러나 MSA는 유행따라 무조건적으로 도입할 수 있는 것이 아닙니다.
• 디자인 패턴으로 유명한 마틴 파울러는 "모놀리식으로 관리하기에 특별히 복잡한 시스템을 운영할 상황이 아니면 마이크로서비스는 고려할 필요조차 없다" 라고 하기도 하였습니다.

도입의 어려움

• MSA는 도입이 쉬운 아키텍처가 아닙니다. 하나로 뭉쳐진 모놀리식의 DB를 서비스별로 잘 쪼개야 하는데 그 과정이 쉽지 않을뿐더러 그 기준을 세우기도 어렵습니다.

복잡한 운영

• 종류가 다른 서비스가 여기저기 흩어져서 API로 통신을 하는 구조인데, 이런 구조에서는 필연적으로 API 호출이 많아질 수 밖에 없습니다. 이로 인한 통신 비용과 지연 시간을 관리해야 하고 또한 서비스간 데이터의 동기화 문제로 해결해야 합니다.

트랜잭션 유지의 어려움

• 모놀리식 아키텍처에서는 RDBMS가 제공해주는 트랜잭션 기능을 통해 데이터를 일관성 있게 관리할 수가 있는데요. MSA는 DB가 여러 개로 분산되어 있으므로 트랜잭션을 따로 관리해주어야 합니다.

디버깅 및 테스트의 어려움

• 에러가 발생했을 때 어느 시스템에서 장애가 난 것인지 파악해야 하는데 여러 시스템에 걸친 작업을 추적해야 하므로 디버깅이 까다롭고
• 통합 테스트를 할 때 여러 서비스의 API를 검증해야 하므로 복잡성이 늘어날 수 밖에 없습니다.

 

마무리

• MSA를 도입하기 전에 아키텍처를 적용했을 때 비용을 얼마나 절감할 수 있는지, MSA를 도입해야 할 만큼 서비스가 복잡한 것인지, 또한 MSA를 적용할 인프라(기술, 인력 등)가 준비되어 있는지를 고려해보아야 할 것입니다!

 

참고 자료

• 팀드모네 IT 유튜브 채널
• 배달의 민족 마이크로서비스 여행기
• MSA 아키텍처란
• Do Not Use MSA
• DDD의 도메인과 바운디드 컨택스트