MicroService Architecture VS Monolithic Architecture

문상우·2023년 7월 2일

Microservice Architecture Monolithic Architecture msa

Architecture

목록 보기

1/1

MicroService Architecture를 알기전에 기존에 쓰이던 방식인 Monolithic Architecture를 알아야할 필요가 있다.

Monolithic Architecture는 단일 통합 단위로 구축되고, MicroService Architecture는 작고 독립적으로 배포 가능한 서비스 모음이다.

Monolithic Architecture란,

우리가 기존에 개발하던 방식으로, 흔히 하나의 프레임워크로 개발을 진행할 때, 사용되는 방식을 말한다. 특정 기능을 분리하지 않고 전체의 서비스를 하나의 도구, 하나의 프레임워크로 구성하는 것을 말한다.

MicroService Architecture란,

위에서 말한 것처럼 전체의 서비스를 하나로 집약시켜놓지 않고, 하나의 기능(서비스)별로 구분한 것을 말한다. 주문이면 주문, 결제면 결제 이런 식으로, 하나의 서비스에 필요한 일련의 과정을 모두 집약하여 개발하는 것을 말한다. 이러한 방식을 사용하여 여러 기능을 필요 조건에 맞게 다양한 기술로 개발하여 서로 호출하며 하나의 전체적인 서비스를 구성해 가는 것을 말한다.

그렇다면, 무조건 MicroService Architecture가 좋냐 ? 그렇게는 생각되지 않는다. 아래에서 각 기술에 대한 장점과 단점을 살펴보자

Monolithic Architecture 장점

모놀리식 아키텍처를 사용하여 개발할 때 주요 이점은 하나의 코드를 기반으로 하는 애플리케이션을 가짐으로, 이런 단순함을 통한 빠른 개발 속도이다.

손쉬운 배포 : 하나의 실행 파일 또는 디렉토리로 배포가 더 쉽다.
개발 : 하나의 코드 기반으로 애플리케이션을 구축하기에, 개발이 편하고 빠르다.
성능 : 여러개로 분산되어 있지 않고 하나의 중심에서 동작하기에, 속도가 빠르다.
간소화된 테스트 : Monolithic은 하나의 코드로 작성되어 있으므로, 테스트하기가 간편하다. 즉, 모두 한 코드로 작성되어 있고 함께 존재하기 때문에, End-to-End 테스트가 용이하다. (MSA는 테스트에 필요한 서비스들을 모두 동작시켜야 함.)
손쉬운 디버깅 : 모든 코드가 한 곳에 있으므로 요청을 따르고 문제를 찾기가 당연히 더 쉽다.
고가용성 : 고가용성 서버 환경을 만들 수 있다. (같은 어플리케이션으로 하나 더 만들면 끝)
단순성 : 어떤 기능이라도 같은 환경이므로 복잡하지 않다.

하지만, 결국 이런 장점들은 하나의 코드 기반으로 만들어도 부하가 크지 않고 복잡하지 않을 정도의 규모의 프로젝트를 진행할 때이다. 프로젝트의 규모가 커질 수록, 장점은 단점으로 변할 수 있다.

Monolithic Architecture 단점

모놀리식 애플리케이션은 너무 커져 확장이 문제가 될 때까지 매우 효과적일 수 있지만, 단일 기능에서 약간의 변경을 수행하려면 전체 플랫폼을 컴파일하고 테스트해야 한다. 이는 오늘날 개발자가 선호하는 확장성 좋은 설계와는 거리가 있다.

느린 개발 속도 : 대규모의 모놀리식 애플리케이션은 개발을 더 복잡하고 느리게 만든다.
확장성 : 개별 구성 요소를 확장할 수 없다.
신뢰성 : 모듈에 오류가 있으면 전체 애플리케이션의 가용성에 영향을 줄 수 있다. 즉, 일부분의 오류가 전체 프로젝트의 오류가 된다.
기술 채택의 장벽 : 프레임워크 또는 언어의 모든 변경 사항은 전체 애플리케이션에 영향을 미치므로 변경 사항에 많은 비용과 시간이 소요되며, 기능별로 알맞는 기술, 언어, 프레임워크를 선택하기 까다롭다.
유연성 부족 : 모놀리스는 모놀리스에 이미 사용된 기술의 제약을 받는다. 기존에 존재하는 기술의 이해도가 필요하며, 다른 기술을 쓰려고 해도 기존에 존재하는 기술과 호환이 되어야 한다.
배포 : 모놀리식 애플리케이션에 약간의 수정사항이 있어도 전체 모놀리식을 다시 빌드하고 배포해야 한다. 한 프로젝트의 덩치가 커지기 때문에 애플리케이션 구동시간이 늘어나고, 배포 시간도 길어진다.
유지보수 : 많은 양의 코드가 한번에 존재하기에, 개발자가 모든 로직을 이해하기 힘들고 이 때문에, 유지보수도 힘들어 진다.

MicroService Architecture 장점

마이크로서비스는 성장하는 소프트웨어와 회사의 많은 문제를 해결할 수 있다. 마이크로서비스 아키텍처는 독립적으로 실행되는 단위로 구성되므로 다른 서비스에 영향을 주지 않고 각 서비스를 개발, 업데이트, 배포 및 확장할 수 있다. 향상된 안정성, 가동 시간 및 성능으로 소프트웨어 업데이트를 더 자주 수행할 수 있다.

높은 이해 : Monolithic과는 다르게 기능별로 마이크로 서비스를 개발하여, 작업 할당을 서비스 단위로 하기 때문에, 개발자는 자신이 개발한 부분을 온전히 이해할 수 있게 된다.
안정성 : 각각 독립적으로 서비스를 개발, 업데이트, 배포 및 확장하기 때문에, 필요할 때마다 필요한 서비스만 빌드 + 배포가 가능해진다. 이를 통해 전체 애플리케이션을 중단시킬 위험 없이 특정 서비스에 대한 변경 사항을 배포할 수 있다.
유연성 : 특정 기술에 강한 언어와 프레임워크를 선택해 서비스를 구성할 수 있다. 즉, 여러 기술의 강점을 살릴 수 있다.
오류 : 일부분의 오류가 있으면 해당 기능에만 오류가 발생하고 그 부분만 빠르게 고쳐서 정상화가 가능하다.
빠른 업로드 : 팀은 새로운 기능을 실험하고 문제가 있는 경우 롤백할 수 있다. 이를 통해 코드를 더 쉽게 업데이트하고 새로운 기능의 시장 출시 시간을 단축할 수 있다. 또한 개별 서비스의 결함과 버그를 쉽게 격리하고 수정할 수 있다.
배포 : 위 장점들을 통해 릴리스 주기가 더 빨라지고 빈번해졌다. 이전에는 일주일에 한 번 업데이트를 푸시했지만 지금은 하루에 두세 번 정도 업데이트를 푸시할 수 있다.

MicroService Architecture 단점

복잡성 : 관리가 힘들어진다. 작은 여러 서비스들이 뭉쳐 하나의 서비스가 되기 때문에, 모든 서비스들에 대한 이해를 필요로 하고 모리터링 하기도 힘들어진다.
무분별한 개발 : 여러 팀이 만든 더 많은 장소에 더 많은 서비스가 있기 때문에 마이크로서비스는 모놀리식 아키텍처에 비해 더 복잡하다.
기하급수적 인프라 비용 : 각각의 새로운 마이크로서비스에는 테스트 스위트, 배포 플레이북, 호스팅 인프라, 모니터링 도구 등에 대한 자체 비용이 있을 수 있다.
추가된 조직적 오버헤드 : 팀은 업데이트 및 인터페이스를 조정하기 위해 또 다른 수준의 커뮤니케이션 및 협업을 추가해야 한다. 기존처럼 하나에 모든 서비스가 있는게 아니고 하나의 도구 또는 하나의 언어 및 프레임워크만 쓰는 것이 아니므로, 협업에 대한 부분에 있어 매우 상세한 설명이 필요할 것 같다.
디버깅 문제 : 각 마이크로 서비스에는 고유한 로그 집합이 있어 디버깅이 더 복합해진다. 또한 단일 비즈니스 프로세스가 여러 시스템에서 실행될 수 있어 디버깅이 복합하다.
연동 : 통신관려 오류가 잦을 수 있다. MicroService끼리 통신을 하니 하나로 되어 있는 Monolithic에 비해 통신관련 오류가 잦다. 또한, 연동을 위해 다른 서비스를 호출하는 코드가 추가되는게 이 부분이 Monolithic에 비해 매우 까다롭다고 한다.
테스트 : End-to-End 테스트를 위해 내가 만든 서비스 뿐 아니라, UI, Gateway 등 여러개의 MicroSerivce를 구동시켜야 한다. 테스트를 매번 이렇게 진행하면 매우 복잡해질 것 같다.

Monolithic VS MicroService

위 사진은 Monolithic Architecture와 MicroService Architecture를 간단하게 그려본 그림이다. MicroService는 서비스 별로 Business Logic 과 DataBase를 가지고 있는 반면, Monolithic Architecture는 서비스가 합쳐져 있어, 각 서비스 별로 분리되어 있지 않고, 하나의 DataBase를 공유하며 Business Logic 도 한곳에서 처리하는 것을 볼 수 있다. 이 그림을 통해 각 기술에 대한 이해를 높일 수 있다.

결론

개별적으로 하나의 언어 및 프레임워크를 공부하기 위해 사이드 프로젝트를 만들고자 프로젝트를 기획하고 있다면 Monolithic Architecture를 쓰는게 좋을 것 같다. 공부 목적이기도 하고, 하나의 프레임워크를 익히기에는 Monolithic Architecture가 개발 측면에서도 공부 측면에서도 좋을 것 같다.

하지만, 큰 프로젝트를 만들기로 다짐하여 여러 서비스(결제, 주문, 장바구니, 후기 등)를 만들어야 한다면, 이 때부터는 하나의 도구 및 프레임워크에 갇히지 않고, 서비스 별로 단위를 나눠 MicroService Architecture로 만드는 것이 적절하다고 생각한다. 물론 혼자서의 힘으로는 힘들겠지만, 요즘처럼 하나의 언어나 프레임워크에 국한되지 않고, 상황에 맞게 기술에 적합한 프레임워크를 선정해 개발하는 상황에서는 다른 프레임워크와의 연동, 통신을 해보는것이 큰 강점이 될 수 있을거라 생각한다. 아마 요즘 개발자들 사이에서 커뮤니케이션이 중요해지는 이유도 MicroService Architecture의 특징이라고 생각한다. 각자 다른 서비스를 개발하기에, 하나의 서비스로서 제공하기 위해서는 원활한 커뮤니케이션이 필요할 것이기 때문이다. 물론, 기존의 Monolithic Architecture보다는 어렵겠지만, 확장성 좋은 설계를 원한다면 MicroService에 대한 깊은 이해가 필요할 것 같다.