record logo record

Tech

MSA(MicroService Architecture)

update: 01 October 2020

목차

MSA 등장 배경

MSA는 웹기반의 분산 시스템의 디자인에 많이 반영되고 있는 아키텍쳐 입니다. 특정 사람이 정의한 아키텍쳐가 아니라, 분산 웹 시스템의 구조가 유사한 구조로 설계 되면서 개념적으로만 존재하였습니다.

마틴파울러(Martin Fowler)가 2014년도에 MSA에 대한 개념을 글로 정리하여 개념을 정립 시키는데 일조를 하였습니다.

MSA를 이해 하기 이전에 Monolithic Architecture 스타일에 대해서 이해해야 합니다.

Monolithic Architecture

tech-monoliths-and-msa

Monolithic Architecture 란 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어있는 형태입니다.

기존의 전통적인 웹 시스템 개발 스타일로, 하나의 애플리케이션 내에 모든 로직들이 들어가 있는 구조 입니다.

예를 들어, 온라인 쇼핑몰 애플리케이션이 있을때, 톰캣 서버에서 동작하고 있는 WAR 파일 내에, 사용자 관리, 상품, 주문 등 모든 컴포넌트들이 들어있고 이를 처리하는 UX 로직까지 하나로 포장되서 들어가 있는 구조입니다.

특징
장점

전체 애플리케이션을 하나로 처리하기 때문에 다음과 같은 장점이 있습니다.

단점

Monolithic 구조는 일정 규모 이상의 서비스, 많은 개발 인력이 투입되는 프로젝트에서는 해당 스타일은 한계를 보입니다.

※참고※
MSA 이전에 CBD, SOA 등 Monolith를 논리, 물리적으로 구조화 하기 위한 노력들이 있었습니다.
또한, MSA는 SOA의 부분집합으로 여겨지고 있습니다.

MSA(MicroService Architecture) 란?

MSA(MicroService Architecture) 는 “하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍쳐” 입니다.

MSA는 대용량 웹서비스 가 많아짐에 따라 정의된 아키텍쳐입니다. MSA의 근간은 SOA(Sevice Oriented Architecture: 서비스 지향 아키텍쳐) 에 두고있습니다.

SOA는 Enterprise 시스템을 중심으로 고안된 아키텍쳐라면, MSA는 SOA 사상에 근간을 두고 대용량 웹서비스 개발에 맞는 구조로 사상이 경량화 되고, 대규모 개발팀의 조직 구조에 맞도록 변형된 아키텍쳐입니다.

MAS 구조

tech-msa-structures

마이크로 서비스 아키텍쳐의 기본 구조 는 각 컴포넌트가 서비스라는 형태로 구현되고 API를 이용하여 타 서비스와 통신을 합니다.

배포 구조 관점 에서 볼때, 각 서비스는 독립된 서버로 타 컴포넌트와의 의존성이 없이 독립적으로 배포 됩니다.

예를 들어 사용자 관리 서비스는 독립적인 war파일로 개발되어, 독립된 톰캣 인스턴스에 배치됩니다. 확장을 위해서 서비스가 배치된 톰캣 인스턴스는 횡적으로 스케일(톰캣 인스턴스 수를 추가)이 가능하고, 앞단에 로드 밸런서를 배치하여 서비스간의 로드를 분산 시킵니다.

tech-monolith-and-msa-database

데이터 저장관점 에서는 중앙 집중화된 하나의 데이터 베이스를 사용하는 것이 아니라 서비스 별로 별도의 데이터 베이스를 사용합니다. Monolithic 구조의 경우 하나의 데이터 베이스(RDBMS)를 사용하는 경우가 일반적입니다. 마이크로 서비스 아키텍쳐의 경우, 서비스가 API에서 부터 데이터 베이스까지 분리되는 수직 분할 원칙(Vertical Slicing)에 따라서 독립된 데이터 베이스를 가집니다. 또한 이 경우, 다음과 같은 장단점 을 가지고 있습니다.

MSA 특징

API Gateway

API Gateway는 마치 프록시 서버 처럼 api들 앞에서 모든 api에 대한 end point를 통합 하고, 몇가지 추가적인 기능을 제공하는 미들웨어 로, SOA의 ESB(Enterprise Service Bus)의 경량화 버전 입니다. API Gateway가 MSA에서 수행하는 주요 기능은 다음과 같습니다.

End Point 통합 및 위상(topology - 연결성, 연속성) 정리

MSA의 문제점 중의 하나는 각 서비스가 다른 서버에 분리 배포 되기 때문에, API의 URL(End Point)이 다르다는 점입니다.

예를 들어, 사용자 컴포넌트 는 https://user.server.., 상품 컴포넌트 는 https:product.server..와 같이 분리된 URL을 사용합니다. 이러한 점은 API 사용에 불편함이 있습니다.

또한, MSA는 컴포넌트를 되도록 업무 단위로 잘게 짜르는 fine grained(작은 덩어리)의 서비스를 지향하기 때문에, 컴포넌트의 URL 수는 더 많이 늘어 날 수 있습니다.

API를 사용하는 클라이언트에서 서버간 통신이나, 서버간의 API 통신의 경우 P2P(Point to Point)형태로 위상이 복잡 해지고 거미줄 모양의 서비스 컴포넌트간의 호출 구조는 향후 관리의 문제 를 일으킬 수 있습니다. (ex. 특정 end point 변경 시)

tech-msa-apigateway-p2p

이러한 위상의 문제점을 해결하기 위해서 중앙에 서비스 버스와 같은 역할을 하는 채널을 배치 시켜서, 전체 위상를 P2P에서 Hub & Spoke 방식으로 변환 시켜서, 서비스간 호출을 단순화 시킬 수 있습니다.

tech-msa-apigateway-hub-spoke

ESB vs API Gateway

SOA 프로젝트의 실패중의 하나가 ESB로 꼽히는 경우가 많습니다. 이는 ESB를 Proxy나 Gateway처럼 가벼운 연산만이 아니라, 여러개의 서비스를 묶는 Orchestration 로직을 무겁게 사용했기 때문입니다.

ESB는 메세지를 내부적으로 XML로 변환하여 처리하는데, XML 처리는 생각하는것 보다 파싱에 대한 오버헤드가 매우 큽니다. 또한, ESB의 고유적인 Bus나 Gateway로써의 특성이 아니라 타 시스템을 통합 하기 위한 EAI적인 역할을 ESB를 이용해서 구현함으로써 많은 실패 사례를 만들었습니다.

이러한 개념적인 문제를 해결하기 위해서 나온 제품군이 API Gateway라는 미들웨어 제품군 입니다. ESB와 기본적인 특성은 유사하나 기능을 낮추고 EAI의 통합 기능을 제거하고 API 처리에만 집중한 제품군입니다.

API Gateway를 도입할때 MSA의 다른 것들 보다 많은 부분을 할애하는 이유는 컴포넌트를 서비스화 하는 부분 까지는 큰 문제가 없이 적응을 하지만 API Gateway의 도입 부분의 경우, 내부적인 잡음이 날 수 있고, 또한 도입을 했더라도 잘못된 설계나 구현으로 인해서 실패 가능성이 비교적 높은 모듈이기 때문입니다. MSA의 핵심 컴포넌트 이지만, 도입을 위해서 높은 수준의 기술적인 이해와 개발 능력을 필요로합니다.

Orchestration

Orchestration란 기존 open api의 mash up과 같은 개념으로, 여러개의 서비스를 묶어서 하나의 새로운 서비스를 만드는 개념입니다.

예를 들어, 기존에 상품 구매, 포인트 서비스가 있을때, 이 두개의 서비스를 묶어서 “포인트로 상품 구매” 라는 새로운 서비스를 만드는 것을 말합니다.

이러한 Orchestration 기능은 API Gateway를 통해서 구현될 수 있습니다. 이는 MSA가 fine grained 형태로 컴포넌트들이 잘게 쪼개져있기 때문에 가능한 일입니다.

그러나, Orchestration을 API Gateway를 통해 구현하는 것은 Gateway 입장에서 부담이 되는 일 입니다. 과거 SOA 시절에 많은 ESB 프로젝트가 실패한 원인 중의 하나가 과도한 Orchestration 로직을 넣어서 전체적인 성능 문제가 발생 한 경우가 많았습니다.

Orchestration 서비스의 활용은 MSA에 대한 높은 이해와 API Gateway 자체에 대한 높은 수준의 기술적인 이해가 필요합니다. 실제로 넷플릭스의 경우 MSA를 사용하고, 여러개의 서비스들을 gateway를 통해 Orchestration를 사용하고 있습니다.

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

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

MSA 장점

MSA 단점

References