App Engine에서 VPN 데이터베이스에 연결하려면 맞춰야 할 것

App Engine Standard가 Cloud VPN을 통해 프라이빗 데이터베이스에 도달할 수 없다는 주장은 플랫폼의 이전 세대에서 남은 것입니다. Standard 인스턴스는 일부 다른 런타임처럼 VPC 고유 주소를 받지는 않지만, 네트워크에 있는 Serverless VPC Access 커넥터를 통해 이그레스를 보낼 수 있습니다. 그 경로가 생기면 Cloud VPN과 원격 방화벽은 커넥터 트래픽을 다른 소스와 똑같이 봅니다. 실패하는 경우는 드물게 능력 자체가 아니라, 한 번도 맞춰지지 않은 세 가지 설정 중 하나입니다.

예전 답은 어디서 나왔나

커넥터가 존재하기 전에는 Standard가 공용 엔드포인트와만 통신할 수 있다는 것이 실제 답이었고, 팀들은 이를 우회하려고 프록시 VM이나 다른 런타임으로 옮겼습니다. 플랫폼은 바뀌었지만 통설은 그대로였습니다. 온라인 조언 상당수는 이그레스 옵션이 아예 없던 시대를 아직도 반영합니다.

수정은 들리는 것보다 좁습니다. Standard는 프라이빗 네트워크에 도달할 수 있지만, 지원되는 이그레스 통합을 통해서만, 그리고 그 통합이 실제로 포착하는 대상에만 가능합니다.

먼저 이그레스 경로를 고르세요

서비스에 연결된 커넥터가 그 트래픽을 VPC로 넣습니다. 커넥터 문서에는 리전 전제 조건과 이그레스 설정이 나옵니다. 커넥터는 서비스 리전에 있어야 하며 배포하는 ID가 사용할 수 있어야 합니다.

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only은 프라이빗 대상을 VPC로 보내고 나머지는 일반 인터넷 경로에 두는데, 보통 데이터베이스 연결에 필요한 것이 이것입니다. all-traffic는 아웃바운드 트래픽을 VPC를 통해 폭넓게 밀어내므로, 일반 인터넷 호출도 VPC의 NAT와 방화벽 태세를 물려받습니다.

파일을 로컬에서 편집해도 배포하기 전에는 아무것도 바뀌지 않습니다. 실행 중인 버전은 생성 당시의 구성을 유지합니다.

소스 주소는 커넥터이지, 노트북이 아닙니다

디버깅 시간의 대부분이 여기에 쓰입니다. 원격 VPN 게이트웨이와 데이터베이스 방화벽은 VPC 내부에서 커넥터에 할당된 범위를 허용해야 합니다. 사무실 주소도, 서비스의 공용 이그레스 주소도 아닙니다. 규칙을 하나라도 쓰기 전에 콘솔에서 그 범위를 확인하세요.

두 곳이 더 일치해야 합니다. VPC 라우트 테이블에는 원격 데이터베이스 네트워크로 가는 경로가 필요하고, 원격 측에는 커넥터 범위로 돌아오는 경로가 필요합니다. 터널이 트래픽 선택자를 사용한다면 커넥터 범위가 협상된 범위 안에 있는지 확인하세요. 원격에서 로컬 방향으로만 존재하는 경로는 흔한 누락이며, 핑은 통과시키지만 TCP 핸드셰이크는 끝내지 못합니다.

VM 서브넷만 허용하는 터널은 커넥터 패킷을 유용한 오류 메시지 없이 버리므로, 데이터베이스 타임아웃이 자격 증명 문제처럼 보입니다.

DNS는 다른 경로로 다닙니다

프라이빗 데이터베이스 호스트 이름은 커넥터가 도달하는 네트워크 안에서 Cloud DNS 피어링이나 VPC가 사용할 수 있는 전달 영역을 통해 확인되어야 합니다. 워크스테이션에서 확인해도 배포된 서비스에 대해 아무것도 증명하지 못합니다. 노트북이 그 리졸버를 쓰지 않기 때문입니다.

VPC 내부에서 이름이 공용 주소로 확인된다면, 잘못된 방화벽을 디버깅하려는 것입니다.

URL Fetch는 커넥터를 사용하지 않습니다

이그레스 설정은 런타임의 일반 아웃바운드 소켓을 다루며, 레거시 URL Fetch 서비스는 그 경로에 포함되지 않습니다. urlfetch로 보낸 요청은 구성과 무관하게 커넥터를 무시합니다. 실패하는 호출이 아직 URL Fetch를 쓰는 오래된 라이브러리 안에 있다면, 해결책은 그 호출을 표준 HTTP 클라이언트로 옮기는 것입니다.

데이터베이스 드라이버에서는 좀처럼 문제가 되지 않지만, 같은 서비스에서 한 엔드포인트는 되고 다른 하나는 안 되는 전형적인 이유입니다.

좁은 쿼리 하나로 검증하세요

배포한 뒤 원격 측을 지켜보면서 배포된 버전에서 허용된 데이터베이스 작업을 하나 실행하세요. 데이터베이스나 VPN 게이트웨이가 기록하는 소스 주소는 커넥터의 것이어야 합니다. 아니라면 요청이 VPC에 들어간 적이 없고, 어떤 터널 구성으로도 고칠 수 없습니다. 콘솔에서 찾은 범위와 비교하세요. 불일치는 보통 두 번째 커넥터가 그 버전을 처리하고 있다는 뜻입니다.

VPC 내부의 VM에서 성공한 쿼리는 경로가 존재함을 보여줍니다. 서비스가 그 경로를 선택했다는 것까지 보여주지는 않습니다.