마이크로 서비스 아키텍처(이하 MSA, msa)는 작고 독립적인 서비스들로 구성된 어플리케이션 구조를 의미한다. 기존에 모놀리식 아키텍처와 상반되는 개념으로 최근에 많은 서비스에서 사용되는 개념이다.
모놀리식 아키텍처
모놀리식 아키텍처는 소프트웨어 내 모든 구성요소가 단일 프로젝트에 포함된 구조이다. 한 프로젝트에 로직, 데이터 액세스 레이어가 있고 하나의 DB를 사용한다. 또 UI까지 포함하기도 한다.
모놀리식 아키텍쳐는
- 빠르게 프로토타입을 만들 수 있다.
- 필요한 피쳐가 하나의 프로젝트에 모두 있어서 복잡한 통신이 필요 없다.
- 코드베이스가 커지면 복잡해져서 유지보수가 어렵다.
- 일부 기능 수정에도 전체 어플리케이션을 재배포해야한다.
- 일부 기능의 에러로 전체 어플리케이션에 영향이 간다.
마이크로 서비스 아키텍처
MSA는 하나의 큰 어플리케이션을 여러개의 작은 서비스 유닛으로 나누어서 조합한다. 각 마이크로 서비스는 독립적이지만 상호 통신이 가능한 상태로 구축한다. 또 서비스마다 DB가 따로 존재한다.
MSA는
- 각 서비스가 독립적이어서 배포가 빠르고 가볍다.
- 단일 서비스 배포시 전체 서비스의 중단이 없다.
- 모듈화되어 있어 유지보수 및 개발속도 향상에 용이하다.
- 서비스가 분리되어 있어 각 서비스에 맞는 기술을 선택할 수 있다.
- 단일 서비스의 장애가 전체 어플리케이션에 영향을 주지 않는다.
- 각 서비스 간의 상호 통신을 확인해야 한다.
- 각 서비스간 호출시 Latency가 생긴다.
- 서비스가 분산되어 있어 트랜잭션 관리, 장애 추적이 어렵다.
- 서비스마다 DB가 분리되어 데이터의 중복이 발생한다.
MSA에 역시 단점이 있음에도 서비스의 규모가 커지면 커질 수록 코드베이스가 커지고 담당하는 개발자가 많아질수록 모놀리식의 단점을 커버하기가 힘들기 때문에 MSA 구조를 택하는 경우가 많다.
여기에서 또 SOA라는 개념도 존재하는데, SOA는 Service-Oriented Architecture의 약자이다. 다른 회사의 백엔드 개발자와 네트워킹을 한 적이 있는데, 해당 회사의 서비스 구조에 대해서 물어보았다. 당시에 MSA에 대해 관심을 가지고, 공부하던 도중 DB를 꼭 분리해야할까? 라는 생각이 있었다.
물론 DB의 가용성, 안정성을 생각하면 분리하는 것이 좋지만 서비스가 아직 MSA의 모든 개념을 담아야할 정도로 크지 않다면, 굳이? 라는 생각이 들었다. 또 AWS RDS의 비용이 어마어마했고, 충분한 클러스터링과 성능을 가진 RDS를 분리할 필요가 있을까 했다.
그 개발자분은 회사에서 서버는 여러개지만 DB는 단일로 사용하고 있다고 했었고, 아마 SOA와 비슷하게 구조를 가져간게 아니었을까 싶다.
SOA는 MSA와 동일하게 서비스 기반, 서비스 기능 단위로 서버 유닛을 분리하지만 MSA와 다르게 공유 데이터베이스를 사용하며 재가용성, 재사용을 중점으로 둔다. 이는 한 팀에서 개발한 서비스를 다른 팀에서도 그대로 사용할 수 있다는 의미이다. 이에 비해 MSA는 서비스 간의 결합도를 최대한 낮추는데 집중한다.
또 MSA에서는 경량화된 HTTP REST API, 메시지 큐를 사용하지만 SOA에서는 WSDL, UDDI, DSB와 같은 공통적인 통신 방식을 사용하여 서비스간 결합도가 증가하며 이 방식은 무거운 통신 방식에 속한다.
이미지출처
https://www.redhat.com/ko/topics/microservices/what-are-microservices
