GKE 에이전트 서브스트레이트 정보

에이전트 기판은 Kubernetes 클러스터에서 에이전트 워크로드를 대규모로 실행합니다. 이는 일반적인 리소스 비효율성을 해결합니다. 개인 비서 및 코딩 에이전트와 같은 대화형 에이전트는 사용자 입력 또는 외부 트리거를 기다리는 데 대부분의 시간을 소비하는 경우가 많습니다. 이러한 비활성 에이전트를 계속 실행하면 활성 워크로드에 할당할 수 있는 CPU와 메모리가 사용됩니다.

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

에이전트 기판은 에이전트 샌드박스의 기능을 기반으로 하며 표준 Kubernetes 컨트롤 플레인의 병목 현상을 우회하여 에이전트 샌드박스를 개선합니다. 따라서 머신당 동시 에이전트 수가 크게 늘어나고 에이전트 시작 시간이 대폭 단축됩니다.

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

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

Agent Substrate의 이점

에이전트 기판을 사용하여 다음 목표를 달성할 수 있습니다.

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

사용 사례

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

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

Agent Substrate 작동 방식

에이전트 기판은 Kubernetes를 기반으로 빌드되지만 Kubernetes를 이해하지 않아도 사용할 수 있습니다. 에이전트 기판의 핵심 개념은 다음과 같습니다.

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

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

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

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

워크로드 격리 및 GKE Sandbox

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

제한사항 및 요구사항

에이전트 기판에는 다음과 같은 제한사항과 요구사항이 있습니다.

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

다음 단계