모든 백엔드에서 AI 추론 모델 서빙을 위한 네트워킹

Last reviewed 2026-05-20 UTC

이 문서에서는 온프레미스 또는 서드 파티 및 Google을 포함한 모든 제공업체에서 호스팅되는 여러 AI 모델의 통합 프런트엔드를 만드는 참조 아키텍처를 제공합니다. Google Cloud모든 추론 서버가 Google Kubernetes Engine (GKE)에서 호스팅되는 경우 GKE의 AI 추론 모델 서빙을 위한 네트워킹을 참조하세요.

이 아키텍처는 개발자가 각 모델의 개별 IP 주소를 지정하지 않고도 모델을 선택할 수 있도록 설계되었습니다. 대신 개발자는 OpenAI API 모델 이름이 포함된 요청을 프런트엔드 엔드포인트로 보냅니다. 아키텍처의 시스템은 지정된 모델을 호스팅하는 백엔드로 요청을 라우팅합니다. 아키텍처의 프런트엔드 부하 분산기는 다음과 같은 중앙 집중식 관리 기능을 제공합니다.

  • 모델을 호스팅하는 방식과 관계없이 모든 모델 호출을 위한 단일 프런트엔드 엔드포인트
  • API 관리 기능
  • AI 가드레일 체크포인트
  • Service Extensions 삽입 지점(향후 확장성)

이 문서는 단일 추론 엔드포인트 뒤에 신규 또는 기존 생성형 AI 모델을 배치하려는 네트워크 관리자 및 생성형 AI 애플리케이션 관리자를 대상으로 작성되었습니다. 이 문서에서는 애플리케이션을 설계하거나 개별 생성형 AI 모델을 배포하는 방법에 대한 안내를 제공하지 않습니다. 모델 배포 방법에 대한 안내는 기업에서 생성형 AI 및 머신 러닝 모델 빌드 및 배포를 참조하세요. 이 아키텍처는 분산형 애플리케이션을 위한 크로스 클라우드 네트워크와 같은 애플리케이션 네트워킹 아키텍처 및 기타 설계와 함께 작동합니다.

아키텍처

다음 다이어그램은 리전 내부 애플리케이션 부하 분산기 프런트엔드를 가리키는 소비자 네트워크의 엔드포인트가 있는 아키텍처를 보여줍니다. 이 부하 분산기는 지정된 모델의 이름을 사용하여 온프레미스 또는 모든 제공업체에서 호스팅되는 모델 복제본 세트로 요청을 라우팅합니다. 프런트엔드 부하 분산기는 호스팅된 모든 모델에 통합 서비스를 제공합니다.

AI 추론을 위한 네트워킹에 대한 대략적인 개요입니다.

다이어그램에 표시된 아키텍처에는 다음 구성요소가 포함됩니다.

모델 복제본 세트 구성

아키텍처에서 프런트엔드 부하 분산기는 모델 이름을 기반으로 트래픽을 특정 백엔드 서비스로 전달합니다. 지정된 모델의 추론 서버는 다음 표에 설명된 구성 중 하나에서 호스팅될 수 있습니다.

복제본 세트 유형 설명 복제본 부하 분산
Agent Platform 모델 복제본은 Agent Platform에서 실행됩니다. Agent Platform 엔드포인트를 Private Service Connect 네트워크 엔드포인트 그룹 (NEG)으로 게시합니다. 프런트엔드 부하 분산기는 Private Service Connect NEG를 각 고유 모델의 백엔드로 사용하며 각 모델은 백엔드 서비스로 구성됩니다. Agent Platform은 내부적으로 확장 및 부하 분산을 실행합니다. Agent Platform은 측정항목 기반 가중 부하 분산 및 프리픽스 캐시 기반 라우팅을 실행하여 리소스 사용률을 최적화하고 추론을 가속화합니다. 자세한 내용은 엔드포인트에 모델 배포를 참조하세요.
GKE 추론 서버는 GKE 복제본 세트 VPC 네트워크의 GKE 클러스터에서 포드로 실행됩니다. GKE 내의 여러 모델 복제본은 추론 게이트웨이 뒤에 단일 백엔드를 공동으로 형성합니다. 추론 게이트웨이는 프런트엔드 부하 분산기가 Private Service Connect NEG를 사용하여 액세스하는 Private Service Connect 엔드포인트를 게시합니다. 추론 게이트웨이 는 GKE 클러스터의 추론 백엔드에 모델 인식 부하 분산을 제공합니다. 추론 게이트웨이는 해당하는 경우 프리픽스 일치를 사용합니다. 프리픽스 일치가 없으면 추론 게이트웨이는 GPU 또는 TPU 측정항목을 기반으로 요청을 분산합니다. 이 구성은 수평형 포드 자동 확장을 지원합니다.
Cloud Run 추론 서버는 Cloud Run에서 실행됩니다. Cloud Run은 프런트엔드 부하 분산기가 서버리스 NEG를 사용하여 액세스하는 엔드포인트를 게시합니다. Cloud Run 트래픽을 기반으로 복제본 수를 자동으로 확장합니다. 단일 노드 복제본으로만 제한됩니다.
공식 판매처 겸 리셀러 추론 서버는 온프레미스 또는 다른 클라우드에서 실행됩니다. 라우팅 VPC 네트워크에서 리전 내부 프록시 네트워크 부하 분산기 를 구성합니다. 이 부하 분산기는 프런트엔드 부하 분산기가 Private Service Connect NEG를 사용하여 액세스하는 Private Service Connect 엔드포인트를 게시합니다. 라우팅 VPC 네트워크의 내부 부하 분산기에는 온프레미스 추론 서버 앞의 온프레미스 또는 기타 클라우드 부하 분산기의 IP 주소를 가리키는 하이브리드 NEG 백엔드가 있습니다. 외부 부하 분산기의 부하 분산 메커니즘은 외부 시설의 관리자가 구성합니다.
인터넷 공개 인터넷 IP 주소에서 액세스할 수 있는 추론 서버입니다. 프런트엔드 부하 분산기에는 인터넷에서 호스팅되는 모델의 IP 주소를 가리키는 인터넷 NEG 백엔드가 있습니다. 관리형 서비스 제공업체에서 확장을 처리합니다.

요청 흐름

시스템은 다음과 같이 추론 요청을 라우팅합니다.

  1. 최종 사용자가 Private Service Connect 엔드포인트로 OpenAI API 요청을 보냅니다. 이 요청에는 다음이 포함됩니다.
    • 프롬프트
    • 모델 이름(호스팅된 추론 서버 중 하나의 모델 이름과 일치해야 함)
  2. Private Service Connect 엔드포인트는 요청을 프런트엔드 내부 애플리케이션 부하 분산기로 전달합니다.
  3. 부하 분산기는 요청을 Service Extensions로 전달합니다.
  4. Service Extensions 추론 페이로드 프로세서 코드는 요청 본문에서 모델 이름을 읽고 X-Gateway-Model-Name 헤더에 씁니다.
  5. 부하 분산기는 Service Extensions 트래픽 확장 프로그램 콜아웃을 사용하여 필요한 API 관리 서비스에 대한 요청을 API 관리 시스템으로 보냅니다.
  6. 부하 분산기는 Service Extensions 트래픽 확장 프로그램 콜아웃을 사용하여 검사를 위해 프롬프트를 Model Armor로 보냅니다.
    • 프롬프트에 수정할 수 없는 민감한 정보가 포함되어 있으면 프롬프트가 차단되고 Model Armor는 정책 위반이 발견되었음을 나타내는 응답을 반환합니다.
    • 프롬프트에 수정할 수 있는 민감한 정보가 포함되어 있거나 프롬프트에 문제가 없는 경우 Model Armor는 민감한 정보를 수정하고 프롬프트를 전달합니다.
  7. Model Armor에서 요청을 허용하면 부하 분산기는 URL 맵을 참조하고 모델 이름 커스텀 헤더를 기반으로 백엔드 서비스로 요청을 전달합니다. 필요한 경우 URL 맵은 백엔드에 필요한 사항과 일치하도록 요청의 URL과 경로를 다시 작성합니다.
  8. 백엔드 서비스는 요청을 연결된 복제본 세트 부하 분산기로 전달합니다.
  9. 특정 추론 서비스의 부하 분산기는 요청을 복제본 중 하나에 할당합니다.
  10. 복제본은 요청을 처리하고 응답을 다시 보냅니다.
  11. 프런트엔드 리전 내부 애플리케이션 부하 분산기는 검사를 위해 응답을 Model Armor로 보냅니다.
  12. 애플리케이션 부하 분산기는 응답을 Private Service Connect 엔드포인트로 다시 보내고 최종 사용자에게 전달합니다.

다음 다이어그램은 샘플 배포의 라우팅 뷰를 보여줍니다.

샘플 복제본 세트에 대한 프롬프트 흐름입니다.

이 예시에서 프롬프트는 사용자가 선택한 모델에 따라 처리됩니다.

  • Gemma: 모든 프롬프트는 Gemma 모델을 호스팅하는 복제본 세트로 라우팅됩니다.
  • Llama: 시스템은 Llama 모델을 모두 호스팅하는 두 복제본 세트 간에 이러한 프롬프트를 동일하게 부하 분산합니다. 이 두 복제본 세트는 동일한 방식으로 호스팅될 필요가 없습니다. 예를 들어 한 복제본 세트는 Agent Platform에서 호스팅되고 다른 복제본 세트는 GKE에서 호스팅될 수 있습니다.
  • LoRA-1-gemma 또는 LoRA-2-gemma: 시스템은 두 모델을 모두 처리할 수 있는 동일한 복제본 세트로 모든 프롬프트를 보냅니다.

사용 제품

이 문서의 참조 아키텍처에는 다음과 같은 Google Cloud 제품이 사용됩니다.

  • Cloud Load Balancing: 확장 가능한 고성능 전역 및 리전 부하 분산기 포트폴리오입니다.
  • Virtual Private Cloud (VPC): 워크로드에 확장 가능한 전역 네트워킹 기능을 제공하는 가상 시스템입니다. Google Cloud VPC에는 VPC 네트워크 피어링, Private Service Connect, 비공개 서비스 액세스, 공유 VPC가 포함됩니다.
  • Private Service Connect: 소비자가 VPC 네트워크 내부에서 비공개로 관리형 서비스에 액세스할 수 있도록 허용하는 기능입니다.
  • Cloud Run: Google의 확장 가능한 인프라에서 직접 컨테이너를 실행할 수 있게 해주는 서버리스 컴퓨팅 플랫폼입니다.
  • Apigee: API 액세스 및 사용 방식을 세부적으로 제어할 수 있는 API 관리 도구입니다. 보안, 비율 제한, 할당량 적용, 분석을 제공합니다.
  • Model Armor: 프롬프트 인젝션, 민감한 정보 유출, 유해한 콘텐츠로부터 생성형 AI 및 에이전트 AI 리소스를 보호하는 서비스를 제공합니다.

설계 대안

이 섹션에서는 이 아키텍처의 기본 가정에 대한 대안을 설명합니다.

AI 가드레일

AI 가드레일에는 Model Armor를 사용하는 것이 좋습니다. 관리를 중앙 집중화하려면 이 아키텍처와 같이 부하 분산기에서 직접 호출하는 것이 좋습니다. 다음과 같은 대체 방법으로 Model Armor를 구현할 수도 있습니다.

  • API 관리 정책을 사용하여 Model Armor를 호출합니다.
  • 복제본에만 Model Armor를 배포합니다.

모델 엔드포인트 이외의 위치에 AI 가드레일을 구현하는 경우 필요하지 않으면 프런트엔드 부하 분산기에서 Model Armor를 사용 중지할 수 있습니다. Model Armor를 사용하지 않으려면 트래픽 확장 프로그램을 사용하여 NVIDIA NeMo Guardrails와 같은 다른 가드레일 제품을 배포할 수 있습니다.

API 관리

이 문서의 아키텍처는 부하 분산기 서비스 확장 프로그램을 사용하여 배포되는 API 관리에 Apigee를 사용합니다. Apigee가 요구사항을 충족하지 않는 경우 Service Extensions를 사용하여 다른 API 관리 서비스를 배포할 수 있습니다.

Service Extensions를 사용하여 API 관리를 배포하는 것이 요구사항을 충족하지 않는 경우 클라이언트 연결 네트워크와 API 연결 네트워크를 배포해야 할 수 있습니다. 이 시나리오에서 API 관리 서비스는 두 네트워크 간의 브리지 역할을 합니다. Apigee에 이를 배포하는 방법에 대한 자세한 내용은 Apigee 네트워킹 옵션을 참조하세요.

다른 네트워크에 연결

이 문서의 아키텍처는 단일 소비자 VPC 네트워크를 사용합니다. 하지만 교차 클라우드 네트워크 배포에서 서비스 액세스 VPC 네트워크를 사용하여 Private Service Connect 엔드포인트를 다른 여러 네트워크와 공유할 수 있습니다. 배포

설계 고려사항

워크로드의 아키텍처를 빌드할 때는 best practices와 Google Cloud Well-Architected Framework에서 제공하는 권장사항을 고려하세요.

보안, 개인 정보 보호, 규정 준수

  • 배포에 분산 서비스 거부 공격 (DDoS) 보호, 웹 애플리케이션 방화벽 (WAF) 기능, IP 주소 검사를 추가하려면 Cloud Armor를 프런트엔드 리전 내부 애플리케이션 부하 분산기에 추가합니다.
  • 모든 백엔드에 공통 인증 레이어를 추가하려면 IAP (Identity-Aware Proxy)를 구현하여 ID를 확인하고 승인 정책을 적용합니다.
  • 웹 애플리케이션에서 Agent Platform 모델로 트래픽을 라우팅할 때는 인증을 위한 ID 모델을 선택해야 합니다.
    • 서비스 계정 ID (일반 웹 앱에 권장): 애플리케이션은 IAP를 통해 최종 사용자를 인증하지만 서비스 워크로드 ID (예: Cloud Run, GKE 또는 서드 파티 ID 사용)를 사용하여 Agent Platform을 호출합니다. 이 구현은 최종 사용자로부터 Identity and Access Management (IAM)를 추상화하지만 어떤 사용자가 어떤 프롬프트를 생성했는지 추적하려면 애플리케이션 수준 로깅이 필요합니다.
    • 최종 사용자 ID 통과 (엄격한 감사 가능성에 권장): 애플리케이션은 최종 사용자의 Google OAuth 액세스 토큰을 캡처하여 Authorization: Bearer 헤더에서 Agent Platform으로 직접 전달합니다. 이 구현은 사용자 작업의 기본 제공 Cloud 감사 로그 로깅을 제공하지만 모든 최종 사용자에게IAM 권한 Google Cloud(예: roles/aiplatform.user)이 프로비저닝되어야 합니다.

안정성

리전 오류를 방지하려면 멀티 리전 배포 아키타입을 사용하여 배포를 두 번째 리전에 복제합니다. Google Cloud 멀티 리전 배포 아키타입

운영 효율성

  • 문제를 신속하게 식별하고 해결할 수 있도록 트래픽 흐름을 모니터링하려면 리전 내부 애플리케이션 부하 분산기에 Cloud Logging 로그를 사용합니다.
  • 조직에서 지원하는 모델을 쉽게 검색할 수 있도록 사용 가능한 모델을 반환하도록 쿼리할 수 있는 목록을 구현합니다. 예를 들어, 목록 모델 API 호출에 응답하는 서버에 목록을 만들 수 있습니다.

성능 최적화

배포

이 아키텍처의 샘플 구현을 배포하려면 GitHub에서 제공되는 AI 추론 모델 서빙을 위한 네트워킹 코드 샘플을 사용하세요.

AI 모델 배포 방법에 대한 자세한 내용은 다음 리소스를 참조하세요.

다음 단계

참여자

작성자: 빅터 모레노 | Cloud Networking 제품 관리자

기타 참여자: