GKE의 Agent Substrate 정보

GKE의 Agent Substrate는 Kubernetes 클러스터에서 대규모로 에이전트 워크로드를 실행합니다. 이는 일반적인 리소스 비효율성 문제를 해결합니다. 대화형 에이전트 (예: 개인 비서, 코딩 에이전트)는 대부분의 시간을 사용자 입력이나 외부 트리거를 기다리는 데 사용합니다. 이러한 비활성 에이전트를 계속 실행하면 활성 워크로드에 할당할 수 있는 CPU와 메모리가 사용됩니다.

GKE의 Agent Substrate는 유휴 에이전트를 정지하고 에이전트의 활성 메모리 (RAM) 및 로컬 파일의 스냅샷을 만들어 이 문제를 해결합니다. 정지된 에이전트가 다시 작동해야 하는 경우 시스템은 1초 이내에 에이전트의 상태를 사용 가능한 샌드박스로 복원합니다.

GKE의 Agent Substrate는 GKE의 Agent Sandbox 기능을 기반으로 하며, 표준 Kubernetes 컨트롤 플레인의 병목 현상을 우회하여 GKE의 Agent Sandbox를 개선합니다. 따라서 머신당 동시 에이전트 수가 크게 증가하고 에이전트 시작 시간이 크게 단축됩니다.

표준 Kubernetes 배포 (GKE의 에이전트 샌드박스 포함)는 각 에이전트 워크로드를 전용 포드와 연결합니다. Kubernetes는 확장성이 뛰어나지만 포드의 시작 지연 시간과 예약 처리량에 의해 제한됩니다. 또한 Kubernetes는 최대 절전 모드 포드를 지원하지 않으며 클러스터에 수백만 개의 유휴 에이전트를 유지하면 포드 한도와 컨트롤 플레인 메모리가 소진됩니다. 유휴 컴퓨팅에 대한 비용을 지불하지 않으려면 포드를 종료하고 외부 스토리지에서 에이전트 상태를 관리해야 합니다. GKE의 Agent Substrate는 기본 포드에서 에이전트 상태를 분리하여 이러한 확장 제약 조건을 해결합니다. 즉, 수백만 개의 정지된 에이전트 스냅샷을 스토리지에 저장하고 필요에 따라 웜 워커의 공유 풀에 복원합니다.

GKE의 Agent Substrate는 자체 GKE Standard 클러스터에 직접 배포하는 오픈소스 시스템입니다. 핵심 프로젝트는 오픈소스 Agent Substrate 저장소에서 개발되지만 Google은 자격 요건을 충족하는 Google Cloud 고객을 위해 substrate-gke 저장소에서 GKE에 최적화된 배포 도구와 스크립트를 제공합니다.

GKE의 Agent Substrate 이점

GKE의 Agent Substrate를 사용하여 다음 목표를 달성할 수 있습니다.

  • 신뢰할 수 없는 코드를 안전하게 실행: GKE의 Agent Substrate는 커널 및 네트워크 격리를 적용하므로 광범위한 인프라를 위험에 빠뜨리지 않고 AI 생성 코드를 실행할 수 있습니다.
  • 장기 실행 스테이트풀(Stateful) 에이전트 빌드: 에이전트의 작업 메모리와 파일이 세션 간에 보존됩니다. 에이전트는 일시중지된 지점부터 다시 시작합니다.
  • 실시간으로 요청에 응답: 새 요청이 정지된 에이전트를 트리거하면 시스템이 에이전트 상태를 순식간에 복원합니다.
  • 컴퓨팅 비용 절감: 모든 에이전트에서 작업자 샌드박스 풀을 공유하여 더 적은 수의 머신에서 더 많은 에이전트를 실행할 수 있습니다. 유휴 에이전트는 정지되고 CPU 및 메모리를 사용하지 않으므로 에이전트가 작업을 활발하게 처리할 때만 컴퓨팅 비용을 지불합니다.

사용 사례

GKE의 Agent Substrate는 수십 개에서 수백만 개의 동시 에이전트에 이르기까지 모든 규모의 에이전트를 실행하도록 설계되었습니다. 다음은 세 가지 워크로드 예시입니다.

  • 생산성 에이전트: 몇 주 동안 컨텍스트를 유지하는 장기 백그라운드 어시스턴트입니다. 이러한 어시스턴트는 대부분의 시간을 트리거를 기다리는 데 사용하므로 사용하지 않을 때 워크로드를 정지하면 컴퓨팅 비용이 절감됩니다.
  • 임시 샌드박스: 신뢰할 수 없는 LLM 생성 코드를 실행하거나, 도구 호출을 실행하거나, 데이터를 분석하기 위한 주문형 격리 환경입니다. 샌드박스는 1초 이내에 복원되므로 시스템은 단기 작업에 일회용 환경을 제공하고 실행이 완료되면 리소스를 해제할 수 있습니다.
  • 코딩 에이전트: 개발자와 실시간으로 대화하여 코드를 작성, 빌드, 테스트하는 AI 어시스턴트입니다. 에이전트는 샌드박스 내에서 터미널 명령어를 실행하고 파일을 수정합니다. 에이전트가 유휴 상태이면 개발자가 다른 프롬프트를 전송할 때까지 시스템에서 에이전트를 정지합니다.

GKE의 Agent Substrate 작동 방식

GKE의 Agent Substrate는 Kubernetes를 기반으로 빌드되지만 이를 사용하기 위해 Kubernetes를 이해할 필요는 없습니다. GKE의 Agent Substrate 핵심 개념은 다음과 같습니다.

  • 작업 수행자: 실행 중인 에이전트의 단일 인스턴스입니다.
  • ActorTemplate: 액터를 인스턴스화하는 데 사용되는 구성 청사진 (컨테이너 이미지, 환경 변수, 컴퓨팅 리소스 정의)입니다.
  • 작업자: 활성 작업자가 실행되는 안전한 샌드박스입니다.
  • WorkerPool: 액터를 수신할 준비가 된 사전 시작된 유휴 작업자 그룹입니다.

액터는 특정 작업자에 연결되지 않으므로 시스템은 유휴 에이전트를 정지하고 확보된 컴퓨팅을 재사용할 수 있습니다. 이 아키텍처를 사용하면 시스템이 제한된 수의 머신에서 수백만 개의 에이전트를 실행할 수 있습니다.

일반적인 에이전트 수명 주기는 다음 단계를 따릅니다.

  1. 라우팅: 애플리케이션에서 들어오는 각 API 요청은 대상 Actor를 지정합니다. 예를 들어 사용자가 채팅 인터페이스에 새 프롬프트를 입력하면 애플리케이션은 사용자의 세션을 관리하는 특정 액터를 대상으로 요청을 전송합니다.
  2. 재개: 요청이 정지된 액터에 대한 것이면 시스템은 WorkerPool에서 웜 작업자를 요청하고 액터의 스냅샷을 해당 작업자에 복원합니다.
  3. 실행 중: 시스템이 새로 활성화된 이 작업자로 요청을 라우팅하고 작업자가 작업을 처리합니다.
  4. 정지: 액터가 작업을 완료하고 유휴 상태가 되면 시스템은 액터의 메모리와 파일의 새 스냅샷을 만들고 스냅샷을 스토리지에 저장하고 빈 워커를 풀에 다시 해제합니다.

워크로드 격리 및 GKE Sandbox

GKE의 Agent Substrate는 gVisor 또는 Cloud Hypervisor를 사용하여 호스트 커널에서 애플리케이션 코드를 격리하는 샌드박스에서 각 워크로드를 실행합니다. GKE의 에이전트 기판 설치에는 작업자용 gVisor 런타임이 포함되어 있으므로 기본 GKE 노드에서 GKE Sandbox를 구성할 필요가 없습니다.

제한사항 및 요구사항

GKE의 Agent Substrate에는 다음과 같은 제한사항과 요구사항이 있습니다.

  • 클러스터 버전 및 베타 API: GKE의 에이전트 기판은 버전 1.36 (베타 플래그 사용 설정됨) 또는 버전 1.37 이상을 실행하는 GKE Standard 클러스터에서 지원됩니다. 1.36 이전 버전은 지원되지 않습니다. 또한 GKE에는 베타 API (podcertificaterequests 및 clustertrustbundles)가 필요합니다. 버전 1.36을 실행하는 기존 클러스터에서 이러한 API를 사용 설정하는 경우 포드 인증서 프로젝션이 사용 설정되도록 기존 노드도 교체해야 합니다. 버전 1.37 이상에서는 기존 노드를 교체할 필요가 없습니다.
  • GKE용 워크로드 아이덴티티 제휴: GKE 클러스터에 GKE용 워크로드 아이덴티티 제휴가 사용 설정되어 있어야 합니다. GKE의 에이전트 기판은 GKE용 워크로드 아이덴티티 제휴를 사용하여 에이전트 스냅샷을 저장하기 위한 Cloud Storage와 같은 Google Cloud API에 인증합니다.
  • VM 제품군:
    • 혼합 CPU 아키텍처: GKE의 Agent Substrate는 gVisor의 알려진 문제로 인해 혼합 CPU 아키텍처 (예: E2 머신 유형)에서 실행되는 범용 머신 시리즈를 지원하지 않습니다.
    • 액터 템플릿당 균일한 VM 유형: 단일 ActorTemplate (액터를 만드는 데 사용되는 구성 청사진) 내에서 VM 유형을 혼합하는 것은 지원되지 않습니다. 예를 들어 클러스터에 C4 및 N2 VM을 사용하는 노드 풀이 두 개 있는 경우 ActorTemplate에는 해당 템플릿의 액터가 여러 머신 유형에 분산되지 않도록 단일 VM 유형 (예: C4)을 지정하는 노드 선택기가 포함되어야 합니다.
  • GPU 지원: Actor 컨테이너로의 GPU 기기 패스 스루는 지원되지 않습니다. nvidia.com/gpu를 지정하면 GPU 지원 노드에만 포드가 배치되지만 GPU 기기가 Actor 컨테이너에 전달되지 않습니다. 또한 gVisor는 라이브 CUDA 컨텍스트의 스냅샷을 만들 수 없습니다.
  • 네트워킹:
    • 이그레스 정책: 다음 기능을 포함하여 EgressPolicy 규칙 (호스트 이름 및 IP 주소별 네트워크 제어)은 지원되지 않습니다.
      • 기본 거부 규칙
      • 호스트 이름 기반 규칙
      • 사용자 인증 정보 삽입
    • 열린 연결: 에이전트가 정지되면 열린 네트워크 연결 (예: 데이터베이스 세션 또는 MCP 서버 연결)이 유지되지 않습니다. 에이전트 코드는 에이전트가 재개될 때 외부 서비스에 다시 연결하는 작업을 처리해야 합니다.
  • 모니터링 가능성 및 관리형 OpenTelemetry: GKE용 관리형 OpenTelemetry에는 다음과 같은 제한사항이 있습니다.
    • 수집기 커넥터는 지원되지 않으므로 원격 분석 벤치마킹에 외부 프록시 미터를 사용해야 합니다.
    • 수집기 배포는 대규모 클러스터의 포드 수에 따라 선형적으로 확장되는 메모리 캐시 오버헤드를 발생시킵니다.
    • GKE용 관리형 OpenTelemetry에서는 TLS가 지원되지 않습니다.
  • 스토리지: 시스템에서 에이전트의 스냅샷을 저장하려면 Cloud Storage가 필요합니다.
  • 설치 환경: Cloud Shell의 GKE에는 Agent Substrate를 설치할 수 없습니다. Cloud Shell에는 5GB의 영구 디스크 스토리지 한도가 있으므로 설치에 충분한 디스크 공간이 제공되지 않습니다. 디스크 공간이 충분한 로컬 워크스테이션 또는 가상 머신 (VM)에서 GKE에 Agent Substrate를 설치해야 합니다.

다음 단계