✅ MSA(Micro Service Architecture)
MSA는 하나의 큰 어플리케이션을 여러 개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처이다.
레고처럼, 작은 레고블록(MicroService) 하나하나를 붙여서 어떠한 큰 결과물을 만드는 형태를 MSA라고 할 수 있다.
✅ MSA 등장배경
Monolithic Architecture
Monolithic Architecture란 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 형태를 말한다. (예를 들어, Auth 모듈, Post 모듈, Chatting 모듈 등을 개발하고 개발 완료된 Application을 하나의 결과물로 패키징하여 배포되는 형태)
간단한 아키텍처고 유지보수가 용이하기 때문에 아직까지 많은 소프트웨어가 Monolithic 형태로 구현되어 있고, 소규모 프로젝트에서는 이게 합리적이다.
하지만 일정 규모 이상의 서비스 or 수백명의 개발자가 투입되는 프로젝트에서 이는 다음과 같은 한계를 보인다.
- 서비스/프로젝트가 커질수록, 전체 시스템 구조의 파악 어려움
- 빌드 시간, 테스트 시간, 배포 시간이 기하급수적으로 늘어남
- 서비스를 부분적으로 scale-out(여러 서버로 나누어 일을 처리)하기 어려움
- 부분 장애가 전체 서비스의 장애로 이어지는 경우 발생
- 한 framework와 언어에 종속적
MSA 등장
네이버와 같은 서비스의 경우 뉴스, 메일, 지식인, 카페, 검색엔진 등의 기능이 한 백엔드 애플리케이션에 합쳐져있다면...😨
개발과 유지보수가 어려울 것이고, 많은 개발자들이 한 애플리케이션에서 작업하면 conflict가 많이 발생할 것이고, 서비스가 한계에 다다를 것이다.
이와 같은 문제를 해결하기 위해 뉴스 API, 카페 API, 쇼핑 API 등으로 다른 서버를 사용할 수 있게 하는 MSA라는 개념이 나왔다.
MSA는 API를 통해서만 상호작용 할 수 있다. 즉 마이크로 서비스는 서비스의 end-point를 API의 형태로 노출하고, 실질적인 세부사항은 모두 추상화한다. 내부의 구현 로직, 아키텍처, 프로그래밍 언어 같은 기술적인 사항들은 서비스 API에 의해 철저히 가려진다.
각각의 서비스는 모듈화되어 있으며, 모듈끼리는 RCP 또는 message-driven API등을 이용해 통신한다.
✅ Micro service의 정의
- 각각의 서비스는 그 크기가 작을 뿐, 서비스 자체는 하나의 모놀리틱 아키텍처와 유사한 구조를 가짐
- 각각의 서비스는 독립적으로 배포 가능
- 각각의 서비스는 다른 서비스에 대한 의존성이 최소화되어야 함
- 각 서비스는 개별 프로세스로 구동되며, REST와 같은 가벼운 방식으로 통신되어야 함
✅ MSA의 장단점
장점
MSA는 서비스가 커지면서 생겼던 모놀리틱 아키텍처의 문제점들을 어느정도 보완해줄 수 있다.
- 배포 관점
서비스 별 개별 배포 가능 (배포 시 전체 서비스의 중단 없음)
요구사항을 신속하게 반영해 빠르게 배포할 수 있음 - 확장 관점
특정 서비스에 대한 확장성이 용이함
클라우드 사용에 적합한 아키텍처 (why..?) - 장애 관점
장애가 전체 서비스로 확장될 가능성 적음
부분적 장애에 대한 격리가 수원함
단점
모놀리틱 아키텍처는 단순한 아키텍처인데 비해 MSA는 보다 복잡하기에, 전체 서비스가 커짐에 따라 그 복잡도가 기하급수적으로 늘어날 수 있다.
- 성능 관점
서비스 간 호출 시 API를 사용하기 때문에 통신 비용이나 Latency가 그만큼 늘어남 - 테스트/트랜잭션 관점
통합테스트가 어려움
서비스가 분리되어 있기 때문에 테스트와 트랜잭션의 복잡도가 증가하고, 많은 자원을 필요로 함 - 데이터 관리 관점
데이터가 여러 서비스에 걸쳐 분산되기 때문에 한 번에 조회하기 어렵고, 데이터의 정합성(데이터 값이 서로 일치함)도 관리하기 어려움 - 배포 관점
실제 운영환경의 배포가 어려움. 서비스 1개를 재배포할 경우 다른 서비스들과 연계가 정상 적동하는지 확인해야함
