API Gateway에 필요한 리소스를 결정하는 방법은?
January 25, 2024
배경
API 게이트웨이는 기업의 외부 서비스를 위한 통합 진입점 역할을 하며, 그 중요성은 부인할 수 없습니다. API 게이트웨이 자체의 가용성에 문제가 생기면 기업이 제공하는 모든 서비스에 직접적인 영향을 미치게 되며, 이는 받아들일 수 없는 재앙입니다. 따라서 프로덕션 시나리오에서 API 게이트웨이의 적절한 배포 규모를 결정하는 것이 중요합니다.
필요한 리소스를 결정하는 것은 API 게이트웨이의 성능, 가용성 및 안정성을 보장하고, 리소스 활용과 비용 효율성을 최적화하는 데 필수적입니다. 리소스가 부족하면 요청 시간 초과, 혼잡 및 패킷 손실과 같은 문제가 발생하여 사용자 경험과 서비스 품질에 영향을 미칠 수 있습니다. 반대로, 과도한 리소스는 리소스 낭비, 운영 복잡성 증가, 비용 및 위험 증가로 이어질 수 있습니다.
따라서 API 게이트웨이에 필요한 리소스를 결정하는 것은 중요한 단계이며, 비즈니스 요구 사항, 트래픽 예측 및 성능 테스트를 기반으로 신중한 계획과 조정이 필요합니다. 이 글은 다양한 산업의 모범 사례를 참고하여 참조할 수 있는 세 단계 프로세스를 설명합니다:
- 게이트웨이 선택: 단일 코어 QPS
- 비즈니스 유형: 금융 또는 비금융 서비스
- 고가용성 요구 사항
게이트웨이 선택
API 게이트웨이의 기본 구성 요소의 병목 현상은 일반적으로 네트워크, 디스크 또는 메모리가 아닌 CPU에 있습니다. API 게이트웨이의 단일 코어 CPU 처리 능력은 그 우수성을 나타내는 중요한 지표입니다. 동일한 API 요청 트래픽에 대해 리소스 소비가 낮을수록 필요한 머신 수가 줄어들어 운영 관리가 간소화되고 서비스 가용성이 향상됩니다.
Apache APISIX는 오픈소스 API 게이트웨이로, 모니터링, 속도 제한 등 일반적인 기업용 플러그인이 활성화된 상태에서 단일 코어 CPU가 최소 10,000 QPS를 지원할 수 있다고 보수적으로 추정합니다. 기업은 활성화된 플러그인, 하드웨어 환경, 네트워크 조건 및 API 요청 특성의 차이를 고려하여 구체적인 테스트를 수행하고 결과를 수집할 수 있습니다.
비즈니스 유형
대부분의 비금융 기업은 프로덕션 환경에서 API 게이트웨이의 CPU 리소스 사용량을 20-30% 범위 내에서 제어할 수 있으며, 이는 이상적인 시나리오입니다. 서비스 호출이 3-5배 증가하더라도 효과적으로 처리할 수 있습니다. 뉴스, 엔터테인먼트, 인터넷과 같은 산업은 이러한 부하를 사용할 수 있습니다.
그러나 은행, 금융, 증권과 같은 산업에서는 API의 가치가 높기 때문에 일상적인 CPU 부하를 5-10%로 유지하는 것이 이상적입니다. 이를 통해 API 게이트웨이는 평소보다 10-20배 높은 갑작스러운 트래픽 급증을 처리할 수 있습니다.
고가용성 요구 사항
가용성에 대한 더 높은 요구 사항이 있는 경우, API 게이트웨이 프록시 인스턴스는 최소 2개의 노드를 가져야 합니다.
실제 사례
금융 서비스 부문 사용자
기업 사례:
- 일일 API 호출 QPS는 100,000
- API 게이트웨이의 일일 부하는 10%
- 게이트웨이 선택: Apache APISIX (단일 코어 QPS: 10,000)
위 정보를 기반으로 필요한 CPU 수는 100,000 / 10,000 / 10% = 100입니다. 4 CPU 코어 머신을 사용하는 경우 25대가 필요하며, 8 CPU 코어 머신을 사용하는 경우 13대가 필요합니다.
비금융 서비스 부문 사용자
기업 사례:
- 일일 API 호출 QPS는 100,000
- API 게이트웨이의 일일 부하는 25%
- 게이트웨이 선택: Apache APISIX (단일 코어 QPS: 10,000)
위 정보를 기반으로 필요한 CPU 수는 100,000 / 10,000 / 25% = 40입니다. 4 CPU 코어 머신을 사용하는 경우 10대가 필요하며, 8 CPU 코어 머신을 사용하는 경우 5대가 필요합니다.
결론
실제 사용에서 트래픽은 복잡하고 가변적이므로 평균을 유연하게 조정해야 합니다. APISIX와 같은 우수한 API 게이트웨이를 채택하고 하드웨어 리소스를 적절히 구성함으로써 기업은 비용과 서비스 요구 사항을 더 잘 균형 잡을 수 있으며, 기업 API를 최종 사용자에게 안전하고 안정적이며 효율적으로 노출시킬 수 있습니다.