서버리스 네트워크 엔드포인트 그룹 개요

네트워크 엔드포인트 그룹(NEG)은 부하 분산기의 백엔드 엔드포인트 그룹을 지정합니다. 서버리스 NEGCloud Run, App Engine 또는 Cloud Functions 서비스를 가리키는 백엔드입니다.

서버리스 NEG는 다음을 나타낼 수 있습니다.

  • Cloud Run 서비스나 동일한 URL 패턴을 공유하는 서비스 그룹
  • Cloud Functions 함수나 동일한 URL 패턴을 공유하는 함수 그룹
  • App Engine 앱(표준 또는 가변), 앱 내의 특정 서비스 또는 특정 버전의 앱

서버리스 앱에 HTTP(S) 부하 분산이 사용 설정된 경우 다음을 수행할 수 있습니다.

  • 다른 서비스와 공유되지 않는 전용 IPv4 또는 IPv6 IP 주소에서 제공되도록 서버리스 앱을 구성할 수 있습니다.
  • 다양한 리전에서 실행되는 여러 서비스에 단일 URL을 매핑하여 사용자에게 가장 가까운 리전으로 요청을 라우팅할 수 있습니다. 이는 Cloud Run(완전 관리형)에서만 지원됩니다.
  • Compute Engine, Google Kubernetes Engine, Cloud Storage에 사용하는 것과 동일한 SSL 인증서와 비공개 키를 재사용할 수 있습니다. 이렇게 하면 서버리스 앱용 별도 인증서를 관리할 필요가 없습니다.

또한 HTTP(S) 부하 분산을 설정하면 서버리스 앱을 기존 Cloud 서비스와 통합할 수 있습니다. 다음과 같은 작업을 수행할 수 있습니다.

  • 다른 Google Cloud 기술과 URL 공간을 공유할 수 있습니다. 여러 백엔드 서비스를 사용하면 단일 외부 HTTP(S) 부하 분산기가 요청 URL의 호스트 또는 경로를 기반으로 Cloud Run(완전 관리형), App Engine, Cloud Functions, Compute Engine, Google Kubernetes Engine, Cloud Storage로 트래픽을 전송할 수 있습니다.
  • 외부 HTTP(S) 부하 분산기를 통해 액세스하는 모든 서비스에 제공되는 에지 DDoS 방어/WAF 보안 제품인 Google Cloud Armor로 서비스를 보호할 수 있습니다. Cloud Run(완전 관리형) 및 App Engine의 경우 이 기능과 관련된 몇 가지 제한사항이 있습니다.
  • Cloud CDN을 사용하여 서비스에서 전송을 최적화하도록 사용 설정할 수 있습니다. Cloud CDN을 사용하면 사용자에게 친숙한 콘텐츠를 캐시할 수 있습니다. Cloud CDN은 캐시 무효화와 Cloud CDN으로 서명된 URL 등의 기능을 제공합니다.
  • Google의 에지 인프라를 사용하여 사용자와 더욱 가까운 HTTP(S) 연결을 종료하여 지연 시간을 줄일 수 있습니다.

이 문서의 나머지 부분에서는 HTTP(S) 부하 분산과 함께 서버리스 NEG를 사용하는 방법을 설명합니다. 서버리스 NEG는 다른 부하 분산기 유형에서 사용할 수 없습니다.

다른 NEG 유형에 대한 자세한 내용은 다음을 참조하세요.

엔드포인트 유형

서버리스 NEG에는 포트 또는 IP 주소와 같은 네트워크 엔드포인트가 없습니다. NEG와 동일한 리전에 있는 기존 Cloud Run(완전 관리형), App Engine 또는 Cloud Functions 서비스만 가리킬 수 있습니다.

서버리스 NEG를 만들 때 Cloud Run(완전 관리형), App Engine 또는 Cloud Functions 서비스의 정규화된 도메인 이름(FQDN)을 지정합니다. 엔드포인트는 SERVERLESS 유형입니다. 다른 엔드포인트 유형은 서버리스 NEG에서 지원되지 않습니다.

서버리스 NEG는 두 개 이상의 엔드포인트를 가질 수 없습니다. 각 서버리스 NEG에는 하나의 엔드포인트만 허용되므로 부하 분산기는 프런트엔드 역할만 하며 지정된 서버리스 엔드포인트로 트래픽을 프록시 처리합니다. 하지만 백엔드 서비스에 여러 서버리스 NEG가 포함된 경우 부하 분산기는 이러한 NEG 간 트래픽을 분산하므로 요청 지연 시간이 최소화됩니다.

네트워크 등급

스탠더드 또는 프리미엄 네트워크 서비스 등급을 이용하여 부하 분산기에서 서버리스 NEG를 사용할 수 있습니다. 프리미엄 등급은 여러 리전에 서버리스 NEG를 설정하려는 경우에만 필요합니다.

부하 분산 구성요소

다음은 서버리스 NEG가 HTTP(S) 부하 분산 모델에 어떻게 부합하는지 보여줍니다.

단순 HTTPS 부하 분산(확대하려면 클릭)
서버리스 앱의 HTTP(S) 부하 분산

전달 규칙

전달 규칙은 프런트엔드 구성의 일부이며 외부 IP 주소, IP 버전(IPv4 또는 IPv6), 프로토콜(HTTP 또는 HTTPS(HTTP/2 포함)), 포트 번호(80 또는 443)를 포함합니다.

대상 프록시

서버리스 NEG는 HTTP 및 HTTPS 대상 프록시와만 함께 사용할 수 있습니다. 서버리스 NEG를 사용하는 서비스는 TCP 또는 SSL 대상 프록시와 함께 사용할 수 없습니다.

URL 맵

외부 HTTP(S) 부하 분산기의 전달 선택은 URL 맵을 기반으로 합니다. URL 맵을 통해 대상 HTTP(S) 프록시는 URL 맵에서 요청 호스트 이름과 경로를 확인하여 사용할 백엔드 서비스를 결정합니다. 부하 분산기는 URL 맵에서 여러 백엔드 서비스를 참조할 수 있습니다. 각 백엔드 서비스는 다른 백엔드 유형과 연결될 수 있습니다. 예를 들어 서버리스 NEG의 백엔드 서비스와 Compute Engine 인스턴스 그룹의 다른 백엔드 서비스를 사용할 수 있습니다.

백엔드 서비스

서버리스 NEG는 부하 분산기에서 백엔드 서비스의 백엔드로 사용할 수 있습니다. 백엔드 서비스는 여러 서버리스 NEG의 지원을 받을 수 있지만, 각 서버리스 NEG는 단일 Cloud Run(완전 관리형)(또는 App Engine이나 Cloud Functions) 서비스의 FQDN 또는 동일한 도메인에서 제공되는 여러 서비스를 가리키는 URL 마스크만을 가리킬 수 있습니다.

URL 마스크는 사용자 요청을 올바른 서비스에 매핑하는 방법을 서버리스 NEG 백엔드에 알려주는 URL 스키마 템플릿입니다. URL 마스크는 애플리케이션에 커스텀 도메인을 사용하고 있고 동일한 도메인에서 제공되는 여러 Cloud Run(완전 관리형), Cloud Functions 또는 App Engine 서비스가 있는 경우에 유용합니다. 이러한 경우 각 Cloud Run(완전 관리형), App Engine 또는 Cloud Functions 서비스에 대해 별도의 서버리스 NEG를 만드는 대신 커스텀 도메인의 일반 URL 마스크(예: example.com/<service>)를 사용하여 NEG를 만들고 해당 NEG가 요청의 URL에서 서비스 이름을 추출하도록 허용할 수 있습니다. 자세한 내용과 예시는 URL 마스크를 참조하세요.

서버리스 NEG를 백엔드로 추가할 때 유의해야 할 추가 제한사항이 있습니다. 자세한 내용은 제한사항을 참조하세요.

URL 마스크

URL 마스크는 애플리케이션이 여러 Cloud Run(완전 관리형), Cloud Functions 또는 App Engine 서비스로 구성된 경우 서버리스 NEG를 더 쉽게 구성할 수 있는 선택적 기능입니다. 서버리스 NEG 백엔드는 단일 Cloud Run(완전 관리형)(또는 App Engine이나 Cloud Functions) 서비스 또는 여러 서비스를 가리키는 URL 마스크를 가리킬 수 있습니다.

URL 마스크는 URL 스키마의 템플릿입니다. 서버리스 NEG는 이 템플릿(예: example.com/<service>)을 사용하여 수신 요청의 URL에서 서비스 이름을 추출하고 요청을 적절한 서비스에 매핑합니다.

URL 마스크는 서버리스 앱이 Google Cloud에서 제공하는 기본 주소가 아닌 커스텀 도메인에 매핑된 경우에 유용합니다. example.com과 같은 커스텀 도메인을 사용하면 동일한 도메인의 여러 하위 도메인 또는 경로에 여러 Cloud Run(완전 관리형), Cloud Functions 또는 App Engine 서비스를 배포할 수 있습니다. 이러한 경우 각 Cloud Run(완전 관리형), App Engine 또는 Cloud Functions 서비스에 대해 별도의 서버리스 NEG 백엔드를 만드는 대신 커스텀 도메인의 일반 URL 마스크(예: example.com/<service>)를 사용하여 단일 서버리스 NEG를 만들고 해당 NEG가 요청의 URL에서 서비스 이름을 추출하도록 허용할 수 있습니다.

다음 이미지는 URL 마스크를 사용하여 사용자 요청을 다른 서비스에 매핑하는 단일 백엔드 서비스와 서버리스 NEG가 있는 외부 HTTP(S) 부하 분산기를 보여줍니다.

서버리스 앱에 트래픽 분산(확대하려면 클릭)
URL 마스크를 사용하여 트래픽을 다른 서비스로 분산

URL 마스크는 애플리케이션의 서비스가 예측 가능한 URL 스키마를 사용할 때 가장 잘 작동합니다. URL 맵 대신 URL 마스크를 사용하면 loginsearch 서비스에 별도의 서버리스 NEG를 만들 필요가 없다는 장점이 있습니다. 또한 애플리케이션에 새 서비스를 추가할 때마다 부하 분산기 구성을 수정할 필요가 없습니다.

서버리스 NEG에 대한 URL 마스크를 만들고 구성하는 방법은 서버리스 NEG 설정을 참조하세요.

제한사항

  • Google Cloud Console을 사용하여 서버리스 NEG를 만들 수 없습니다. gcloud 명령줄 도구 또는 API를 사용하세요. 도구에 대한 개념 및 설치 정보는 gcloud 개요를 참조하세요.
  • 서버리스 NEG는 IP 주소 또는 포트와 같은 네트워크 엔드포인트를 가질 수 없습니다.
  • 서버리스 NEG는 해당 NEG가 생성된 리전과 동일한 리전에 있는 Cloud Run(완전 관리형), App Engine 또는 Cloud Functions 서비스만을 가리킬 수 있습니다.
  • 서버리스 NEG 백엔드를 사용하는 부하 분산기는 NEG가 가리키는 Cloud Run(완전 관리형), App Engine 또는 Cloud Functions 서비스와 동일한 프로젝트에서 만들어야 합니다.
  • Cloud Monitoring은 서버리스 NEG 백엔드에서 지원되지 않습니다. 다른 유형의 백엔드가 있는 백엔드 서비스는 영향을 받지 않습니다.
  • 서버리스 NEG로 구성된 외부 HTTP(S) 부하 분산기는 기본 서버리스 리소스(예: App Engine, Cloud Functions 또는 Cloud Run(완전 관리형) 서비스)가 예상대로 작동하는지 감지할 수 없습니다. 즉, 한 리전의 서비스가 오류를 반환하더라도 해당 리전의 전체 Cloud Run(완전 관리형), Cloud Functions 또는 App Engine 인프라가 정상적으로 작동하면 외부 HTTP(S) 부하 분산기가 자동으로 트래픽을 다른 리전으로 전달하지 않습니다. 외부 HTTP(S) 부하 분산기로 사용자 트래픽을 라우팅하기 전에 새로운 버전의 서비스를 철저히 테스트해야 합니다.

서버리스 NEG 백엔드가 있는 백엔드 서비스와 관련된 제한사항은 다음과 같습니다.

  • 백엔드 서비스에는 리전당 서버리스 NEG 하나만 포함될 수 있습니다. 단일 백엔드 서비스에서 여러 서버리스 NEG를 결합하려면 모든 NEG가 서로 다른 리전에서 기능적으로 동일한 배포를 나타내야 합니다. 예를 들어 NEG는 서로 다른 리전에 배포된 동일한 Cloud Run(완전 관리형), App Engine 또는 Cloud Functions 서비스를 가리킬 수 있습니다.
  • 백엔드 서비스에 결합된 모든 서버리스 NEG도 동일한 유형의 백엔드를 사용해야 합니다. 즉, Cloud Run(완전 관리형) 서버리스 NEG는 다른 Cloud Run(완전 관리형) 서버리스 NEG와만 결합될 수 있으며 App Engine 서버리스 NEG는 App Engine 서버리스 NEG와만 결합될 수 있습니다.
  • 동일한 백엔드 서비스에서 서버리스 NEG를 다른 유형의 NEG(영역별 또는 인터넷 NEG)와 혼합할 수 없습니다. 예를 들어 동일한 백엔드 서비스에서 GKE 클러스터와 Cloud Run(완전 관리형) 서비스로 라우팅할 수 없습니다.
  • 서버리스 NEG로 라우팅되는 백엔드 서비스를 설정할 때 특정 필드가 제한됩니다.
    • 분산 모드를 지정할 수 없습니다. 즉, RATE, UTILIZATION, CONNECTION 필드는 유효하지 않습니다.
    • 서버리스 백엔드에는 상태 확인이 지원되지 않습니다. 따라서 서버리스 NEG 백엔드가 포함된 백엔드 서비스는 상태 확인으로 구성할 수 없습니다.

사용 중인 서버리스 컴퓨팅 플랫폼에 따라 추가적인 제한사항이 적용될 수 있습니다.

Cloud Run(완전 관리형)의 제한사항

  • Cloud Run(완전 관리형)에는 SSL/TLS 인증서와 도메인이 필요합니다. 따라서 부하 분산기는 HTTP 대상 프록시 대신 HTTPS 대상 프록시를 사용해야 합니다.
  • IAP(Identity-Aware Proxy)는 Cloud Run(완전 관리형)에서 작동하지 않습니다.
  • Google Cloud가 Cloud Run(완전 관리형 서비스)에 자동으로 할당하는 URL은 사용 중지할 수 없습니다. 이미 Cloud Run(완전 관리형) 서비스의 기본 URL을 가지고 있는 사용자는 부하 분산기를 무시하고 서비스 URL으로 직접 이동할 수 있습니다. 즉, 부하 분산기를 통해 Google Cloud Armor 보안 정책을 구성할 수 있더라도 기본 URL이 있는 사용자는 이러한 정책을 우회할 수 있습니다.
  • Cloud Run(완전 관리형)에서 gRPC 서버 측 스트리밍 API를 사용할 때 소요 시간이 30초를 초과하는 요청에는 RST_STREAM 메시지가 표시됩니다. resource.timeoutSec 속성을 설정하여 제한 시간을 늘리기 위해 백엔드 서비스 구성을 수정하려고 하면 Timeout sec is not supported for a backend service with Serverless network endpoint groups 오류가 발생합니다.

Cloud Functions의 제한사항

  • IAP는 Cloud Functions에서 작동하지 않습니다.
  • Google Cloud가 Cloud Functions 함수에 자동으로 할당하는 URL은 사용 중지할 수 없습니다. 하지만 internal-and-gclb 인그레스 설정을 사용하여 내부 트래픽과 외부 HTTP(S) 부하 분산기에서 노출된 공개 IP로 전송된 트래픽만 허용할 수 있습니다. cloudfunctions.net 또는 Cloud Functions를 통해 설정된 다른 커스텀 도메인으로 전송되는 트래픽은 차단됩니다. 이렇게 하면 사용자가 외부 HTTP(S) 부하 분산기를 통해 설정된 액세스 제어(예: Google Cloud Armor 보안 정책)를 우회할 수 없습니다.

App Engine의 제한사항

  • App Engine에서는 멀티 리전 부하 분산이 지원되지 않습니다. 이는 App Engine에 프로젝트당 1개의 리전이 필요하기 때문입니다.
  • 요청 경로에는 하나의 IAP 정책만 허용됩니다. 예를 들어 백엔드 서비스에서 IAP 정책을 이미 설정한 경우 App Engine 앱에서 다른 IAP 정책을 설정하면 안 됩니다.

  • Google Cloud가 App Engine 서비스에 자동으로 할당하는 URL은 사용 중지할 수 없습니다. 이미 App Engine 서비스의 기본 URL을 가지고 있는 사용자는 부하 분산기를 무시하고 서비스 URL으로 직접 이동할 수 있습니다. 즉, 부하 분산기를 통해 Google Cloud Armor 보안 정책, SSL 인증서, 비공개 키를 구성할 수 있더라도 기본 URL이 있는 사용자는 이러한 정책을 우회할 수 있습니다.

가격 책정

서버리스 NEG가 있는 외부 HTTP(S) 부하 분산기의 가격 책정 정보를 보려면 네트워크 가격 책정을 참조하세요.

다음 단계