소프트웨어 전문지 마이크로소프트웨어 394호는 클라우드(Cloud)와 백엔드(Back-End)를 주제로 담았습니다. 트래비스CI, 데브옵스, PaaS, 마이크로서비스 아키텍처 등 마소 394호의 주요 기사들을 IT조선 독자에게도 소개합니다. [편집자주]

마이크로서비스 아키텍처(Microservice Architecture, 이하 MSA)에 대해 마틴 파울러(Martin Fowler)는 "MSA는 단일 애플리케이션을 작은 서비스 모음으로 개발하는 접근 방식이다. 각 작은 서비스는 자체적으로 실행할 수 있고, HTTP와 같은 경량 메커니즘으로 서로 통신한다. 이런 서비스는 비즈니스 역량 기반으로 구축되며, 독립적으로 배포될 수 있다. 서로 다른 프로그래밍 언어로 작성되고 다른 데이터 저장 기술을 사용할 수 있기 때문에 이 서비스의 중앙 집중식 관리는 거의 필요하지 않다."고 정의했다.

즉, MSA는 큰 애플리케이션 하나를 여러 개의 작은 서비스로 나누고, 이 서비스를 조합해 비즈니스 로직을 수행하는 아키텍처다. 애플리케이션 하나를 서비스별로 나누면 모듈성이 향상된다. 또한 애플리케이션을 개발, 테스트하기 더 쉽다. 소규모 자율 팀이 각각의 서비스를 독립적으로 개발, 배포 및 확장할 수 있도록 지원해 개발을 병렬화한다. 또한 개별 서비스 아키텍처가 지속적인 리팩토링을 수행할 수 있다.

단일 애플리케이션(Monolithic Style)으로 시스템을 개발하는 것은 아주 자연스러운 방법이다. 단일 프로그램으로 개발할 경우 로컬 환경에서 개발하기도 쉬우며, 테스트 및 배포 또한 매우 간편하다. 하지만 애플리케이션의 작은 변경에도 전체 프로그램을 다시 빌드하고 배포해야 해서 시간이 오래 걸린다. 게다가 코드가 점점 복잡해져 모듈 구조 유지가 점점 어려워지고, 애플리케이션을 구성하는 프로그래밍 언어 또는 프레임워크를 변경할 수 없는 문제도 있다.

MSA를 사용하면 각 서비스 독립적으로 배치할 수 있고 확장할 수 있으며, 서로 다른 프로그래밍 언어로 개발할 수 있다. 각 서비스는 그것을 만든 팀이 직접 관리한다.

모놀리식 애플리케이션 구조와 MSA 구조. / 마이크로소프트웨어 394호 발췌
모놀리식 애플리케이션 구조와 MSA 구조. / 마이크로소프트웨어 394호 발췌
MSA에서는 각 컴포넌트를 서비스라는 개념으로 정의한다. 서비스는 비즈니스 로직뿐 아니라 데이터베이스까지 독립적으로 개발하고, 컴포넌트 간 상호 의존성이 없다. RESTful API 같은 인터페이스로 기능을 외부에 제공한다.

큰 애플리케이션을 나누는 경우 일반적으로 기술적 계층을 기반으로 UI팀, 비즈니스 로직팀, 데이터베이스팀으로 나눈다. 이런 분할 방식은 각 팀을 분리할 때, 단순한 변경이 필요한 경우에도 협업을 해야 한다. 따라서 MSA는 비즈니스 로직에 따라 서비스 기준으로 팀을 나눈다. 각 팀에서 UI부터 데이터베이스까지 전부 관리한다.

MSA는 데이터를 저장할 때 중앙 집중화된 하나의 데이터베이스를 사용하는 것이 아니라 각 서비스마다 별도의 데이터베이스를 사용한다. 데이터베이스 종류 자체를 서로 다른 데이터베이스로 사용할 수도 있고, 같은 데이터베이스를 사용한다고 하더라도 각각의 데이터베이스는 분리된다. 또한 서비스끼리 충돌하는 데이터 중복 문제를 동기화해야 한다.

MSA 장점으로 ▲확장성 ▲개발팀의 운영과 스케줄링의 높은 자유도 ▲각 서비스는 개별 팀에서 독립적으로 개발/배포 가능 ▲각 서비스는 심플하며, 각 비즈니스 요구사항에 특화 ▲각 서비스는 다른 프로그래밍 언어, 다른 도구를 사용해 개발 가능 등이 있다.

MSA 단점은 ▲코드와 데이터의 중복 ▲통합 테스트의 어려움 ▲트랜잭션 처리의 어려움 ▲서비스 간 통신 비용 증가 ▲분산 시스템의 복잡성과 비동기성 등이 있다.

임근원, 박해성, 김준희, 채병훈, 김주형, 이준범 필자의 ‘DDD와 MSA로 쇼핑몰 구축하기’에 대한 자세한 내용은 ‘마이크로소프트웨어 394호(https://www.imaso.co.kr/archives/3939)’에서 확인할 수 있다.


관련기사