MSA란 무엇인가?
- MAS는 MicroService Architecture의 줄임말로, 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크라고 할 수 있다.
- 마이크로서비스는 완전히 독립적으로 배포가 가능하고 다른 기술 스택 (개발 언어, 데이터 베이스 등) 사용 가능한 단일 사업 영역에 초점을 두는 것이 특징이다.
MSA의 등장 배경
- Monolithic Architecture
- 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 형태이다.
- 장점
- 간단한 Architecture이고 유지 보수가 용이하다.
- 단점
- 서비스 or 프로젝트가 커지면 커질 수록, 영향 및 전체 시스템 구조의 파익이 어려운 문제가 있다.
- 빌드 시간 및 테스트 시간, 배포시간이 기하급수적으로 늘어나며 서비스를 부분적으로 scale-out하기가 힘들어진다.
- 부분의 장애가 전체 서비스의 장애에 영향을 주게 된다.
- 한 Frame work와 언어에 종속적이게 된다.
현재까지는 많은 소프트웨어가 Monolithic 구조로 구현되어 있어서 소규모 프로젝트에서는 Monolithic Architecture가 훨씬 합리적이라고 합니다. 하지만 일정 규모 이상의 서비스 혹은 수 백명의 개발자가 투입되는 프로젝트에서는 Monolithic Architecture는 뚜렷한 한계를 보이며, 여기서 MSA의 필요성이 나오게 됩니다. 기존의 특정한 물리적인 서버에 서비스를 올리던 on-promise 서버 기반의 Monolithic 구조에서 이제는 클라우드 환경을 이용해 서버를 구성하는 MicroService Architecture로 많은 서비스들이 전환을 하고 있다.
MSA의 특징
1) 특징
- MSA는 API를 통해서만 상호작용할 수 있으며 마이크로 서비스는 서비의 end-point(접근점)을 API 형태로 외부에 노출하고 실질적인 세부 사항들은 모두 추상화한다.
- 서비스 내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터 베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려지게 된다.
- MSA 내에 각각의 서비스들은 크기가 작을 뿐, 서비스 자체는 하나의 모놀리틱 아키텍처와 유사한 구조를 가지며 각 서비스들은 개별 프로세스로 구동되며 REST API와 같은 가벼운 방식으로 통신이 되어야 한다.
2) 장단점
- 장점
- 배포관점 서비스 별 개별 배포가 가능하게 되며 배포 시에 전체 서비스의 중단이 없기 때문에 요구사항을 신속하게 반영하여 빠르게 배포가 가능해진다.
- 확장 관점에서 특정 서비스에 대해 확장성이 용이하며, 클라우드 사용에 적합한 아키텍처이다.
- 장애 관점에서 특정 서비스 내에 장애가 발생해도 전체 서비스에 확장될 가능성이 매우 적으며 부분적 장애에 대한 격리가 수월하다.
- 신기술의 적용이 유연하고, 서비스를 polyglot하게 개발 또는 운영할 수 있다.
- 단점
- MSA는 monolithic 구조에 비해 복잡한 아키텍처로 전체 서비스가 커짐에 따라 복잠함이 급격하게 증가한다.
- 성능 측면에서 서비스 간 호출시 API를 활용하기 때문에 통신 비용이나 처리 지연이 늘어나게 된다.
- 한 트랜잭션 처리 및 각각의 어플리케이션에 대한 에러 처리가 반드시 필요하다.
- 배포에 대한 자동화가 필수 요소이다.
- 테스트 / 트랜잭션인 측면에서 서비스가 분리되어 있기 때문에 테스트와 트랜잭션의 복잡도가 증가하고 많은 자원이 필요로 하게 된다.
- 데이터 관리 측면에서 데이터가 여러 서비스에 걸쳐 분산되기 때문에 한번에 조회하게 어렵게 되고 데이터의 정합성 또한 관리하기 어렵게 된다.
MSA의 핵심 구성요소에는 API Gateway 패턴, Service Mesh, Message Queueing 등이 있으며 이것은 다음 포스팅에서 더 자세하게 다룰 예정이다.
또한
[우아콘 2020] - 배달의 민족 마이크로 서비스 여행기
(https://www.youtube.com/watch?v=BnS6343GTkY)를 시청해보면 좋겠다..