APi Gateway

» dev

API Gateway

API 게이트웨이는 API서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화하여 묶어주고 API에 대한 인증과 인가 기능에서 부터 메세지에 따라서 여러 서버로 라우팅 하는 기능을 담당할 수 있다.

API Gateway 주요 기능

1. 인증/인가

API 게이트웨이의 가장 기본적인 기능은 API 에 대한 인증과 인가 관련 기능이다.\

  • 인증: API 를 호출하는 클라이언트에 대한 identity(신분)를 확인 해주는 기능
  • 인가: 클라이언트가 API를 호출할 수 있는 권한이 있는지를 확인해주는 기능

내가 페이스북 계정을 가지고 있는 사용자가 맞는지, API 호출시 어느 권한(일반사용자, 관리자 권한)까지 호출할 수 있는지를 판단하여 API 호출을 허가하는 기능이라고 볼 수 있다.

API 토큰 발급

인증 인가를 거칠때 마다 매번 사용자의 인가/인증 절차를 거치기는 불편하다. 사용자로 부터 매번 사용자 ID와 비밀 번호를 받기는 번거롭고, 그렇다고 사용자 ID와 비밀 번호를 저장해놓는 것은 해킹의 빌미를 제공한다.

그래서 사용자 인가를 통과 시, 토큰을 발행해주면 사용자가 토큰을 이용하여 API를 호출할 수 있다.
API 서버는 이 토큰으로 사용자의 권한을 확인한 후, API 호출을 허가해준다.

클라이언트를 인증하는 방법은 여러가지가 있다.

  1. id, password
  2. 공인인증서
  3. 지문이나 OTP(One time password)

위 방식외에도 다양한 방법이 있다.

클레임 기반, 서버 기반

사용자의 인증/인가를 위한 권한 정보를 토큰에 저장하는 것을 클레임 기반 토큰(Claim based token)이라고 하는데 JWT(JSON Web Token)SAML 토큰 등이 이에 해당된다.

{
    "name": "tony",
    "role": ["ADMIN", "ENDUSER"],
    "org": "petstore"
}

서버 기반의 경우 권한 정보를 서버에 저장하게 되는데, 클라이언트에게 unique한 String만을 반환한다.

토큰에 연관되는 정보가 서버에 저장되기 때문에 안전하고, 많은 정보를 저장할 수 있으며, 토큰에 대한 정보를 수정하기가 용이하다.
그러나, 서버단에서 별도의 토큰 저장소를 유지해야 하기 때문에 구현 노력이 더 높게 든다. 토큰은 매 API 호출마다 정보를 가지고 와야 하기 때문에, DBMS와 같은 FILE IO 기반의 저장소 보다는 redis, memcached와 같이 메모리 기반의 고속 스토리지를 사용하는 것이 좋다.

엔드포인트별 API 호출 인증

API Gateway는 토큰을 발급했으면 이 토큰을 바탕으로 유효성을 검증한 후 검증되면 서버로 전달해준다.

서버 기반의 경우 토큰을 저장소에서 권한 정보들을 찾아 API 호출 가능 여부를 결정한다.

클레임 기반 토큰의 경우는 API Gateway에서 토큰을 열어보고 그 안에 있는 내용을 검증하여 API 호출 가능 여부를 결정한다.

내부 서버간의 통신에서는 별도의 인증을 하지 않는 경우도 있고, 외부 서버의 통신의 경우 특정 IP를 허용하거나 양방향 SSL 인증 방식을 사용하여 API 호출을 인증하는 방법도 있다.

엔드포인트별 API 요청 인가

토큰을 이용해 사용자의 권한을 제어하는 방법은 크게 두가지가 있다. 하나는 개별 토큰에 권한을 부여하는 방식, 다른 하나는 역할(ROLE) 기반으로 권한을 부여하는 방식이 있다.

개별 토큰에 권한을 부여하는 방법의 경우 개별 토큰에다가 세밀하게 권한을 부여할 수 있지만 이러한 토큰이 많아지면 관리하기 어렵다는 특징이 있다.

역할 기반으로 토큰에 권한을 부여한다면 토큰에 권한을 부여하는 숫자가 줄어들기 때문에 역할별로 엔드포인트를 나눠서 관리할 수도 있다.
예를들어, 관리자용 엔드포인트(/service/admin), 일반 사용자용 엔드포인트 (/service/user)로 정의하여 나눌 수 있다.

2. API 라우팅

API Gateway의 주요 기능 중 하나는 같은 API 요청이라도 서비스나 클라이언트 종류에 따라서 다른 엔드포인트로 라우팅을 해주거나 로드밸런싱 기능을 지원해준다.

로드 밸런싱

API Gateway 뒷단에 다수의 API 서버가 있다고 할때, 여러개의 API 서버로 부하를 분산하는 기능이다.

단순하게 로드밸런싱을 라운드 로빈으로도 제공해줄 수 있고 원하는 트래픽에 따라 분산시킬 수도 있다.

무엇보다 API 서버가 장애가 났을때 이를 감지해서 로드 밸런싱 리스트에서 빼고, 복구 되었을때 다시 로드 밸런싱 기능에 넣을 수 있다.

서비스 및 클라이언트 별 엔드포인트 제공

같은 API를 여러개의 엔드포인트를 통해서 서비스를 제공할 수있다.
하나의 시스템이 다양한 서비스나, 다양한 클라이언트등으로 서비스를 제공할때, 각각 다른 서비스 별 또는 클라이언트 별로 다른 엔드포인트를 제공할 수 있다.

💡 실제로 멀티 서비스를 제공하는 플랫폼형태의 경우에는 이 기능이 매우 유용하다.
특히 같은 API라도 클라이언트의 종류에 따라서 인증 방식이 다를 수 있고 보안 메커니즘이 다를 수 있다.

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

메시지 내용을 기반으로 하는 라우팅이다. HTTP 헤더의 정보를 기반으로 다른 서버에 라우팅 할 수 있다.

Body에도 정보를 가질 수 있는데 Gatwway가 매번 JSON을 파싱해서 열어보면 빠르게 통과해야 하는 API Gateway에 많은 부담을 준다.

그래서 메세지 기반의 라우팅을 사용할 때는 이러한 파싱에 대한 오버헤드를 잘 고려하고, 가능하면, HTTP URL이나 HTTP Header에 라우팅 필드를 넣는 것이 좋다.

3. 공통 로직 처리

API Gateway는 특성상 모든 API 서버 앞쪽에 위치하기 때문에 모든 API 호출이 Gateway를 거치기 때문에 공통된 로직 처리가 필요하다면 Gateway 에다가 넣으면 좋다.
이를 통해 각각의 서비스는 자신의 비즈니스 로직에 집중하면 되므로 API 로깅이나 인증같은 기능은 공통 로직으로 포함된다.

4. Mediation(메디에이션)

메디에이션이란 “중재” 또는 “조정” 이라는 의미를 가지는데 API 서버가 클라이언트가 원하는 API 형태와 다를 때 API 게이트웨이가 이를 변경해주는 기능을 이야기 한다.

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

JSON으로 된 요청(Request) 메세지가 들어왔을때, 이를 API 서버로 보낼때 변환 해서 보내거나, 또는 API 서버에서 생성된 응답을 클라이언트에 리턴할때 변경해서 보내는 기능을 의미한다.

에를들어, 카페의 운영 시간에 대한 정보만 원하지만 전체 정보를 가지는 API만 가지고 있을 경우, API Gateway에서 운영 시간 정보만 추출하여 리턴하는 방식이다.

이는 권장하지 않는 방식으로 포맷에 맞는 API를 새로 생성하는 것이 좋다.

프로토콜 변환

다양한 서비스나 클라이언트를 지원하게 되면 다양한 통신 프로토콜을 지원해야 하는 경우가 있다. 예를들면 웹에서는 JSON이나 HTTP를 이용한 REST 기반의 통신을 많이 쓰지만 배나 비행기에서는 REST도 무겁기 때문에 바이너리 기반의 경량 프로토콜을 사용하게 된다. 이렇게 다양한 타입의 프로토콜을 지원하기 위해서 프로토콜마다 새로운 서비스를 구현하는게 아니라 API Gateway에서 프로토콜 변환을 이용해 서비스를 호출할 수 있도록 하면 된다.

메세지 호출 패턴 변환 (Message Exchange Pattern : MEP)

메시지 호출 패턴 변환이란 동기 비동기 호출같은 통신을 변경시킬 수 있다. API 클라이언트는 동기 호출을 했지만 API Gateway에서는 메시지 큐 서비스를 이용해 비동기 통신을 이용해 요청을 처리해주고 응답을 줄 수 있다.

어그레게이션 (aggregation)

API Gateway에서는 여러개의 API를 묶어서 하나의 API 처럼 처리하게 보이는 동작을 만들 수 있다. 이렇게 만들면 API Gateway에 부하가 집중되므로 조심해야 한다. 그리고 로깅과 디버깅이 어렵다는 단점이 있다.

5. 로깅 및 미터링

API 호출 로깅

API Gateway의 주요 기능인 공통 로직 처리 기능에서 봤듯이 API Gateway는 공통적으로 처리하는 기능에 유용하고 이에는 로깅이 있다. 모든 API 시작 지점이 Gateway부터 시작하므로 이부터 시작해서 서비스간 호출 패턴을 파악해서 사용자 패턴을 파악할 수 있다. 이는 빅데이터와 연계해서 유용하다.

또한 문제가 발생했을 때 문제를 추적하기 위한 용도로 많이 사용되기도 한다.

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

API 미터링과 차징은 유료 API 서비스를 위한 기능으로 미터링은 API 호출 횟수, 클라이언트 IP, API 종류, In/Out 용량등을 측정할 수 있는 지표들을 기록하는 서비스다.

6. QoS 조정 (Quality of service)

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

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

유료 서비스인 경우만 아니라, 플랫폼 차원에서 다양한 클라이언트나 다양한 서비스로 API 를 제공하는 경우, 각 클라이언트나 서비스에 따라서 이 QoS를 조정하는 기능은 유용하게 사용될 수 있다. 특정 서비스나 클라이언트가 폭주하여 API를 과도하게 사용하여 다른 서비스들이 API를 사용할 수 없게 한다던가 그런 문제를 미연에 예방할 수 있다.