마이크로서비스 아키텍처란 무엇일까?
우선, 제가 구글에서 검색했을 때에는 다음과 같이 나왔습니다.
- 작고, 독립적으로 배포 가능하며 개별의 기능을 수행하는 프로덕트들로 구성된 시스템
- 하나의 큰 어플리케이션을 여러 개의 작은 어플리케이션으로 쪼개어 변형과 조합이 가능하도록 한 아키텍쳐
마이크로서비스 아키텍처라는 것이 등장하기 전에는 모놀리식 아키텍처라는 구조가 가장 흔하게 접할 수 있고, 많이 보아왔으며, 가장 흔하게 사용되던 아키텍처였습니다.
Monolithic이 “하나로 짜여 있는”이라는 의미를 가지고 있는데, 모놀리식 아키텍처는 말 그대로 하나의 큰 애플리케이션 안에서 서로 필요한 기능을 호출하고, 응답하는 방식의 아키텍처입니다.
소규모의 애플리케이션에서는 개발 속도가 빠르고, 난이도도 쉬워 크게 문제가 되지 않았지만 대규모 애플리케이션에서는 오히려 복잡도가 엄청나게 증가하고, 이로 인해 유지 보수가 쉽지 않다는 문제점이 발생했습니다.
따라서 모놀리식 아키텍처의 문제점을 인식하고 이를 개선하기 위해 새로운 방식의 아키텍처가 등장했는데, 이 아키텍처가 바로 마이크로서비스 아키텍처입니다.
마이크로 아키텍처란, 하나의 큰 애플리케이션을 여러 작은 애플리케이션으로 분리하여 필요한 기능을 컴포넌트간의 통신으로 호출하는 방식의 아키텍처입니다.
하나의 서버에 모든 서비스를 구동하던 이전과는 다르게, 필요에 맞게 개발 스택을 골라 각기 다른 서버에서 작게 분리한 애플리케이션을 구동한다는 것이 모놀리식 아키텍처와의 가장 큰 차이점입니다.
모놀리식 아키텍처의 문제점은 무엇일까?
모놀리식 아키텍처의 주요 문제점은 다음과 같습니다.
- 다양한 기능이 추가될수록 서비스의 복잡도 증가
- 작은 기능 하나의 배포를 위해 전체 서비스 재배포 필요
- 서비스 배포 / 빌드 / 테스트 시간이 오래 걸림
- 작은 버그 하나가 전체 서비스에 영향을 끼칠 가능성이 큼
- 높은 모듈간의 결합도로 인한 유지 보수의 어려움
- 시스템 확장이 유연하지 못 함
위에서 언급했듯이 소규모의 애플리케이션에서는 크게 문제점이 드러나지 않지만, 규모가 클수록 이와 같은 문제점이 뚜렷하게 드러나게 됩니다.
넷플릭스, 우버와 같은 글로벌 기업은 물론이고 카카오와 삼성, 그리고 우아한형제들과 같은 국내 대기업 및 스타트업에서도 위와 같은 문제점으로 인해 유지보수가 한계에 이르자 완전히 아키텍처를 변경하여 서비스를 개선하였습니다.
마이크로서비스 아키텍처를 적용하여 얻을 수 있는 이점은?
모놀리식 아키텍처를 사용했을 때의 문제점을 해결할 수 있다는 것이 제일 큰 이점이라고 할 수 있지만, 조금 더 구체적으로 말해보자면 다음과 같습니다.
-
각각의 서비스가 독립적으로 개발 및 배포가 가능하기 때문에 보다 더 유연하게 서비스를 운영할 수 있습니다.
다양한 서비스를 운영하는 대기업에서는 각각의 서비스마다 전담 팀을 만들어 운영함으로써 독립적으로 개발 및 배포 작업을 수행할 수 있습니다.
따라서 다른 서비스와 상관 없이 하나의 서비스에만 집중할 수 있기 때문에 더 유연하게 서비스 운영이 가능합니다.
-
소비자의 피드백을 빠르게 수용하여 반영할 수 있습니다.
더 유연하게 서비스를 운영할 수 있다는 말의 연장선이라고 볼 수 있을 것 같습니다.
독립적으로 개발 및 배포가 가능하기 때문에 보다 더 자유롭게 피드백을 반영할 수 있습니다.
-
높은 확장성을 가지고 있기 때문에 빠르게 성장하는 대규모 서비스에 적합합니다.
모놀리식 아키텍처의 문제점을 본다면 너무나도 당연한 이야기라고 생각합니다.
특정 서비스에서의 추가 기능 개발이 다른 서비스에 영향을 줄 일이 거의 없다시피 하기 때문에 서비스 운영에 장애를 일으킬 가능성이 거의 없습니다.
또한, 빠르게 증가하는 트래픽에 맞게 특정 서비스에서 사용하는 서버 자원을 탄력적으로 조절하여 원활한 서비스를 제공할 수 있습니다.
마이크로서비스 아키텍처의 장단점
당연하게도 이전 아키텍처에 비해 엄청나게 매력적인 장점을 가지고 있기 때문에 여러 글로벌 기업에서 채택하여 적용했을 것입니다.
그럼 마이크로서비스 아키텍처의 장점에는 무엇이 있을까요?
장점
- 단위 서비스에 집중하는 것이 수월하여 높은 생산성을 지니고 있습니다.
- 단위 서비스의 복잡도가 많이 낮아집니다.
- 트래픽이 높은 서비스에 한해 독립적으로 서비스 스케일 조정이 가능합니다.
- 서비스 특징에 맞는 개발 스택을 사용할 수 있고, 유연하게 신기술을 적용할 수 있습니다.
하지만 이전의 문제점 많은 아키텍처를 개선한 것이라고 단점이 존재하지 않다는 말은 아닙니다.
그럼 단점은 무엇이 있을까요?
단점
- 분산 환경이기 때문에 아키텍처 구성 비용 관리 및 모니터링 대상이 증가합니다.
- 데이터베이스 트랜잭션 또는 테스트와 같은 문제로 인해 설계가 어렵다.
각 서비스 간 통신 패턴에는 어떤 것이 있을까?
-
API Gateway Pattern
클라이언트로 받은 요청을 API Gateway를 통해 하위 컴포넌트로 전달하는 방식입니다.
API Gateway를 통해 Authentication이나 Logging 작업과 같은 공통 작업을 처리가 가능합니다.
Encapsulation의 장점이 있어 비즈니스 로직 노출을 최소화 할 수 있습니다.
하지만 API Gateway의 Scale-Out이 원활하게 이루어지지 않을 경우에는, 이 부분에 트래픽이 몰려 병목 지점이 될 수 있습니다.
또, 추가적인 계층이 만들어지기 때문에 그만큼의 지연 시간이 생길 수 있습니다.
-
Event Driven Pattern
이 패턴은 Event Store를 통해 각 컴포넌트에서 이벤트 발행 및 구독을 통한 통신하는 방식입니다.
비즈니스의 흐름에 따라 서비스 기능을 수행할 수 있으며, 비동기적으로 로직 처리가 가능하기 때문에 응답 지연 시간을 줄일 수 있습니다.
데이터베이스 트랜잭션이 용이하기 때문에 Eventually Consistency(최종적 일관성)을 유지할 수 있습니다.
최근 2020년도 우아한테크콘서트에서의 발표 세션 중 하나가 마이크로서비스 아키텍처 적용기였는데, 우아한형제들에서는 Event Driven Pattern 방식을 통해 컴포넌트 간 통신을 구현하였습니다.
결론, 글을 작성하며 느낀 점
이를 보고 최근 웹 개발 시장에서 마이크로서비스 아키텍처라는 단어는 정말 어디에서든지 등장하는 핫한 키워드인 것 같습니다.
요즘에는 마이크로서비스 아키텍처에 기반하여 프론트엔드에서도 동일한 아키텍처를 적용하여 개발하는 마이크로 프론트엔드라는 개발 방법도 등장했습니다.
그만큼 이 아키텍처가 가지는 이점이 굉장히 매력적일 것이라 생각을 하여 이에 대해 열심히 찾아보며 공부를 진행했습니다.
공부를 하면 할 수록 최근 관심을 가지고 찾아봤던 다양하고 복잡한 기술이 들어가 매우 흥미로웠지만, 가장 먼저 이 아키텍처를 적용한 애플리케이션을 과연 혼자서 개발할 수 있을까하는 생각이 들었습니다.
처음 개념을 보고서는 되게 어렵다고 느껴지기도 했고, 모놀리식 아키텍처에 비해 해야 할 업무가 방대하게 늘어나기 때문에 혼자서는 많이 힘들지 않을까하는 생각이 듭니다.
그래도 작은 서비스일지라도 혼자서 만들어보고 싶다는 욕심이 계속 들기도 하고, 웹 개발 트렌드에 뒤쳐지지 않아야 할 것 같아 서브 프로젝트를 계획해야겠다는 생각을 가지게 되었습니다.
비록 개발 속도는 엄청나게 느릴지라도, 이를 통해 배워갈 것이 엄청나게 많을 것 같다는 느낌이 듭니다.
Source
-
MSA(Micro Service Architecture)로의 전환
https://medium.com/myrealtrip-product/msa-micro-service-architecture-로의-전환-6caa8efa2380
-
2020 Woowacon - 배달의민족 마이크로서비스 여행기
-
WikiPedia - Microservice Architecture