개요
개발을 함에 있어 MSA라는 용어를 한번씩은 들어봤을 것 입니다. 이번 포스팅에서는 MSA가 무엇이고, 왜 많은 기업들이 해당 아키텍처를 사용하고 있으며 어떠한 장,단점이 있는지 알아보도록 하겠습니다.
MSA란?
- Micro Service Architecture의 약자로, 여러 서비스의 집합체라고 이해하시면 됩니다.
- 도메인 별로 서비스들을 독립적으로 나누어 아키텍처를 구성하는 방식입니다.
- 서비스 별로 endpoint를 api 형태로 외부에 노출하고, 실질적인 구현은 모두 추상화 하는 방식
- 실질적인 구현은 모두 추상화하고, api 형태로만 통신하므로 각 서비스별로 다른 기술을 사용해도 된다.
MSA 구조를 구축하는 이유
대규모 시스템을 가진 많은 기업들이 MSA를 도입하려는 이유는 아래와 같다고 생각합니다.
기존에는 Monolithic Architecture였다.
- 많은 기업의 시스템은 규모가 크지 않다면 소프트웨어의 모든 구성요소가 한 프로젝트에 담겨 있는 형태입니다.
(저희 회사의 관리자 시스템만 해도 빌드 하는데 1분 30초 정도가 걸리니 ㅎㅎ..) - 이렇게 모든 기능이 한 프로젝트에 구성되어 있는 구조인 모놀리식은 규모가 커짐에 따라 아래와 같은 한계가 발생합니다.
- 서비스의 일부 장애가 전체 서비스의 장애로 확대될 수 있음
- 전체 시스템 구조 파악이 쉽지 않음
- 서비스 변경이 어렵고, 수정 시 사이드 이펙트 파악이 힘들 수 있음.
- 빌드 시간 및 테스트, 배포 시간 급증
- 서비스의 특정 부분만 스케일 아웃하기 어려움.
"역할 별로 서비스를 나눔으로써 위와 같은 한계점을 극복하기 위해" MSA가 등장하게 된 것 입니다.
MSA의 장점
- 배포
- 서비스 별 개별 배포가 가능하다.
- 특정 서비스의 요구사항만을 반영하여, 빠르게 배포가 가능하다.
- 확장
- 특정 서비스에 대한 스케일 아웃이 유리하다.
- 장애
- 일부 장애가 전체 서비스로 확장될 가능성이 적다.
- 부분적으로 발생하는 장애에 대한 격리가 훨씬 수월하다.
- etc
- 새로운 기술을 적용하기 유연하다. (특정 서비스만 다른 기술, 언어로 구현 가능)
- 각 서비스에 대한 구조 파악 및 분석이 모놀리식 구조에 비해 쉽다.
단점
- 트랜잭션 및 테스트 관리
-
모놀리식 아키텍처는 단일 트랜잭션을 유지하면 되지만, MSA 구조에서는 각 서비스별로 데이터베이스가 나누어 지기 때문에 하나의 트랜잭션으로 묶기가 어렵다.
-
예를 들어, 게시글 작성 시 게시글 테이블 뿐 아니라, 회원의 정보를 가져오기 위해 회원 테이블을 조회하는 상황일 때, 모놀리식 아키텍처는 하나의 DB에 회원, 게시글 테이블이 존재하기에 하나의 트랜잭션으로 묶을 수 있다.
-
그러나, MSA 구조는 회원 도메인, 게시글 도메인 별로 DB가 나뉘어 지기 때문에 일반적으로 하나의 트랜잭션으로 묶기 어렵다.
-
이러한 문제를 해결하기 위한 패턴은 2PC(Two-Phase Commit), Saga 패턴이 존재한다.
-
또한, 통합 테스트가 어렵고 개발 환경과 운영 환경을 동일하게 가져가는 것이 쉽지 않습니다.
- 성능
- 내부 혹은 외부 서비스 간 API를 호출하는 방식으로 통신하므로, 통신 비용이나 Latency에 대한 이슈가 존재할 수 있다.
- 데이터 관리
- 여러 서비스에 데이터가 분산되어 있어 데이터를 조회 및 관리가 어렵다.
생각 정리
-
시스템의 규모가 커짐에 따라 MSA를 도입하는 것은 필연적이라고 생각합니다.
-
그러나 서비스의 역할별로 구조를 분리하여 전체 시스템을 구축하는 것이기에 새로운 인력이나 시스템 구조를 완벽하게 파악하지 못한 사람들의 관점에서는 운영 포인트가 늘어날 수도 있다고 생각합니다.
-
분리된 서비스를 담당하는 팀을 각각 구성할 수 있는 정도의 기업이라면 MSA 도입을 고려하는 것이 충분히 좋은 방안이라고 생각합니다.
-
결국, 모든것은 역시 TRADE-OFF 라고 생각합니다.
-
시스템의 규모가 적당히 크지 않다면 모놀리식이, 규모가 대규모라면 MSA 도입하는 것이 충분히 좋은 방안이라고 생각합니다.
