GKE의 Agent Substrate 정보

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

GKE의 Agent Substrate는 애플리케이션이 유휴 에이전트를 정지할 수 있도록 하여 이 문제를 해결합니다. 애플리케이션이 에이전트를 정지하면 시스템은 에이전트의 활성 메모리(RAM)와 로컬 파일의 스냅샷을 생성합니다. 정지된 에이전트가 다시 작동해야 하는 경우 시스템은 1초 이내에 에이전트의 상태를 사용 가능한 샌드박스로 복원합니다.

GKE의 Agent Substrate는 GKE의 Agent Sandbox 기능을 기반으로 하며, 표준 Kubernetes 컨트롤 플레인의 병목 현상을 우회하여 GKE의 Agent Sandbox를 개선합니다. 따라서 GKE의 Agent Substrate는 GKE의 Agent Sandbox보다 머신당 더 많은 동시 에이전트를 실행하고 에이전트를 더 빠르게 시작합니다. GKE의 Agent Substrate를 GKE의 Agent Sandbox와 비교하고 AI 에이전트 워크로드에 적합한 아키텍처를 선택하려면 GKE에서 AI 에이전트 워크로드 아키텍처 계획을 참조하세요.

표준 Kubernetes 배포(GKE의 Agent Sandbox 포함)는 각 에이전트 워크로드를 전용 포드와 연결합니다. 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의 Agent Substrate 설치에는 자체 gVisor 런타임이 포함됩니다. GKE의 Agent Substrate가 실행되는 노드 풀에서는 GKE Sandbox를 사용 설정하지 마세요. GKE의 Agent Substrate는 이러한 노드에서 실행할 수 없습니다. GKE의 Agent Sandbox를 포함한 다른 워크로드에는 GKE Sandbox를 계속 사용할 수 있습니다.

제한사항 및 요구사항

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

  • 클러스터 모드, 버전, 출시 채널: GKE의 Agent Substrate는 컨트롤 플레인 및 노드 풀이 버전 1.37 이상을 실행하는 GKE Standard 클러스터를 지원합니다. Autopilot 클러스터 및 1.37 이전 버전은 지원되지 않습니다. 버전 1.37 이상에서 GKE는 podcertificaterequests 및 clustertrustbundles Kubernetes API를 제공하고 노드가 포드 인증서와 트러스트 번들을 포드에 마운트할 수 있도록 하므로 이러한 API의 베타 버전을 직접 사용 설정할 필요가 없습니다. 하지만 설치 프로그램은 생성하거나 구성하는 모든 클러스터에서 베타 버전을 사용 설정합니다. 확장 출시 채널은 명시적으로 사용 설정된 베타 API를 지원하지 않으므로 확장 출시 채널에 등록된 클러스터에는 설치 프로그램을 사용할 수 없습니다.

  • GKE용 워크로드 아이덴티티 제휴: GKE 클러스터에 GKE용 워크로드 아이덴티티 제휴가 사용 설정되어 있어야 합니다. GKE의 에이전트 기판은 GKE용 워크로드 아이덴티티 제휴를 사용하여 에이전트 스냅샷을 저장하기 위한 Cloud Storage와 같은 Google Cloud API에 인증합니다. 스냅샷을 저장하고 복원하기 위해 시스템은 ate-snapshot-transfer라는 전용 서비스 계정을 사용합니다. 각 저장 또는 복원 작업의 사용자 인증 정보는 한 Actor의 스냅샷에만 액세스할 수 있습니다. 따라서 GKE 노드에 스냅샷 버킷에 대한 액세스 권한을 부여할 필요가 없습니다. 설치 프로그램은 ate-snapshot-transfer 서비스 계정을 만들고 스냅샷 버킷에 대한 액세스 권한을 부여합니다. 대신 권한을 직접 설정하는 경우 다음 IAM 역할을 부여합니다.

    • 스냅샷 버킷에서 ate-snapshot-transfer 서비스 계정과 ate-api-server Kubernetes 서비스 계정에 스토리지 객체 관리자(roles/storage.objectAdmin) 및 스토리지 버킷 뷰어(roles/storage.bucketViewer) 역할을 부여합니다.
    • ate-snapshot-transfer 서비스 계정에서 ate-api-server Kubernetes 서비스 계정에 서비스 계정 토큰 생성자 역할(roles/iam.serviceAccountTokenCreator)을 부여합니다. ate-api-server 서비스 계정은 ate-snapshot-transfer 서비스 계정을 가장하여 각 작업자의 사용자 인증 정보를 발급합니다.
    • 마이크로VM 런타임을 사용하는 경우 atelet Kubernetes 서비스 계정에 애셋 버킷에 대한 스토리지 객체 뷰어 역할(roles/storage.objectViewer)을 부여합니다.

    전체 바인딩 목록과 이에 상응하는 gcloud 명령어는 setup-gcp README의 create iam가 실제로 부여하는 권한을 참조하세요.

  • VM 제품군:

    • 혼합 CPU 아키텍처: GKE의 에이전트 기판은 gVisor의 알려진 문제로 인해 혼합 CPU 아키텍처(예: E2 머신 유형)에서 실행되는 범용 머신 시리즈를 지원하지 않습니다.
    • 액터 템플릿당 균일한 VM 유형: 하나의 ActorTemplate에서 만드는 모든 액터는 동일한 VM 유형에서 실행되어야 합니다. ActorTemplate은 Kubernetes 리소스가 아니며 노드 선택기가 없습니다. 대신 ActorTemplate의 workerSelector 필드는 라벨을 기준으로 WorkerPool 리소스를 선택합니다. 각 WorkerPool는 spec.template.nodeSelector 필드를 사용하여 작업자의 노드를 선택할 수 있습니다. 예를 들어 클러스터에 C4 VM과 N2 VM을 사용하는 노드 풀이 있는 경우 각 WorkerPool를 구성하여 한 VM 유형의 노드만 선택합니다. 그런 다음 C4 VM을 사용하는 WorkerPool 리소스만 일치하도록 ActorTemplate의 workerSelector 필드를 설정합니다.
    • 마이크로 VM 런타임을 위한 중첩된 가상화 또는 베어메탈: 마이크로 VM 런타임은 자체 가상 머신에서 각 샌드박스를 실행하므로 이 런타임을 사용하는 작업자에게는 가상 머신을 실행할 수 있는 노드가 필요합니다. 이러한 노드는 Arm이 아닌 x86 CPU 아키텍처를 사용해야 합니다. 설치 프로그램이 클러스터를 만들면 생성되는 노드 풀에 중첩 가상화가 사용 설정됩니다. 기존 클러스터의 GKE에 Agent Substrate를 설치하거나 마이크로VM 워커에 자체 노드 풀을 추가하는 경우 중첩 가상화가 사용 설정되었거나 x86 베어메탈 머신 유형을 사용하는 노드 풀을 사용합니다. 노드 풀을 만들 때만 중첩된 가상화를 사용 설정할 수 있습니다. C3, C4, N2, N4와 같이 중첩된 가상화를 지원하는 머신 시리즈를 확인하려면 머신 시리즈 비교를 참조하세요.

  • GPU 지원: 액터 컨테이너로의 GPU 기기 패스 스루는 지원되지 않습니다. nvidia.com/gpu를 지정하면 GPU 지원 노드에만 포드가 배치되지만 GPU 기기가 Actor 컨테이너에 전달되지 않습니다. 또한 gVisor는 라이브 CUDA 컨텍스트의 스냅샷을 만들 수 없습니다.

  • 개방형 네트워크 연결: 에이전트가 정지되면 개방형 네트워크 연결(예: 데이터베이스 세션 또는 MCP 서버 연결)이 유지되지 않습니다. 에이전트 코드는 에이전트가 재개될 때 외부 서비스에 다시 연결하는 작업을 처리해야 합니다.

  • 모니터링 가능성 및 관리형 OpenTelemetry: GKE용 관리형 OpenTelemetry에는 다음과 같은 제한사항이 있습니다.

    • 수집기 커넥터는 지원되지 않으므로 원격 분석 벤치마킹에 외부 프록시 미터를 사용해야 합니다.
    • 수집기 배포는 대규모 클러스터의 포드 수에 따라 선형적으로 확장되는 메모리 캐시 오버헤드를 발생시킵니다.
    • GKE용 관리형 OpenTelemetry에서는 TLS가 지원되지 않습니다.

  • 스토리지: GKE 기반 Agent Substrate는 다음 Cloud Storage 버킷을 사용하며, 이 버킷이 없으면 설치 프로그램이 생성합니다.

    • 스냅샷 버킷: 클러스터에 있는 모든 에이전트의 스냅샷을 저장합니다. 이 버킷은 필수 항목입니다.
    • 애셋 버킷: Linux 커널 및 루트 파일 시스템과 같이 마이크로 VM 런타임에 필요한 파일을 저장합니다. microVM 런타임은 이러한 파일을 사용하여 자체 가상 머신에서 각 샌드박스를 실행합니다. 이 버킷의 이름은 스냅샷 버킷 이름 뒤에 -assets가 붙은 이름입니다. 예를 들어 스냅샷 버킷 이름이 example-snapshots이면 애셋 버킷 이름은 example-snapshots-assets입니다. 마이크로 VM 런타임을 사용하지 않으면 이 버킷은 비어 있습니다.

  • 높은 샌드박스 밀도를 위한 커널 설정: 노드에서 약 800개 이상의 동시 샌드박스를 실행하면 파일 시스템 모니터링(inotify) 및 주소 결정 프로토콜(ARP)의 인접 테이블에 대한 Linux 커널의 기본 한도를 초과합니다. 한도가 높지 않으면 샌드박스가 시작되지 않고 네트워킹이 중단될 수 있습니다. 설치 프로그램은 생성하는 클러스터에 필요한 커널 설정을 적용합니다. 기존 클러스터의 GKE에 Agent Substrate를 설치하거나 자체 노드 풀을 추가하는 경우 이러한 설정을 직접 적용해야 합니다. 필수 값은 클러스터 요구사항 및 GKE의 Agent Substrate 인프라 설계를 참조하세요.

  • 설치 환경: Cloud Shell의 GKE에 Agent Substrate를 설치할 수 없습니다. Cloud Shell에는 5GB의 영구 디스크 스토리지 한도가 있으므로 설치에 충분한 디스크 공간이 제공되지 않습니다. 디스크 공간이 충분한 로컬 워크스테이션 또는 가상 머신(VM)에서 GKE에 Agent Substrate를 설치해야 합니다.

다음 단계