본문으로 건너뛰기

3.3. 액세스 토큰 검증 및 요청 처리

3.3.1. 액세스 토큰 검증(Access Token Verification)

클라이언트는 인증/인가 서버의 사용자 인증을 통해 액세스 토큰(Access Token)을 발급받은 뒤, API 게이트웨이로 데이터허브 API를 호출합니다. 이때 API 게이트웨이는 클라이언트가 제시한 액세스 토큰이 정당하게 발급된 토큰인지 검증하며 액세스 토큰의 만료 여부와 클라이언트가 해당 API를 호출할 권한이 있는지 확인합니다. 이러한 검증 과정에는 인증/인가 서버가 발급한 공개키(RSA Public Key)를 이용합니다. 액세스 토큰 없이 API 요청을 하거나 유효하지 않은 액세스 토큰을 이용한 경우 적절한 오류 응답이 가능하도록 합니다.

API 게이트웨이가 액세스 토큰을 검증하는 과정은 아래와 같습니다.

API 게이트웨이 접근제어 토큰 검증 구성

  1. API 게이트웨이 구동 시 인증/인가 서버에 액세스 토큰 검증을 위한 토큰 검증 키(RSA Public Key)를 요청한다.
  2. 클라이언트는 인증/인가 서버로부터 데이터허브 API 호출에 필요한 액세스 토큰을 발급받는다.
  3. 클라이언트는 액세스 토큰을 HTTP 요청 헤더에 포함하여 API 게이트웨이로 데이터허브 API를 호출한다.
  4. API 게이트웨이는 토큰 검증 키를 이용하여 클라이언트 요청에 포함된 액세스 토큰이 정당하게 발급되었는지, 만료되지 않았는지, API를 호출할 권한이 있는지 확인한 뒤 해당 데이터허브 서비스로 라우팅한다. 이외 경우에는 적절한 응답을 전달한다.

3.3.2. 요청 수 제한(Rate Limit)

API 게이트웨이는 클라이언트가 특정 시간내에 제한된 양의 API 호출만 가능하도록 제어할 수 있어야 합니다. 일반적으로 제한시간은 1초이며, 1초 당 호출 가능한 최대 요청 수 설정을 통해 과도한 요청 발생 시 오류 응답을 하도록 해야합니다. 요청 제한기능은 1. 개별 메모리 캐시를 이용한 인스턴스 별 요청 수 제한 방법, 2. Redis (링크)와 같은 네트워크 캐쉬를 이용한 클러스터 기준 요청 수 제한 방법과 같이 2가지 구성이 가능합니다. 또한, 제한 유형을 두어 Client 별, IP 별, Host 별로 제한 할 수 있습니다.

API 게이트웨이에서 클라이언트의 요청 수를 제한하는 방법은 아래와 같습니다.

API 게이트웨이 요청 수 제한 구성

  1. 클라이언트는 데이터허브 서비스에 접근하기 위해 API 게이트웨이로 다수의 데이터허브 API 요청을 한다.
  2. API 게이트웨이는 수신한 데이터허브 API 요청을 조건(Client, IP, Host 등)과 일치하도록 해당 요청 수를 집계한다.
  3. 사전 정의된 1초당 요청가능 수 범위 이내에서 API 요청을 데이터허브 서비스로 라우팅한다.
  4. 1초당 요청가능 수 범위가 초과한 경우 해당 API 요청을 차단(Block)하고 429 Too Many Request라는 HTTP 응답 코드를 반환한다.

Note: 인스턴스 별 요청가능 수 제한은 Redis와 같은 인메모리 데이터 저장소(in-memory data store)의 도움 없이 인스턴스별로 요청 가능 수를 제한할 수 있으나, 전체 인스턴스로 전송되는 요청 수를 집계할 수 없으므로 명확한 요청 수 제한을 하기 어려울 수 있습니다.

3.3.3. 요청 재전송

API 게이트웨이가 데이터허브 서비스로 클라이언트의 요청을 라우팅했으나 해당 서비스가 응답하지 않는 경우, API 게이트웨이는 이전 요청을 해당 서비스로 재전송할 수 있습니다.

아래는 API 게이트웨이의 요청 재전송 예시입니다.

API 게이트웨이 재요청 구성

3.3.4. 내부 서비스 요청 전달 금지

데이터허브 API 요청에 해당하는 라우팅 룰이 존재하나 해당 라우팅 룰을 통한 데이터허브 서비스 처리에 오류가 발생한 것으로 판단한 경우(Circuit Open 상태), 해당 서비스로 요청을 전달하지 않고 에러로 처리합니다(Fallback). 이 기능은 Circuit Breaker 솔루션 중의 하나인 resilience4j (링크)를 통해 구현했습니다.