주변에서 마이크로서비스 아키텍처(Microservices architecture; MSA)에 대한 이야기가 많이 들려옵니다. 마이크로서비스 역시 장단점이 있는 하나의 기술입니다. 마이크로서비스를 사용하면 서비스를 분리하여 관리하게되며 애자일한 개발 환경과 점점 더 복잡해지는 애플리케이션에서 분명한 이점을 갖습니다. 동시에, 서비스를 분리하면서 생기는 단점도 존재합니다.

모노리틱 아키텍처(Monolithic Architecture)

MSA를 잘 이해하기 위해서는 먼저, 반대되는 개념인 모노리틱(Monolithic) 아키텍처에 대해서 살펴볼 필요가 있습니다. 모노리틱 아키텍처는 단일 시스템으로 기존의 전통적인 웹 시스템 개발 스타일 입니다. 쉽게 말해 하나의 애플리케이션 내에 모든 로직들이 모두 들어 가 있는 구조입니다.

이러한 애플리케이션 구조는 실제로 많은 서비스에서 사용하고 있습니다. 단순한 구조의 애플리케이션은 로컬 환경에서 개발하기에도 편리하고 전체 애플리케이션을 하나로 처리하기 때문에 배포 역시 간편하며 테스트도 하나의 애플리케이션만 수행하면 되기 때문에 편리합니다.

그러나 이러한 모노리틱 아키텍처 시스템은 대형 시스템 개발시 몇가지 문제점을 갖습니다.

서비스의 복잡도가 증가되면 아주 간단한 기능을 하나 추가하기 위해서도 매우 많은 줄의 코드를 수정해야합니다. 또한 크기가 크기 때문에, 빌드 및 배포 시간, 서버의 기동 시간이 오래 걸리며 프로젝트를 진행하는 과정에서 한사람의 실수는 전체 시스템의 빌드 실패를 유발할 수 있습니다. 전체 시스템의 구조를 제대로 파악하지 않고 개발을 진행하게 되면, 특정 컴포넌트나 모듈에서의 성능 문제나 장애가 다른 컴포넌트에까지 영향을 주게 됩니다. 또한, 컴포넌트별로 다른 기술을 도입하고자할 때 유연하게 대응하지 못한다는 단점 등 여러가지 단점이 있습니다.

마이크로서비스 아키텍처(Microservices architecture; MSA)

모노리틱 아키텍처의 대부분의 단점은 애플리케이션의 규모가 커지면서 발생합니다. 애플리케이션의 규모가 커지고 구조가 복잡해질 때 고려해볼 수 있는 아키텍처가 있습니다. 마이크로서비스 아키텍처(Microservices architecture; MSA)는 하나의 큰 애플리케이션을 여러개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처입니다. 기존의 통합 관점의 단일 시스템(Monolitic)을 서비스 단위로 나누고 분리하는 개념의 아키텍처라고 할 수 있습니다. 마이크로서비스 아키텍처는 기존에 없다가 갑자기 등장한 개념은 아닙니다. 기존의 CBD, SOA로부터 이어온 개념이로 모든 기술들이 그렇듯이 개념에 새로운 기술요소들이 융합되어 현재 우리가 가지고 있는 문제점들을 해결하기 위한 방법으로 등장하고 있습니다. 각 서비스 단위로 나눈다는 의미는 ‘사용자 관리’, ‘주문 관리’ 등 기능 단위로 서비스를 나누며 각 서비스는 모노리틱 아키텍처와 유사한 구조를 가집니다. 다만 하나의 서비스에서 처리하는 규모가 작기때문에 이를 마이크로서비스라고 부릅니다.

구조

마이크로 서비스 아키텍처의 구조는 다음과 같은 모양을 따릅니다.
각 컴포넌트는 서비스 형태로 구현되고 API를 이용하여 타 서비스와 통신합니다.

마이크로 서비스 아키텍처에서는 데이터 베이스 또한 각 서비스 별로 나뉩니다. 이는 데이터의 트랜잭션 관리나 정규화 등의 관점에서 매우 비효율적으로 보일 수 있습니다. 데이터 베이스도 각자 만들어진 목적이 있으며 그 목적에 맞게 사용하는 것이 가장 효율적인 방법입니다. 물론, 하나의 데이터베이스를 각각의 개별 서비스가 공유해서 사용하는 방식도 가능하지만 마이크로서비스 아키텍처가 가지는 근본적인 장점을 최대한 활용하기 위해서는 이렇게 서비스별로 별도의 데이터베이스를 사용하는 것이 필요합니다.

API Gateway

모노리틱 아키텍처의 경우 실제 요청이 도착하여 결과를 반환하기까지 서버는 다양한 종류의 쿼리를 데이터베이스에 보내야합니다. 이러한 방식은 애플리케이션 구조가 간단하다는 장점이 있지만 특정 기능에 변경이 있을 경우 해당 기능을 포함하고 있는 모든 코드를 수정해야한다는 단점이 있습니다.

API Gateway는 그 이름에서도 유추할 수 있듯이 서비스로 전달되는 모든 API 요청의 관문(Gateway) 역할을 하는 서버입니다. API Gateway는 클라이언트의 요청을 일괄적으로 처리하는 역할 뿐만 아니라, 전체 시스템의 부하를 분산시키는 로드 밸런서의 역할, 동일한 요청에 대한 불필요한 반복작업을 줄일 수 있는 캐싱, 시스템상을 오고가는 요청과 응답에 대한 모니터링 역할도 수행할 수 있습니다.

로드 벨런싱(Load Balancing)
하나의 인터넷 서비스가 발생하는 트래픽이 많을 때 여러 대의 서버가 분산처리하여 서버의 로드율 증가, 부하량, 속도저하 등을 고려하여 적절히 분산처리하여 해결해주는 서비스

로드 벨런서(Load Balancer)
스위치라는 용어도 많이 쓴다. 허브가 한 포트로 신호가 들어오면 같은 신호를 다른 모든 포트로 전달하는 것에 비해, 스위치는 신호를 필요로하는 포트로만 신호를 전달. 따라서 스위치에서는 불필요한 트래픽이 감소, 이는 곧 네트워크에서의 데이터 전송 속도의 향상으로 이어진다. 동의어는 아니지만 동의어처럼 많이들 쓰고 있다.

이렇게 API Gateway를 이용하여 서비스 요청에 대한 처리를 하게되면 특정 서비스의 변경사항이 생기거나 서비스가 통합/분리 되더라도 클라이언트는 그 사실을 인지할 필요가 없으며 API Gateway 내부의 변경사항만으로 처리가 가능하게 됩니다. 이렇게 시스템 내부의 아키텍처를 숨길 수 있는(encapsulate) 특성이 API Gateway가 갖는 가장 큰 장점이라고 할 수 있습니다.

Orchestration

기존 open api의 mash up과 같은 개념으로, 여러개의 서비스를 묶어서 하나의 새로운 서비스를 만드는 개념이다. 예를 들어, 포인트 적립과, 물품 구매라는 서비스가 있을때, 이 두개의 서비스를 묶어서 “물품 구입시 포인트 적립”이라는 새로운 서비스를 만들어 낼 수 있다. 이러한 orchestration 기능은, api gateway를 통해서 구현될 수 있다. 하지만 과도한 orchestration 로직은 전체적인 성능 문제를 유발합니다. 때문에 orchestration 서비스의 활용은 MSA에 대한 높은 이해와 api gateway 자체에 대한 높은 수준의 기술적인 이해를 필요로 합니다.

공통 기능 처리 (Cross cutting function handling)

또한 API에 대한 인증 (Authentication)이나, Logging과 같은 공통 기능에 대해서 서비스 컴포넌트 별로 중복 개발해야 하는 비효율성을 유발할 수 있다. api gateway에서 이러한 공통 기능을 처리하기 되면, api 자체는 비지니스 로직에만 집중을 하여 개발에 있어서의 중복등을 방지 할 수 있다.

Conway’s Law (컨웨이의 법칙)

“소프트웨어의 구조는 그 소프트웨어를 만드는 조직의 구조와 일치한다”

마이크로서비스 아키텍처는 이 컨웨이 법칙에 근간을 두고 있습니다. 이는 각 컴포넌트를 팀에 배치해서 책임지고 개발하는 것을 근간으로 하며, 팀간의 의존성을 제거해서 각 팀이 컴포넌트 개발을 독립적으로할 수 있는 구조로 잡혀있습니다.