[Architecture] MSA vs Monolithic

https://www.inflearn.com/

MSA vs Monolithic

---

개요

  MSA로 구성된 Service와 Monolithic으로 구성된 Service의 장단점과 각각의 Trade-Off를 비교하고 생각해본다. 

 

목차

• MSA는 어떠한 특징을 갖고 있을까?
• Monolithic Architecture는 어떠한 특징을 갖고 있을까?
• 둘 중 뭐가 더 좋은 Architecture일까?

 

소개

MSA(MicroService Architecture)란 무엇일까?

 

MSA란, 커다란 어플리케이션을 작고 간단한 서비스(Service)로 나누어 유지관리와 테스트를 간편화할 수 있고, 느슨하게 결합하게 하며, 개별적인 서비스 단위로 배포할 수 있고, 비즈니스 기능을 중심으로 체계화하는 "소프트웨어 설계 방법"이라고 할 수 있다.

 

트렌드에 민감해지고, 하나의 어플에 다양한 컨텐츠들이 들어서면서, MSA는 많은 주목을 받고 있다. 그렇다면 이러한 MSA를 사용한다면 어떠한 이점을 얻을수 있을까?

 

MSA의 이점은 무엇이 있을까?

 

확장성

  각 서비스를 독립적으로 배포할 수 있게됨으로 신규 업무 서비스의 확장시, 작은 서비스 단위로 빠르게 배포하여 확장할 수 있다.

유연한 테스트

  모놀리식으로구성되어 있는 프로그램의 경우, 많은 서비스들이 하나의 트랜잭션 혹은 서비스로 연결되어 있어 테스트를 하고자 하는 경우 전체 서비스를 돌려야 함으로, 테스트의 크기가 자연스레 커지게 된다. 하지만, MSA로 설계될 경우 작은 서비스별로 테스트가 가능하므로 모놀리식에 비해 더 작고 유연한 테스트가 가능하게 된다.

책임의 분리

  서비스가 많아지고, 업무가 커지게 되면 업무에서의 책임을 나누어야 한다. 이때, 모놀리식의 경우 서비스가 분리되어 있지 않아서 하나의 업무에 대해 명확한 업무 분리가 어렵게 된다. 특히 규모가 큰 회사일수록 신규 프로젝트에 대한 대응개발에 대해 기존 비슷한 서비스를 수행한 부서에서 로직을 수정할 것인지 신규 프로젝트를 추진하는 부서에서 비슷한 코드가 존재함에도 코드를 새로 추가할 것인지에 대한 R&R 구분이 어렵게 된다. 하지만, MSA를 사용하는 경우 로직을 수정해야 하는 Domain을 갖는 부서에서 R&R을 갖는 방향을 가질 수 있게 됨으로 조금 더 명확한 책임의 분리가 가능하게 된다. 이는 곧, 업무의 구분이 확실하게 되는것이고 불필요한 의견다툼을 줄여 프로젝트를 빨리 나아가게 할 수 있는 이점이 될 수 있다.

 

신뢰성

  에러가 발생한다면, 전체 서버가 멈출수도 있는 Monolithic과는 달리 MSA는 서비스별로 나누어져 있으므로, 에러가 발생한 서비스와 연관이 없는 서비스의 경우에는 에러 발생 없이 서비스를 지속할 수 있게 된다.

 

MSA는 분명히 뚜렷한 장점을 가지고 있다. 현대 IT 시장에서 분야의 경계는 허물어지고 있으며 하나의 어플리케이션에서 다양한 영역의 컨텐츠들이 빠르게 추가되어 나아가고 있다. 분명 이러한 측면에서, 확장성이 용이한 MSA는 이점이 있다. 하지만 실제 업무에서 MSA를 들여다보게 된다면, 우리는 많은 생각을 해보아야 한다.

 

그렇다면, MSA의 Trade-Off는 무엇이 있을까?

 

트랜잭션 관리의 복잡함

  MSA의 경우 작은 서비스 단위로 업무를 분리하게 된다. 기존 모놀리식의 경우는 하나의 서비스를 하나의 트랜잭션으로 관리하고 있거나, 서비스(혹은 시스템)가 하나의 파드 혹은 서버에 띄워져 있어 에러를 핸들링하거나 추적하기 용이하다. 하지만, MSA는 각 도메인(서비스)가 분리되어 있는 특성상 여러 서비스를 참조하게 되는 경우, 호출하게 되는 서비스별로 트랜잭션 및 에러를 관리해주어야 하고 에러가 발생하는 경우 Depth의 깊이에 따라 에러를 핸들링하는 방식이 까다롭다. 특히, 트랜잭션 중 오류가 발생되었을 때 해당 트랜잭션을 복원하는 과정은 Depth가 깊어짐에 따라 많이 고민해보아야 할 문제이다.

자원(리소스)의 비용
  일반적으로 MSA로 구현하면 클라우드와 연계하여 필요한만큼만 서버를 띄우기 때문에 비용이 절약되는것으로 오해하는 사람들이 많다. 하지만 실제로 이는 맞는말이 아니라고 생각한다. 토이프로젝트를 진행하다보면, 정말 작은 서비스에서 클라우드의 일부 기능만 사용하더라도 비용이 급격히 늘어나는것을 우리는 알 수 있다. 이를 실제 큰 규모의 프로젝트로 대입한다면 어떠할까? 트래픽이 증가하면, 이에 대응하기 위해 그만한 서버가 띄워지고 다시 트래픽이 감소하면 서버의 갯수를 줄일 수 있는것은 상당한 이점이다. 하지만, 기본적인 운영을 위한 파드를 띄우는데 드는 리소스와 그 외적인 비용들은, 기존의 일반적인 대형 서버를 둔 모놀리식의 비용과는 자원의 비용에서 꽤 큰 차이가 있다. 따라서, 클라우드를 기반으로한 MSA를 도입하고자 할 때에는 자원이 얼마나 필요할지에 대해서도 고민해보아야 할 문제라고 생각한다.

 

위에서 언급한 내용들 외에도, 조금만 더 검색을 해본다면 다양한 장단점들이 있음을 알 수 있다. 그렇다면, 이러한 MSA와 비교되는 Monolithic은 어떠한 특징들을 갖고 있을까?

 

Monolithic Architecture란 무엇일까?

 

Monolithic Architecture는 독립적이고, 통합단위로 구축된 아키텍쳐이다. 즉, 모든 비즈니스 로직이 하나의 코드 기반으로 결합되어 단일 네트워크 상에서 돌아가도록 설계된 거대한 구조물과 같은 방식의 설계 방법이라고 할 수 있다.

 

Monolithic과, MSA의 가장 큰 차이는 "비즈니스 로직이 하나로 결합되어 있는가" 혹은 "작은 서비스 단위로 나누어 서비스 단위로 구분되어 있는가"라고 생각한다. 여기서 우리는, 현대의 트렌드에서는 민첩하고 확장성이 좋은 MSA가 옳은것이 아닌가? 라고 생각할 수 있다. 하지만 이는 잘못된 생각이라고 생각한다. Monolithic Architecture의 장점은 데부분 MSA의 단점이다. 그렇다면 구체적으로 어떠한 이점이 있을까?

 

Monolithic Architecture의 이점은 무엇일까?

 

하나의 트랜잭션으로 관리

  MSA구조로 설계될 경우, 각 서비스 도메인은 자신의 업무를 처리하고 다른 도메인을 호출하게 된다. 이때, 각 도메인은 DB 처리와 로직을 끝마치고 다른 서비스를 호출하였는데 호출한 도메인에서 에러가 발생한다면 어떻게 해야할까? 에러가 발생한 도메인은, 자신을 호출한 도메인을 찾아서 에러가 발생했음을 알려주어야 한다. 또 에러를 전달받은 도메인은 자신의 서비스 도메인에서 발생한 에러가 아님에도 불구하고, 해당 에러에 대한 로직을 구현해 주어야하고, 만약 자신을 호출한 도메인이 또 있다면 해당 도메인에게 알려주어야할 수도 있게된다. 반면, Monolithic의 경우 일반적으로 하나의 네트워크에서 하나의 트랜잭션으로 관리되어 움직임으로 에러가 발생한다면, 해당 네트워크에서 에러를 받아 처리해주면 된다. 이러한 구조는 서버가 잘못되어 DB 데이터를 삭제해야하거나, DB 데이터를 다시 추가해주어야 하는 경우 상당한 이점을 가져올 수 있게 된다.

 

저렴한 비용

  Monolithic의 경우, 대형 서버 몇대를 구매하여 운영하면 된다. 흔히 말하는 Scale-Up 방식을 통해 좋은 컴퓨팅 자원을 사서 운영하는 방식이다. 이러한 방식은, 초기 구매 비용을 제외한다면 클라우드 자원에 비해 훨씬 저렴한 비용적 이점을 갖게된다. 하지만, MSA로 인해 클라우드로 전환되어 가는 시점에서, 대형 서버를 생산하고 업그레이드 하는 회사는 줄어들 것이고 이에 따라 특정 회사의 제품에 종속될수도 있는것은 고려해보아야 할 문제이다.

 

쉬운 배포

  MSA는 서비스의 규모가 작아서 빠르게 배포할 수 있다. 하지만, 많은 서비스들은 서비스별로 종속되어 있기 때문에 배포하기 전에 충분한 테스트를 거치고 수행되어야 한다. 반면, Monolithic은 하나의 서버를 실행하는 파일을 빌드하고 컴파일하여 End-To-End Test에 용이하여 테스트가 완료되면 단일 파일을 배포 하면 되기에 비교적 배포를 쉽게 할 수 있다는 이점이 있다.

 

이러한 장점에도 불구하고, MSA가 등장하면서 많이 비교되는 단점에는 어떠한것들이 있을까?

 

어떤 단점이 Monolithic Architecture를 뒤쳐지게 만들까?

 

확장성

  Monolithic은 단일 서버 혹은 네트워크로 되어 있기 때문에, 작은 기능 하나를 수정하여 배포하는데도 전체 서버를 다시 빌드하고 배포해야 한다. 이는 작은 서비스 단위로 운영되는 MSA에 비해 더 느린 확장성을 가져올 수 밖에 없는 치명적인 단점이다.

 

유연성, 그리고 느린 개발속도

  Monolithic은 꾸준히 Scale-Up 되어 왔기 때문에, 기존의 기술스택들이 확장되어 나아가는 형태가 많다. 이는 새로운 기술을 도입하는데에 어려움을 겪게 하고, 어플의 크기가 커짐에 따라 다양한 기능들이 하나의 서버안에 누적되어 녹아져 가게 됨으로, 필요한 기능들을 찾고 사용하는데에 어려움이 발생하는 단점이 있다.

 

둘 중 뭐가 더 좋은 Architecture일까 ?

 

나의 생각부터 말하자면, 아직은 모르겠다. MSA는 분명 현대 트렌드에 어울리는 명확한 장점을 갖고 있다. 하지만, 서비스에 맞는 도메인을 명확하게 구분해야 하고 클라우드 비용을 계산하고, 에러 핸들링을 어떻게 해야할지등과 같이 많은 고민을 필요로 한다. 또한, 업무의 규모에 따라 MSA의 장점을 살리지 못하게 될수도 있다. 예를 들어, 규모가 큰 서비스가 존재하고 이 서비스를 많은 서비스에서 참조하게 된다면 해당 서비스에 에러가 발생하였을 때, 해당 서비스를 참조하는 모든 서비스에서 에러가 발생하는 것이므로 신뢰성에서 큰 장점을 발휘하지 못하게 될수도 있다. 이처럼, 무조건적으로 MSA를 사용하는것이 옳다고 할수는 없다.

 

하지만, 산업의 경계가 허물어지고 금융앱에서는 비금융 서비스가, 비금융 서비스에서는 금융서비스가 나오는 현대 트렌드에서 빠르고 유연한 어플리케이션은 반드시 필요로 한다고 생각한다. 누구는 Monolithic이 맞고, 또 누구는 MSA가 맞고, 또 누구는 둘을 적절히 조화롭게 사용해야 한다고 말한다. 하지만 아직 나는 뭐가 정답인지 알수는 없다. 위에서 정리한 내용들을 바탕으로 하나씩 정립해 나아가다 보면 언젠가는 해답을 찾아낼 수 있을 것이라고 생각한다.