Intro

MSA냐 Monolithic이냐...상황에 따라 많은 논란이 될 수도 있는 주제라 생각한다.
어떤 상황에서는 굳이 MSA를 채택한다고 해서 좋을 게 없을 수도 있다.

이번 포스팅에서는 두 구조를 비교 해 보도록 하겠다.

차이점

우선 두 아키텍쳐에 대해 설명하기 전에 확실한 차이점 부터 언급하고 진행하도록 하겠다.
배포를 하는 단위가 하나의 통합 된 유닛이냐, 각각이냐로 구별 할 수 있다.
모놀리식 아키텍쳐는 하나의 거대한 서비스를 전체적으로 빌드하고 배포한다면, 마이크로 서비스는 N개의 서비스가 존재하고 각자 따로 배포가 진행된다.

Monolithic Architecture

학부 시절에 개발하는 다양한 과제 목적의 서비스는 모놀리식 아키텍쳐를 채택했을 가능성이 매우 높다.
모놀리식이라는 단어 자체로 이해할 수 있듯이, 하나의 큰 서비스라고 생각하면 된다.
웹 서비스라는 큰 틀에서 하나의 거대한 아키텍쳐가 존재한다. UI 뿐만 아니라 데이터베이스, 비즈니스 로직 등이 하나의 큰 아키텍쳐 내에 존재하는 구조다.

당연히 그렇게 하는 것 아닌가 라고 생각할 수 있다. 사실 학부 수준의 과제 프로그램에서 MSA 라고 부를 법한 규모의 프로젝트를 개발 한 적은 일단 필자의 경험에서는 없다.

조금 이해가 안 될 수 있으니 예시를 하나 들자면, 쇼핑몰 웹 서비스를 하나 론칭한다고 생각 해 보면 이해하기 쉽다. React.js로 프론트엔드를 개발한다고 해도 배포 할 때 하나의 WAR나 JAR로 함께 빌드하는 게 가능하다. React.js 도 결국엔 빌드하고 나면 바닐라 자바스크립트 코드들이고 HTML, CSS, Javascript 코드들은 Apache 와 같은 웹 서버에서 동작하게 된다. 그러므로 단순히 프론트엔드와 백엔드를 분리했다고 해서 MSA를 구축했다고 하기에는 무리가 있다.

즉 다시 요약하자면, 빌드할 때 단 한번의 빌드로 프로젝트 전체를 배포 할 수 있다면 해당 서비스 아키텍쳐는 모놀리식이라고 할 수 있다.

장점은 빌드 후 배포하는 게 상당히 쉽다는 것. 한 번의 배포로 모든 프로젝트가 빌드되고 그대로 배포하면 그만이다. 또한 HA 구조를 택하기 매우 쉬워진다. 그냥 하나 더 구축하면 그만이다.

단점은 한번 프로젝트가 진행되고 나면 기술스택의 변경이 매우 힘들어진다. React.js 와 Spring Framework 를 연동하고 MySQL DB를 사용하는 상황을 가정해보자. 만약에 React.js 말고 다른 스택을 사용하려면, 모든 코드를 전부 뜯어고치는 건 너무 당연한 얘기고 빌드 방식 또한 바꿔야 한다. 함께 빌드한다는 가정하에 React.js 관련 설정들을 전부 뜯어 고쳐야 한다. UI 만 해도 이런데 만약 특정 비즈니스 로직에 필요한 기술스택을 변경해야 한다면, 모든 코드를 죄다 뜯어고쳐야 하는 상황이 올 수 있다.

뿐만 아니라 빌드 그 자체가 상당히 오래걸린다. 단순히 React.js + Spring 으로 빌드한다고 해도 각각을 빌드하는 데 얼마나 시간이 걸릴지는 경험자들은 대충 감이 올 것이다. 개인 프로젝트 수준으로 작업한다고 해도 상당히 오래걸린다. 코드 한, 두줄 변경하고 테스트하려고 또 그걸 반복해야 한다. React.js + Spring 의 예시가 아니라고 해도 마찬가지다. 프로젝트의 덩치가 점점 커지면 커질수록 특정한 하나의 비즈니스 로직에 대한 코드를 변경했음에도 불구하고 이걸 테스트 해 보기 위해 아주 괴로운 빌드시간을 견뎌야 할 수도 있다. 또한 DB의 성능이 크게 하락할 수 있다. 또한 각 프로젝트 요소들 간에 결합도가 상당히 높아질 수 있다.

Micro Service Architecture

앞서 말했듯 MSA는 단순히 백엔드 프론트엔드를 분리 한 구조만을 얘기하는 것은 아니다. 조금 더 명확하게 보자면, 하나의 프론트엔드 UI 를 공유하더라도 각각의 서비스가 모두 분리된 상황을 생각하면 쉽다.

쇼핑몰을 구축한다고 생각 해 보면, 제품에 대한 비즈니스 로직과 결제등의 비즈니스로직들을 각각의 서비스로 분리해서 개발하는 구조를 의미한다.

쇼핑몰에서 결제 시스템에 이슈가 생겼다고 가정 해 보자. 모놀리식 아키텍쳐라면 모든 서비스가 중단 될 가능성이 크다. 하나의 프로젝트에 결제 비즈니스 로직이 포함되어있기 때문이다. 유저 입장에서는 결제 시스템이 에러가 났을 때 전체 서비스를 사용할 수 없다면 제품들에 대한 정보 또한 조회할 수 없기 때문에 서비스의 품질에 상당히 불편함을 느낄 수 있다.

MSA로 해당 서비스를 구축한다면 결제 부분만 점검중이라는 공지 하나 띄우면 된다. 즉 아이쇼핑 정도는 유저들이 할 수 있다. 결제야 점검 끝나는대로 하면 되는거니까.

MSA의 장점은 이 처럼 서비스 간에 결합도가 낮아지기 때문에 서비스의 개발 및 업데이트가 상당히 유연해질 수 있다. 각 서비스 별로 빌드가 따로 진행되기 때문에 좀 더 에자일하게 서비스 개발을 진행할 수 있다. CI/CD에 상당히 유리한 구조가 되고 테스트 또한 서비스 별로 따로 진행할 수 있다. 또한 서비스 각각에 필요한 기술스택을 선택하는 데 매우 유연한 선택지를 가질 수 있다. 그리고 단순히 HA구조 등 서비스를 확장할 때 단순히 서버만 여러대 두는 게 아닌 아주 다양한 방식으로 유연하게 서비스를 확장시킬 수 있다.

단점은 유지보수 그 자체의 문제점이라고 할 수 있다. 각각이 분리 된 서비스인 만큼 유지보수 비용이 많이 들 수 있다. 즉 개발 그 자체의 난이도가 상당히 올라가고 유닛 테스트가 유리한 만큼 통합 테스트가 어려워진다. 또한 CI/CD에 유리한 구조라는 건 배포 그 자체에 대한 난이도가 올라간다는 얘기고 트랜잭션 관리가 상당히 어려워진다.

Outro

반드시 Monolithic이 나쁜것도 아니고 MSA가 좋은것도 아니다. 프로젝트의 규모가 작다면 굳이 MSA를 처음부터 구축 할 필요는 없다고 생각한다. 팀의 규모가 작고 프로젝트가 시작 단계라면 우선 Monolithic으로 개발 하며 추후 하나하나 분리하는 방향을 선택하는 게 모범적인 방안이라고 생각한다.

다음 포스팅의 주제는 Service Oriented Architecture. 곧 돌아오겠다.

Reference

https://www.atlassian.com/ko/microservices/microservices-architecture/microservices-vs-monolith