원문: Pier-Jean Malandrino, "Architecture Patterns: API Gateway"
"API 게이트웨이"란 무엇인가
API 게이트웨이는 서버나 마이크로서비스로부터 자원을 찾는 클라이언트의 요청을 중개하는 도구입니다. API 게이트웨이는 관리하고, 라우팅하고, 통합하고, 보호합니다.
이전에 살펴본 여러 패턴과 마찬가지로 이 패턴은 "마이크로서비스 맥락" 패턴으로 자주 설명되지만 꼭 그런 것만은 아닙니다. "마이크로서비스가 아닌" 경우에도 사용할 수 있으며 때때로 마이크로서비스에서 사용하지 말아야 할 때도 있습니다.
자세한 내용을 알아봅시다.
요청 라우팅
이 기능은 클라이언트의 요청을 받아 어떤 서비스가 요청을 처리할지 결정하는 것입니다. 다양한 측면이 있을 수 있습니다.
동적 라우팅: API 게이트웨이는 URL 경로, HTTP 메서드, HTTP 헤더 등을 기반으로 요청을 동적으로 라우팅할 수 있습니다. 주의: 다중 테넌시 컨텍스트에서 유용할 수 있습니다.
서비스 버전 관리: 여러 버전의 서비스를 동시에 유지할 수 있습니다. 클라이언트는 상호작용할 버전을 지정할 수 있습니다. 주의: 이는 마이크로서비스 환경에서 매우 유용할 뿐 아니라 SOA 또는 다양한 버전을 허용해야 하는 모든 유형의 API에 매우 유용합니다.
부하 분산: 일부 게이트웨이는 로드 밸런서와 함께 서비스의 여러 인스턴스로 부하를 분산할 수 있습니다.
API 구성
여러 서비스 요청을 단일 응답으로 결합하여 클라이언트 통신을 간소화합니다. 다음과 같이 수행할 수 있습니다.
집계: 예를 들어 클라이언트가 사용자와 주문에 대한 세부 정보를 원할 수 있습니다. 별도의 호출을 하는 대신 한 번의 호출을 통해 게이트웨이가 사용자와 주문 서비스에서 데이터를 가져와 결과를 집계합니다.
변환: 여러 서비스의 데이터를 클라이언트가 원하는 형식으로 변환합니다.
주의: 이 부분은 프런트엔드를 위한 백엔드(BFF)라고 불리는 다른 패턴으로도 달성할 수 있으며 필요에 따라 게이트웨이와 결합할 수도 있습니다.
요청 제한
주어진 시간 내에 사용자 또는 서비스가 할 수 있는 요청의 수를 제한합니다. 이는 API를 보호하는 데 매우 유용하며 여러 용도가 있습니다.
클라이언트별 제한: 클라이언트의 역할, 구독 수준 등에 따라 다른 요청 제한을 둘 수 있습니다.
버스트 제한 대 지속적 제한: 단기적인 트래픽 버스트를 허용하거나 더 긴 기간 동안 요청을 제한합니다.
시스템 과부하 방지: 너무 많은 요청으로 인해 서비스가 과부하되어 성능 저하 또는 장애가 발생하지 않도록 보장합니다.
보안
허가된 요청만 서비스에 도달하도록 보장함으로써 클라이언트별 인증을 제공할 수 있습니다.
인증: JWT, OAuth 토큰, API 키 등과 같은 방법을 사용하여 클라이언트의 신원을 확인합니다.
권한 부여: 인증된 클라이언트가 할 수 있는 작업을 결정합니다.
위협 감지: 일부 게이트웨이는 DDoS 공격, SQL 인젝션 등 잠재적 보안 위협을 식별하고 차단할 수 있습니다 (이전 논의와 관련됨).
캐싱
자주 사용되는 데이터를 임시로 저장하여 후속 요청을 더 빠르게 처리합니다. 이는 추구하는 캐싱 전략에 따라 달라질 수 있으며 BFF에서도 할 수 있고 전혀 안 할 수도 있습니다.
응답 캐싱: 중복 요청을 피하기 위해 일반적인 요청에 대한 서비스 응답을 저장합니다.
TTL(Time-To-Live): 캐싱된 데이터가 너무 오래되지 않도록 보장하기 위해서 저장 기간을 설정합니다.
캐시 무효화: 오래되었거나 잘못된 데이터를 제거하는 메커니즘입니다.
서비스 탐색
자동으로 서비스 인스턴스의 네트워크 위치를 찾습니다.
동적 위치: 쿠버네티스와 같은 동적 환경에서는 서비스가 이동할 수 있습니다. 게이트웨이는 이 위치를 추적하여 소비자가 신경 쓰지 않도록 합니다. 이는 클라이언트 측에서 확장성 효과를 분리하는 방법입니다.
상태 확인: 서비스 인스턴스가 상태 확인에 실패하면 게이트웨이는 해당 인스턴스로 요청을 라우팅하지 않습니다. 이는 소비자가 중단된 서비스에 요청을 보내지 않도록 방지하여 장애 관리 품질을 개선하고 일부 유형의 악용을 방지할 수 있습니다.
서비스 검색 도구와의 통합: 주로 Consul, Eureka 또는 쿠버네티스 서비스 탐색과 같은 도구와 통합됩니다.
분석 및 모니터링
API 사용량 및 시스템 상태에 대한 데이터를 수집합니다. 특히 이 기능을 통해 시스템의 복잡성에 관계없이 전체 시스템 활동을 파악할 수 있기 때문에 데브옵스는 이 기능에 관심을 가질 것입니다.
로깅: 모든 요청과 응답에 대한 데이터를 캡처합니다.
메트릭: 요청률, 응답 시간, 오류율 (HTTP 코드 등으로 분류) 등의 주요 메트릭을 추적합니다.
시각화: Grafana 또는 Kibana와 같은 도구와 통합하여 데이터를 시각화합니다.
알림: 문제가 발생하거나 메트릭이 임계치를 초과하면 시스템 운영자에게 알립니다.
이것은 일반적인 표현일 수 있습니다.
장점과 트레이드오프
장점
간소화된 클라이언트
통합 접근점을 통해 클라이언트는 백엔드 서비스의 복잡성을 몰라도 통신할 수 있습니다. 다양한 엔드포인트와 프로토콜을 직접 처리할 필요가 없으므로 클라이언트 개발을 간소화하고 일관된 경험을 유지합니다.
중앙 집중식 관리
API 게이트웨이의 주요 장점은 요청 제한이나 보안 검사와 같은 일반적인 기능이 한 곳에서 처리된다는 점입니다. 이는 중복 코드를 줄이고 규칙과 정책의 일관된 애플리케이션을 보장합니다.
횡단 관심사
로깅이나 모니터링과 같이 다중 서비스에 적용되는 문제들은 게이트웨이 수준에서 처리할 수 있습니다. 이는 일관성을 보장하고 모든 서비스에서 이러한 기능을 구현해야 하는 오버헤드를 줄입니다.
최적화된 요청과 응답
클라이언트의 요구사항 (예: 모바일 대 웹 대 데스크톱)에 따라 API 게이트웨이는 요청과 응답을 수정할 수 있습니다. 불필요한 페이로드를 줄이고 속도를 높여 클라이언트에게 가장 최적화된 형식의 데이터를 제공하는 것을 보장합니다.
보안 강화
인증 및 권한 부여 메커니즘을 중앙 집중화함으로써 게이트웨이는 일관되고 강력한 보안 장벽을 제공합니다. 또한 트래픽을 암호화하여 추가적인 데이터 보호 계층을 제공합니다.
안정성
회로 차단과 같은 기능은 서비스 과부하를 방지하여 순조로운 시스템 운영을 보장합니다. 게이트웨이는 서비스가 응답하지 않을 경우 신속하게 요청을 라우팅하거나 일시 중지하여 전체의 시스템 상태를 유지할 수 있습니다.
트레이드오프
단일 장애 지점(SPOF)
적절한 고가용성 및 장애 조치 전략이 없으면 API 게이트웨이는 시스템의 약점이 될 수 있습니다. 게이트웨이가 다운되면 백엔드 서비스에 대한 모든 접근이 차단될 수 있습니다. 이는 프로덕션 환경에 매우 전략적이고 민감한 요소가 될 뿐 아니라 주어진 환경에서 게이트웨이가 작업할 때 해당 접근에 의존하는 모든 서비스가 영향을 받기 때문에 생산 및 개발 측면에서 모두 고려되어야 합니다.
복잡성
API 게이트웨이를 도입하면 관리하고 운영해야 할 또 다른 구성 요소가 추가됩니다. 이는 배포 복잡성을 증가시킬 수 있으며 추가 구성 및 유지보수가 필요할 수 있습니다. 항공 우주 개발뿐만 아니라 소프트웨어 엔지니어링에서도 동의하는 "최고의 부품은 없는 부품"이라는 일론 머스크의 말에 동의합니다.
지연 시간
모든 요청과 응답이 게이트웨이를 통과하므로 광범위한 처리나 변환이 이루어지는 경우 추가적인 지연 시간이 발생할 수 있습니다. 이전 논의와 마찬가지로 일반적으로 트랜잭션 경로에 더 많은 구성 요소가 있을수록 더 많은 시간이 걸립니다.
확장 문제
높은 트래픽은 API 게이트웨이에 부담을 줄 수 있습니다. 게이트웨이가 성능 저하 없이 최대 부하를 처리하기 위해 수직 및 수평 확장 모두를 포함한 적절한 전략이 필수입니다 (SPOF 논의에 연결됨).
잠재적 비효율성
신중하게 설계하지 않으면 게이트웨이가 중복된 API 호출이나 불필요한 데이터 변환과 같은 비효율이 생길 수 있습니다. 적절한 최적화와 지속적인 모니터링이 중요합니다.
결론
API 게이트웨이는 많은 아키텍처 패턴과 마찬가지로 최신 소프트웨어 시스템의 다양한 요구를 충족시키는 강력한 기능 모음을 제공합니다. 클라이언트 요청을 위한 통합 진입점을 제공함으로써 마이크로서비스 기반 시스템에서 클라이언트와 서비스 간의 상호 작용을 간소화하고, 보안을 강화하며, 최적화합니다. 그러나 다른 도구나 패턴과 마찬가지로 고유한 문제점이 있습니다. 지연 시간 증가의 가능성, 특수한 확장 고려 사항의 필요성, 단일 장애 지점의 위험성은 신중한 계획, 설계, 지속적인 모니터링의 중요성을 강조합니다. 신중하게 활용하고 장점과 트레이드오프를 철저히 이해한다면 API 게이트웨이는 확장 가능하고 안전하며 효율적인 시스템 상호 작용을 달성하는 데 있어 매우 유용하게 될 수 있습니다. 항상 그렇듯이 설계자와 개발자는 API 게이트웨이가 특정 상황에 적합한지 판단하기 위해 장단점을 저울질해야 하고 잠재적 위험을 완화하며 그 힘을 활용해야 합니다.