Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

직접 VPC 이그레스

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개의 인스턴스만 Direct 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 범위를 지원합니다.

RFC 1918
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
RFC 6598
- 100.64.0.0/10
클래스 E
- 240.0.0.0/4

시작하기 전에

프로젝트에 기존 VPC 네트워크와 서브넷이 있는지 확인합니다. 기존 VPC가 아직 없으면 VPC 네트워크 만들기의 안내에 따라 VPC를 만듭니다.
Compute Engine API 및 Cloud Build API를 사용 설정합니다.

API 사용 설정
VPC 직접 연결 이그레스를 사용하려면 최신 버전의 Google Cloud CLI를 실행해야 합니다.
```
gcloud components update
```

필요한 역할

배포 서비스 계정에 다음 역할을 부여하여 App Engine이 VPC 네트워크에 액세스할 수 있는지 확인합니다.

App Engine 서비스 에이전트 역할: 기본적으로 App Engine 서비스 에이전트에는 필요한 권한이 포함되어 있는 App Engine 서비스 에이전트 역할 (roles/appengine.serviceAgent)이 있습니다.
커스텀 권한: 보다 세부적으로 제어할 수 있도록 프로젝트에 대한 다음 추가 권한을 App Engine 서비스 에이전트에 부여합니다.
- compute.networks.get
- compute.subnetworks.get
- 프로젝트 또는 특정 서브넷에 대한 compute.subnetworks.use 권한
- compute.addresses.get
- compute.addresses.list
- compute.addresses.create
- compute.addresses.delete
- compute.addresses.createInternal
- compute.addresses.deleteInternal
- compute.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.iam.gserviceaccount.com" \
--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 직접 연결 이그레스를 사용하여 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)

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 주소를 수동으로 삭제합니다.
콘솔
1. Google Cloud 콘솔에서 IP 주소 페이지로 이동합니다.
  
  IP 주소로 이동
2. 쿼리를 실행하여 이전 단계에서 식별한 유출된 IP 주소를 선택합니다.
3. 고정 주소 해제를 클릭하여 유출된 주소를 삭제합니다.
gcloud
gcloud compute addresses delete 명령어를 실행합니다.
gcloud compute addresses delete ADDRESS_NAME --region=REGION
다음을 바꿉니다.
- ADDRESS_NAME: 유출된 IP 주소의 이름입니다.
- REGION: 유출된 IP 주소의 리전입니다.