콘텐츠로 이동하기
AI 및 머신러닝

Vertex AI 파이프라인의 네트워크 도달성 확장

2022년 4월 21일
https://storage.googleapis.com/gweb-cloudblog-publish/images/vertexai.max-2600x2600.jpg
Bernie Ongewe

Technical Solutions Engineer

* 본 아티클의 원문은 2022년 3월 3일 Google Cloud 블로그(영문)에 게재되었습니다. 


Vertex AI 파이프라인 및 작업은 Service Networking API를 사용하여 네트워크를 구성합니다. 이에 따라 프로젝트 네트워크에 피어링되는 테넌트 프로젝트의 Google 소유 VPC 네트워크에서 실행됩니다. 이 피어링에는 다음과 같은 표준 VPC 피어링 네트워크 제약이 적용됩니다.

  • Google 소유 네트워크에는 자체 기본 경로가 있으며 네트워크의 기본 경로를 인터넷으로 가져오지 않습니다.
  • 피어링된 네트워크는 정적 및 동적 경로를 서로 내보내도록 구성할 수 있습니다. 하지만 전환 피어링은 허용되지 않습니다. 따라서 기본적으로 테넌트 프로젝트의 Vertex AI 작업은 네트워크에 피어링된 다른 네트워크에 도달할 수 없습니다.

이를 감안할 때 처음에는 예를 들어 Vertex AI 작업에 대한 액세스를 허용하는 방화벽 규칙을 공개 엔드포인트에 적용할 수 없는 것처럼 보입니다. 또한 이러한 작업은 네트워크와 피어링된 다른 서비스에 도달하기 위해 네트워크를 통해 즉시 라우팅될 수 없습니다.

이 문서에서는 Google에서 관리하는 VPC의 Vertex AI 파이프라인 작업이 다음 연결을 완료할 수 있도록 허용하는 구성을 제안합니다.

  • 사용자가 제어하는 공개 소스 IP를 사용하여 인터넷의 엔드포인트에 액세스
  • 네트워크를 통해 연결을 전달하여 피어링된 다른 엔드포인트에 액세스

데이터 과학자는 조직의 네트워크 관리자와 네트워크 요구사항에 대한 대화를 유도하기 위해 이 문서를 참조로 사용할 수 있습니다.

공개 발신 소스 IP 제어

일부 사용 사례에서는 파이프라인 작업이 인터넷을 통해 엔드포인트에 연결될 수 있어야 합니다. 이러한 연결을 허용하는 방화벽 규칙을 구성하려면 관리자는 파이프라인에서 사용하는 공개 소스 IP를 알아야 합니다.

파이프라인 작업은 사용자가 액세스할 수 없는 Google 소유 프로젝트에서 실행되기 때문에 사용자는 인터넷으로 직접 전송되는 아웃바운드 연결을 제어할 수 없습니다.

IAM 인증을 사용하여 이러한 엔드포인트를 보호하는 것이 좋지만 일부 사용자는 서비스 거부 공격으로부터 보호하고 조직의 보안 요구사항을 준수하는 방화벽 규칙을 배포해야 합니다.

다음 워크플로는 이러한 연결에 대한 아웃바운드 소스 IP를 제어하는 방법을 보여 줍니다.

NAT 인스턴스를 통한 액세스

이 구성을 통해 파이프라인은 사용자가 제어하는 NAT 인스턴스의 소스 IP를 사용하여 인터넷의 엔드포인트에 액세스할 수 있습니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/image6_jTnI7Ua.max-700x700.png

워크플로

  • 피어링된 네트워크의 인터페이스와 아웃바운드 네트워크의 다른 인터페이스로 NAT 인스턴스를 만듭니다. 요구사항을 충족하는 이미지를 선택할 수 있지만 표준 Debian 인스턴스를 사용하여 내용을 계속 알아보겠습니다. 참고: User Network1은 NAT 인스턴스를 8.8.8.8에 대한 다음 홉으로 참조하므로 User Network1에서 라우팅 루프를 방지하기 위해 NAT 인스턴스에서 트래픽을 8.8.8.8로 전달하여 User Network2의 다른 인터페이스로 보내야 합니다.
  • 이 인스턴스에서 IP 전달이 사용 설정되어 있고 공개 IP가 있는지 확인합니다.
  • 프로젝트의 VPC 경로 페이지로 이동을 참조하고 인스턴스를 다음 홉으로 사용하여 대상에 정적 경로를 추가합니다. 아래 예시에서는 8.8.8.8을 대상으로 사용합니다.
  • 또한 피어링 구성에서 `커스텀 경로 내보내기`를 사용 설정하여 이 정적 경로를 테넌트 프로젝트로 내보냅니다. 여기서는 8.8.8.8로의 정적 경로를 서비스 네트워킹으로 내보낸 것을 볼 수 있습니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/image11_iQAXlF8.max-1200x1200.png

  • 인스턴스의 UI로 이동하고 인스턴스를 구성하여 전달된 트래픽의 소스 IP를 자체 아웃바운드 인터페이스로 변환합니다. 아래 예시에서 Debian 인스턴스의 인터페이스 en4는 피어링된 네트워크에 있으며 en5는 아웃바운드 네트워크입니다.

로드 중...

  • 또한 User Network2의 아웃바운드 인터페이스 및 게이트웨이를 다음 홉으로 사용하여 엔드포인트에 대한 정적 경로로 인스턴스를 구성합니다.
로드 중...

인스턴스의 다음 패킷 캡처는 파이프라인 10.100.1.2 주소의 아웃바운드 연결이 인스턴스 10.1.1.2 주소로 변환되는지 확인합니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/image7_BXXMzVB.max-1000x1000.png
https://storage.googleapis.com/gweb-cloudblog-publish/images/image4_rYBeqAr.max-1000x1000.png

프록시를 통한 액세스

특정 서비스에 연결할 때 Vertex에서 사용하는 소스 IP를 제어해야 하는 경우 네트워크에서 서비스 프록시를 구성할 수도 있습니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/image9_oMNI4ln.max-500x500.png

Vertex AI 작업은 직접 피어링된 네트워크의 프록시에 도달할 수 있습니다. 파이프라인에서 외부 엔드포인트에 대한 요청은 프록시를 통해 릴레이되고 프록시의 공개 IP 주소에서 시작되는 것처럼 보입니다.

마찬가지로 Vertex AI 작업의 연결은 프록시의 공개 IP에서 시작되는 것처럼 공개 엔드포인트에 표시됩니다.

다른 피어링된 서비스에 대한 액세스

때에 따라 파이프라인은 서비스 네트워킹을 사용하는 다른 서비스에 액세스해야 합니다.

Redis용 Memorystore를 사용하여 이 내용을 계속 살펴보겠습니다. 전환 피어링이 지원되지 않는다는 점을 상기해보면, 아래 예시에서 Vertex 네트워크의 연결은 기본적으로 네트워크를 통해 Redis 네트워크로 전달할 수 없습니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/image10_3hDxzSY.max-700x700.png

피어링된 서비스의 코로케이션

권장되는 옵션은 동일한 서비스 네트워킹 예약에서 서로 통신해야 하는 모든 서비스를 배포하는 것입니다. 아래 예시에서 Vertex AI 작업은 Redis에 직접 도달할 수 있습니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/image8_oARYQRz.max-600x600.png

이 범위를 확장하여 다른 서비스를 지원하는 방법에 대한 자세한 내용은 Vertex AI를 위한 IP 범위 예약 설명을 참고하세요. 많은 서비스에서 새로운 범위를 예약하거나 기존 범위를 사용하는 옵션을 제공합니다. 기존 범위를 사용하는 방법에 대한 안내는 해당 서비스 문서를 참고하세요.

NAT 인스턴스

NAT 인스턴스 또는 프록시를 통해 Vertex AI 파이프라인 공개 IP를 할당하기 위해 위에서 설명한 워크플로는 이 Redis 예시에 액세스할 수 있도록 손쉽게 조정할 수 있습니다.

아래 다이어그램에서 User Network1에는 NAT 인스턴스를 다음 홉으로 사용하는 Redis에 대한 정적 경로가 있으며 이 경로를 Vertex 네트워크로 내보냅니다. Vertex AI의 연결은 User Network2의 NAT 인스턴스 인터페이스에서 시작된 것처럼 Redis에 표시됩니다.

이 구성에서는 새로운 서비스 네트워킹 IP 범위가 추가되는 경우에 대비하여 관리할 경로 수를 줄일 수 있습니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/image2_h0RvOdn.max-900x900.png

라우팅 인스턴스

또한 NAT 인스턴스를 User Network1과 User Network2 간의 라우팅 인스턴스로 바꿀 수 있습니다.

이 구성에서는 User Network1의 Redis IP 범위에 대한 정적 경로와 User Network2의 Vertex AI IP 범위에 대한 정적 경로가 필요합니다. 두 정적 경로 모두 라우팅 인스턴스를 다음 홉으로 가리킵니다.

이 구성은 NAT 인스턴스를 사용하는 것보다 문제를 더 쉽게 해결할 수 있습니다. 양방향 연결을 유지하기 위해 새 서비스를 제공하는 경우 네트워크 관리자와 협력하여 두 네트워크의 라우팅 테이블을 업데이트해야 하는 방법을 알려줍니다.

Cloud VPN

라우팅 인스턴스 대신 User Network1과 User Network2 간 Cloud VPN을 구성할 수도 있습니다. 이 경우에도 각 서비스 네트워크에서 서로 연결되기 위해 네트워크를 통해 라우팅된다는 것을 알 수 있도록 정적 경로를 양방향으로 내보내야 합니다. 계속해서 정적 경로를 유지해야 하지만 이 옵션을 사용하면 라우팅 인스턴스를 직접 관리할 필요가 없습니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_XwKbwWB.max-800x800.png

프록시 인스턴스

마찬가지로 Vertex가 프록시를 통해 Redis에 액세스하면 해당 연결은 프록시 IP에서 시작된 것처럼 보입니다. Redis 인스턴스는 Vertex AI 네트워크에 도달하는 방법을 모르더라도 응답할 수 있습니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/image3_3WdruiR.max-700x700.png

요약

Vertex AI는 Service Networking API를 사용하여 Google 소유 테넌트 프로젝트를 소비자 프로젝트에 연결할 수 있는 여러 서비스 중 하나입니다. 이러한 서비스의 배포 가이드에서는 서비스를 프로젝트의 엔드포인트에 연결하는 방법을 설명합니다.

이 문서에서는 네트워킹 구성에 대해 자세히 설명하며 Vertex AI를 인터넷의 다른 서비스 네트워킹 소비자 또는 엔드포인트에 연결하는 옵션을 살펴봅니다.

게시 위치