MSA
오늘날 대규모 서비스를 구축하고 운영하는 기업들은 점점 더 마이크로서비스 아키텍처, Microservice Architecture, MSA를 선택하고 있다. MSA는 무엇이고, 왜 쓰고, 장 단점이 무엇인지 알아보자
정의
MSA는 하나의 거대한 어플리케이션을 여러 단위로 나눈 독립적인 서비스들의 집합으로 구성된 아키텍처다. 각 서비스는 특정한 도메인 기능만을 담당하며, 독립적으로 개발, 배포, 확장할 수 있기 때문이다.
MSA는 기능별로 서비스들을 분리하여 각각의 독립적인 단위로 구성하는 구조다. 각각의 서비스들을 분리하여 별도의 저장소, 배포 주기, 실행 환경을 가지며 다른 서비스들과 API, 메시지 큐 등을 통해 통신한다.
모놀리식 아키텍처
MSA의 반대는 모놀리식 아키텍처, Monolithic Architecture는 전통적인 시스템 구조로, 하나의 큰 애플리케이션 안에 모든 기능이 포함된 형태를 의미한다. 하나의 코드베이스, 하나의 배포 단위로 구성되어 처음 구축하거나 단순한 서비스에는 유리하다. 하지만 시스템이 커질수록 변경이 어려워지고, 장애 영향 범위가 커진다는 단점을 갖는다.
차이
| 모놀리식 | MSA | |
|---|---|---|
| 구성방식 | 하나의 큰 Application | 여러 개의 작은 독립 서비스 |
| 개발/배포 | 전체 빌드/배포 필요 | 각 서비스 별도 배포 가능 |
| 장애 영향 | 전체 시스템에 영향 | 일부 서비스만 영향 받음 |
| 확장성 | 전체를 스케일 아웃 | 필요한 서비스만 확장 |
| 기술 스택 | 통일 필요 | 서비스마다 달리 선택 |
MSA 중요 특징
MSA는 단순히 서비스를 나눈다는 개념을 넘어, 개발 방식, 조직 운영, 인프라 설계 전반에 영향을 미치는 철학적 접근이다.
- 서비스 단위 분리
- 기능별로 서비스를 분리함으로써, 각 서비스는 하나의 도메인만 집중하도록 설계한다.
- 코드 복잡도를 줄이고 유지보수가 단순해진다.
- 독립적 배포 가능
- MSA는 자체적으로 배포되게 때문에 하나의 서비스 수정이나 배포가 다른 서비스에 영향이 없음
- 장애 격리와 빠른 릴리즈에 유리
- 다양한 기술 스택 허용
- 서비스 간 결합성이 낮아 언어나 프레임워크를 자유롭게 선택이 가능
- 운영 복잡도가 그만큼 증가
- 개발 속도 향상
- 서비스에 집중하며 병렬 개발이 가능하기 때문에 개발 속도 향상
- CI/CD 환경과 잘 결합되면 릴리즈 주기가 짧아짐
- 조직 구조와 정렬
- 조직의 구조가 소프트웨어 구조에 영향을 미침
- 팀 단위로 명확하게 서비스 책임을 나눌 수 있음
장점과 단점
확장성과 유연성이 좋아 많이 선택하는 MSA 또한 장단점을 가지고 있다.
| 장점 | |
|---|---|
| 유연한 확장성 | - 자주 호출되거나 부하가 높은 서비스만 개별적으로 확장 가능 - 리소스 효율적 사용 |
| 빠른 배포 주기 | - 전체 시스템을 멈추지 않고 각 서비스 부분 배포 가능 - 배포 속도와 유연성 상승 |
| 복원력 향상 | - 하나의 서비스에 장애가 발생해도 전체 시스템 영향 없음 - 빠른 장애 복구가 가능하다. |
| 도메인 주도 설계와 궁합 | - 각 서비스가 특정 도메인에만 집중 - DDD(도메인 주도 설계)와 잘 어울림 |
| 단점 | |
|---|---|
| 분산 시스템 복잡도 증가 | - 통신, 인증, 데이터 일관성 문제 등 복잡한 시스템 설계 필요 |
| 서비스 간 통신 부담 | - REST, gRPC, kafka등 다양한 통신 수단 조합 필요 - 장애시 재시도 및 보상 트랜잭션 설계 필요 |
| 트랜잭션 관리 어려움 | - 전통적인 단일 트랜잭션 처리가 어려움 - 분산 트랜잭션이나 SAGA 패턴 고려 필요 |
| DevOps 요구 증가 | - 서비스 수가 많아질수록 배포, 로깅, 모니터링 등 운영 자동화 역량 요구 |
| 초기 설계 비용 상승 | - 명확한 도메인 정의와 서비스 분리를 위한 아키텍처 설계 시간 많이 소요 |
MSA 선택 기준
MSA는 모든 프로젝트에 적합한 만능 구조가 아니다. 오히려 지나치게 일찍 도입하거나, 팀의 역량, 조직 구조에 맞지 않게 적용하면 오히려 유지보수 혹은 배포에 어려움을 겪을 수 있다. 따라서 MSA를 도입하기 전에는 아래와 같이 조건을 충족하는지 신중하게 따져봐야 한다.
| 조건 | |
|---|---|
| 시스템 규모가 크다 | 하나의 애플리케이션에 수~백개 기능이 얽혀 있고, 개발자 수가 많아질수록 마이크로서비스의 분리가 큰 효과를 발휘한다. |
| 독립 배포가 자주 필요하다 | 일부 기능만 수정하고 빠르게 배포해야 할 때, 전체 시스템을 재배포 하지 않아도 되는 구조가 유리하다. |
| 도메인이 명확히 구분된다. | 사용자, 결제, 상품, 배송 등과 같이 서비스 간의 경계가 뚜렷할수록 마이크로서비스화하기에 적합하다. |
| 팀이 분산되어 있는 경우 | 여러 팀이 독립적으로 서비스 개발과 운영을 담당하는 경우, 조직 구조에 맞춰 서비스 분리를 한다면 생산성과 책임이 명확해 진다. |
결론
MSA는 기술적 트렌드가 아니라, 조직, 시스템, 도메인을 바라보는 관점의 변화다. 도입 시에는 단순히 나눈다가 아닌 “왜 나누는지”, “어떻게 연결할지”, “실패에 어떻게 대응할지”에 대한 깊은 고민이 필요하다. 궁극적으로는 빠른 변화 대응, 안정적인 확장, 팀 간 자율성을 추구하는 조직에 가장 적합하니, 잘 고민하고 채택해야 된다.