‘스프링 5.0 마이크로서비스 2/e’ 라는 책을 읽으며 이 책에게 가장 많이 했던 질문이다. “마이크로서비스가 도대체 뭐야?” 아직 이 책의 중반부를 읽어가고 있지만 중간 회고를 하듯 마이크로서비스가 무엇인지에 대하여 나와 같은 고민을 하는 분들에게 조금이라도 도움을 드리고자 한다.
Monolithic or Microservices
아직 마이크로서비스에 대해 잘 모르는 분들은 아마 모놀리식(Monolithic) 아키텍처에 익숙할 것이다. 만약 모놀리식 아키텍처에 대한 개념을 모른다고 생각해도 아래의 글을 보면 이미 익숙한 개발방식 이란걸 알아챌 것이다. 그럼 마이크로서비스 아키텍처를 알아보기 전에 우리에게 익숙한 모놀리식 아키텍처를 먼저 살펴보자.
Monolithic architecture
모놀리식(Monolithic)의 사전적 정의는 “단단히 하나로 짜여져있는”, “획일적이고 자유가 없는” 이라는 의미이다. 단어의 의미와 같이 모놀리식 아키텍처는 하나의 어플리케이션에 사용자가 필요한 모든 기능이 개발되는 방식을 일컫는다.
위의 그림을 살펴보면 하나의 어플리케이션 안에 여러 서비스(Accounting, Inventory, Shipping Service)가 패키지별로 나뉘어진 모습을 볼 수 있다. 간단히 예를 들면 스프링 프레임워크를 이용하여 어플리케이션을 개발하고 jar 혹은 war 파일로 빌드하여 서버에 배포하여 서비스하는 형태가 바로 모놀리식 아키텍처인 것이다. 이처럼 하나의 어플리케이션에 모든 기능이 개발되고 배포되는 형태가 가져오는 이점과 문제점 그리고 한계에 대하여 알아보자.
- 장점
- 트랜잭션(Transaction) 설정이 단순하여 트랜잭션 처리에 관한 이슈가 적다.
- 인프라 구성(Infra structure)이 단순하기 때문에 관리가 편하다.
- 배포(Deploy)가 간편하다.
- 테스트(Test)하기 쉽다.
- 개발에 사용되는 언어가 적어 러닝커브(Learning curve)가 낮다. - 단점
- 확장성(scaling)이 낮아 여러 서비스별 기능을 확장시키기 힘들다.
- 에러가 발생할 경우 서비스 전체에 영향을 미치게 되어 클라이언트가 중단된다.
- 서비스(기능)이 많을수록 어플리케이션의 덩치가 커져 개발 및 유지보수가 점점 더 어려워진다.
- 언어 및 프레임워크의 버전업이 필요할 경우 고려할 사항이 많아 매우 힘들며 아키텍처 특성상 안정적인 버전을 고수하게 된다.
모놀리식은 우리에게 익숙하며 마이크로서비스에 비해 개발하고 서비스하기 편리하지만 기술이 발전과 사용자의 증가율에 따라 우리는 전통적인 개발방식에 대하여 한계를 느끼기 시작하였고 서비스를 운영하는 대다수의 기업들은 한계를 해결하기 위하여 다양한 시도를 하게 되었다.
Microservice architecture
마이크로서비스(Microservice)는 한마디로 작은 단위 서비스의 집합체이다. 하나의 어플리케이션을 개발하는데 단일 서버 / 클라이언트만을 사용하여 인프라를 구성하는 구조가 아닌 어플리케이션 내부의 기능을 서비스 단위로 분리하여 서비스 하나당 하나의 어플리케이션 구조로 구성되어 있는것이 마이크로서비스이다.
- 핵심 역량
작은 서비스들은 각자 서비스리스너, 기능구현 로직, 라이브러리, 저장소를 가지며 독자적으로 실행이 가능한 단위이다.- 지원 역량
이 작은 서비스들이 하나의 어플리케이션이 될 수 있도록 중앙 로그관리, 운영 모니터링, 의존 관계 관리, 서비스 게이트웨이, 보안 서비스, 로드벨런서 정의 등의 공통 서비스들을 개발하여 각 서비스들을 관리하도록 구성해야 한다.- 프로세스, 통제 및 인프라스트럭처
각 서비스별 API 및 관리 문서들이 정리되어있어야 하며 자동화된 QA 검사 및 배포, 인프라스트럭처 프로비저닝이 도입되어야 하며 운영환경을 개발자가 신경쓰지 않아도 자동으로 관리해주는 환경이 마련되어야 한다. 또한 애자일 개발 프로세스를 활용하여 팀원끼리 실용적인 개발환경을 갖추는것도 매우 중요하다.
모놀리식 아키텍처에 비해 마이크로서비스(서비스 단위로 분리하는 것)가 어떤 이점을 주길래 우리는 마이크로서비스를 구축하려고 하는것일까?
마이크로서비스가 무조건 좋은것은 아니며 구성시 고려해야할 점들이 많고 모놀리식에 비해 관리해야할 리소스들이 많지만 그래도 마이크로서비스를 구현하는 이유는 이점들이 강력하기 때문이다.
- 장점
- 서비스별로 분리되어 있어 하나의 어플리케이션처럼 배포하여 서비스 할 수 있다.
- 각 서비스별 배포 및 확장이 가능하고 다른 서비스에 크게 영향을 미치지 않는다.
- 각 서비스에 적합한 기술 스택을 사용하여 개발할 수 있으며 언어나 라이브러리, 프레임워크의 버전업에 있어서 큰 리소스가 발생하지 않는다.
- 서로 비동기 통신을 하여 한 서비스에서 장애가 발생하여도 전체 기능에 크게 영향을 미치지 않는 구조이다.
- A 어플리케이션에서 B 어플리케이션 서비스의 기능이 필요할 경우 코드를 복제할 필요 없이 서비스를 호출함으로써 해당 서비스의 기능을 이용할 수 있다. - 단점
- 하나의 서비스에 서비스 리스너, 저장소, 연산 로직을 가지기 때문에 중복 데이터가 서비스들끼리 필요할 경우 구성이 복잡해지거나 비효율적인 동작들이 증가하게 될 수 있다.
- 서비스들끼리 서로 관계를 가지지 않는것이 좋지만 그러지 못한 경우 트랜잭션 처리가 매우 복잡해질 수도 있다.
- 각 서비스의 로그를 중앙 집중식으로 관리하는 로그서버가 별도로 구성되어야 하므로 로그 관리 인프라 개발에 훨씬 더 많은 리소스가 요구된다.
- 단위별 테스트는 쉽지만 통합 테스트를 실행하기 정말 어렵다.
일반적으로 마이크로서비스가 모놀리식에 비하여 많은 기술스택과 인프라 지식을 요구하며 작게 나뉘어진 서비스들을 통합적으로 관리하기 위해 구현해야 하는 리소스가 많이 들어가기 때문에 마이크로서비스가 필요한 케이스와 모놀리식 아키텍처가 필요한 케이스 등을 잘 구분해서 개발 전 충분한 설계를 하는것이 가장 중요하다.
