[MSA] Monolithic Architecture VS Micro Service Architecture

이번 포스팅에서는 MSA 에 대해서 알아보도록 하겠습니다.

MSA 는 micro service architecture 의 줄임말로서 하나의 큰 어플리케이션을 여러 개의 작은 어플리케이션으로 나눠 만드는 아키텍쳐 입니다.

MSA 가 등장하기 이전에는 하나의 서비스는 하나의 어플리케이션으로 만드는 것이 일반적이었죠. 이를 Monolithic architecture, 모놀리식 아키텍쳐 라고 합니다.

MSA 에 대해서 자세히 알아보기 전에 모놀리식 아키텍쳐 에 대해서 알아보고 왜 MSA 가 등장하게 되었는지 알아보도록 하겠습니다.

 

Monolithic Architecture

Monolithic 의 뜻을 사전에 검색해보면 단단히 짜여 하나로 되어 있는 라는 의미라는 걸 알 수 있습니다.

말 그대로 하나의 프로젝트에 대해서 하나의 어플리케이션이 대응되게 됩니다.

그렇기 때문에 이 어플리케이션은 큰 규모를 이루게 됩니다.

Monolithic Architecture 의 장점과 단점을 비교해보고 왜 MSA 가 나왔는지 알아보도록 합시다.

장점

• 로컬 환경에서 개발이 편리
• 통합 시나리오 테스트 진행이 수월
• 배포가 간편

단점

• 코드의 수정 및 추가가 힘듦
• 효율적인 자원 관리가 힘듦
• 자주 업데이트 불가능
• 새로운 기술 적용이 힘듦
• 부분의 장애가 서비스 전체적인 장애
• scale out 이 불가능
  scale out 에 대해서만 따로 포스팅을 쓸 예정이지만 간단하게 소개 해드리겠습니다.
  서버를 운영하다보면 갑작스런 이용자의 증가, 사업 확장 등의 이유로 더 많은 서버 용량과 성능이 필요하게 됩니다.이럴 경우 서버를 확장시키는 여러 방법이 있는데 scale out 은 서버를 여러 대 추가하여 확장하는 방법입니다.
  만약 기능 별로 분리가 되어 있다면 수강신청의 경우, 로그인하는 서버와 수강신청을 하는 서버만 확장을 시킴으로서 많은 트래픽을 견딜 수 있지만 기능 별로 분리가 안 되어 있다면 모든 서버를 통째로 추가해야 할 것 입니다.
  예를 들면 대학교의 수강신청 등이 있겠네요.
  
  

장점과 단점 모두 Monolithic Architecture 의 공통적인 특징, 단순함 때문에 야기됩니다.

프로젝트가 하나의 어플리케이션으로 이루어져 있으니 개발하기도 편하고, 전체적인 테스트가 수월합니다. 당연히 배포도 하나의 어플리케이션만 하면 되겠죠.

하지만 프로젝트 규모가 점점 커질수록 단순함은 독이 됩니다.

너무 많은 기능들이 하나의 어플리케이션에 묶여있다보니 서로 의존성이 높아지고 이는 개발자들에게 있어서는 이해하기 어려운 코드가 될 것 입니다.

 

이러한 장단점이 극명하기 때문에 Monolithic Architecture 가 좋지않다고만 볼 수는 없습니다.

실제로 아직 많은 소프트웨어가 Monolithic 방식으로 개발되고 유지되고 있으며 특히 소규모 프로젝트의 경우에는 특별히 나눌 필요없이 Monolithic Architecture 가 더 합리적일 수 있습니다.

하지만 프로젝트의 규모가 커지고 한 프로젝트에 속한 개발자가 많아질수록 부적합해집니다.

다들 아시다시피 최근에 등장하는 프로젝트들은 모두 규모가 크고 많은 기능들을 필요로 합니다. 대체로 그렇습니다.

그렇기 때문에 MSA 가 등장하였고 더 각광받은 것이죠.

 

Micro Service Architecture

MSA 무엇인지는 서론에서 알아봤으니 바로 특징을 알아보도록 합시다.

장점

• 빌드 및 테스트 시간을 단축
  물론 처음부터 끝까지 서비스를 빌드하고 테스트하는 시간은 같습니다.
  하지만 개발을 하다보면 부분적으로 테스트를 해야하는 순간도 필요할텐데 MSA 는 이를 가능하게 하여 시간을 절약할 수 있습니다.
• 유연하게 기술을 적용
  서버가 분리되다보니 각 서버의 언어와 프레임워크도 유연하게 가져갈 수 있습니다.
  auth 서버는 django 로 채팅서버는 node로 구현하는 방식으로 말이죠.
• scale out 가능
  위에서 언급했으니 넘어가겠습니다.
• 서비스간의 연관성 낮음
  연관성이 낮은 건 부정적으로 보일 수도 있지만 아주 긍정적인 부분입니다.
  한 서버에서의 문제가 다른 서버에 영향을 미치지 않게 되므로 긍정적인 부분입니다.
  물론 문제가 생긴 서버가 다른 서버를 호출하는 경우에는 이야기가 좀 달라지긴 하지만 이건 다음에 알아보도록 하겠습니다.

단점

• 성능 이슈
  Monolithic 의 경우 다른 기능을 호출할 경우 같은 프로젝트 내에서 method 호출로 끝납니다.
  이는 단순히 메모리 안에서 일어나 매우 빠르고 문제의 소지가 적습니다.다른 서비스 간에 Network 통신(주로 http)을 주고 받게 됩니다.
  method 를 호출하는 것과는 많은 차이가 있죠.
  하지만 Micro Service Architecture 의 경우에는 이렇게 단순하게 처리할 수 없습니다.
• 트랜잭션이 불편
  서버가 나뉘고 다른 서버 간의 트랜잭션 처리를 해야할 경우, 불편함이 따릅니다.
  트랜잭션을 위한 로직이 또 필요해지죠.
• 개발 시간 증가
  MSA 는 서버가 분리 됨에 따라 이에 따라 관리가 필요합니다.
  DB가 서버에 맞춰 증가할 수도 있고, 로깅, 모니터링, 배포, 테스트 등 여러 관리에 신경을 더 써야하죠.

MSA 를 어떤 기준으로 나눠야할까?

이제 MSA 가 작은 어플리케이션으로 나누는 건 알겠는데 그렇다면 어떻게 나눠야 할까요?

정말 어려운 질문이고 사실 정답은 없습니다.

세계적인 기업 우버의 사례를 통해 어떻게 나눠야 하는지 방향을 잡아보도록 합시다.

우버도 처음에는 Monolithic Architecture 를 통해 개발되었습니다.

하지만 지금처럼 세계적인 기업으로 성장하는 과정에서 여러 문제에 직면하였습니다.

위에서 봤던 Monolithic Architecture 의 문제점이었죠.

하나의 기능을 수정하고 테스트 해보기 위해서는 시간이 너무 오래 걸리고, 개발자 수가 늘어나면서 그 많은 개발자들이 하나의 서비스에 매달려있는 것이 여러 문제를 야기했습니다.

결국 우버도 MSA 를 적용하였고 문제점들을 해결할 수 있었습니다.

우버는 차량을 찾고 원하는 차량을 찾으면 요금을 지불하는 방식의 서비스 입니다.

원하는 차량을 찾기 위해서는 평균적으로 몇 번의 검색이 필요할까요?

제가 이 정답을 알지는 못하지만 결제보다는 차량 조회에 트래픽이 훨씬 많이 몰린다는 것은 에측할 수 있습니다.

역시 우버는 차량 조회를 따로 서비스로 분리하였고 이에 대한 scale out 을 통해 유연하게 대처하고 있습니다.

우버의 예시처럼 기본적으로 기능 별로 분리하고 특히 기능 중에서 많은 트래픽이 예상되는 부분은 따로 분리하는 것이 좋습니다.

유저의 인증 서버나 조회와 같이 말이죠.

 

마무리

두 아키텍쳐에 대해서 비교하고 각각의 장단점을 살펴보았습니다.

Monolithic Architecture 의 대안으로 Micro Service Architecture 가 나온 것은 맞지만 후자가 전자보다 좋다고는 절대 말할 수 없습니다.

각 프로젝트의 상황에 맞게 적절한 아키텍쳐를 고르는 것이 가장 현명한 방법일 겁니다.