MSA 기본 개념

MSA(Microservice Architecture)란?

하나의 큰 애플리케이션을 여러 개의 작고 독립적인 서비스로 나누어 개발하고 배포하는 소프트웨어 개발 아키텍처.

 

프로젝트 하나에 모든 API(결제 관련 API, 인증 관련 API, 상품 관련 API)를 전부 구현하는 모놀리식 아키텍처 방식과 비교해보자.

이에 반해, 마이크로서비스 아키텍처(MSA)는 서비스에 필요한 API들을 하나의 프로젝트가 아닌 여러 개의 프로젝트로 나눠서 구현하는 방식이다. 아래 그림을 보면 결제 관련 API들끼리 모아놓은 프로젝트와, 인증 관련 API들끼리 모아놓은 프로젝트와, 상품 관련 API들끼리 모아놓은 프로젝트를 분리해서 구성했다. 그리고 MSA에서는 독립적으로 분리된 하나의 프로젝트를 서비스(service)라고 부른다. 

보통 DB를 서비스마다 분리해서 쓴다.

MSA가 도대체 어떤 특징과 장점을 갖고 있길래 많은 회사에서 MSA를 도입하는 걸까?

---

MSA의 핵심 특징과 장점

MSA의 핵심적인 특징은 독립성이다. 각 기능을 독립적으로 분리해서 프로젝트를 구성함으로써, 다양한 장점이 생기게 된다.

1. 서비스 별 독립적인 배포 → 배포 사이클이 빨라짐

하나의 큰 프로젝트를 100명이 작업하는 것보다, 여러 개의 프로젝트로 나눠서 각 프로젝트를 관리하는 팀을 구성해 독립적으로 작업하는 게 훨씬 효율적이다. 그 이유는 다음과 같다.

• 서로 의사소통할 인원이 적기 때문에 프로젝트 진행이 빠르다.
• 팀이 독립적으로 개발/배포를 진행할 수 있다.
• 코드의 양이 비교적 작기 때문에 코드 작성, 테스트, 빌드 과정의 시간이 훨씬 적게 걸린다.

2. 데이터베이스의 독립적인 분리 → 대규모 트래픽 처리 용이

모놀리식 아키텍처에서는 단일 데이터베이스를 활용하는 구조를 많이 채택한다. 하지만 AWS의 단일 데이터베이스의 가장 좋은 성능의 데이터베이스로 셋팅을 한다고 하더라도 트래픽이 감당이 안 되는 순간이 온다. 
읽기 전용 데이터베이스를 추가하거나 캐시를 활용해 트래픽을 줄이려는 시도를 하지만, 이런 셋팅을 다 해도 트래픽을 감당 못할 때가 있다. 이런 경우에 MSA 구조를 활용해 각 서비스 별로 데이터베이스를 따로따로 둠으로써 대규모 트래픽을 감당하기도 한다.

3. 서비스를 독립적으로 분리 → 장애 전파를 최소화

모놀리식 서비스에서는 단일 데이터베이스를 사용하고 있기 때문에, 결제 API로 인해 데이터베이스에 장애가 나면 결제와 관련되지 않은 다른 기능들도 100% 같이 장애가 난다.

반면, MSA 구조에서는 각 서비스 별로 데이터베이스도 독립적으로 분리해서 구축하기 때문에, 결제 서비스가 장애가 나더라도 다른 서비스에는 영향을 덜 끼친다.

---

언제 MSA를 도입하는게 적절할까?

글로벌 기업들의 사례를 보면 크게 3가지 이유 때문에 MSA로 전환을 했다.

1. 신속한 배포
2. 대규모 트래픽를 안정적으로 처리
3. 시스템 안정성 확보

이는 MSA의 핵심적인 장점 3가지와 완전 일치한다.

따라서 모놀리식 아키텍처로 프로젝트를 관리하고 운영하면서 다음과 같은 문제를 만날 때 MSA 전환을 고민하면 된다.

1. 프로젝트 규모가 크거나 또는 개발자 인원이 너무 많아서 배포 사이클이 느려진 경우
2. 모놀리식 아키텍처에서는 도저히 감당할 수 없는 트래픽이 발생하는 경우
3. 모놀리식 아키텍처로 인한 장애 전파의 횟수가 잦거나, 한 번의 장애 전파도 서비스에 치명적인 경우

MSA로 전환하는데는 모놀리식 구조보다 훨씬 복잡하고 많은 시간과 비용이 드므로, 득실을 신중히 따져야 한다.

---

MSA인지 아닌지 판단하는 기준

MSA인지 아닌지를 판단할 때 핵심 개념은 ‘독립성’이다.

많은 기업들이 MSA로 전환하는 이유는 독립성으로 인해 생기는 장점들 때문이다. 따라서 독립성을 적용시켰냐 여부가 MSA를 판단하는 데 중요한 기준점이 된다.

MSA에서 얘기하는 ‘독립성’ 

1. 각 서비스를 독립적으로 개발 및 배포 가능해야 한다.

각 서비스를 독립적으로 개발 및 배포가 가능해야만, MSA의 핵심적인 장점(’배포 사이클이 빠르다’)을 취할 수 있게 된다.

 

2. 서비스 간 API 통신 및 DB 분리

서비스는 간에는 API로만 통신해야 한다. 가령, 다른 서비스의 DB에 직접적으로 접근해서 데이터를 가져오면 안 된다.

그래야 API를 제외한 다른 부분에서 의존성이 안 생겨서 독립적인 개발/배포가 원할하게 가능해지고,

DB를 별도로 분리해서 써야 DB 장애로 인한 장애 전파를 예방할 수 있다.

 

---

참고 자료 & 이미지 출처
비전공자도 이해할 수 있는 MSA 입문/실전