VPC 직접 연결 이그레스를 사용하면 App Engine 서비스가 가상 프라이빗 클라우드 (VPC) 네트워크로 트래픽을 전송할 수 있는 고성능 네트워킹 솔루션이 제공됩니다. VPC 직접 연결 이그레스를 사용하면 워크로드가 VPC 네트워크 리소스에 원활하게 액세스할 수 있으며 서버리스 VPC 액세스 커넥터를 구성할 필요가 없습니다.
주요 이점
- 간소화된 관리: 커넥터 인스턴스, 머신 유형, 확장 설정을 관리하는 운영 오버헤드를 없앱니다. App Engine은 서비스의
app.yaml파일 내에서 직접 구성을 처리합니다. - 비용 효율성: VPC 직접 연결 이그레스를 사용하면 추가 요금이 발생하지 않으며 커넥터 VM에 대한 고정 월별 요금을 지불할 필요가 없습니다.
- 성능 및 안정성 향상: 커넥터를 사용할 필요가 없으므로 직접 VPC 이그레스는 VPC 네트워크 리소스에 더 빠르고 안정적인 연결을 제공합니다. App Engine 서비스만큼 빠르게 확장되며 유지보수 중에 커넥터에서 발생할 수 있는 연결 끊김을 방지합니다.
세분화된 보안: App Engine 서비스 버전에 직접 네트워크 태그를 적용하여 정확한 서비스별 방화벽 규칙과 네트워크 정책을 사용 설정할 수 있습니다.
VPC 흐름 로그 지원: 서브넷에서 VPC 흐름 로그를 사용 설정하여 App Engine 서비스의 이그레스 트래픽을 로깅할 수 있습니다.
제한사항
IP 주소 사용: 서비스의 IP 주소 사용량은 실행 중인 인스턴스 수에 따라 직접 확장되며 확장 기능은 선택한 서브넷에서 사용 가능한 IP 주소 수에 따라 제한됩니다.
유지보수 이벤트: 네트워킹 인프라 유지보수 이벤트 중에 서비스에서 짧은 연결 중단이 발생할 수 있습니다. 비정기적인 연결 재설정을 처리할 수 있는 클라이언트 라이브러리를 사용하는 것이 좋습니다.
콜드 스타트: 초기 콜드 스타트 시간은 리전 및 특정 사용 사례에 따라 다릅니다. 드물지만 콜드 스타트가 최대 1분까지 지속될 수 있습니다.
VPC 직접 연결 인그레스: App Engine은 VPC 직접 연결 인그레스를 지원하지 않습니다.
인스턴스 수: App Engine 버전당 최대 100개의 인스턴스만 VPC 직접 연결 이그레스를 사용하도록 구성할 수 있습니다.
VPC 흐름 로그: 로그 레코드에 App Engine 서비스 버전을 표시하지 않습니다. 서비스 이름은
AppEngineServiceDetails필드에 표시됩니다.
IP 주소 할당
App Engine 서비스를 VPC 네트워크에 배치하려면 VPC 네트워크 또는 서브넷을 지정하거나 둘 다 지정합니다. 네트워크만 지정하면 서브넷은 네트워크와 동일한 이름을 사용합니다. App Engine은 서브넷에서 IP 주소를 할당합니다.
IP 주소는 임시 주소이므로 개별 IP에 따라 정책을 만들지 마세요. 방화벽 규칙과 같이 IP를 기반으로 정책을 만들어야 하는 경우 전체 서브넷의 IP 주소 범위를 사용해야 합니다.
서비스에서 사용하는 네트워크 또는 서브넷을 변경하려면 새 네트워크 및 서브넷 값을 사용하는 새 버전을 배포합니다.
수직 확장 및 축소
트래픽이 급증할 때 더 빠르게 수직 확장할 수 있도록 App Engine에서는 한 번에 16개 (28 서브넷 마스크)의 블록으로 IP 주소를 예약합니다.
App Engine에서 사용할 수 있는 IPv4 주소가 충분한지 확인하려면 서브넷의 IPv4 주소 범위가 /26 이상이어야 합니다.
IP 할당 효율성과 관리 편의성을 위해 동일한 서브넷에 여러 리소스를 배치합니다. IPv4 주소 공간이 제한된 경우 지원되는 IPv4 범위를 참조하여 더 많은 옵션을 확인하세요.
서브넷을 삭제하려면 먼저 App Engine 서비스를 삭제하거나 재배포하여 서브넷 사용을 중지한 후 1~2시간 정도 기다려야 합니다.
서비스의 IP 주소 소비
안정적인 상태에서 App Engine은 인스턴스 수의 2배 (2X)만큼의 IP 주소를 사용합니다. 버전이 축소되면 App Engine은 최대 20분 동안 IP 주소를 보관합니다. 합해서 2배 이상의 IP 주소와 버전 업데이트를 고려한 버퍼를 예약하세요.
예를 들어 version 1이 인스턴스 100개에서 0으로 축소되고 version 2가 0에서 최대 100개로 확장되도록 버전을 업그레이드하면 App Engine은 축소 후 최대 20분 동안 version 1 IP 주소를 유지합니다. 20분의 보관 기간 동안 IP 주소((100 + 100) * 2)를 최소 400개 이상 예약해야 합니다.
지원되는 IPv4 범위
App Engine은 서브넷에 대해 다음 IPv4 범위를 지원합니다.
시작하기 전에
프로젝트에 기존 VPC 네트워크와 서브넷이 있는지 확인합니다. 기존 VPC가 아직 없으면 VPC 네트워크 만들기의 안내에 따라 VPC를 만듭니다.
Compute Engine API 및 Cloud Build API를 사용 설정합니다.
VPC 직접 연결 이그레스를 사용하려면 최신 버전의 Google Cloud CLI를 실행 중인지 확인합니다.
gcloud components update
필요한 역할
배포 서비스 계정에 다음 역할을 부여하여 App Engine이 VPC 네트워크에 액세스할 수 있는지 확인합니다.
App Engine 서비스 에이전트 역할: 기본적으로 App Engine 서비스 에이전트에는 필요한 권한이 포함되어 있는 App Engine 서비스 에이전트 역할 (
roles/appengine.serviceAgent)이 있습니다.커스텀 권한: 보다 세부적으로 제어할 수 있도록 프로젝트에 대한 다음 추가 권한을 App Engine 서비스 에이전트에 부여합니다.
compute.networks.getcompute.subnetworks.get- 프로젝트 또는 특정 서브넷에 대한
compute.subnetworks.use권한 compute.addresses.getcompute.addresses.listcompute.addresses.createcompute.addresses.deletecompute.addresses.createInternalcompute.addresses.deleteInternalcompute.regionOperations.get
Compute 네트워크 사용자 역할: 기본 App Engine 서비스 에이전트 역할이나 커스텀 권한을 사용하지 않는 경우 App Engine 서비스 에이전트 서비스 계정에 대한 Compute 네트워크 사용자 역할 (
roles/compute.networkUser)을 부여합니다. 외부 IPv6가 있는 서브넷에는 Compute 공개 IP 관리자 역할 (roles/compute.publicIpAdmin)도 필요합니다.예를 들어 Compute 네트워크 사용자 역할을 부여하려면 다음 명령어를 실행합니다.
gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:service-PROJECT_NUMBER@gcp-gae-service." \ --role "roles/compute.networkUser"
다음을 바꿉니다.
- PROJECT_ID: 프로젝트의 ID입니다.
- PROJECT_NUMBER: App Engine 서비스를 배포하는 프로젝트 번호입니다.
VPC 직접 연결 이그레스로 App Engine 서비스 구성
새 App Engine 서비스 또는 기존 App Engine 서비스가 VPC 네트워크에 직접 연결할 수 있도록 하려면 다음 단계를 따르세요.
app.yaml파일에 다음vpc_access설정을 추가합니다.vpc_access: network_interface: network: NETWORK subnet: SUBNET tags: - NETWORK_TAGS vpc_egress: EGRESS_SETTING
다음을 바꿉니다.
NETWORK: 애플리케이션 인스턴스가 연결되는 기존 네트워크의 이름입니다(예:
default). VPC 네트워크 또는 서브넷을 지정하거나 둘 다 지정합니다. 네트워크만 지정하면 서브넷은 네트워크와 동일한 이름을 사용합니다.SUBNET: 애플리케이션 인스턴스가 연결되는 기존 서브네트워크의 이름입니다(예:
default). VPC 네트워크 또는 서브넷을 지정하거나 둘 다 지정합니다. 네트워크만 지정하면 서브넷은 네트워크와 동일한 이름을 사용합니다.선택사항: NETWORK_TAGS: 방화벽 규칙 및 라우팅 정책에 사용할 App Engine 서비스의 인스턴스와 연결할 네트워크 태그 목록입니다.
선택사항: EGRESS_SETTING: 아웃바운드 트래픽이 라우팅되는 방식을 제어합니다. 이 필드는 다음 구성 설정을 지원합니다.
all-traffic: 모든 아웃바운드 요청이 VPC 네트워크를 통해 라우팅됩니다.private-ranges-only(기본값): 내부 IP 주소로의 트래픽만 VPC 네트워크를 통해 라우팅됩니다. 인터넷 트래픽은 기본 App Engine 경로를 사용합니다.
다음 명령어를 실행하여 App Engine에 배포합니다.
gcloud beta app deploy
서비스 연결 해제
VPC 네트워크에서 서비스 연결을 해제하려면 다음 안내를 따르세요.
app.yaml파일에서vpc_access섹션을 삭제합니다.서비스를 다시 배포합니다.
gcloud beta app deploy
IP 관리 권장사항
서비스의 각 인스턴스가 서브넷의 IP 주소를 사용하므로 IP 주소를 관리해야 합니다. IP 주소를 관리하려면 다음 전략을 사용하세요.
권장 IP 범위: 호환성을 극대화하려면 RFC 6598 (
100.64.0.0/10) 범위로 시작하는 것이 좋습니다.대체 IP 범위: 권장 IP 범위인
100.64.0.0/10를 이미 사용 중인 경우 서브넷에서 클래스 E(240.0.0.0/4)와 같은 RFC 1918 이외의 범위를 사용할 수 있습니다.서브넷 크기 조정: 서브넷의 IPv4 주소 범위가
/26이상인지 확인하여 확장에 충분한 주소를 제공합니다.IP 초과 프로비저닝: 소진을 방지하기 위해 서브넷에서 사용 가능한 IP 수를 초과 프로비저닝하는 것이 좋습니다. Cloud Run 서비스와 마찬가지로 원활한 확장 및 업데이트를 위해 일반적으로 실행 중인 인스턴스 수의 4배(안정적인 상태의 경우 2배, 배포 중 추가 2배)만큼의 IP를 사용해야 합니다.
아웃바운드 인터넷 트래픽 격리
기본적으로 vpc_egress가 private-ranges-only로 설정된 경우 App Engine은 서버리스 워크로드 간에 공유되는 동적 IP 주소의 리전 풀을 통해 아웃바운드 인터넷 트래픽을 전송합니다. IP 평판에 의존하거나 대량의 프로브 트래픽을 생성하는 워크로드에는 이 기본 공유 풀을 사용하지 마세요.
대신 다음과 같은 경우 vpc_egress: all-traffic를 설정하고 전용 고정 아웃바운드 IP 주소를 사용하여 Cloud NAT를 통해 아웃바운드 트래픽을 라우팅합니다.
- 서비스가 서드 파티 웹 애플리케이션 방화벽 (WAF) 뒤에 있는 Payment Gateway, 호스팅된 데이터베이스, 파트너 API와 같이 평판에 민감한 외부 엔드포인트에 연결됩니다. 전용 고정 IP 주소는 공유 풀의 다른 테넌트에서 발생하는 노이즈 트래픽이 외부 WAF 차단 또는
HTTP 403오류를 트리거하지 않도록 방지합니다. - 서비스에서 승인된 네트워크 스캔, 포트 열거, 호스트 디지털 지문, 취약점 조사, 웹 스크래핑 또는 부하 테스트를 실행합니다. 기본 공유 IP 풀에서 이러한 워크로드를 실행하면 IP 평판이 저하되고, Google Cloud 서비스이용 정책을 위반하여 다른 고객의 서비스를 중단할 수 있으며, Google에서 워크로드를 제한하거나 정지할 수 있습니다.
Cloud NAT를 통해 승인된 스캔 또는 연결이 많은 워크로드를 실행하는 경우 포트 소진을 방지하기 위해 충분한 고정 IP 주소를 할당하고 포트 예약을 구성합니다.
문제 해결
이 섹션에서는 VPC 직접 연결 이그레스를 사용하여 App Engine 서비스를 배포할 때 발생할 수 있는 일반적인 오류를 설명합니다.
서브넷을 삭제할 수 없음
서브넷을 삭제하려면 먼저 서브넷을 사용하는 모든 리소스를 삭제하거나 다시 배포해야 합니다. App Engine이 서브넷을 사용하는 경우 서브넷을 삭제하기 전에 VPC 네트워크에서 App Engine 서비스의 연결을 해제하거나 다른 서브넷으로 이동합니다.
App Engine 서비스를 삭제하거나 이동한 후 서브넷을 삭제하기 전에 App Engine에서 IP 주소를 해제할 때까지 1~2시간 기다립니다.
배포 실패
배포가 실패하면 Google Cloud CLI에 근본 원인을 나타내는 오류 메시지가 표시됩니다. 일반적인 문제에는 다음이 포함됩니다.
app.yaml파일의 네트워크 또는 서브넷 이름의 맞춤법이 잘못된 경우와 같이 VPC 메타데이터가 잘못되었습니다. 잠재적인 오류를 수정하려면app.yaml파일에서 VPC 구성을 검토하세요.IAM 권한이 부족합니다. 배포 서비스 계정에 필요한 권한을 부여해야 합니다. 배포 중에 권한 오류가 발생하면 서비스 계정에 다음 추가 역할을 부여해야 합니다.
- Cloud Build 서비스 계정(
roles/cloudbuild.builds.builder) - 서비스 계정 토큰 생성자 (
roles/iam.serviceAccountTokenCreator)
- Cloud Build 서비스 계정(
IP 주소 소진
서브넷에 사용 가능한 IP 주소가 부족하면 App Engine이 새 인스턴스를 시작하지 못하고 오류를 로깅합니다. 이 문제를 해결하려면 서브넷의 IP 범위를 확장하거나 서비스를 더 큰 서브넷으로 이동합니다.
IP 주소 유출
IP 주소 유출로 인해 IP 주소가 소진될 수 있습니다. 표준 작업 중에는 IP 주소 유출이 발생할 가능성이 낮지만 다음과 같은 원인으로 인해 발생할 수 있습니다.
- 배포 서비스 계정에 주소 예약 권한 (
create,createInternal)만 있고 주소 해제 권한 (delete,deleteInternal)이 없습니다. - 다른 Google Cloud 주소 예약이 활성 상태인 동안 서비스 계정이 삭제되었습니다.
- 서버리스 주소 예약이 활성 상태인 동안 Cloud Billing 계정이 삭제되었다가 나중에 프로젝트에서 다시 사용 설정되었습니다.
- 서버리스 주소 예약이 아직 존재하는 동안 Google Cloud 프로젝트가 삭제되었다가 나중에 복원되었습니다.
이 문제를 해결하려면 다음 단계를 따르세요.
로그 탐색기에서 다음 로그를 쿼리하여 유출된 주소를 식별합니다.
protoPayload.authorizationInfo.permission=~"compute.addresses.delete.*" protoPayload.authorizationInfo.resourceAttributes.type="compute.addresses" protoPayload.resourceName=~"projects/.*/regions/.*/addresses/serverless-.*" severity>=WARNING이 쿼리가 결과를 반환하지 않으면 IP 주소 유출이 없으며 추가 작업이 필요하지 않습니다.
쿼리에서 결과가 반환되면 배포 서비스 계정에 App Engine 서비스 에이전트 역할 (
roles/appengine.serviceAgent)이 포함되어 있는지 확인합니다. 이 역할을 사용할 수 없는 경우 배포 서비스 계정에 다른 필수 역할 및 권한을 부여해야 합니다.Google Cloud 콘솔 또는 Google Cloud CLI를 사용하여 유출된 IP 주소를 수동으로 삭제합니다.
콘솔
Google Cloud 콘솔에서 IP 주소 페이지로 이동합니다.
쿼리를 실행하여 이전 단계에서 확인한 유출된 IP 주소를 선택합니다.
고정 주소 해제를 클릭하여 유출된 주소를 삭제합니다.
gcloud
gcloud compute addresses delete명령어를 실행합니다.gcloud compute addresses delete ADDRESS_NAME --region=REGION
다음을 바꿉니다.
- ADDRESS_NAME: 유출된 IP 주소의 이름입니다.
- REGION: 유출된 IP 주소의 리전입니다.