Micro Service Architecture
MSA란 마이크로 서비스 아키텍처(Micro Service Architecture)의 약자로 단일 프로그램을 각 컴포넌트 별로 나누어 작은 서비스의 조합으로 구축하는 방법
Why MSA ❓
Monilith
모놀리식 아키텍처의 경우 모든 프로세스가 긴밀하게 결합되고 단일 서비스로 실행된다. 따라서 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야하기 때문에 코드 베이스가 증가하게 되며, 모놀리식 애플리케이션의 기능을 추가하거나 개선하기가 더 복잡해진다. 또한 이러한 복잡성으로 인해 실험에 제한을 받고 새로운 아이디어를 구현하기가 어려워진다.MSA
마이크로서비스 아키텍처의 경우, 애플리케이션이 독립적인 구성 요소로 구축되어 각 애플리케이션 프로세스가 서비스로 실행된다. 이러한 서비스는 경량 API를 사용하여 잘 정의된 인터페이스를 통해 통신을하고 서비스는 비즈니스 기능을 위해 구축되며 서비스마다 한 가지 기능을 수행한다. 그 결과 서비스가 독립적으로 실행되기 때문에 애플리케이션의 특정 기능에 대한 수요를 충족하도록 각각의 서비스를 업데이트, 배포 및 확장할 수 있다.
MSA 장점
- 1. 서비스 별 개별 배포가 가능하다.
MSA 사용 시 전체 서비스의 중단이 없이 개별 배포가 가능하다.
- 2. 요구사항을 신속하게 반영하여 빠르게 배포할 수 있다.
- 3. 확장성이 높다
클라우드 사용에 적합하며, 특정 서비스에 대한 확장성이 용이하다.
- 4. 장애가 전체 서비스로 확장될 가능성이 적다.
서비스가 개별적으로 독립되어 있기 때문에 장애가 전체 서비스로 확장될 가능성이 적다.
MSA 문제점
- 1. 개발 복잡도와 숙련도
분산 시스템 개발은 일반 개발보다 복잡하다. 독립적인 서비스이기 때문에 각 모듈의 인터페이스를 신중하게 처리해야 한다. 요청에 응답하지 않게 될 경우에 대한 방어 코드도 작성해야 하며 호출 대기 시간이 일정 수준을 넘기면 복잡한 상황이 발생할 수 있다. 또한 동기적인 처리방식인 REST 통신으로 인한 제약이 발생할 수 있다.
- 2. 트랜잭션 관리
MSA는 Database Per Service라는 새로운 요구사항으로 분산된 서비스마다 분리된 DB들 간의 트랜잭션 관리가 어려울 수 있다. 또한 반정규화 된 데이터의 동기 처리도 신경을 써야 합니다.
- 3. 통합 테스트 어려움
MSA 기반의 애플리케이션을 테스트하는 것은 번거로울 수 있다. 테스트를 시작하기 전에 의존성이 있는 서비스를 미리 확인해야 한다.
- 4. 배포 복잡도
MSA의 배포는 복잡 할 수 있다. 각 서비스 간의 조정이 필요 할 수 있다.
💎 CHOICE
팀의 현장조사를 통해 문제를 확인한 후 팀의 서비스 하나에 너무 많은 사람이 같이 붙어있어 관리가 어려워 나누고 싶거나, 기술 부채가 누적되어 일부를 조금씩이라도 뜯어서 고치고 싶거나, 혹은 서비스 모듈 간 기술 스택 자유도를 부여하고 싶다면 MSA 도입을 고려할 수 있다.
참조
오늘도 공부 📖🌙