에이전트 런타임 성능 최적화 및 확장

Agent Runtime은 에이전트의 성능을 최적화하고 확장할 수 있는 배포 매개변수를 제공합니다. 이러한 매개변수를 구성하면 예측할 수 없거나 급증하는 트래픽 패턴을 효과적으로 처리할 수 있습니다.

이 페이지에서는 Agent Runtime의 성능을 최적화하고 확장하는 방법에 관한 권장사항을 설명하며 다음 시나리오를 다룹니다.

이 시나리오에서는 배포 매개변수를 사용하여 일반적인 성능 병목 현상을 해결하는 방법을 보여줍니다. 특히 실제 애플리케이션에서 예측할 수 없고 급증하는 트래픽 패턴에 유용합니다.

콜드 스타트 문제

콜드 스타트 는 요청이 도착했지만 이를 처리할 유휴 인스턴스 또는 컨테이너가 없어 Agent Runtime이 새 인스턴스 또는 컨테이너를 시작해야 할 때 발생합니다. 이렇게 하면 요청에 상당한 지연 시간이 추가됩니다.

예를 들어 기본 min_instances=1로 에이전트에 300개의 동시 요청을 전송하면 다음과 같은 결과가 표시될 수 있습니다.

  • 콜드 스타트 (첫 번째 실행): 평균 지연 시간은 약 4.7초입니다.

  • 웜 스타트 (즉시 두 번째 실행): 평균 지연 시간은 약 0.4초입니다.

4초가 넘는 오버헤드는 부하를 처리하기 위해 새 인스턴스가 시작되는 데 거의 전적으로 기인합니다.

콜드 스타트 문제를 완화하려면 다음 방법을 시도해 보세요.

  • 기준 트래픽을 처리할 수 있을 만큼 높은 min_instances 값을 설정합니다. 예를 들어 min_instances=10을 예시 에이전트에 설정하면 콜드 스타트의 평균 지연 시간을 약 1.4초로 줄일 수 있습니다. 트래픽이 급증하거나 많은 애플리케이션의 경우 min_instances를 1에서 확장하지 않고도 일반적인 부하를 처리할 수 있는 값으로 설정합니다. 최댓값은 10입니다.

  • 큐를 사용하여 안정적이고 지속적이며 예측 가능한 부하를 Agent Runtime으로 전송합니다. 예를 들어 min_instances=10 및 기본 concurrency (9)를 사용하여 에이전트 개발 키트(ADK) 기반 에이전트에서 60초 동안 분당 1,500개의 쿼리 (초당 쿼리 수 25개)의 지속적인 부하 테스트를 실행하면 다음과 같은 결과가 발생할 수 있습니다.

    • 평균 지연 시간은 약 1.6초로 일관되게 낮습니다.

안정적이고 지속적인 부하는 서비스를 상태로 유지하고 최적의 성능을 제공합니다.

비동기 작업자 활용도 부족

기본적으로 container_concurrency는 각 Agent Platform 인스턴스가 한 번에 하나의 요청만 처리하는 동기 코드에 맞게 구성됩니다. Agent Development Kit (ADK)를 기반으로 하는 에이전트와 같은 비동기 에이전트는 여러 I/O 바운드 요청 (예: LLM 또는 도구 호출)을 동시에 처리할 수 있습니다.

예를 들어 min_instances=10 및 기본 container_concurrency=9를 사용하여 ADK 기반 에이전트에 300개의 동시 요청을 전송하면 다음과 같은 결과가 발생할 수 있습니다.

  • 중간 지연 시간은 약 4초이지만 최대 지연 시간은 60초로 급증합니다. 이는 서비스가 천천히 확장되는 동안 요청이 대기열에 많이 추가됨을 나타냅니다.

비동기 작업자의 활용도 부족을 완화하려면 각 Agent Platform 인스턴스가 여러 요청을 처리할 수 있도록 container_concurrency를 늘립니다. 각 에이전트 프로세스가 처리할 수 있는 동시 요청 수는 container_concurrency / 9입니다. 값 9는 각 컨테이너 내에서 병렬로 실행되는 에이전트 프로세스 수를 나타냅니다.

예를 들어 min_instances=10container_concurrency=36을 사용하여 동일한 ADK 기반 에이전트에 300개의 동시 요청을 전송하면 다음과 같은 결과가 발생할 수 있습니다.

  • 최대 지연 시간이 60초에서 약 7초로 줄어듭니다. 이는 기존 인스턴스가 트래픽 급증을 더 효과적으로 흡수할 수 있음을 보여줍니다.

비동기 에이전트 (예: ADK 기반 에이전트)의 경우 container_concurrency를 9의 배수 (예: 36)로 시작점으로 설정합니다. 이렇게 하면 트래픽 급증에 대한 응답성이 개선되고 확장으로 인한 지연 시간이 줄어듭니다.

container_concurrency 값을 너무 높게 설정하면 메모리 부족 (OOM) 오류가 발생할 수 있습니다.

다음 단계

가이드

Agent Platform 관리형 런타임에 배포된 에이전트를 관리하는 방법을 알아봅니다.

가이드

Agent Platform 런타임에서 에이전트를 사용합니다.

리소스

Agent Platform의 할당량 및 한도에 대해 알아봅니다.