#주저리주저리
사내 프로젝트에서 MSA를 도입한다고 간단하게 공부해보고, 이전 포스팅에서 MSA에서 사용되는 분산 트랜잭션에 대해서도 간략하게 정리해보았지만... 결국 빠듯한 일정으로 인해 기존의 Monolithic 형태로 구현했다.
정말 한번쯤 접해보고 싶은 아키텍처였는데 결국 사용해보지 못한게 엄청 아쉬웠다. 그러던 중, 마음이 맞는 대학 동기끼리 진행하게된 팀 프로젝트에서 아직까진 확정은 아니지만 사용하게 될 것 같아 미리 공부하고 학습하기 위해 포스팅을 작성하게 되었다!
이번만큼은 흐지부지 넘어가지 않으려면 어느정도 베이스를 갖춰 있어야한다고 생각했기 때문이다.
MSA의 개념
MSA는 독립적으로 배포 가능한 여러 서비스들로 하나의 어플리케이션이 구성된 아키텍처를 의미한다. 이게 대체 무슨말일까?
Monolithic이란?
우선 MSA에 대한 개념을 확실하게 이해하기 위해서는 우리가 일반적으로 사용하고 있는 구조가 왜 Monolithic인지부터 알아야한다고 생각한다.
Monolithic은 서비스를 개발할 때, 오직 하나의 프로젝트에서 관리되고, 하나의 어플리케이션으로 만들어지는 아키텍처를 의미한다. 이 정의만으로는 명확하게 Monolithic과 MSA의 차이를 구분하기 쉽지 않을 것이다.
간단한 예를 살펴보자. 만약 "온라인 쇼핑몰"을 개발하는 경우, 우리는 온라인 쇼핑몰에서 제공하는 기능을 크게 "유저 관리", "상품 관리", "주문" 등으로 구분할 수 있을 것이다. 이 때, Monolithic은 각 기능들에 대해서 세분화시키지 않고 "온라인 쇼핑몰"이라는 하나의 큰 서비스에서 모든 기능들을 제공하거나 데이터를 관리하는 구조를 의미한다.
그에 반해, MSA는 "유저 관리", "상품 관리", "주문"으로 3가지 서비스로 분리하여 어플리케이션을 구성한다.
이러한 구조로 인해 Monolithic은 다음과 같은 장단점을 지닌다.
장점
- 배포와 운영, 테스트가 간편하다.
- MSA에 비해 비교적 높은 성능을 보인다.
-> 별도의 rpc나 API를 통해 타 서비스의 기능을 사용하는 것이 아니라 같은 서버 내의 함수를 끌어다 사용하며, 하나의 DB를 사용하기 때문에 DB 자체 트랜잭션을 통해 일관성을 유지하면 되기 때문에 DB간에 별도의 일관성을 유지하기 위한 작업에 소요되는 오버헤드가 없다. - 구성하기 간단하다.
단점
- 크고 작은 변경을 배포하는 데 시간이 동일하게 오래 걸린다.
- 일부분에서 발생한 문제가 전체 어플리케이션의 장애로 이어질 수 있다.
-> 이로 인해 에러 발생 근원지를 파악하기 어려워 trouble shooting이 힘들다. - 새로운 기술이나 특정 기능에 유리한 언어를 도입하기 힘들다.
- 부분적인 Scale-Out이 불가능하다.
-> 효율적으로 자원과 비용을 관리하기 힘들다.
이러한 모든 장단점은 결국 Monolithic이 하나의 서비스로 구성되어 있다는 특징에서 파생된다.
MSA란?
MSA는 Monolithic과 다르게 하나의 큰 어플리케이션을 각각의 서비스를 담당하는 작은 프로젝트 단위로 구성하는 것을 의미한다.
즉, 각각의 서비스는 각 서비스에서 담당하는 기능과 데이터를 정의하여 별도로 구성되고 타 서비스 정보나 기능이 필요한 경우 API나 RPC를 통해 통신하여 해결하는 구조로 이루어져있다.
데이터가 분리되어 있다는 말은 DB도 서로 분리되어 있다는 얘기다. 별도의 DB로 이루어져있으니
Join 연산도 불가능하고 Transaction의 4가지 원칙도 DB자체에서 제공해주는 것이 아니라 개발자가 직접 조작해주어야 한다.
처음에는 이러한 구조를 보면 불필요하게 데이터가 분산되어 있고, 상호간의 통신도 간접적으로 이루어져야하니 오히려 안 좋은 것이 아닐까하는 생각이 들었다.
하지만 이런 복잡한 구조를 지닌만큼, Monolithic에서 발생하는 수많은 단점들을 MSA에서 보완할 수 있다. 바로 각 서비스가 거의 독립적으로 동작한다는 것이다. 타 서비스에 종속적으로 구성되어 별도로 배포해야하고, 영향을 많이 받는 Monolithic과 달리, MSA는 하나의 서비스가 타 서비스와 통신하는 API 및 RPC 부분을 제외하고는 오롯이 하나의 어플리케이션으로 동작할 수 있는 것이다.
따라서 아래의 장단점을 지닌다.
장점
- 변경이 필요한 일부 서비스만 수정하여 배포가 가능하여 Agile 기법과 CI/CD와 같은 개념이 뜨고 있는 지금, 최적의 아키텍처를 구성할 수 있다.
- 타 서비스에서 발생한 에러의 영향을 최소화할 수 있다.
- 각 서비스별로 별도의 언어와 프레임워크로 구성할 수 있다.
- 부분적인 Scale-out이 자유롭다.
단점
- 통합 테스트가 어렵다. 타 서비스와의 연계에서도 확인해야한다.
- DB 트랜잭션을 유지하기 힘들다.
- 구조가 많이 복잡하여 결정해야할 요소가 많고 구성하는데 많은 어려움이 있다.
사실상 Monolithic의 장단점을 역으로 가져온다고 생각하면 이해하기 편할 것이다.
마치며
최근 트렌드 상 하나의 어플리케이션이 다양한 기능을 제공하고, 앞서 말했듯이 Agile 기법과 CI/CD와 같은 DevOps 개념이 대두에 오른만큼 MSA 아키텍처에 대한 이해는 반드시 알아두어야할 부분이라 생각되어 정리해보았다. 다만, 아직 제대로 다뤄보지 못하여 정리를 하면서도 깔끔하지 않은 부분이 있었는데... 이 부분은 직접 구성해보면서 다시 한번 살펴보면서 정리를 해보아야겠다.
