API GATEWAY

API Gateway란?

- 실제 백엔드 서비스 또는 데이터와 접속하고 API 호출에 대한 정책, 인증 및 일반 액세스 제어를 적용하여 중요한 데이터를 보호하는 트래픽 관리자

- 백엔드 시스템 및 서비스에 대한 액세스를 제어하는 방법

- 외부 클라이언트와 백엔드 서비스 간의 통신을 최적화하여 클라이언트에게 원활한 경험을 제공하도록 설계

- 클라이언트의 모든 API 호출을 가져와 요청 라우팅, 구성 및 프로토콜 변환을 사용하여 올바른 마이크로서비스로 라우팅

- API 서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화하여 묶어주고 API에 대한 인증과 인가 기능에서부터 메시지에 따라서 여러 서버로 라우팅하는 고급기능까지 많은 기능 담당

- Client 로부터 Car나 Person에 대한 요청 수신

- 수신된 요청을 구분해서 각 관련 Backend Service로 전달

- Backend Service로부터의 응답을 모아 Client에게 전달

오늘의 집 Gateway 예시

 

주요 역할

Request Routing

: location 설정을 통해 Routing할 Path 정의

- =: 특정 Path와 일치하면 Routing

- ~: Regular Expression에 따라 일치하면 Routing

- 그 외의 경우, 설정한 Path로 시작하는 모든 경우에 대해 Routing

location = /api/v1/test {
        proxy_pass  http://v1_test_api;
}
...
location ~ /api/v1/[12][0-9]+ {
        proxi_pass  http://v1-api;
}
...
location  /api/v1/real {
        proxy_pass  http://v1-api;
}

 

Load Balancing

- API gateway 뒷단에 다수의 API서버가 있다고 가정

- 여러개의 API서버로 부하를 분산할 기능 필요

- Round Robin 방식으로 부하 분산 기능

- 뒷단의 서버가 살아있으면 부하를 보내고, 죽었으면 부하를 안보내는 기본 기능

- API 서버가 Hang up(멈춤)에 걸렸을 때 이를 인지해서 부하를 안보내는 기능

- 단순 IP 포트가 살아있음을 가지고 판단하는 것이 아닌, 쓰레드 수, 응답 시간 등으로 서버의 장애 상태 판단

upstream v1-api {
        server 192.168.10.1:9001;
        server 192.168.10.2:9001;
        sticky cookie srv_id expires=1h;
}

ex) 

- Roung Robin 방식으로 2개의 서버로 Request가 전달되게 설정

- sticky session을 설정해서 처음 연결된 서버로 1시간 동안 계속 Rounting 시키도록 설정

 

 

메시지 또는 헤더기반 라우팅

- 메시지 헤더를 파싱해서 메시지 헤더에 있는 내용을 기반으로 라우팅 가능

- HTTP 헤더에 country code가 있을 경우, country code에 따라 어느 지역의 API서버를 호출할지 Routing 가능

- API 호출에 대해서 라우팅 정보를 추출하기 위해 HTTP Body에 있는 JSON을 API Gateway가 파싱해서 열어봐야 함

- 빠르게 메시지가 통과해야하는 API Gateway에서는 부담이 될 수 있음

- 라우팅 정보를 HTTP Header에 옮기면 Body를 파싱하지 않고 Header만 파싱한 뒤, Body정보는 라우팅된 서버로 포워딩만 하면 됨

-> 메시지 기반 라우팅을 사용할 때는 오버헤드를 잘 고려하고, 가능하면 HTTP URL이나 HTTP Header에 라우팅 필드를 넣는게 좋음

 

 

공통 로직 처리

- API Gateway 특성상 모든 API서버 앞단에 존재

- 모든 API 호출이 API Gateway를 거쳐감

- 모든 API가 공통적으로 처리해야 하는 공통 기능이 필요한 경우, 공통 기능을 API Gateway로 옮기게 되다면?

- 별도로 API서버에서 이러한 기능을 개발할 필요 없이 비즈니스 로직 자체 구현만 집중하면 됨

공통 로직을 API Gateway로 이전

- API 로깅이나 인증은 전체 시스템에 대해 공통된 기능으로, 공통 계층에서 처리하게 되면 개발 중복 줄일 수 있음

 

 

메디에이션 기능(Mediation)

- 중재 또는 조정

- API 서버에서 제공되는 API가 클라리언트가 원하는 API 형태와 다를 때, API Gateway가 이를 변경

 

1. 메시지 포맷 변환(Message format transformation)

- JSON으로 요청된 메시지가 들어왔을 경우, 이를 API 서버로 보낼 때 변환해서 보내거나 또는 API 서버에서 생성된 응답을 클라이언트에 리턴할 때 변경해서 보내는 기능

 

- 회원의 일부 정보만 리턴해주는 API가 없이, 회원 전체 정보만 리턴해주는 API만 존재하는 경우

- API Gateway를 통해서 특정 정보만 뽑아서 리턴 가능

- 하지만, 요구되는 리턴값에 맞춘 API를 따로 만드는 것이 더 괜찮은 방식일 것 같음

 

2. 프로토콜 변환

- 다양한 서비스나 클라이언트를 지원하게 되면, 클라이언트나 서비스별로 다른 통신 프로토콜을 사용해야 하는 경우가 존재

- 웹에서는 JSON기반의 REST가 많이 사용되지만, 배나 비행기에 사용되는 센서들의 경우 REST가 무겁기 때문에, 바이너리 기반의 경량 프로토콜을 사용

- 예전 엔터프라이즈 시스템의 경우 XML기반의 웹 서비스를 이용하는 경우도 있음

- 이렇게 다양한 프로토콜을 지원하기 위해서, 각 서비스들이 새롭게 구현하는 것이 아닌, API Gateway를 통해 프로토콜을 변환하여 같은 API를 다른 프로토콜로 서비스 가능

- 내부 API는 REST가 아닌, 페이스북 Thrift나 구글의 Protocol Buffer로 구현하고, 외부에 제공하는 API는 API Gateway단에서 REST로 변경하여 서비스하는 구조를 이용

-> 내부 API 성능을 올리고, 외부로는 REST API로 서비스하여 범용성 확보

 

- 근래 IoT와 같은 개념이 활성화

-> HTTP REST 뿐만 아니라 기존의 센서에서 통신하는 다양한 프로토콜을 지원하여 백엔드 API서버의 프로토콜로 맞춰줘야하는 필요성 증대

 

3. 어그리게이션(Aggregation)
- 여러개의 API를 묶어서 하나의 API로 만드는 작업

ex) 계좌이체

1. A 은행에서 잔액 확인
2. A 은행에서 인출
3. B 은행으로 입급

- 3개의 API 호출을 하나의 API인 POST transfer(인출 계좌, 입금 계좌, 금액)으로 구현

 

- 언뜻 좋아보이는 기능이지만, 하나의 플로우에서 여러 API를 호출해야 하고, API Gateway 입장에서는 부하가 큼

- MSA의 전신인 SOA(Service-Oriented Architecture)에서는 Gateway와 유사한 역할을 했던 ESB(Enterprise Service Bus)에서 aggretation을 남발하여 성능 저하 및 시스템 개발 실패까지 가는 경우가 있었음

- 무거운 Aggregation 로직은 별도의 Mediator API 서버라는 계층을 만들어서 API Gateway 밖에서 따로하는 방법 권장됨

 

 

로깅 및 미터링

- API Gateway의 비기능적인 요건으로 중요한 기능이 로깅과 미터링

 

API 호출 로깅

- API 호출시 API Gateway는 공통적으로 호출되는 부분인 만큼, 모든 로그를 중간에서 수집하기 좋음

- 클라이언트와 서버간의 통신이 모드 API를 기반하는 형태로 변경됨에 따라 API 호출 패턴을 분석하면, 사용자의 사용 패턴을 분석할 수 있기 때문에 

-> 빅데이터 영역과 연계하여 API 호출 로그는 아주 중요한 자산으로 다뤄짐

- API 호출 로그는 차후 문제가 발생했을 때, 문제를 추적하기 위한 중요한 자료로 사용됨

- API 로그 수집은 단순 분석 목적 뿐 아니라, 향후 감사 목적용으로도 저장되어야 함

- 근래 서비스되는 클라우드형  API Gateway는 특히 이 API에 대한 로그 분석 기능을 강화해서 출시

 

API 미터링 & 차징(Metering & Charging)

- 유료 API 서비스를 위한 기능

- 미터링: 과금을 위한 API 호출 횟수, 클라이언트 IP, API 종류, IN/OUT 용량 등을 측정 기록하는 서비스

- 차징: 미터링이 된 자료를 기반, API 서비스 사용 금액을 금액 정책에 따라 계산하는 서비스

- SNS Open API 서비스는 무료인 경우가 다수지만, 구글 API의 경우도 특정 호출 횟수를 넘어가면 과금이 되도록 되어 있음

 

 

QoS 조정(Quality of Service)

- API 서비스를 클라이언트 대상에 따라서 서비스 레벨 조정하는 기능

- 유료 서비스가 있는 API를 가정할 때, 무료 사용자는 1일 1000건 호출 횟수 제한이 있거나, 전송 용량, 네트워크 대역폭을 유료/무료 사용자에 따라 다르게 적용하는 것과 같은 기능

- 유료 서비스 뿐만 아니라, 플랫폼 차원에서 다양한 클라이언트나 다양한 서비스로 API를 제공하는 경우, 각 클라리언트나 서비스에 따라서 Qos를 조정하는 기능은 유용하게 사용됨

- 특정 서비스나 클라리언트가 폭주하여 API를 과도하게 사용하여 다른 서비스들이 API를 사용할 수 없게 된는 경우 등을 미연에 예방 가능