마이크로서비스 아키텍처와
API 게이트웨이
분할과 정복
마이크로서비스 아키텍처(MSA: Microservices Architecture)란 무엇인가?
마이크로서비스 아키텍처는 단어 뜻 그대로 작은 서비스(service)를 하나씩 개발하여, 전체 애플리케이션을 만들어 나가는 방식이다. 이를 널리 알린 선구자라 할 수 있는 영국의 마틴 폴러(Martin Fowler)는 마이크로서비스 아키텍처는 하나의 애플리케이션을 작은 서비스의 집합으로 구현하는 개발 방법으로서, 마이크로서비스는 HTTP상에서의 REST API 같은 가벼운 통신 방식을 사용하는 아키텍처라고 정의하였다. 아래 그림은 그 과정을 간단한 다이어그램으로 표기한 것으로, 클라이언트가 요청한 서비스를 API 게이트웨이가 기능별로 분류하여, 각 서비스를 담당하는 API 엔드 포인트를 호출하고, 그에 대한 응답을 API 서버에서 받아오는 구조를 표현하고 있다. 일반적으로 API가 아닌 동적 콘텐츠의 경우는 웹 서버에서 바로 전달받고, 정적 콘텐츠의 경우 CDN을 통해 캐시의 형태로 받는다.
<그림 1. CDN과 결합한 API 게이트웨이>마이크로서비스 아키텍처의 등장 배경
마이크로서비스 아키텍처가 많이 언급이 된 시점은 넷플릭스(Netflix)와 아마존닷컴(amazon.com)이 자사의 시스템에 채택하면서부터인데, B2C 소비자가 많은 웹 기반 분산 시스템의 구현 시, 기존의 모놀리식 아키텍처(monolithic architecture)와 같은 전통적인 시스템 구현 방식으로는 다양한 기능의 빠른 개발과 테스트, 그리고 유지보수의 한계에 부딪혔기 때문이다.
모놀리식 아키텍처(Monolithic Architecture)는 하나의 애플리케이션이 하나의 단일 시스템에 모든 기능과 시스템 컴포넌트들을 담아두고 운영되는 구조로서, 각각의 기능은 강결합(strongly coupled) 상태로 연결되어 있기에, 작은 단위의 기능을 추가하더라도 전체 애플리케이션의 레이어들은 모두 다시 테스트하고 배포해야 하는 구조이다. 따라서 작은 단위 기능을 수정했더라도 전체 레이어를 다시 빌드 및 패키징하여 서버를 재기동해야 하기 때문에, 빠른 기능별 개발과 서비스 적용 및, 365일 무중단 서비스를 해야 하는 대용량 웹 기반 서비스에 적용하기에는 무리가 있다.
<그림 2. 모놀리식 아키텍처와 마이크로서비스 아키텍처의 비교>
MSA의 전신이라 할 수 있는 서비스 지향 아키텍처(SOA: Service Oriented Architecture)는 2000년 초반에 애플리케이션 구성 요소가 표준 통신 프로토콜을 통해 또 다른 애플리케이션에 서비스를 제공하는 아키텍처 접근 방식이다. 서비스라는 기능의 단위가 여기서부터 시작이 되었고, SOAP, XML, UDDI, WSDL과 같은 표준 기술들을 사용하여, 웹 기반 분산 시스템의 시초를 만들었고, 이를 REST API와 API 게이트웨이를 접목하여 MSA로 발전하게 되었다.
마이크로서비스 아키텍처를 도입하는 이유
마이크로서비스 아키텍처에서의 “서비스”는 비즈니스 요구사항을 충족하기 위한 소프트웨어의 작은 구현 단위이며, 이들은 서로가 약결합(loosely coupled) 형태로 연결이 되어 종속성을 최소화한다. 따라서 각각의 기능을 다양한 프로그래밍 언어와 시스템을 활용하여 기능별 개발팀이 서로의 간섭을 최소화하고, 빠르게 개발하고 효율적으로 유지보수할 수 있다.
작은 서비스는 개별적인 개발, 테스트, 배포가 가능하기에 데브옵스(DevOps)의 필수 요소라 할 수 있는 지속적인 개발(CI: Continuous Integration)과 지속적인 배포(CD: Continuous Delivery)에 적합하며, 이 사상은 서비스 지향 아키텍처와 REST(REpresentational State Transfer) 기반의 아키텍처인 ROA(Resource Oriented Architecture)에서의 리소스(resource)와도 일맥상통하며, 더 거슬러 올라가면 소프트웨어 공학의 분할 정복(Divide & Conquer) 사상에서 부터 기인되었다고 볼 수 있다.
마이크로서비스 아키텍처의 핵심은 마이크로서비스와 API 게이트웨이
소프트웨어에서의 요구사항을 구현한 서비스는 과거, 순차형 프로그래밍에서는 함수(function), 객체지향 프로그래밍에서는 클래스(class)를 통해 구현이 되었었다.
MSA가 회자될 무렵에는 마이크로 서비스=API라는 전제하에 모든 기능은 API 형태로 정의가 되고, 다양한 형태의 클라이언트와 서버가 퍼블릭 클라우드와 같은 형태로 존재하였기 때문에, 이 둘을 연결하는 인터페이스를 REST API 방식으로 전달하고, 이에 대한 중간 다리 역할을 API 게이트웨이가 담당한다. API 게이트웨이는 다음과 같은 기능을 가지고 있다.
API 등록(registration)
API 개발팀에서 미리 정의한 API 명세(specification)를 통해 URL을 포함하는 REST API 리소스 형태로 API 게이트웨이에 등록한다. API 명세는 Swagger라 부르는 OAS(OpenAPI Specification)를 업계 표준처럼 많이 사용하고 있으며 YAML 혹은 JSON 형태로 작성한다.
API 분기(routing)
클라이언트의 API 요청을 URL 경로 분석을 통해 해당 서비스를 담당하는 API 엔드 포인트로 연결하는 역할이다. 로드밸런서와 같이 특정 API 서버에 과다한 부하가 걸리지 않도록 트래픽을 분배하는 기능도 포함이 된다.
API 사용자 인증(authentication)
인가된 클라이언트만 사용이 가능한 API의 경우, API 키 혹은 API 토큰을 검사하여, 유효한 사용자만 API 응답을 받을 수 있도록 한다. 최근에는 인증에 필요한 다양한 정보를 JSON 값으로 전달하는 토큰 방식인 JWT(JSON Web Token)도 많이 사용되고 있다.
API 캐싱(caching)
JSON이나 XML 형태를 가진 API 응답 또한 프락시, CDN, 클라이언트에 일정 기간 동안 캐싱이 가능하다. API는 데이터베이스 쿼리와 같은 백엔드 프로세스가 필요하기 때문에 때로 웹 성능에 영향을 줄 수 있기 때문에 캐싱 최적화가 반드시 필요하다.
API 사용빈도 제한(rate limiting)
과다한 API 사용 빈도를 API 키 혹은 API 클라이언트 별로 특정 시간에 몇 회로 제한하는 기능이다. API 공급자의 불필요한 트래픽 낭비를 막고, DDoS성 공격을 막는 효과도 있다.
최근에는 REST API 보다 좀 더 원하는 서비스 내용을 빠르고 가볍게 통신할 수 있는 쿼리형 언어인 GraphQL(Graph Query Language)에 대한 사용도 점차 늘어나고 있다. 대부분의 클라우드, CDN 벤더들은 자체적인 API 게이트웨이를 상품군으로 보유하고 있고, 다양한 오픈소스 형태의 제품도 있다.
마이크로서비스 아키텍처에 어울리는 DevOps 팀 모델
전통적인 소프트웨어 개발팀은 기획, UX, 개발, QA(Quality Assurance), 운영팀과 같이 역할별로 나뉘어 있다. 각 팀의 구성원은 자신이 담당하는 영역에 대해서만 책임을 지고 폭포수 모델(waterfall model) 스타일로 전체 소프트웨어 프로세스 중, 팀에 할당된 마일스톤을 순서대로 수행한다.
마이크로서비스 아키텍처의 경우, 역할이 아닌, 시스템의 서비스 별로 기획에서부터 운영에 이르는 모든 프로세스를 담당하는 팀을 두는 구조를 채택하는 경우가 많기 때문에 하나의 전담팀이 모든 기능을 수행하는 다기능 팀(Cross Functional Team) 전략이 자주 사용된다. 기존의 수직적 팀 구조에서 제품 기능 단위로 수평적으로 팀을 꾸리는 것은 어찌 보면, 태스크포스팀(TFT)과 같은 형태로 볼 수도 있지만, 마치 최근 스타트업의 IT 인력이 모든 것을 작게 시작하여 하나 둘 개발을 완료하고 운영까지 유지하는 DevOps 형태로도 볼 수 있다.
작은 마이크로 서비스를 기획하고, 개발과 테스트, 클라우드와 같은 인프라에 적용하고, API 게이트웨이 혹은 또 다른 마이크로 서비스와 인터페이싱을 담당하며 전체 제품을 이해하고 개발과 운영을 동시에 하는 팀 구조를 통해, 마이크로서비스 아키텍처 본연의 특징인 빠른 서비스의 개발을 충실히 수행한다.
글을 맺으며..
이번 글을 통해 마이크로서비스 아키텍처의 등장 배경과, 장점을 주로 기술하였지만, 모든 신기술의 적용에는 그에 따르는 단점과 이를 받아들이는 조직의 용기와 이해가 필요하다. 따라서 마이크로 서비스 아키텍처가 필요한 웹 기반 대용량 분산 시스템을 계획하는 IT 기업은 기술 도입에 앞서, 조직의 어떤 변화가 필요할지를 미리 고민하고 올바른 선택을 하는 것이 필연적인 과정이다.
