실시간 API Gateway 아키텍처

실시간 API 는 우리 삶에서 얼마나 중요한 역할을 하는지 보여주었습니다. 기업이 디지털 시대에 경쟁을 추구함에 따라 API는 중요한 IT 및 비즈니스 리소스가 되었습니다. 올바른 기본 인프라를 설계하면 API가 안정적이며 안전한 것뿐만 아니라 30ms(0.03초) 내에 End-to-End 간 API 호출을 처리할 수 있는 실시간 API 자격을 갖추게 됩니다.

API 아키텍처는 크게 Data Plane 또는 API Gateway와 정책 및 개발자 포털 서버를 포함하는 Control Plane의 두 가지 구성 요소로 나뉩니다. 실시간 API 아키텍처는 대부분 API 트래픽을 처리하는 Proxy 역할을 하는 API Gateway에 의존합니다. 이는 Performance Chain의 중요한 링크입니다.

API Gateway는 API 인증, 올바른 Backend로 API 요청 라우팅, 시스템 과부하 방지를 위한 Rate Limit 적용, 오류 및 예외 처리 등 다양한 기능을 수행합니다. 실시간 API를 구현하기로 결정했다면 API Gateway 아키텍처의 주요 특징은 무엇입니까? API Gateway를 어떻게 배포합니까?

이 포스트는 NGINX의 가장 크고 가장 까다로운 고객과의 작업을 기반으로 실시간 API 참조 아키텍처를 제공하여 이러한 질문에 답합니다. API 관리 솔루션의 모든 측면을 포괄하지만 Real-TIme 성능 임계값이 충족되는지 확인하는 역할을 하는 API Gateway에 대해 자세히 설명합니다.

목차

1. 실시간 API 참조 아키텍처
1-1. 실시간 API Gateway
1-2. API 정책 서버
1-3. API 개발자 포털
1-4. API 보안 서비스
1-5. API ID 서비스
1-6. DevOps 도구
2. 실시 API Gateway 특성 및 아키텍처 지침
2-1. 고가용성 API Gateway 배포
2-2. API Gateway 인증 및 권한 부여
2-3. 동적 인증 활성화
2-4. 회로 차단기를 사용
2-5. API Gateway Layer 변환
2-6. gRPC 사용
3. NGINX는 어떻게 도움이 될까요?

1. 실시간 API 참조 아키텍처

실시간 API 참조 아키텍처에는 6가지 구성 요소가 있습니다.

1. API Gateway – API 트래픽을 처리하는 빠르고 가벼운 Data Plane 구성 요소입니다. 이것은 Real-Time 아키텍처에서 가장 중요한 구성 요소입니다.
2. API 정책 서버 – API Gateway를 구성하고 API Lifecycle 관리 정책을 제공하는 분리된 서버입니다.
3. API 개발자 커뮤니티 – API를 사용하는 개발자를 위한 신속한 온보딩(Onboarding)을 위한 문서를 제공하는 분리된 웹 서버입니다.
4. API 보안 서비스 – API Gateway에 내장된 기본 보안 메커니즘 이상의 보안을 제공하는 별도의 WAF(Web Application Firewall) 및 Fraud Detection 구성 요소입니다.
5. API ID 서비스 – ID 및 액세스 관리를 위한 인증 및 권한 부여 정책을 설정하고 API Gateway 및 정책 서버와 통합하는 별도의 서비스입니다.
6. DevOps 도구 – API 관리를 CI/CD 및 개발자 Pipeline에 통합하기 위한 별도의 도구 집합입니다.

물론 API 소비자, API Endpoint과 같은 요소와 라우터, 스위치, VM, 컨테이너 등과 같은 다양한 인프라 구성 요소가 있습니다. 필요한 경우 참조 아키텍처에 포함되지만 기업의 공통 인프라로 간주되므로 자세히 논의하지 않습니다. 대신 포괄적인 실시간 API 아키텍처를 생성하는 데 필요한 이 6가지 구성 요소에 집중하겠습니다.

그림 1. Data Plane(API Gateway)을 Control plane에서 분리하여 API 호출 처리에서 관리 Overhead를 제거하는 분리된 아키텍처

그림 2. 런타임 시 실시간 API를 위한 참조 아키텍처: Load Balancer가 전면에 있고 WAF로 보호되는 API Gateway 클러스터

1-1. 실시간 API Gateway

API Gateway의 기능에는 API 요청 라우팅, 인증, TLS Termination, Rate Limit 및 Microservices 아키텍처에 배포될 때 서비스 검색이 포함됩니다. 고가용성을 보장하려면 API를 Expose 하는 각 애플리케이션의 트래픽을 관리하기 위해 API Gateway 클러스터를 배포해야 합니다. API 트래픽을 효율적으로 분산하기 위해 클러스터 앞에 Load Balancer를 배치합니다. Load Balancer는 location (클라이언트 애플리케이션과의 거리) 또는 API 처리 용량을 기준으로 Gateway를 선택합니다. 그런 다음 Gateway는 요청을 Backend로 전달합니다. 최상의 성능을 위해 아래의 실시간 API Gateway이 특성 및 아키텍처 지침에 자세히 설명된 모범 사례를 구현하십시오.

1-2. API 정책 서버

이는 개발자와 DevOps팀이 API를 정의, 게시 및 보호하고 IT Operations이 API를 모니터링 및 분석할 수 있는 Control Plane입니다. 여기에서 Backend 서비스에 대한 요청 라우팅을 구성하고 게시된 API에서 허용되는 항목(예: 읽기 전용 또는 읽기 쓰기) 및 사용할 수 있는 사용자 또는 클라이언트 애플리케이션의 종류를 지정하는 세분화된 액세스 제어 정책을 구성합니다.

또한 정책 서버는 사용을 위해 Expose 해야 하는 모든 API로 API Gateway를 구성합니다. Real-Time 성능을 얻으려면 이 구성 요소를 API 트래픽을 중재하는 API Gateway Data Plane에서 완전히 분리해야 합니다(그림 2 참조). Data Plane이 인증, Rate Limit 및 각 API 호출을 적절한 Backend로 라우팅하기 위해 정책 서버에 의존하는 경우 API 사용자가 시작한 API 호출은 이 Control Plane(경우에 따라 연결된 데이터베이스)을 통과하므로 추가 Overhead로 인해 지연 시간이 더 길어집니다.

1-3. API 개발자 포털

이 구성 요소를 사용하면 API를 사용하는 개발자가 효율적인 방식으로 온보딩 할 수 있습니다. 개발자 포털은 게시된 모든 API의 카탈로그, 각 API에 대한 설명서 및 샘플 코드를 제공합니다. 성능과 가용성을 개선하기 위해 개발자 포털은 Control Plane에서 분리되어 자체 웹 서버에서 별도로 호스팅 됩니다. 분산 개발자 포털을 사용하면 여러 인스턴스를 서로 다른 클라우드, 지역 또는 가용성 영역(Availability Zone)에 배치할 수 있습니다. 이렇게 하면 액세스하는 개발자의 능률을 향상시킬 수 있지만 Data Plane에서 분리되기 때문에, API 호출 처리의 효율성에는 영향을 미치지 않습니다.

1-4. API 보안 서비스

API 보안은 가장 일반적으로 다양한 공격을 감지하기 위해 고급 웹 애플리케이션 방화벽(WAF)을 수반합니다. 신뢰도가 높은 서명을 제공하고 잘못된 형식의 JSON, NULL 요청 또는 gRPC 프로토콜을 준수하지 않는 요청으로 인한 위반을 방지할 수 있어야 합니다. 경로 적용, 메서드 적용, 데이터 유형 검증 및 전체 스키마 검증을 포함한 고급 API 보호를 지원해야 합니다. 이 구성 요소는 Gateway 클러스터와 Load Balancer를 모두 보호해야 합니다.

또한 많은 조직에서 API Fraud Detection를 배포합니다. 이 기능은 API 호출의 논리를 자세히 조사하여 악의적인지 비정상인지 확인하는 작업이 포함됩니다. Fraud Detection는 종종 별도의 기능이지만 시행을 위해 API Gateway 또는 WAF 계층에 연결될 수 있습니다.

API 보안은 거의 필연적으로 지연 시간을 초래하므로 API 처리가 실시간 API 성능 임계값인 30ms를 초과할 수 있다는 점에 유의해야 합니다. 우리는 조직이 API 보안이 더 중요한지 아니면 절대적인 성능이 더 중요한지 결정하도록 권장합니다. 참조 아키텍처에 API 보안을 포함하여 API 관련 보호를 제공하지 않을 수 있는 Edge 또는 경계 보안과 어떻게 다른지 보여줍니다.

1-5. API ID 서비스

이 구성 요소는 API를 보호하고 Backend 리소스를 보호하는 액세스 및 권한 부여 정책을 제공합니다. 권장되는 모범 사례는 Okta 및 Ping Identity와 같은 주요 ID 제공자와 통합하여 API에 대한 안전한 액세스를 보장하는 것입니다. 이러한 솔루션을 사용하면 최종 사용자 및 클라이언트 애플리케이션 속성을 차단하는 액세스 정책을 생성하고 관리할 수 있습니다.

이 참조 아키텍처의 목적을 위해 이러한 ID 서비스가 이미 존재한다고 가정하고 전체 API 아키텍처의 완전성을 위해서만 언급합니다.

1-6. DevOps 도구

API Lifecycle 관리(작성, 게시, Gateway 구성, 모니터링)의 모든 측면을 수행하려면 선언적 API 인터페이스가 제공되어야 합니다. 이를 통해 API 생성 및 Gateway 구성 변경을 자동화할 수 있습니다. Ansible과 같은 자동화 플랫폼 및 Jenkins와 같은 CI/CD 툴킷과 원활하게 통합하여 API 릴리스 속도를 가속화할 수 있습니다.

이러한 형태의 자동화는 API 호출 처리 성능 자체에 영향을 미치지 않지만 개발 프로세스의 일부로 신속하게 변경할 수 있도록 하는 것이 중요합니다. DDoS 공격이나 잘못 구성된 API 클라이언트와 같이 성능에 영향을 미치는 문제가 발생하는 경우 CI/CD 통합을 통해 문제를 신속하게 해결하고 API Gateway를 재구성하여 성능을 허용 가능한 수준으로 복원할 수 있습니다.

2. 실시간 API Gateway 특성 및 아키텍처 지침

NGINX는 API 아키텍처를 구축하기 위해 금융 서비스, 소매, 엔터테인먼트 및 소프트웨어 산업의 일부 대규모 조직과 협력했습니다. 이러한 고객은 모두 30ms 미만의 지연 시간으로 매월 수천억 건의 API 호출을 처리하도록 확장되었습니다. 이러한 고객과의 작업을 통해 실시간 API 참조 아키텍처를 뒷받침하는 다음과 같은 6가지 API Gateway 모범 사례를 분석했습니다.

2-1. 고가용성 API Gateway 배포

신속한 응답을 보장하기 위해서는 무엇보다도 API Gateway가 작동 가능해야 합니다. 가용성을 높이려면 API Gateway 클러스터를 사용해야 합니다. 둘 이상의 API Gateway 클러스터는 API의 안정성과 복원력을 향상시킵니다. 효과적인 제어가 일관된 방식으로 적용될 수 있도록 모든 Gateway 간에 작동 상태(예: Rate Limit)를 공유하는 메커니즘이 있어야 합니다.

2-2. 실시간 API Gateway 인증 및 권한 부여

인증은 사용자 또는 호출 Entity가 주장하는 사용자인지 확인하는 프로세스입니다. 권한 부여는 사용자에게 부여되는 권한 또는 액세스 레벨을 결정하는 프로세스입니다.

권한 부여에는 클라이언트가 특정 리소스에 액세스할 수 있는 권한이 있는지 확인하기 위해 일반적으로 JWT(JSON Web Token)를 사용하는 추가 처리가 수반됩니다. 예를 들어 전자상거래 애플리케이션은 모든 클라이언트에게 제품 및 가격 정보에 대한 읽기 전용 액세스 권한을 부여하지만 일부 사용자에게만 읽기 쓰기 액세스 권한을 부여할 수 있습니다. 이러한 세분성으로 인해 API 호출 자체를 처리하는 Backend 서비스가 요청에 대해 필요한 Context를 가지고 있기 때문에 권한 부여가 가장 잘 수행됩니다. Backend의 비즈니스 Logic Layer에 위임된 권한을 통해 Gateway는 조회를 수행할 필요가 없으므로 응답 시간이 매우 빠릅니다. API Gateway는 확실히 이 기능을 수행할 수 있지만 Real-Time 성능이 저하될 수 있습니다.

2-3. 동적 인증 활성화

Gateway에서 인증 정보(API Key 또는 JWT 사용 여부에 관계없이)를 사전 프로비저닝(Provisioning)하면 런타임에 추가 조회가 최소화됩니다. 따라서 인증은 거의 즉시 이루어집니다.

2-4. 회로 차단기(Circuit Breakers)를 사용

회로 차단기(Circuit Breakers)를 구현하면 계단식 오류(cascading failures)를 방지할 수 있습니다. 예를 들어 설명하겠습니다. 여러 Microservices로 구성된 Backend에서 API 호출을 처리한다고 가정합니다. Microservices 중 하나인 Microservices A는 데이터베이스 조회를 수행합니다. 데이터베이스 조회가 실패하면 Microservices A는 오류를 반환하는 데 매우 오랜 시간이 걸립니다. 이는 현재 API 호출뿐만 아니라 후속 API 호출에 대한 API 응답 시간에 악영향을 미칩니다.

회로 차단기(Circuit Breakers)는 이 문제를 해결합니다. 지정된 시간 내에 발생할 수 있는 오류 수에 대한 제한을 설정합니다. 임계값을 초과하면 회로가 작동하고 이후의 모든 호출은 즉시 오류가 발생합니다. 리소스 고갈로 인해 중단된 클라이언트 애플리케이션이나 사용자가 없습니다.

2-5. API Gateway Layer 변환

XML 형식의 요청 페이로드(Payload)를 JSON으로 변환하는 것과 같은 데이터 변환은 계산 집약적인 경향이 있습니다. 이 작업을 다른 서비스에 할당합니다. Gateway에서 변환을 수행하면 API 호출에 상당한 지연 시간이 추가됩니다.

2-6. gRPC 사용

gRPC는 Google에서 도입한 최신 Open Source 원격 프로시저 호출 프레임워크입니다. 광범위한 언어 지원과 심플한 디자인으로 인기를 얻고 있습니다. gRPC는 Google에 따르면 “구조화된 데이터 직렬화를 위한 언어 중립적이고 플랫폼 중립적이며 확장 가능한 메커니즘”인 프로토콜 버퍼에 의존한다고 합니다. gRPC는 HTTP/2를 전송 프로토콜로 사용하므로 데이터 압축 및 TCP 연결을 통한 다중 요청과 같은 HTTP/2의 모든 이점을 자동으로 상속합니다. 다중화를 사용하면 클라이언트와 서버가 단일 TCP 연결을 통해 여러 요청과 응답을 병렬로 보낼 수 있습니다. HTTP/2는 또한 서버 Push를 지원하여 클라이언트가 곧 리소스를 요청할 것으로 예상하여 서버가 클라이언트에 리소스를 미리 Push 할 수 있도록 합니다. 이렇게 하면 리소스가 요청되기 전에 전송되므로 왕복 지연 시간이 줄어듭니다. 이러한 모든 기능으로 인해 클라이언트 애플리케이션에 더 빠르게 응답하고 네트워크를 효율적으로 활용할 수 있습니다.

3. 실시간 API , NGINX는 어떻게 도움이 될까요?

NGINX Plus는 API를 실시간(Real-Time)으로 제공하기 위해 구축되었습니다. 다음을 지원합니다:

• 클러스터의 모든 인스턴스에서 Rate Limit과 같은 상태 정보를 공유할 수 있는 고가용성 클러스터링.
• API Key와 JWT를 모두 사용하여 인증합니다.
• NGINX Plus Key-Value Store의 메모리 내 SSL/TLS 인증서 저장소. 이 기술은 API Key 또는 JWT와 같은 인증 정보를 사전 프로비저닝하는 데 사용할 수 있습니다.
• gRPC.

고성능 Ethos은 NGINX의 API 관리 솔루션의 정의 기능이기도 합니다. 기존 API 관리 솔루션과 달리 Data Plane(API Gateway인 NGINX Plus)은 Control Plane에 대한 런타임 종속성이 없습니다. 긴밀하게 결합된 Control 및 Data Plane은 API 호출이 데이터베이스, 모듈 및 Scripting을 통과해야 하므로 상당한 지연 시간을 추가됩니다. Data와 Control Plane을 분리하면 API 호출을 처리하기 위한 평균 응답 시간이 줄어들어 복잡성이 줄어들고 성능이 극대화됩니다.

API Gateway와 Load Balancer는 엔터프라이즈급 보안을 제공하는 DevOps 친화적인 WAF인 NGINX App Protect로 보호할 수 있습니다. 올인원 Load Balancer, Reverse Proxy 및 API Gateway인 NGINX Plus는 복잡성과 무분별한 도구 확장을 줄이면서 고가용성과 고성능을 보장합니다.

NGINX Plus와 함께 실시간 API를 배포 테스트 및 사용해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.