MSA 제대로 이해하기 -(3)API Gateway

지난 포스팅에서 MSA를 구성하는 아키텍처 요소에 대해 살펴보았습니다. Inner Architecture와 Outer Architecture로 나누어 설명을 드렸었죠.

MSA 제대로 이해하기 - (2)아키텍처 개요

오늘은 그 중 Outer Architecture에서도 API Gateway에 대해 설명하려 합니다.

API Gateway의 필요성

MSA는 큰 서비스를 잘게 쪼개어 개발/운영 하는 아키텍처입니다. 하나의 큰 서비스는 수십~수백개의 작은 서비스로 나뉘어지며, 만약 이를 클라이언트에서 서비스를 직접 호출하는 형태라면 다음과 같은 문제점이 생길 수 있습니다.

• 각각의 서비스마다 인증/인가 등 공통된 로직을 구현해야하는 번거로움이 있습니다.
• 수많은 API 호출을 기록하고 관리하기가 어렵습니다.
• 클라이언트에서 여러 마이크로 서비스에 대한 번거로운 호출을 해야합니다.
• 내부의 비즈니스 로직이 드러나게 되어 보안에 취약해집니다.

특히 이러한 문제점들은 마이크로 서비스의 갯수가 많아질 수록 기하급수적으로 늘어나게 될 것입니다.

어느 규모 이상의 마이크로 서비스 기반 어플리케이션에는 API Gateway를 도입하는 것이 효율적입니다.

API Gateway는 API 서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화 해주는 또다른 서버입니다. API에 대한 인증과 인가 기능을 가지고 있으며, 메세지의 내용에 따라 어플리케이션 내부에 있는 마이크로 서비스로 라우팅하는 역할을 담당합니다.

API Gateway의 시작은 SOA의 핵심 인프라라고 할 수 있는 ESB(Enterprise Service Bus)에서 시작되었습니다. 따라서 API Gateway의 많은 부분들이 ESB로 부터 승계되었습니다.
ESB가 SOAP/XML 기반의 무거운 기능을 가졌다면, API Gateway는 REST/JSON 기반으로 보다 가볍게 설계된 것이 특징입니다.

API Gateway의 주요 기능

1. 인증 및 인가 ( Authentication and Authorization)

마이크로 서비스 아키텍처에서 각각의 서비스에 API 호출에 대한 인증 및 인가를 하는 것은, 같은 소스코드를 서비스 인스턴스들마다 심어주어야한다는 것을 의미합니다. 이러한 경우, 소스의 중복이 심하여 유지 관리가 어려운 것은 물론, 로깅 및 모니터링을 관리하는 것도 매우 어려워집니다.
이러한 이유로 인증서 관리나, 인증, SSL, 프로토콜 변환과 같은 기능들은 API Gateway에서 오프로드 함으로, 각각의 서비스의 부담을 줄이고, 서비스의 관리 및 업그레이드를 보다 쉽게 할 수 있게 합니다.

Authentication(인증)과 Authorization(인가)의 차이

Authentication은 유저가 누구인지 확인하는 절차(A라고 하며 접근하는 사람이 진짜 A인지 확인하는 절차)이고, Authorization은 어떠한 유저가 특정 자원에 접근하려 할때, 그에대한 접근 권한이 있는지 확인하는 절차입니다.

2. 요청 절차의 단순화

여러 마이크로서비스를 대상으로하는 기능을 이용하려 할 때, 만약 API Gateway가 없다면 클라이언트에서 여러 서비스들에 대해 요청을 진행해야 했을 겁니다.
하지만, API Gateway는 여러 클라이언트의 요청을 단일 클라이언트의 요청으로 대체 가능하도록 합니다. 따라서 클라이언트와 백엔드 간의 API 통신량을 줄여주어 대기시간을 줄이고 효율성을 높여줄 수 있습니다.

3. 라우팅 및 로드밸런싱

API Gateway는 클라이언트로 부터 접수된 메세지에 따라, API 호출을 적절한 서비스에 라우팅 할 수 있는 기능이 있습니다. 또한, 서비스 인스턴스들에 대한 부하분산을 할 수 있습니다.

4. 서비스 오케스트레이션

오케스크레이션은 여러개의 마이크로 서비스를 묶어 새로운 서비스를 만드는 개념입니다. 오케스트레이션 로직을 과도하게 넣는 것은, API Gateway의 부담을 늘리는 것으로, 성능 저하를 일으킬 수 있어, MSA와 API Gateway에 대한 높은 수준의 기술적 이해를 바탕으로 이루어져야 합니다.

5. 서비스 디스커버리

API Gateway는 각 서비스를 호출하기위해, 서비스마다의 IP주소와 포트번호를 알고 있어야 합니다. legacy 환경에서는 고정적인 IP주소를 가지고 있기 때문에 크게 문제될 것이 없지만, 클라우드 환경에서는 동적인 환경에서 배포되기 때문에 서비스의 위치를 찾는 것이 어렵습니다. 이러한 서비스의 위치(IP 주소와 포트번호)를 찾는 것을 "Service Discovery"라 하며, API Gateway에서는 서버사이드나, 클라이언트 사이드를 기준으로 하여 서비스 디스커버리를 구현할 수 있습니다.

API Gateway 적용시 고려해야 할 사항

1. API Gateway 적용의 가장 큰 단점은 API Gateway를 내부 마이크로서비스와 결합한다는 것입니다. 이러한 결합은 기존 SOA에서의 ESB(Enterprise Service Bus)에서 발생했던 문제점이 다시 발생할 수 있습니다.

2000년대 후반, 많은 SOA 프로젝트가 실패한 이유로 SOA의 핵심적인 요소 중 하나인 ESB가 꼽히는 경우를 많이 볼 수 있었습니다. 그 이유는 다음과 같습니다.
첫 번째로, 당시 ESB 내부 처리 로직을 XML을 기반으로 하였는데, XML의 파싱은 오버헤드가 큰 작업이었습니다.
두 번째로, ESB는 가벼운 연산 뿐만 아니라, 과도한 Orchestration 등 무거운 로직을 가지고 있었습니다. 특히 ESB를 Gateway로의 특성이 아닌 시스템을 통합하기 위한 역할로 많이 구현하였기 때문에 많은 실패 사례가 발생하였습니다.

2. API Gateway의 Scale-out 적용이 유연하게 일어나지 않을 경우, API Gateway가 병목지점이 되어 어플리케이션의 성능저하가 일어날 수 있습니다.

3. API Gateway라는 추가적인 계층이 만들어지는 것이기 때문에, 그만큼 네트워크 latency가 증가하게 됩니다.