[Architecture] 유잔씨의 MSA 이모저모 알아보기

들어가기 전에

이번 프로젝트는 MSA 구조로 하자!! 라는 말이 나왔을 때 MSA가 뭐야?? 라는 생각부터 들었다. 계속 공부해도 이렇게 모르는게 많다니. 그래도 일단 모르면 공부해서 적용 해야지 뭐 어떡할거야!!! 라는 마인드를 작창했기에, MSA가 무엇인지 부터 낱낱이 파헤져보고자 한다.

 

---

MSA 란?

MSA란 Microservice Architecture 의 줄임말로, 간단히 정의하자면

" 하나의 어플리케이션을 다수의 독립적인 서비스들의 집합으로 구성하는 것" 이다.

 

Martin Fowler는 MSA에 대해 다음과 같이 정의하였다.

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

 

- 각 서비스가 자체 프로세스에서 실행된다

- 각 서비스는 가벼운 메커니즘(REST API 등)으로 통신하여 단일 애플리케이션을 개발할 수 있어야 한다

- 각 서비스는 독립적으로 배포가 가능해야하며, 다른 서비스에 대한 의존성이 최소화 되어야 한다

- 각 서비스는 그 크기는 작지만, 서비스 자체는 하나의 Monolithic 아키텍처와 유사한 구조를 가진다.

- 서비스에 대한 중앙 집중식 관리가 최소한으로 이루어지며, 각자 다른 프로그래밍 언어로 작성되고 다른 데이터 저장 기술을 사용할 수 있다. 

 

MSA가 왜 등장했고, 장단점이 무엇인지 이해하기 위해서는  MSA 이전에 사용했던 Monolithic Architecture이 무엇인지 알아야 한다.

 

Monolithic Architecture 란?

Monolithic Architecture란, 소프트웨어의 모든 구성 요소가 한 프로젝트에 통합되어 있는 형태이다. 전체 기능을 하나의 코드 베이스로 개발하고 이 대규모 단일 코드 베이스를 빌드하고 배포할 때에는 단일 통합 데이터베이스를 사용한다.

예를 들어, 웹 개발에서 하나의 웹 프로그램을 개발하기 위해 모듈별로 개발을 하고, 완료된 웹 어플리케이션을 하나의 결과물로 패키징하여 배포하는 것을 말한다. 웹의 경우 WAR파일로 빌드되어 WAS에 배포하는 형태이다.

간단하고 유지보수가 용이하며, 서능이 빠르고 트랜잭션 관리가 용이하기 때문에 소규모 프로젝트에서는 Monolithic Architecture가 훨씬 합리적이다.

그러나 일정 규모 이상의 서비스, 혹은 수백명의 개발자가 투입되는 프로젝트에서는 한계가 뚜렷하다.

 

- 기능들 간 결합도가 높기 때문에, 다른 테이블에 직접 접근하기도 하며, 어떤 기능을 변경했을 때 다른 기능에 어떤 영향을 주는지 파악하기 어렵다

- 코드끼리 서로 의존하여, 데이터들도 서로 의존한다

- 부분의 장애가 전체 서비스의 장애로 이어진다.

- 작은 수정으로도 전체 시스템을 빌드 및 배포해야 하고 시간이 오래 걸린다.

- 서비스를 부분적으로 scale-out(서버의 수를 늘리는 수평적인 성능 향상) 하기 힘들다

 

즉, 코드가 운영 환경에 민첩하게 배포되기가 어렵다.

 

MSA의 장점

- 서비스 별로 개별 배포가 가능하므로, 배포 시 전체 서비스의 중단이 없으며 요구사항을 신속하게 반영하여 빠르게 배포할 수 있다.

- 특정 서비스에 대한 확장성이 용이하다. 즉, 탄력적이고 선택적인 확장이 가능하다. 예를 들어, 사람이 몰리는 서비스 부분만 scale-out 할 수 있다. 

- 장애가 전체 서비스로 확장될 가능성이 적다

- 각 기능을 구현할 때 서로 다른 언어와 다른 DB, 다른 서버를 사용할 수 있으므로 기술 부채의 경감 효과가 발생한다

 

즉, 빠르게 변화하는 비즈니스 환경에 민첩하게 대응이 가능하다.

 

MSA의 단점

- 서비스 호출 간 API를 사용하기 때문에 통신 비용, Latency가 늘어난다

- 서비스가 분리되어 있기에 테스트와 트랜잭션 복잡도가 증가하고, 많은 자원을 필요로 한다

- 데이터가 여러 서비스에 분산되어 있기에 관리하기가 어렵다. 

---

마치며

요즘 Netflix, Amazon 등 거대 기업이 MSA로의 전환을 시도하고, 성능 개선을 얻음으로써 MSA가 대세가 된 것은 사실이다. 그러나 장단점이 확실히 존재하고, Monolithic Architecture가 더 적합한 경우도 많고, 그 외의 다양한 Architecture가 존재하기에 상황에 맞춰 적당히 사용하면 된다. 

다음 글은, 11번가에서 MSA로 전환하며 얻은 교훈과 배움들을 공유하는 영상을 요약하며 MSA를 실제로 어떻게 적용하는지를 알아볼 예정이다.