재직 중인 회사에서 최근 MSA의 도입을 준비하고 있다. 그래서 관련하여 공부하거나 알고 있는 내용들과 함께 MSA에 대한 생각을 정리해 보고자 한다.

그전에 간단하게 MSA가 뭔지에 대해 살펴보자.

Micro Service Architecture

우선 MSA는 Micro Service Architecture의 앞 글자만 따서 만들어진 줄임말이다.
즉 각각의 서비스가 Micro 한 형태로 존재한다는 것이다.

각각의 서비스가 Micro 한 형태로 존재한다 라는 게 어떤 건지 아직 이해가 안 될 수 있다. 아래의 내용을 살펴보자.

Server Architecture

MSA를 하기 전의 대부분의 많은 프로젝트는 모놀리식 아키텍처 형태의 구조를 띄고 있다. 하나의 서버에 인증부터 모든 서비스 모듈을 담고 있는 경우라고 생각하면 된다.

모놀리식 아키텍처에서는 여러 모듈이 강한 결합을 유지하고 있다. 즉 서비스의 설계변경이 어렵고 한 Framework 언어에 종속적이다.
(예를 들어 Node.js를 사용하여 Express 프레임워크를 사용 중인 상황에서 새로운 coupon 도메인을 개발하고자 할 때 언어나 프레임워크의 선택권이 없다.)

이러한 모놀리식 아키텍처도 충분히 많은 장점이 있다.
하지만 오늘은 단점에 대해 살펴보기 위해 다음의 예시를 생각해 보자.

<요구사항>

1. 어느 날 쇼핑몰을 운영하는 우리 회사에서는 이벤트를 하기로 했다.
2. 모델을 내세워 TV 광고를 했다.
3. 회원가입만 하면 만원 쿠폰을 주기로 했다.

이 얘기를 들은 개발팀은 사용자가 몰릴 것을 대비해야 한다.
사용자가 몰려 트리 팩이 발생하면 서버를 키우는 방법은 크게 2가지가 있다.

1. ScaleIn
2. ScaleOut

1번의 경우 가장 간단하고 빠른 방법이다. 단점으로는 서버의 크기를 늘리는 데는 한계가 있다. 그리고 비싸다.
그래서 2번의 방법도 병행해야 한다. 서버가 여러 대가 생기면, 해당 서버마다 코드가 올라갈 것이다.

모놀리식 아키텍처에서 ScaleOut 된 그림은 다음과 같다.

그런데 위의 내용을 다시 살펴보자.
이벤트의 내용은 사용자의 가입에 초점이 맞추어져 있다. 예상을 해보면 회원가입. 즉, Auth 모듈 쪽에 가장 큰 트래픽이 발생할 것이고, 그 외 상품페이지, 결제, 배송정보 관리 등의 모듈에서는 상대적으로 트래픽이 회원 도메인에 비해 상대적으로 더 적게 발생할 것이다.
지금 우리가 가진 모놀리식 아키텍처에서는 이를 해결하지 못한다. 즉 서버 내에 있는 전체 모듈에 대해 일괄적으로 ScaleOut을 해야 하는 것이다.

Micro Service Architecture

MSA의 환경을 구축하는 데에는 Cloud 환경이 일반화되면서 더욱 쉬워졌다. 직접 서버를 관리하던 과거에는 서버를 늘리거나 줄이는 것에 대한 부담이 많았다. 하지만 Cloud 환경이 일반화되면서 서버의 추가 및 제거가 너무나 쉽고 간편해졌다.

MSA는 모놀리식 아키텍처와 다르게 각각의 도메인 하나하나를 각 서버로 분리한다.

즉 각각의 서버는 자신의 도메인 로직 처리만을 담당하고 각각 DB를 따로 관리한다.

위의 예시를 들었던 상황을 MSA에서 다시 살펴보자.
이벤트를 위해 Auth 모듈만을 Scale-out 해주면 된다. 즉 서버 증설이 필요 없는 모듈들은 그대로 둠으로써 서버 비용을 절약할 수 있다.

Micro Service Architecture 는 모든 것을 해결해 주는가

위의 글만 보면 MSA라고 하면 매우 좋은 것처럼 보일지 모른다.
하지만 아쉽게도 MSA 역시 단점이 존재한다.

1. 함수 호출이 Network I/O로 변경된다.

기존에는 A도 메인에서 B 도메인의 데이터를 조회하기 위해서는 B.foo()를 통해 함수를 호출하면 된다. 하지만 MSA 환경이 되면서 함수 호출이 아닌 Network I/O가 발생해야 한다. (본인 서버가 아닌 다른 서버에 함수가 존재하기 때문이다)

2. DB가 분리되므로 join, transaction이 어려워진다.

Database는 각각의 서버가 본인의 모듈에 해당하는 데이터만 관리한다. 개발하다 보면 여러 테이블들의 작업을 transaction으로 처리한다거나, join으로 불러올 필요성이 있는 경우가 있다. 하지만 서버가 나누어져 있다 보니 이런 처리가 어렵거나 불가능해진다.

3. 관리해야 할 서비스가 많아진다.

기존에는 1개의 서버만 관리하면 됐다. 하지만 MSA로 구축하게 되면 모듈마다 서버가 생기므로 관리해야 할 서버의 개수가 늘어난다.

4. 모놀리식 아키텍처에 비해 러닝 커브가 높다.

Micro Service Architecture 의 장점은 무엇인가

MSA의 장점은 다음과 같다.

1. 배포 단위가 작아진다.

서버 규모가 작아지므로 배포해야 할 코드의 양이 줄어든다. 빌드 속도가 빨라지며 배포의 속도가 상대적으로 더 빨라진다.

2. 배포로 인한 사이드 이펙트(영향 범위)가 줄어든다.

배포 후 오류가 발생했을 때 해당 오류의 전파 범위가 줄어든다.

3. 배포에 대한 버전 관리를 독립적으로 할 수 있다.

4. 모듈(서버)마다 다른 언어로 개발할 수 있다.

각각 모듈마다 서버가 별도로 뜨기 때문에 해당 모듈에 더 적합한 언어를 선택할 수 있다.

5. 설계 변경에 대해 유연하다.

6. 개발팀의 규모가 커져감에 따라 담당 업무에 대한 분배가 명확해진다.

정리

MSA 라고 하는 아키텍처는 분명 많은 장점을 가지고 있다. 반면 단점도 적지 않게 있다. 특정 도메인만 ScaleOut 할 수 있다는 것은 분명한 장점일 것이다. 하지만 그만큼 관리해야 할 서버가 늘어나는 것은 많은 부담이 된다. (서버 관리를 위한 많은 방법들이 있지만 어째 뜻 부담은 생기고 러닝 커브가 높아진다.)

현재 회사의 개발팀의 규모와 팀원들의 지식수준에 따라 결정해야 할 문제라고 생각한다. 관리해야 할 대상이 늘어나는 부담에 비해 업무 분배, 배포의 속도, ScaleOut 에 대한 효율이 더 좋을 때 MSA의 환경을 고려해 볼 수 있다.

예를 들어 사내에 개발자가 2~3명인데 MSA 구조를 채택하여 운영할 경우, 개발하는 시간보다 인프라를 관리하는 비용이 더 많이 발생할 수 있다.

중요한 것은 생각보다 MSA를 도입할 정도의 서비스라고 한다면 해당 서비스의 규모가 작지 않은 규모임에는 확실할 것이다.