MSA(Micro Service Architecture) 아키텍처란?

취업을 준비하기 위해 구인 광고를 보다 보니 낯설지만 많은 회사가 원하는 경험이 있었는데 바로 MSA 경험이었다.

(도메인 주도 설계는 MSA를 위한 설계 방법 중 하나로 포함했다)

뭐... 요런 공고들 ...? (쳐다도 못 볼 회사들이긴 하지만...)

 

다른 것과는 다르게 특정 기술로 보이진 않아 궁금증이 생겨 찾아보기 시작했다.

 

MSA를 설명하기 전 기존의 방법인 모놀리틱 아키텍처를 그림으로 간략하게 그려보자면 아래와 같다.

 

모든 도메인이 묶여있고 하나의 DB만을 바라보고 있어 하나의 서비스에 대해서만 배포 및 테스트를 수행하면 되고 트랜잭션 또한 DB가 하나이니 서비스의 규모가 크지 않은 경우에는 MSA보다는 더 효율적이라고 할 수 있다.

 

만약, 서비스 규모가 커져 다음과 같은 상황이 발생한다면?

 

위 그림에서의 보이는 단점을 몇 가지만 살펴보자.

 

1. 작은 프로세스의 수정에도 서비스 전체를 빌드, 테스트, 배포해야 한다.

2. 트래픽이 몰리는 특정 도메인에서 만의 scale-out이 힘들다.

3. 다른 하나의 도메인에서의 장애로 인해 서버가 다운될 시 모든 도메인도 마비된다.

4. 신규 입사자의 코드 파악이나 유지 보수로 인한 코드 수정 시 양이 방대해 많은 시간을 필요로 한다.

 

위와 같은 이유로 인해 서비스의 규모가 커지는 기업들은 하나둘씩 MSA를 채택하고 있다.

 

 

 

MSA의 탄생 배경

 

MSA에 반대되는 방식을 살표 보았으니 이젠 MSA에 대해서 알아보자.

 

MSA는 최근에서야 생긴 아키텍처가 아닌 나온 지 5년은 넘은 아키텍처이다.

근데 왜 기업들은 비교적 최근에서야 MSA를 채택하고 전환하는 걸까?

 

여러 가지 이유가 있겠지만 대표적인 예를 들자면 넷플릭스의 성공적인 MSA 도입을 들 수 있다.

 

넷플릭스가 처음 MSA를 도입하게 된 이유를 간략하게만 살펴보자면 데이터베이스의 큰 손상으로 3일간의 서비스 장애를 겪은 이후부터라고 알려져 있다. 좀 더 유연한 서비스의 제공과 서버 관리를 위해 MSA를 채택하게 되었으며 플랫폼을 온 프레미스 환경에서 클라우드로 이전하는데 약 7년이라는 시간에 걸쳐 이전을 완료하였으며 이 과정에서 그 유명한 Netfilx OSS가 개발되었다.

 

 

MSA란?

 

간단하게 설명하면 MSA란 하나의 큰 서비스를 컴포넌트별로 작게 쪼개어 각각 독립적으로 동작하게 만드는 방법이다.

와! 내 방이 생겼잖아?!

 

각 컴포넌트별로 독립적인 서비스가 구성되며 타 서비스와는 API를 통해서만 통신하게 된다.

이때 발생되는 사용자 인증 문제나 권한 정책, 내부 API 서버 구조의 노출 등 다양한 문제가 발생되긴 하나

이는 서버 가장 앞단에 API Gateway를 통해 해결하였으며 이를 포함한 다른 자세한 메커니즘들은 나중에 심화로 따로 다룰 예정이다. (공부할 게 너무 많아요)

 

이렇게 서비스들을 작은 단위로 쪼갤 경우에는 모놀리틱의 단점이 MSA의 장점이 된다.

위에 언급한 내용으로만 정리를 하자면

 

1. 작은 프로세스의 수정에도 서비스 전체를 빌드, 테스트, 배포해야 한다.

=> 각 서비스는 독립적이니 해당 서비스만 작업하면 된다.

 

2. 트래픽이 몰리는 특정 도메인에서 만의 scale-out이 힘들다.

=> 확장이 필요한 서비스만 독립적으로 확장할 수 있다.

 

3. 다른 하나의 도메인에서의 장애로 인해 서버가 다운될 시 모든 도메인도 마비된다.

=> 해당 서비스만의 장애로 전체 시스템이 아닌 해당 서비스만의 격리가 가능해진다.

 

4. 신규 입사자의 코드 파악이나 유지 보수로 인한 코드 수정 시 양이 방대해 많은 시간을 필요로 한다.

=> 속한 팀의 코드를 빨리 파악하며 수정 시에도 연관성을 확인해야 할 부분이 대폭 줄어든다.

 

 

앞서 장점만 언급했으나 당연히 장점만 가득한 꿈의 아키텍처는 아니다.

 

비교적 단순하게 때려박으면(?) 되는 모놀리틱과는 다르게 각각의 서비스를 분리시키고 DB 또한 각각 사용하고 있으니 거기서 발생하는 다양한 문제점에 대해 고민하고 해결해야 한다.

 

대표적인 단점들을 살펴보면

 

1. 설계의 복잡도 증가

모든 서비스는 분리되어 독립적으로 동작중이나 하나의 플로우가 완성되려면 서로 유기적으로 동작해야 하기 때문에 통신 부분, DB 트랜잭션 부분, 장애 처리와 같은 설계의 복잡도가 증대된다.

 

2. 프로세스 처리 속도의 저하

1번과 비슷한 이유로 하나의 프로세스를 처리하는 과정에서 다른 서비스와의 통신이 필요할 경우 통신 시간 + 데이터 가공시간 등 여러 요소에 의해 모놀리틱에 비해 속도가 느리다.

 

3. 로그 관리

서비스별 각자의 로그를 쌓고 있기 때문에 로그의 취합이 어렵다.

 

4. 데이터 관리

서비스별 DB가 각각 따로 존재하여 특정 데이터를 한 번에 조회하는데 난도가 높으며 데이터의 정합성 또한 관리하기 어렵다.

 

5. 테스트

각 서비스별 단위 테스트는 좀 더 가볍게 진행할 수 있겠지만 쪼개진 서비스들은 어차피 거대한 하나의 서비스를 위한 것으로 통합 테스트가 불가피한데 서비스별 환경을 통일시키고 업무 조율 등 상당히 많은 인적 리소스를 소비하게 된다.

 

 

 

간략하게 MSA에 대해 알아보았다.

 

일부 기업들의 성공적인 마이크로 서비스로의 전환 때문인지 많은 기업들이 MSA를 채택하고 있는 추세라고 알고 있다.

백엔드 개발자 지망으로서 하나의 개념을 더 알게 되어 좋은 시간이었고 비슷한 강의를 찾아 간단하게라도 구현해보고 그 과정에서 배우는 것들도 추가적으로 정리할 예정이다.

 

2021년 배달의 민족에서 시행한 우아콘에 마이크로 서비스로 이관하면서의 일을 영상으로 발표한 게 있었는데

지금은 영상이 보이질 않는다... 실제로 모놀리틱에서 마이크로 서비스로 전환을 경험한 개발자의 발표도 추가적으로 보면 좋을 것 같아서 공유한다!

 

(배민 서비스 개발팀 김영한 님 발표 내용)

https://www.youtube.com/watch?v=BnS6343GTkY 

 

 

 

참조 사이트

 

http://clipsoft.co.kr/wp/blog/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98msa-%EA%B0%9C%EB%85%90/

마이크로서비스 아키텍처(MSA) 개념 소개 - CLIPSOFT

https://www.samsungsds.com/kr/insights/msa_and_netflix.html

넷플릭스로 알아보는 MSA

https://velog.io/@tedigom/MSA-%EC% A0% 9C% EB% 8C%80% EB% A1%9C-%EC% 9D% B4% ED%95% B4% ED%95%98% EA% B8% B0-1-MSA% EC% 9D%98-%EA% B8% B0% EB% B3% B8-%EA% B0% 9C% EB%85%90-3 sk2 8 yrv0e

MSA 제대로 이해하기 -(1) MSA의 기본 개념