API 관리와 보안을 위한
API 게이트웨이
마이크로서비스 아키텍처는 무엇인가?
마이크로서비스 아키텍처(MSA: Microservices Architecture)는 단어 뜻 그대로 작은 서비스(service)를 하나씩 개발하고 연결하여 전체 애플리케이션을 만들어 나가는 방식입니다.
MSA를 정의하는 문장은 많지만, 가장 간단한 표현을 빌리자면, MSA의 선구자 - 마틴 폴러(Martin Fowler)의 정의를 들 수 있습니다. 그는 마이크로서비스 아키텍처는 하나의 애플리케이션을 작은 서비스의 집합으로 구현하는 개발 방법이며, HTTP(S) 상에서의 REST API 같은 가벼운 통신 방식을 사용하는 아키텍처라고 정의하였습니다.
아래 그림은 그 과정을 간단한 다이어그램으로 표기한 것으로, 클라이언트가 요청한 서비스를 API 게이트웨이를 통해 각 서비스를 담당하는 API 엔드 포인트를 호출하고, 그에 대한 응답을 API 서버에서 받아오는 구조입니다.
<마이크로서비스 아키텍처의 일반적인 형태>일반적으로 API가 아닌 동적 콘텐츠의 경우는 웹 서버에서 바로 전달받고 정적 콘텐츠의 경우 CDN을 통해 캐시의 형태로 받습니다. 물론 대부분의 CDN은 동적 콘텐츠 캐싱도 지원합니다.
마이크로서비스 아키텍처의 등장 배경
마이크로서비스 아키텍처가 많이 언급이 된 시점은 넷플릭스, 아마존, 우버, 이베이와 같은 공룡 테크 기업들이 자사의 시스템에 사용하고 이를 널리 전파하면서부터입니다. B2C 소비자를 대상으로 하는 다수의 기능을 가진 웹 기반 분산 시스템의 구현 시 기존의 모놀리식 아키텍처(monolithic architecture)와 같은 전통적인 시스템 구현 방식으로는 기능의 빠른 개발, 테스트, 배포 그리고 유지 보수의 한계에 부딪혔기 때문입니다.
모놀리식 아키텍처는 하나의 애플리케이션이 하나의 단일 시스템에 모든 기능과 시스템 컴포넌트들을 담아 운영하는 구조를 가지고 있습니다. 각 기능은 강결합(strongly coupled) 상태로 연결하여 작은 기능 하나를 추가하더라도 전체 애플리케이션의 레이어들을 모두 다시 테스트하고 배포하는 번거로움이 있습니다.
작은 단위 기능을 수정했더라도 전체 레이어를 다시 빌드 및 패키징 하여 서버를 재기동해야 하기 때문에, 빠른 기능별 개발과 단위 서비스 적용 및 365일 무중단 서비스를 해야 하는 대용량 웹 기반 서비스에 적용하기엔 알맞지 않습니다.
<모놀리식 아키텍처와 마이크로서비스 아키텍처의 비교>MSA의 경우 각각의 마이크로 서비스를 독립적으로 개발합니다. 전체 시스템에 가장 적은 영향으로 배포할 수 있는 약결합(loosely coupled) 구조를 통해 기존 아키텍처의 단점을 보완하였습니다.
2000년 초반에 유행했던 MSA의 전신이라 할 수 있는 서비스 지향 아키텍처(SOA: Service Oriented Architecture)는 통신에 필요한 표준 프로토콜을 사용하여 애플리케이션에 서비스를 제공하는 아키텍처 방식입니다. 당시의 서비스라는 기능 단위 개발이 활발히 언급되었고 SOAP, XML, UDDI, WSDL 등의 표준 기술을 사용하여 웹 기반 분산 시스템의 시초를 만들었습니다. 이를 토대로 HTTP 프로토콜 기반의 RESTful 방식과 API 게이트웨이를 접목하여 오늘날의 대중적인 MSA로 발전하게 되었습니다.
마이크로서비스 아키텍처를 도입하는 이유
마이크로서비스 아키텍처에서의 “서비스(service)”는 비즈니스 요구 사항을 충족하기 위한 소프트웨어의 작은 구현 단위입니다. 각각의 기능을 다양한 프로그래밍 언어와 시스템을 활용하여 기능별로 나눠진 개발팀이 서로의 간섭을 최소화하고 빠르게 개발하고 효율적으로 유지 보수할 수 있습니다.
또한 마이크로 서비스는 개별적인 개발, 테스트, 배포가 가능하기에 데브옵스(DevOps)의 필수 요소라 할 수 있는 지속적인 개발(CI: Continuous Integration)과 지속적인 배포(CD: Continuous Delivery)에 적합한 구조를 가지고 있습니다. 이런 서비스 사상은 서비스 지향 아키텍처와 REST(REpresentational State Transfer) 기반의 아키텍처인 ROA(Resource Oriented Architecture)이 말하는 리소스(resource)와도 일맥상통하며 더 거슬러 올라가면 소프트웨어 공학의 분할 정복(Divide & Conquer) 사상에서부터 기인되었다고도 볼 수 있습니다.
MSA의 핵심은 마이크로 서비스와 API 게이트웨이
MSA는 "마이크로 서비스 = API"라는 전제 아래 대부분의 기능을 API로 정의하고, 다양한 형태의 클라이언트와 퍼블릭 클라우드 형태의 서버가 사용됩니다. 이 둘을 연결하는 인터페이스를 REST API 방식으로 전달하는 중간 다리 역할을 API 게이트웨이(gateway)가 담당합니다. API 게이트웨이는 필요한 서비스를 찾고 서비스의 상태를 확인하는 Service Discovery 기능 외에도 다음과 같이 보안 기능을 가지고 있습니다.
● API 인증(authentication)
인증이 필요한 API의 경우, API 키 혹은 API 토큰을 검사하여 유효한 요청에만 API 응답을 줄 수 있도록 한다. 인증에 필요한 정보를 JSON 형태의 웹 토큰으로 전달하는 JWT(JSON Web Token) 방식도 많이 사용한다.
● API 사용빈도 제한(rate limiting)
과다한 API 사용 빈도를 API 키 혹은 API 클라이언트 별로 특정 시간에 몇 회로 제한하는 기능이다. API 공급자 입장에서 불필요한 트래픽 낭비를 막고, DDoS 성 공격을 막는 효과도 있다.
● API 캐싱(caching)
JSON이나 XML 형태를 가진 API 응답 또한 프락시, CDN, 클라이언트 캐시 영역에 일정 기간 동안 캐싱이 가능하다. 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 서버에 과다한 부하가 걸리지 않도록 트래픽을 분배하는 기능도 포함이 된다.
맺으며..
마이크로서비스 아키텍처의 등장 배경과, 장점을 주로 기술하였지만, 모든 신기술의 적용에는 그에 따르는 단점과 이를 받아들이는 조직의 용기와 이해가 필요합니다. 단순 서비스에 MSA를 적용한다면, 오히려 MSA 구조를 지키기 위한 공수가 애플리케이션 개발 공수보다 더 많을 수 있습니다.
