‘마이크로서비스 vs 모놀리식’ 무엇을 선택할까?
마이크로서비스(Microservice) 아키텍처란?
다음 사항을 만족해야 마이크로서비스 아키텍처라고 정의할 수 있습니다.
주변 서비스와 관계 없이 독립적으로 개발, 배포 및 관리가 가능해야 합니다.
Pub-Sub 패턴을 통해 서비스간 통신을 수행합니다.
단일 책임 원칙을 따라야합니다.
※ 단일책임원칙 (Single Responsibility Principle) : 하나의 클래스(객체)는 하나의 책임만 가지며, 그 책임을 완전히 캡슐화함을 일컫는다.느슨하게 결합되어 있습니다.
따라서 ‘마이크로서비스’ 아키텍처라고 불리는 것 중 위의 사항을 아무것도 따르지 않는다면, 그것은 마이크로서비스가 아닙니다. 또한 다음과 같은 환경의 특징들을 가지고있다면 마이크로서비스 아키텍처가 아닙니다.
데이터베이스 (물리적 또는 논리적)를 공유합니다.
Sync방식으로 통신합니다. (REST를 사용한 Service to Service 호출)
Infrastructure를 공유합니다.
상황 파악을 위해서 주변 서비스들의 기초 지식을 알아야만 합니다.
모놀리식(Monilithic) 아키텍처란?
모놀리식 아키텍처는 소프트웨어 개발을 위한 기본 접근 방식입니다. 단일 코드 베이스로, 예를들어 코드 베이스가Java라면 , 전체 애플리케이션은 모두 Java로 작성되어야 하며, 단일 데이터베이스에 연결됩니다.
따라서 모놀리식으로 개발된 애플리케이션은 마이크로서비스 아키텍처보다 구현이 쉽고, 덜 복잡하다는 장점이 있습니다. 그러나, 하기의 사유들 때문에 우리들은 아키텍처의 전환을 도모합니다.
모놀리식 아키텍처는 중소형 애플리케이션에서는 잘 작동하지만 규모카 커질수록 유지보수에 들어가는 비용이 급격히 늘어납니다.
모듈간 강하게 결합되어 있어, 애플리케이션의 일부 부분에 수정이 필요하면 연관된 모듈들도 추가/수정이 필수적입니다.
모든 팀이 동일한 코드, 동일한 프로젝트에서 작업하기 때문에 코드 병합에 대한 충돌이 일어나기 쉽습니다.
미니서비스(Miniservice)란?
지금까지 기존에 많이 사용되어왔던 모놀리식 아키텍처, 그리고 모놀리식에서의 전환 목표가 되는 마이크로서비스를 알아보았습니다. 그렇다면 미니서비스는 무엇일까요 ?
미니서비스는 비즈니스 요구사항을 해결하기 위해 패턴으로 함께 모인 마이크로서비스그룹으로써, 서비스로서의 단일 기능을 말합니다. 다음과 같은 경우 미니서비스라고 정의할 수 있습니다.
여러 응용 프로그램이 동일 데이터베이스를 공유합니다.
서비스는 REST API를 통해 서로 통신하며, 비동기 통신을 위한 이벤트 기반 아키텍처를 수용하지 않습니다.
배포를 위한 인프라를 공유합니다.
Conclusion : 언제 무엇을 사용하는 것이 좋을까?
결론은 상황에 따라 다르다는 것입니다. 모든 프로젝트의 비즈니스 요구사항은 상이할 수 밖에 없습니다. 여러 코드 저장소에 기능이 있는 경우 마이크로서비스 아키텍처를 채택하는 것이 좋을 수 있으나, 단일 코드 저장소에 여러 기능이 있거나, 하나의 서비스에 여러 기능이 있는 경우 미니서비스가 좋은 대안이 될 수 있습니다.
복잡성이 증가하나 다른 서비스와 통신할 필요가 없는 경우 미니서비스를 채택할 수 있으며, 반면 비동기 통신이 필요한 독립 기능이 존재한다면 마이크로서비스를 채택하는 것이 나을 것입니다.
아키텍처는 여러 비즈니스 상황을 고려하여 선택해야 합니다. 최근 마이크로서비스가 대세라고는 하나, 적합하지 않은 경우도 많이 존재합니다.
ktds 구성원들이 Tech를 다루지만, 항상 비즈니스를 염두에 두고 고민을 해야 함을 뜻합니다. 이번 기회에 블로그 컨텐츠를 작성하며 아키텍처에 대해 공부할 수 있는 좋은 기회였고, 현 비즈니스 상황에 최적화된 아키텍처를 선택하셨으면 좋겠습니다