Cloud Endpoints의 아키텍처 개요

OpenAPI | gRPC

Endpoints는 서비스, 런타임, 도구로 구성된 분산형 API 관리 시스템입니다. Endpoints는 관리, 모니터링, 인증 기능을 제공합니다.

Endpoints에 포함된 구성요소는 다음과 같습니다.

Extensible Service Proxy(ESP) 또는 Extensible Service Proxy V2(ESPv2) - Endpoints 기능을 삽입합니다.
Service Control - API 관리 규칙을 적용합니다.
Service Management - API 관리 규칙을 구성합니다.
Google Cloud CLI - 배포 및 관리를 수행합니다.
Google Cloud Console - 로깅, 모니터링, 공유를 수행합니다.

Endpoints 아키텍처

Endpoints 구성요소

ESP

ESP는 백엔드 앞에서 실행되고 인증, 모니터링, 로깅과 같은 Endpoints 기능을 삽입하는 NGINX 기반 프록시입니다. ESP는 Service Management에서 서비스 구성을 검색하여 수신 요청의 유효성을 검사하는데 사용합니다.

ESP는 개발자가 컨테이너화된 환경에서 이를 배포하고 JWT 및 Google ID 토큰을 검증할 수 있도록 설계되었습니다. 경량성과 고성능을 유지하기 위해 많은 캐싱 및 비동기 호출과 같은 다양한 기술이 적용되어 있습니다.

ESP 지원은 다음 플랫폼에서 사용할 수 있습니다.

ESPv2

ESPv2는 OpenAPI 또는 gRPC API 백엔드 앞에서 실행되는 확장 가능한 Envoy 기반 고성능 프록시입니다. ESPv2의 엔드포인트는 OpenAPI 사양 및 gRPC 사양의 버전 2를 지원합니다.

ESPv2는 Google Service Infrastructure와 통합되어 인증, 원격 분석 보고서, 측정항목, 보안 등의 API 관리 기능을 대규모로 사용할 수 있도록 지원합니다.

ESPv2 지원은 다음 플랫폼에서 사용할 수 있습니다.

Service Control

Service Control은 키 인증, 모니터링, 로깅과 같은 API 관리 규칙을 런타임에 적용합니다. Service Control은 다음과 같은 방법을 제공합니다.

확인 - 인증과 API 키를 확인하고 호출이 허용되는지 여부를 나타냅니다.
보고 - 로깅와 모니터링을 위한 레코드 시스템을 알립니다.

서비스 관리

OpenAPI 사양을 사용하여 API의 노출 영역과 동작을 Endpoints 구성이라고 하는 텍스트 파일에 기술합니다. gcloud CLI를 사용하여 Endpoints 구성을 Service Management에 배포합니다. 그러면 도구에서 API 관리 규칙을 구성합니다. 다른 개발자와의 API 공유, 여러 프로젝트에서 API 사용 설정 또는 사용 중지, API 키 생성과 같은 다른 구성 관련 작업도 여기에서 수행됩니다.

gcloud CLI

gcloud CLI는 다양한 Google Cloud 서비스를 호출하는 데 사용할 수 있는 Google Cloud CLI를 제공합니다. Google Cloud CLI를 사용하여 Endpoints 구성을 Service Management로 배포합니다.

Google Cloud Console

Google Cloud Console은 Google Cloud의 그래픽 사용자 인터페이스입니다. Endpoints는 Google Cloud Console을 사용하여 ESP 또는 ESPv2에서 전송되고 Service Control에서 기록되는 모니터링 및 로깅 데이터를 노출하고 API를 다른 개발자와 공유하며 다른 개발자가 API를 호출하도록 API 키를 생성하도록 지원합니다.

배포 시나리오

배포 옵션은 ESP 또는 ESPv2를 Endpoints 프록시로 사용하는 방법에 따라 달라집니다. ESPv2는 원격 프록시로 배포될 수 있으며 다음 섹션에 설명된 대로 ESPv2와 ESP를 사이드카 모드로 배포할 수 있습니다.

원격 프록시 모드

ESPv2를 사용하는 경우 엔드포인트를 원격 프록시로 배포할 수 있습니다. 이 모드는 표준 환경의 Cloud Run, Cloud Run 함수, App Engine과 같은 서버리스 플랫폼에서 실행되는 애플리케이션을 지원하는 데 사용됩니다.

이 모드에서 ESPv2는 Cloud Run 애플리케이션으로 배포됩니다. 이 애플리케이션은 OpenAPI 서비스 구성에서 x-google-backend 필드를 사용하여 ESPv2를 원격 백엔드로 사용하도록 구성됩니다. 이 배포 모드에서 원격 프록시로 작동할 때 단일 ESPv2는 여러 원격 백엔드를 지원할 수 있습니다.

자세한 내용은 Endpoints 구성을 참조하세요.

사이드카 모드

ESP와 ESPv2 모두 백엔드의 각 인스턴스와 함께 컨테이너에서 배포를 지원합니다. 이 서버-로컬 토폴로지는 웹 대면 API는 물론 마이크로 서비스에도 적합합니다. 이 토폴로지는 일반적으로 중앙 집중식 프록시와 관련된 네트워크 홉을 방지하고, 고성능은 물론 확장성이 뛰어난 API 관리를 가능하게 합니다.

일반적으로 부하 분산은 트래픽이 ESP 또는 ESPv2에 도달하기 전에 적용됩니다. App Engine에서 부하 분산은 자동으로 수행됩니다. Compute Engine에서는 Cloud Load Balancing을 통해 수행됩니다. Kubernetes 배포의 경우에는 부하 분산을 위해 인그레스 프록시를 사용할 수 있습니다. Google Kubernetes Engine에서는 부하 분산을 위해 Cloud Load Balancing 또는 수신 프록시를 사용할 수 있습니다.

시작 후 ESP 또는 ESPv2는 Service Management에서 서비스 구성을 가져옵니다. 서비스 구성은 OpenAPI 사양 또는 서비스 구성 YAML 파일인 gRPC에서 생성되며, 인증이 필요한 메서드, API 키가 필요한 메서드와 같이 정책과 함께 관리할 API 영역을 ESP 또는 ESPv2에 알려줍니다.

요청 라우팅

요청이 수신되면 ESP 또는 ESPv2가 Cloud Trace에 대한 trace 토큰을 만듭니다.

그런 다음 ESP 또는 ESPv2는 API의 영역과 일치하는 들어오는 요청 경로를 찾습니다. 일치하는 경로를 찾으면 ESP 또는 ESPv2가 지정된 메서드에 대한 인증 단계를 수행합니다.

JWT 검증이 필요한 경우, ESP 또는 ESPv2는 서명자에 대해 적절한 공개 키를 사용하여 인증을 검증하고 JWT에서 대상 필드를 검증합니다. API 키가 필요한 경우, ESP 또는 ESPv2는 Service Control API를 호출하여 키를 검증합니다.

Service Control은 검증할 키를 조회하고, 키와 연관된 프로젝트가 API를 사용 설정했는지 확인합니다. 키가 유효하지 않거나 프로젝트가 API를 사용 설정하지 않았으면 호출이 거부되고 Service Control API를 통해 로깅됩니다.

Service Control이 키를 성공적으로 검증하면 모든 원본 헤더가 포함된 요청과 JWT 검증 헤더(해당하는 경우)가 백엔드에 전달됩니다.

응답이 백엔드에서 수신되면 ESP 또는 ESPv2는 응답을 호출자에게 반환하고 최종 타이밍 정보를 Trace로 전송합니다. Service Control API가 호출 포인트를 로깅하여 측정항목과 로그를 적절한 대상에 기록합니다.

Kubernetes의 ESP 또는 ESPv2

다음 다이어그램은 ESP가 API 서비스 애플리케이션 컨테이너 앞에 있는 사이드카 컨테이너로 실행되는 전체 아키텍처를 보여줍니다. my-apiAPI는 my-api.com에 호스팅되고 Kubernetes 서비스를 통해 지원됩니다. ESPv2를 사용하는 사이드카 배포에서 아키텍처가 동일합니다.

Kubernetes의 Endpoints 개요