MSA 개발에서 API Gateway 패턴 사용은 옵션이 아닌 필수입니다. 이번 사례에서는 효과적인 API 제공을 위하여 우리 서비스에는 어떠한 API Gateway 패턴을 선택해야 하는지 알아봅니다.

API의 ProgrammableWeb 디렉토리는 2005년부터 외부에서 사용 가능한 API를 추적해 왔으며 2019년 6월에 개수가 22,000개를 넘었습니다. 게시된 API의 수는 그 날짜까지 4년 동안 거의 60% 증가하여 API 경제가 은(는) 강력하게 성장할 뿐만 아니라 여기에 머물러 있습니다.

API는 많은 비즈니스의 핵심이며 막대한 가치와 수익을 제공합니다. 이제 IT 조직은 앞서 나가기 위해 API에 대한 액세스를 관리하고 제어할 수 있는 방법이 그 어느 때보다 필요합니다.

목차

1. API 관리의 중요성
2. API Gateway ≠ API Management
3. 일반적인 API Gateway 배포(Deployment) 패턴
  3-1. 중앙 집중식, Edge Gateway
  3-2. Two-Tier(2계층) Gateway
  3-3. Microgateway (마이크로게이트웨이)
  3-4. 파드별(Per-Pod) Gateway
  3-5. 사이드카 게이트웨이 및 서비스 메시 (Sidecar Gateways and Service Mesh)
4. NGINX의 효과적인 API 딜리버리(Delivery)

1. API 관리의 중요성

조직이 모놀리식 애플리케이션에서 마이크로서비스 기반 앱으로 전환하기 시작하면서 API가 효율적인 디지털 커뮤니케이션을 촉진할 뿐만 아니라 새로운 수익원이 될 수 있다는 것도 깨달았습니다. 예를 들어 Salesforce.com은 API를 통해 연간 수익의 50% 이상을 창출하지만 Expedia.com은 거의 90%를 API에 의존합니다.

이러한 높은 이해 관계로 인해 기업은 API가 고성능, 제어 및 보안 상태인지 확인해야 합니다. API 구조 문제를 감당할 수 없습니다.

2. API Gateway ≠ API Management

API Gateway와 API Management라는 용어는 때때로 같은 의미로 사용되지만 차이점이 있다는 점에 유의해야 합니다.

API Gateway는 API에 대한 액세스를 위한 gatekeeper로서 API 소비자와 해당 API를 노출하는 애플리케이션 간의 트래픽을 보호하고 관리합니다. API Gateway는 일반적으로 인증 및 권한 부여, Backend에 대한 요청 라우팅, 시스템 과부하를 방지하고 DDoS 공격으로부터 보호하기 위한 속도 제한(rate limiting), 성능 향상을 위해 SSL/TLS 트래픽 오프로드, 오류 또는 예외 처리를 처리합니다.

반대로 API Management는 API 정의(defining) 및 게시(publishing), 성능 모니터링, 비즈니스 가치 극대화를 위한 사용 패턴 분석을 포함하여 전체 수명 주기에 걸쳐 API를 관리하는 프로세스를 의미합니다.

3. 일반적인 API Gateway 배포(Deployment) 패턴

그렇다면 API를 효과적으로 제공하려면 어떻게 해야 할까요?

세계 최고의 API Gateway인 NGINX는 오늘날 웹에서 API 트래픽의 절반 이상을 제공합니다. 기술적으로 “올바른” 패턴은 없지만 일반적으로 접하게 되는 가장 일반적인 API Gateway 패턴은 다음과 같습니다.

3-1. 중앙 집중식, Edge Gateway

이것은 가장 일반적인 API Gateway 패턴이며 기존 ADC(Application Delivery Controller) 아키텍처를 따릅니다. 이 패턴에서 Gateway는 다음을 포함하여 거의 모든 것을 처리합니다.

• SSL/TLS termination
• 인증 (Authentication)
• 권한 부여 (Authorization)
• 요청 라우팅 (Request routing)
• 속도 제한 (Rate limiting)
• Request/response manipulation
• Facade routing

이 접근 방식은 중앙 집중식 거버넌스를 통해 모놀리식 애플리케이션의 애플리케이션 서비스를 공개적으로 노출할 때 적합합니다. 그러나 마이크로서비스 아키텍처나 빈번한 변경이 필요한 상황에는 적합하지 않습니다. 기존의 Edge Gateway는 north-south 트래픽에 최적화되어 있으며 분산 마이크로서비스 환경에서 생성되는 더 많은 양의 east-west 트래픽을 효율적으로 처리할 수 없습니다.

3-2. Two-Tier(2계층) Gateway

서비스가 점점 더 작아지고 더 많이 분산됨에 따라 많은 조직이 다중(multiple) Gateway에 대한 역할 분리를 도입하는 2계층(multi-layer) 게이트웨이 패턴으로 이동하고 있습니다.

이 접근 방식은 다음을 관리하는 첫 번째 계층으로 보안 게이트웨이를 활용합니다.

• SSL/TLS termination
• 인증 (Authentication)
• 연결 및 요청의 중앙 집중식 로깅 (Centralized logging of connections and requests)
• 추적 주입 (Tracing injection)

라우팅 게이트웨이는 다음을 처리하는 두 번째 계층의 역할을 합니다.

• 권한 부여 (Authorization)
• 서비스 발견 (Service discovery)
• 부하 분산 (Load balancing)

2계층 게이트웨이 패턴은 분산된 서비스와 독립적인 기능 확장을 위한 유연성이 필요한 상황에서 가장 잘 작동합니다. 그러나 이 접근 방식은 분산 제어를 지원하지 않기 때문에 서로 다른 환경과 애플리케이션을 관리하는 여러 팀이 있는 경우 문제가 발생할 수 있습니다.

3-3. Microgateway (마이크로게이트웨이)

microgateway 게이트웨이 패턴은 개별 DevOps 팀에 전용 게이트웨이를 제공하여 2계층 접근 방식을 기반으로 합니다. 이는 개별 DevOps 팀이 서비스 간 트래픽(east-west 트래픽)을 관리하는 데 도움이 될 뿐만 아니라 다른 애플리케이션에 영향을 주지 않고 변경할 수 있도록 합니다.

이 pattern은 edge에서 다음 기능을 활성화합니다.

• SSL/TLS termination
• 라우팅 (Routing)
• 속도 제한 (Rate limiting)

그런 다음 조직은 다음을 관리하는 각 서비스에 대해 개별 microgateway를 추가합니다.

• 부하 분산 (Load balancing)
• 서비스 발견 (Service discovery)
• API별 인증 (Authentication per API)

microgateway는 마이크로서비스와 함께 작동하도록 설계되었지만 일관성과 제어를 달성하기 어렵게 만들 수도 있습니다. 각 개별 microgateway에는 다양한 정책, 보안 규칙 세트가 있을 수 있으며 여러 서비스의 모니터링 및 메트릭 집계가 필요할 수 있습니다. microgateway는 쉽게 “micro”의 반대가 될 수 있습니다. API 또는 API 세트의 비즈니스 목적을 기반으로 하는 전체 구성이 필요합니다.

3-4. 파드별(Per-Pod) Gateway

파드(Pod)별 게이트웨이 패턴은 프록시 게이트웨이를 개별 파드 또는 컨테이너에 포함하여 microgateway 패턴을 수정합니다. 게이트웨이는 파드에 대한 수신(Ingress) 트래픽을 관리하고 인증 및 속도 제한(rate limiting)과 같은 정책을 적용한 다음 요청을 로컬 마이크로서비스에 전달합니다.

파드별 게이트웨이 패턴은 라우팅 또는 로드 밸런싱을 수행하지 않으므로 위 패턴 중 하나와 조합하여 배포되는 경우가 많습니다. 특히 파드별 게이트웨이를 사용하여 다음 기능 중 일부 또는 전체를 수행할 수 있습니다.

• Pod의 애플리케이션에 대한 SSL/TLS termination
• 추적 및 메트릭 생성
• 인증 (Authentication)
• 속도 제한 및 대기열 (Rate limiting and queuing)
• Error handling, including circuit breaker‑style error messages

파드당 게이트웨이는 일반적으로 가볍고 구성이 정적입니다. 트래픽을 로컬 마이크로서비스 인스턴스로만 전달하므로 애플리케이션의 토폴로지가 변경되는 경우 재구성할 필요가 없습니다. 정책 중 하나를 변경해야 하는 경우 마이크로서비스 파드를 새 프록시 구성으로 다시 배포할 수 있습니다.

3-5. 사이드카 게이트웨이 및 서비스 메시 (Sidecar Gateways and Service Mesh)

사이드카 게이트웨이 패턴은 게이트웨이를 마이크로서비스와 함께 수신(ingress) 및 송신(egress) 프록시로 배포합니다. 이를 통해 사이드카 프록시가 인바운드 및 아웃바운드 통신을 모두 처리하고 라우팅하여 서비스가 서로 직접 통신할 수 있습니다.

이 패턴은 다음을 관리하는 Edge Gateway를 사용합니다.

• SSL/TLS termination
• 클라이언트 인증 (Client authentication)
• 중앙 집중식 로깅 (Centralized logging)
• 추적 주입 (Tracing injection)

그런 다음 사이드카 프록시는 다음을 제공하는 각 서비스의 진입점(entry point)으로 사용됩니다.

• 아웃바운드 부하 분산 (Outbound load balancing)
• 서비스 검색 통합 (Service discovery integration)
• 서비스 간 인증 (Inter‑service authentication)
• 권한 부여 (Authorization)

사이드카 패턴은 사이드카 프록시가 자주 변경되는 전체 애플리케이션 토폴로지를 인식하는 경우에만 필요에 따라 아웃바운드 라우팅 및 로드 밸런싱을 수행할 수 있기 때문에 상당한 제어 평면 복잡성을 도입합니다. 사이드카 프록시는 로컬 애플리케이션의 모든 아웃바운드 요청을 투명하게 가로채야 하므로 패턴은 데이터 평면 복잡성도 도입합니다. 패턴은 패턴에 필요한 사이드카 프록시, 주입, 트래픽 캡처 및 통합 제어 평면을 제공하는 사이드카 기반 서비스 메시를 사용하여 가장 쉽게 구현됩니다. 사이드카 프록시 패턴은 서비스 메시에 대한 가장 인기 있는(아직 성숙하기는 하지만) 접근 방식으로 서서히 떠오르고 있으며, 서비스 메시 제어 평면에서 개별 프록시를 구성하는 여러 팀에 대한 역할 기반 액세스 제어를 가능하게 합니다.

4. NGINX의 효과적인 API 딜리버리(Delivery)

오늘날 기술은 혁신, 성장 및 수익성을 위한 주요 차별화 요소입니다. API는 조직이 고객, 내부 사용자 및 파트너에게 향상된 경험을 제공할 수 있도록 하는 서비스 및 데이터에 대한 액세스를 가능하게 하는 현대 디지털 비즈니스를 이끄는 연결 조직입니다. API가 많을수록 API를 간소화, 확장 및 보호할 수 있는 올바른 최신 API 관리 솔루션을 갖추는 것이 더욱 중요합니다.

NGINX는 API Gateway로서의 NGINX Plus의 원시 성능(raw power)과 효율성을 NGINX Controller와 결합하여 사용 가능한 가장 빠른 API Management 솔루션을 제공합니다. 이를 통해 팀은 멀티 클라우드 환경에서 대규모로 API를 정의, 게시, 보호, 모니터링 및 분석할 수 있습니다.