[MSA]Microservice Architecture(MSA) 튜토리얼

MSA란 정확하게 정의된 어휘는 아니지만 대략 서비스를 잘게 쪼개 여러 가지 이득을 노리는 구조이다.

 

반대말까진 아니지만 비교되는 구조로 모놀리식 아키텍처(Monolithic Architecture)가 있으며

 

최근 스타트업의 기술블로그를 구경하면 모놀리식에서 MSA로 전환한다는 말이 많이 보인다.

 

이 글에서는 두 아키텍처의 간단한 비교와 장단점에 대해서 알아보자.

 

Monolithic Architecture

 

모놀리식 아키텍처는 이름 그대로 하나의 구조에 모든 서비스가 포함된 구조를 가리킨다.

 

크고 아름다운 하나의 구조 안에 모든 서비스가 들어있기 때문에 비교적 단순하며, 이에 따른 장단점은 아래와 같다.

 

• 장점
  
  
  • 단순한 구조를 가지고 있기 때문에 개발 난이도가 낮고 속도가 빠르다. 
  • 하나의 통합된 DB를 가지기 때문에 데이터 무결성과 정합성 관리가 쉽다.
  • 같은 이유로 서비스간 통신 비용, 트랜잭션의 복잡도와 테스트 난이도가 낮다.
  • 역시 같은 이유로 배포와 부하 분산 처리가 간단하다.
  • 종합하면 초기 개발과 유지보수에 비용이 상대적으로 적게 소모된다.
• 단점
  
  • 서비스 간 결합이 강한 데다 단일 구조이기 때문에 규모가 커질수록 관계가 복잡하게 꼬인다.
  • 따라서 작은 부분의 장애가 서비스 전체의 장애를 일으킬 가능성이 커진다.
  • 작은 변경사항에도 서비스 전체를 재배포해야 하기 때문에 시간 비용이 커진다.
  • 부하 분산 처리가 간단하지만 원하지 않는 부분의 부하도 함께 분산처리 돼 역시 비용이 커진다.
  • 초기에 정해진 언어나 기술스택이 강제된다.
  • 종합하면 프로젝트의 기간과 규모가 커질수록 개발 및 유지보수 비용이 증가하게 된다.

 

Microservice Architecture

 

MSA는 각 서비스가 독립적으로 기능 및 배포가 가능한 구조를 가리킨다.

 

쉽게 말하면 하나의 큰 모놀리식 아키텍처를 여러 개의 작은 모놀리식 아키텍처로 쪼갠 뒤

 

외부와의 통신은 API Gateway로, 서비스 간 소통은 REST API, 혹은 메시지 큐를 이용하는 구조라고 할 수 있다.

 

Message Queue(MQ) - 일종의 통신방법. 분산된 시스템에서 데이터 동기화를 보장한다.

API Gateway - 사용자와 서버 사이의 엔드포인트.
                          서비스 엔드포인트를 하나로 묶어주고 인증 및 권한부여, 라우팅 등을 책임진다.

 

위와 같은 구조를 바탕으로 MSA는 아래와 같은 장단점이 존재한다.

 

• 장점
  
  
  • 작은 프로젝트 여러 개로 나뉘기 때문에 코드 가독성이 좋다. 따라서 유지보수가 쉽다.
  • 서비스 간의 관계는 정해진 통신을 제외하면 존재하지 않아 결합도가 약하다. 부분의 문제가 전체의 문제가 될 확률이 적다.
  • 서비스 단위로 개발, 테스트, 배포가 진행되기 때문에 배포게 소요되는 비용이 적어진다.
  • 원하는 서비스의 스케일만 키울 수 있다. 즉 원하는 부분의 부하만 분산할 수 있다.
  • 서비스 간 결합도가 낮아 새로운 서비스에 원하는 언어나 기술스택을 적용할 수 있다.
  • 종합하면 프로젝트가 커지고 길어질수록 유지보수와 배포에 강점을 보인다.
• 단점
  
  
  • 복잡한 구조 덕택에 초기 개발 난이도가 높고 속도가 느리다. 즉, 초기 개발 비용이 높다.
  • 서비스에 따라 DB 역시 분산되므로 데이터의 정합성 관리가 어렵다.
  • 서비스 간 결합도가 낮고 독립적이기 때문에 통신비용이 발생하고, 이는 트랜잭션 비용의 증가로 이어진다.
  • 단위 테스트는 쉽지만 통합 테스트의 비용이 크다.
  • 종합하면 초기 개발과 테스트에 소모되는 비용이 크다고 할 수 있다.

 

Summary

 

많은 기업들이 유행처럼 MSA를 도입하고 있지만, 그것이 만능을 의미하는 것은 아님을 알았다.

 

공부하면서 논문을 두어 개 주워서 읽었는데, 거기서도 MSA로의 전환은 성능을 위한 것이 아님을 명확히 하고 있었다.

 

WebFlux와 마찬가지로 현재 잘 돌아가고 특별히 확장을 해야 할 상황이 아니라면 무리해서 도입할 필요까지는 없는 듯.

 

더구나 돈과 시간이 모두 부족한 스타트업에서 처음부터 MSA로 설계를 시작했다간

 

서비스가 배포되기도 전에 준비된 돈과 시간이 다 떨어질 수도 있으니 조심해야 할 것 같다.

 

검색하면서 읽은 많은 의견도 처음엔 일단 모놀리식으로 빠르게 개발 및 배포하고

 

상황에 따라 MSA로 전환할 것을 추천하고 있었다.

 

개인적으로 MSA를 사용한 토이 프로젝트를 진행해보고 싶지만...

 

일단 하는 것부터 제대로 하기로.

 

시간이 나면 이번 글에 이어서 MSA의 실전이란 어떤 것인가 정리해보고 싶다.

 

MSA 튜토리얼, 끝!