Docs Cloud Devops

API Gateway

[System Design] API Gateway란 무엇인가?

마이크로서비스 아키텍처(MSA)를 도입하다 보면 수많은 백엔드 서비스들이 생겨납니다. 클라이언트가 이 수많은 서비스들과 직접 통신하게 된다면 보안, 인증, 트래픽 제어 등 공통적인 처리를 각 서비스마다 중복으로 구현해야 하는 문제가 발생합니다.

이러한 문제를 해결해 주는 시스템 디자인의 핵심 컴포넌트가 바로 **API Gateway(API 게이트웨이)**입니다.

1. API Gateway란?

API Gateway는 클라이언트(웹 브라우저, 모바일 앱, 외부 서비스 등)와 백엔드 마이크로서비스들 사이에 위치하는 서버 측 아키텍처 컴포넌트입니다.

가장 큰 목적은 외부 클라이언트가 백엔드 시스템의 기능에 접근할 수 있도록 **단일 진입점(Single Entry Point)**을 제공하는 것입니다. 클라이언트의 요청을 받아 적절한 마이크로서비스로 라우팅(전달)하고, 서버의 응답을 다시 클라이언트에게 반환하는 중개자 역할을 합니다.

💡 API Gateway의 도입 효과 라우팅, 인증(Authentication), 처리율 제한(Rate Limiting)과 같은 공통 작업을 API Gateway가 전담하게 됩니다. 덕분에 개별 마이크로서비스는 본연의 비즈니스 로직에만 집중할 수 있어, 시스템 전체의 성능과 확장성이 크게 향상됩니다.

2. API Gateway의 요청 처리 흐름 (Step-by-Step)

클라이언트의 요청이 API Gateway를 거쳐 백엔드로 전달되기까지의 흐름은 다음과 같습니다.

API Gateway Architecture (이미지 설명: 클라이언트 요청이 API Gateway의 다양한 필터를 거쳐 백엔드로 전달되는 과정)

  1. 요청 수신: 클라이언트가 API Gateway로 HTTP 요청을 보냅니다.
  2. 요청 파싱 및 검증: API Gateway가 HTTP 요청의 속성들을 파싱하고 유효한지 검증합니다.
  3. 접근 제어: Allow-list(허용 목록) 또는 Deny-list(차단 목록) 검사를 수행합니다.
  4. 인증 및 인가: Identity Provider(IdP)와 통신하여 사용자가 누구인지, 접근 권한이 있는지 확인합니다.
  5. 처리율 제한(Rate Limiting): 미리 정의된 한도 내의 요청인지 확인하고, 초과 시 요청을 거절합니다.
  6. 경로 매칭(라우팅): 기본 검사를 통과한 요청을 URL 경로(Path)를 기반으로 어떤 백엔드 서비스로 보낼지 결정합니다.
  7. 프로토콜 변환: 필요하다면 백엔드 서비스가 사용하는 통신 프로토콜로 요청을 변환하여 전달합니다.
  8. 오류 처리 및 로깅: 응답 지연 등 장애 발생 시 서킷 브레이커(Circuit Breaker)를 통해 대처하고, ELK 스택 등을 활용해 로그와 메트릭을 수집합니다.

3. API Gateway의 핵심 기능 상세

API Gateway가 제공하는 강력한 기능들을 구체적인 예시와 함께 살펴보겠습니다.

🔐 보안 강화 (Security Enforcement)

  • 목적: 인증, 인가, 처리율 제한 등 보안 메커니즘을 중앙 집중식으로 적용하여 백엔드 서비스를 보호합니다.
  • 적용 예시: 백엔드 서비스에 요청이 도달하기 전에 API Gateway가 사용자의 인증 토큰을 확인하여 로그인 상태인지 검증할 수 있습니다. 또한 특정 데이터에 접근할 수 있는 사용자의 권한을 확인하고, 남용을 방지하기 위해 사용자별 요청 수를 제한할 수도 있습니다.

⚖️ 부하 분산 (Load Balancing)

  • 목적: 백엔드 서비스 인스턴스 간에 들어오는 요청은 로드밸런싱 알고리즘에 따라서 적절한 인스턴스에 분배하여, 단일 서비스가 병목 지점(Bottleneck)이 되는 것을 방지합니다.
  • 적용 예시: 애플리케이션의 트래픽이 많아지면 API Gateway는 상품 카탈로그 서비스로 들어오는 요청을 여러 서버 인스턴스에 분배하여, 자원을 효율적으로 사용하고 안정적인 성능을 유지할 수 있습니다.

🛡️ Rate Limiting and Throttling

  • 목적: 클라이언트가 정해진 시간 내에 보낼 수 있는 요청 수를 제어하여 백엔드 서비스가 과부하에 걸리는 것을 막습니다.
  • 적용 예시: 공개된 API의 경우, 특정 사용자가 단시간에 엄청난 요청을 보내 전체 시스템의 성능을 저하시킬 수 있습니다. API Gateway에서 “사용자당 분당 최대 100회 요청”과 같이 제한을 두면, 초과 시 일시적으로 요청을 차단하여 서비스 안정성을 유지할 수 있습니다.

🔍 서비스 디스커버리 연동 (Service Discovery Integration)

  • 목적: 수시로 스케일 업/다운되는 환경에서 백엔드 서비스들을 동적으로 찾아 연결합니다.
  • 적용 예시: Kubernetes 환경에서는 트래픽에 따라 서비스 인스턴스가 동적으로 생성되고 사라집니다. API Gateway는 Consul이나 Eureka 같은 서비스 디스커버리 툴과 연동하여, 수동 설정 변경 없이도 항상 정상적으로 살아있는 서비스 인스턴스로 요청을 라우팅합니다.

🔄 프로토콜 변환 (Protocol Translation)

  • 목적: 클라이언트와 백엔드 서비스 간에 서로 다른 프로토콜을 사용하더라도 원활한 통신을 가능하게 합니다.
  • 적용 예시: 클라이언트는 외부에서 HTTP/HTTPS로 요청을 보내지만, 내부 백엔드 서비스들끼리는 WebSockets이나 gRPC를 사용할 수 있습니다. API Gateway가 중간에서 이 프로토콜들을 매끄럽게 변환해 줍니다.

⚡ 서킷 브레이커 (Circuit Breaker Pattern)

  • 목적: 특정 백엔드 서비스에 장애가 발생했을 때 연쇄적인 시스템 장애(Cascading Failures)를 방지합니다.
  • 적용 예시: 주문 처리 서비스가 응답하지 않는 상황을 가정해 보겠습니다. API Gateway는 이 장애 패턴을 감지하고 서킷 브레이커를 발동시켜, 일정 시간 동안 주문 서비스로 향하는 요청을 차단합니다. 그동안 클라이언트에게는 미리 정의된 Fallback(대체) 응답을 보내어 시스템 전체가 마비되는 것을 막습니다.

📊 모니터링과 로깅 (Monitoring and Logging)

  • 목적: 디버깅과 성능 분석을 위해 요청 및 응답 데이터를 기록합니다.
  • 적용 예시: 유입되는 모든 요청의 경로, 응답 시간, 에러율 등을 로깅합니다. 이는 추후 병목 구간을 찾거나 사용자의 패턴을 분석하는 데 귀중한 데이터가 됩니다.

💾 응답 캐싱 (Caching Responses)

  • 목적: 자주 변하지 않는 데이터를 캐싱하여 응답 지연 시간(Latency)을 줄이고 백엔드 부하를 감소시킵니다.
  • 적용 예시: 상품 카탈로그처럼 업데이트가 잦지 않은 데이터는 API Gateway 단에서 캐싱해 둘 수 있습니다. 클라이언트가 상품 정보를 요청할 때마다 매번 백엔드 DB를 조회하는 대신, 캐시된 데이터를 즉시 반환하여 속도를 비약적으로 높일 수 있습니다.

4. API Gateway vs Load Balancer (로드밸런서)

시스템 디자인을 공부하다 보면 “API Gateway와 로드밸런서는 어떻게 다를까?”라는 의문이 생길 수 있습니다.

API Gateway vs Load Balancer (이미지 출처: DesignGurus)

두 컴포넌트는 다루는 영역과 목적이 다릅니다.

  • API Gateway: 특정 API URL 경로를 기반으로 요청을 분석하고, **“어떤 마이크로서비스로 보낼 것인가(라우팅)“**에 초점을 맞춥니다. 주로 인터넷을 통해 애플리케이션 간 상호 작용을 돕는 웹 기반 인터페이스(API)의 요청을 처리합니다.
  • Load Balancer: 단일 IP 주소로 들어온 엄청난 양의 요청을 서버의 성능과 가용성을 고려하여 **“여러 대의 백엔드 서버 중 어디로 분산시킬 것인가”**에 초점을 맞춥니다.

요약하자면, API Gateway는 요청의 내용(URL Path, HTTP 헤더, 토큰 등)을 분석하여 목적지에 맞는 마이크로서비스로 연결해 주는 L7(애플리케이션 계층) 수준의 스마트 라우터에 가깝습니다. 비즈니스 로직과 아키텍처에 대한 이해를 바탕으로 라우팅, 인증, 보안 등을 중앙에서 처리합니다.

반면, 로드밸런서는 개별 요청의 비즈니스적 의미보다는 서버의 상태(가용성, 리소스)에 집중하여, 동일한 역할을 하는 여러 서버 인스턴스에 트래픽을 고르게 분배하는 데 목적을 둡니다.

(실제 아키텍처에서는 클라이언트 트래픽이 외부 로드밸런서를 거쳐 다수의 API Gateway 인스턴스로 분산되고, API Gateway가 다시 백엔드 마이크로서비스들로 요청을 라우팅하는 방식으로 상호 보완적으로 사용됩니다.)

5. API Gateway 병목 원인과 성능 개선

백엔드 마이크로서비스 아키텍처(MSA)에서 트래픽이 폭증할 때 병목은 DB나 특정 비즈니스 서비스에서 발생할 수 있습니다. 그러나 모든 요청이 지나는 API Gateway 역시 병목 지점이 될 수 있으므로, 먼저 메트릭과 분산 추적을 통해 실제 병목 위치를 확인해야 합니다.

여기서는 Gateway가 병목이 되는 주요 원인을 살펴보고, 상황에 따라 적용할 수 있는 인증 계층 분리, 커넥션 오버헤드 개선 방법을 알아보겠습니다.

5.1 API Gateway 병목의 2가지 핵심 원인

트래픽이 급증하면 API Gateway의 CPU 사용량이 포화되고 응답 지연 시간(Latency)이 급격히 증가할 수 있습니다.

게이트웨이 인스턴스(Pod)를 스케일 아웃(Scale-out)해도 지연 시간이 개선되지 않는다면, 요청 처리 경로(Request Path)의 연산뿐 아니라 Upstream 포화, 커넥션 관리, 부하 분산 설정까지 함께 점검해야 합니다.

① CPU 집약적인 JWT 인증 연산

  • Gateway가 외부 요청마다 JWT 서명을 검증하면 암호화 연산이 누적되어 CPU 리소스를 많이 소비할 수 있습니다.
  • 특히 높은 RPS 환경에서는 토큰 검증, JWK(Key Set) 조회, 권한 정책 평가가 Gateway CPU 사용량의 주요 원인이 될 수 있습니다.

② Per-Request Connection 생성으로 인한 네트워크 오버헤드

  • Gateway가 내부 백엔드 마이크로서비스(Upstream)로 요청을 전달할 때 요청마다 새로운 TCP 커넥션과 TLS 핸드셰이크를 맺고 끊으면 네트워크 오버헤드가 커집니다.
  • 문제점:
    • 요청마다 추가 RTT(Round Trip Time)가 발생하여 Latency가 증가합니다.
    • 커넥션을 자주 닫으면서 OS 소켓이 TIME_WAIT 상태로 대량 누적되고, 가용 에페메럴 포트(Ephemeral Port)가 고갈되어 Connection Refused 또는 EADDRNOTAVAIL 에러가 발생합니다.

5.2 해결책 1: 2-Tier Auth Gateway 분리 아키텍처

인증이 실제 병목으로 확인된 경우, 인증 연산 부하와 라우팅 트래픽 부하를 격리하기 위해 Gateway 계층을 **Tier 1(인증 전담)**과 **Tier 2(라우팅 전담)**로 분리할 수 있습니다. 다만 계층 분리는 네트워크 홉과 운영 복잡도를 늘리므로, 단일 Gateway의 캐싱·스케일 아웃만으로 해결되지 않을 때 적용합니다.

[Client] ──► Tier 1: Auth Gateway ──► Tier 2: Lightweight API Gateway ──► Upstream Services

계층별 역할

  1. Tier 1 (Stateless Auth Gateway):

    • 역할: 인증 검증만 전담합니다.
    • 검증 경로 최적화: JWK를 로컬 캐시에 보관해 매 요청마다 IdP를 호출하지 않도록 합니다. JWT 알고리즘(RS256, ES256 등)은 라이브러리와 워크로드에 따라 검증 비용이 달라지므로, 벤치마크 결과와 보안 요구 사항을 기준으로 선택합니다.
    • 검증 결과 캐싱: 검증을 마친 토큰 결과를 Auth Gateway 메모리(Local LRU Cache)에 짧은 TTL로 캐싱할 수 있습니다. 캐시 TTL은 토큰 만료 시간을 넘지 않아야 하며, 즉시 무효화가 필요하면 Redis Pub/Sub 등의 무효화 이벤트를 함께 사용합니다.
    • 검증 결과 전파: 검증이 완료된 사용자 정보(User ID, Roles 등)는 내부 전용 헤더(예: X-User-Context)에 담아 Tier 2로 전달합니다. 이때 외부에서 들어온 동일 헤더는 제거하고, Tier 간 mTLS 또는 사설 네트워크로 요청 출처를 검증해야 헤더 위·변조를 막을 수 있습니다.

  2. Tier 2 (Lightweight Core Gateway):

    • 역할: Tier 1이 넘겨준 검증된 요청을 전달받아 라우팅과 Rate Limiting을 빠르게 수행합니다.
    • 성능: 암호화 연산 부담이 줄어들므로 라우팅과 네트워크 I/O에 맞춰 독립적으로 확장할 수 있습니다.

💡 Architecture Tip: 부하 특성에 따른 HPA(Horizontal Pod Autoscaler) 최적화 게이트웨이를 2-Tier로 분리하면 **인증 부하(CPU-bound)**와 **라우팅 부하(I/O-bound)**의 스케일링 특성을 물리적으로 격리할 수 있습니다. 그 결과 쿠버네티스 환경에서 각 Tier의 성격에 맞춘 독립적인 Auto-scaling 정책 수립이 가능해집니다.

  • Tier 1(Auth Gateway): JWT 연산 부하에 반응하도록 CPU 사용량 기준 HPA를 적용합니다. 예를 들어 목표 CPU 사용률을 65%로 시작한 뒤 부하 테스트 결과에 맞춰 조정합니다.

  • Tier 2(Core Gateway): 네트워크 패킷 전송량, RPS, 동시 연결 수 등의 Custom Metric을 기준으로 HPA를 적용합니다.

5.3 해결책 2: Upstream Connection Pooling 및 HTTP/2 Multiplexing

Gateway와 내부 백엔드 마이크로서비스(Upstream) 간 커넥션 재사용으로 Handshake 지연 및 소켓 고갈 문제를 근본적으로 해결합니다.

적용 방안

  • Upstream Connection Pooling (커넥션 풀링):

    • 게이트웨이 내부 HTTP 클라이언트 엔진에 Upstream 서비스별 커넥션 풀을 유지하여 연결을 재사용합니다. 풀 크기는 Upstream Pod 수, 동시 요청 수, 서버의 연결 한도를 기준으로 부하 테스트를 통해 설정합니다.
    • 배포나 스케일 인·아웃으로 Upstream 인스턴스가 바뀔 때는 오래된 연결을 정상적으로 드레이닝(Draining)하고, 헬스 체크를 통과한 인스턴스에만 새 연결을 생성합니다.

  • HTTP/2 Multiplexing:

    • Gateway ↔ Upstream 간 통신 프로토콜을 HTTP/1.1에서 HTTP/2 또는 gRPC로 전환합니다.
    • 단 1개의 TCP 커넥션 상에서 바이너리 프레임 기반의 멀티플렉싱(Multiplexing)을 수행하여, 여러 요청과 응답을 동시에 병렬 처리합니다.

  • Aggressive Keep-Alive & Timeout 전략:

    • TCP 커넥션의 Keep-Alive 유지 시간과 idle timeout을 Upstream·로드밸런서의 timeout보다 짧거나 길지 않도록 일관되게 조정합니다. 지나치게 긴 연결은 유휴 리소스를 점유하고, 지나치게 짧은 연결은 핸드셰이크를 증가시킬 수 있습니다.
    • HTTP/2는 커넥션당 최대 동시 스트림 수와 장기 스트림의 영향을 함께 관찰합니다. 필요하면 여러 커넥션으로 분산해 특정 커넥션의 지연이 전체 요청에 영향을 주지 않도록 합니다.

5.4 모니터링 및 핵심 관측 지표 (Metrics)

API Gateway 병목 여부와 최적화 효과를 추적하기 위해 반드시 모니터링해야 하는 핵심 지표는 다음과 같습니다.

지표 (Metric)설명권장 목표치 / 튜닝 방향
Gateway CPU per Request요청 1건당 소비되는 CPU 시간 또는 CPU 사용률 추이인증·정책 처리 전후의 변화와 포화 여부를 비교
Upstream Connection Reuse RatioUpstream 커넥션 재사용 비율 (Reused / Total Conns)신규 연결 급증 여부를 확인하고 서비스 특성에 맞는 목표치 설정
Auth Verification Latency토큰 서명 검증 및 인증 처리 소요 시간 (p50, p99)캐시 히트·미스 비율과 함께 확인하여 인증 병목 여부 판단
Gateway Socket State CountsOS 커넥션 소켓 상태 (TIME_WAIT, ESTABLISHED)TIME_WAIT 소켓의 급증 방지 및 일정 수준 유지
Upstream Latency Breakdown요청 단계별(파싱, 인증, 라우팅, Upstream 응답) 소요 시간 세분화OpenTelemetry 트레이싱으로 구간별 병목을 파악
Gateway 오류율 및 거절 수4xx/5xx, timeout, Rate Limit 거절 건수배포·스케일링 직후의 오류 증가와 원인을 확인

Reference

Previous
slow index
Next
AWS NAT Gateway