요즘 핫이슈로 개발자라면 무조건 알아야 할 개념인 MSA에 적어보고자 한다.
MSA의 등장배경: 모놀리식 아키텍처 (Monolithic Architecture)
- 소프트웨어의 모든 구성 요소가 한 프로젝트에 통합되어있는 형태
- 쉽게 학교에서 프로젝트할 때를 생각하면 됨
- 소규모 프로젝트에서 합리적: 간단한 architecture, 용이한 유지보수
- 쉽게 학교에서 프로젝트할 때를 생각하면 됨
- 수백명의 개발자가 투입되는 프로젝트같은, 일정 규모 이상의 서비스를 운영할 때 한계가 있음
- 서비스, 프로젝트가 커지면 커질수록 영향도 파악 및 전체 시스템 구조 파악에 어려움이 있음
- 빌드 시간 및 테스트 시간, 배포 시간이 기하급수적으로 늘어남
- 서비스를 부분적으로 scale-out하기 힘듦
- 부분의 장애가 전체 서비스의 장애로 이어질 수 있음
Micro Service 뜻
“the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.”
출처: https://martinfowler.com/articles/microservices.html
- small services, each running in its own process: 스스로 돌아갈 수 있는 작은 서비스
- independently deployable: 독립적 배포 가능
- 각각의 서비스는
- 매우 작은 단위로 구성되어 있지만 서비스 자체는 하나의 MA(모놀리틱 아키텍처)와 유사 구조를 지님
- 독립적으로 배포 가능
- 다른 서비스에 대한 의존성이 최소화 되어야 함
- 개별 프로세스로 구동되며, REST와 같은 가벼운 방식으로 통신되어야 함
MSA의 장점
- 배포(Deployment) 관점: 서비스 별 개별 배포 가능 (배포 시 전체 서비스 중단이 없음) -> 요구사항을 신속하게 반영하여 빠르게 배포할 수 있음
- 확장(Scaling) 관점: 특정 서비스에 대한 확장성이 용이 -> 클라우드 사용에 적합한 아키텍처
- 장애(Failure) 관점: 장애가 전체 서비스로 확장될 가능성이 적음 -> 부분적 장애에 대한 격리가 수월함
- 신기술의 적용이 유연하며, 서비스를 polyglot하게 개발/운영할 수 있음
MSA의 단점
- Monolithic Architecture보다 복잡한 아키텍처 -> 전체 서비스가 커질수록 그 복잡도는 기하급수적으로 늘어남
- 성능: 서비스 간 호출 시 API를 사용함 -> 통신 비용 및 latency(지연 시간)이 그만큼 늘어남
- 테스트/트랜잭션: 서비스가 분리되어 있음 -> 테스트와 트랜잭션 복잡도 증가, 많은 자원을 요구
- 데이터 관리: 데이터가 여러 서비스에 걸쳐 분산되기 때문에 한 번에 조회화기 어렵고, 데이터의 정합성 또한 관리가 힘듦
MSA 구조
- Inner Architecture (남색 부분): 내부 서비스와 관련된 아키텍처
- 고려사항
- 마이크로 서비스를 어떻게 정의할 것인가?
- DB Access 구조를 어떻게 설계할 것인가?
- 마이크로 서비스 내 api를 어떻게 설계할 것인가?
- 논리적인 컴포넌트들의 layer를 어떠한 방식으로 설계할 것인가?
- 표준이 없어 MSA를 설계하는데 가장 어려운 부분
- 고려사항
- Outer Architecture (회색 부분)
- External Gateway
- Service Mesh
- Container Management
- Backing Services
- Telemetry
- CI/CD Automation