API Gateway는 수신되는 모든 요청을 가로채서 API 관리 시스템을 통해 전송하여 필요한 다양한 기능을 처리합니다. 중간에 API Gateway 서버로 모았다가 다시 목적지로 뻗어나가는 구조로 API Gateway는 api 가 지나다니는 통로라고 생각하면 된다. API Gateway는 MSA에서 언급되는 컴포넌트 중 하나이며, 모든 클라이언트 요청에 대한 엔드 포인트(End Point)를 통합하는 서버이다. 뿔뿔히 흩어져있는 MSA 서비스들을 API Gateway를 통해 한 군데로 모아 관리한다.
출처 : https://bambooagile.eu/insights/monolith-vs-microservices/
기존의 모노톨릭 아키텍처일때는 하나의 서버에 운영되었던 것이, MSA가 도입되면서 도메인별 데이터를 저장하고 도메인별로 하나 이상의 서버가 따로 존재하게 되었다. 한 서비스에 한개 이상의 서버가 존재하기 때문에 이 서비스를 사용하는 클라이언트 입장에서는 다수의 엔드 포인트가 생기게 되고, 엔드 포인트 변경이 일어나면 관리가 힘들게 된다. 이런 환경에 클라이언트에서 서비스를 직접 호출하면 다음과 같은 문제가 발생한다.
ServiceDiscovery
: API Gateway는 각 서비스를 호출하기위해, 서비스마다의 IP주소와 포트번호를 알고 있어야 합니다. 이러한 서비스의 위치(IP 주소와 포트번호)를 찾는 것
API 게이트웨이의 주요 기능은 다음과 같다.
인증은 요청을 보내는 사용자의 신원을 확인하는 거고 인가는 사용자가 이 요청에 대한 요구를 할 권한이 있는지 확인하는 과정이다.
API Gateway를 통해, 제한된 사용자의 요청, 사용 제한 초과 시 요청을 거부하거나 인증되지 않은 요청, 변조된 요청에 대해 요청을 거부한다.
1) API 토큰 발급
API 게이트 웨이는 클라이언트를 인증한 후, 이러한 API 토큰을 생성 및 발급해주는 역할
2) 엔드포인트별 API 호출 인증
클라이언트나 서비스 별로 제공되는 엔드포인트에 대해서 API 인증 방식이 다르기 때문에, API 게이트웨이에서는 각 엔드 포인트 별로 다양한 형태의 인증 방식을 제공해야 한다.
ex) api token으로 인증하는 경우, 별도의 인증없이 api를 제공하는 경우(내부 서버와의 통신), 양방향 SSL등의 인증 방식(외부서버와의 통신시 높은 보안요구)
3) 엔드포인트별 API 요청 인가
권한에 따라 엔드포인트를 나눠 접근 제어할 수 있게 한다.
ex) 관리자용 API 엔드포인트, 일반 사용자용 API 엔드포인트
1) 백엔드 API 서버로의 로드 밸런싱
API 게이트웨이를 지나 여러 개의 API 서버를 갖는 구성에서, API 게이트웨이는 로드 밸런서 역할을 수행해 여러 개의 API 서버로 부하를 분산시킬 수 있다.
무엇보다 API 서버가 장애가 났을 경우에 이를 알아채고 그쪽으로 트래픽을 전달하지 않을 수도 있다.
2) 서비스 및 클라이언트 별 엔드포인트 제공
API 게이트 웨이는 API 서버가 공통적인 API를 가지더라도, 각 서비스나 클라이언트 타입에 따라서 각각 다른 API 를 선별적으로 서비스 할 수 있도록 해준다. 엔드 포인트 별로 노출(expose)하는 API를 다르게 할 수 있다.
API Gateway는 특성상 모든 API 서버 앞쪽에 위치하기 때문에 모든 API 호출이 Gateway를 거치기 때문에 공통된 로직 처리가 필요하다면 API Gateway에다가 넣으면 좋다.
ex) 로깅
API 호출시 API 게이트웨이는 공통적으로 호출되는 부분인 만큼 모든 로그를 중간에서 수집하기가 가장 좋다.
메디에이션 기능은, 클라이언트에서 호출하는 요청과 API 서버가 제공하는 API의 스펙에 차이가 발생할 때, 이를 중간에서 중재해주는 기능을 이야기한다.
1) 메시지 포맷 변환
JSON으로 된 요청(Request) 메세지가 들어왔을때, 이를 API 서버로 보낼때 변환 해서 보내거나, 또는 API 서버에서 생성된 응답을 클라이언트에 리턴할때 변경해서 보내는 기능(과연 가능한것인가?🤔)
2) 프로토콜 변환
웹에서는 JSON이나 HTTP를 이용한 REST 기반의 통신을 많이 쓰지만 배나 비행기에서는 REST도 무겁기 때문에 바이너리 기반의 경량 프로토콜을 사용하게 된다.다양한 타입의 프로토콜을 지원하기 위해서 프로토콜마다 새로운 서비스를 구현하는게 아니라 API Gateway에서 프로토콜 변환을 이용해 서비스를 호출할 수 있도록 하면 된다.
출처) https://bcho.tistory.com/1005
3) 메시지 호출 패턴 변환
클라이언트는 동기 호출을 했지만 API Gateway에서는 메시지 큐 서비스를 이용해 비동기 통신을 이용해 요청을 처리해주고 응답
API Gateway는 여러 클라이언트의 요청을 단일 클라이언트의 요청으로 대체 가능하도록 한다. 따라서 클라이언트와 백엔드 간의 API 통신량을 줄여주어 대기시간을 줄이고 효율성을 높여준다.
Agregation이란 서로 다른 API를 묶어서 하나의 API로 제공하는 것을 의미한다. 즉, 일련의 과정을 위해 여러개의 서른 다른 서비스의 API를 호출하는 경우를 말한다. → API Gateway에 부하를 크게 만들어 해결점으로 Mediator API 서버라는 계층이 등장하게 됨.