AI 에이전트 스케일링: C#로 Elasticity, State, Throughput 마스터하기

Source: Dev.to

고성능 AI 에이전트 아키텍처

금요일 밤 피크 타임에 고급 레스토랑을 상상해 보세요. 주방은 혼란 그 자체입니다: 주문이 쌓이고, 셰프들은 땀을 흘리며, 접시가 떨어지면 전체 테이블의 주문이 사라집니다.

이 상황을 여러분의 AI 인프라에 비유해 보세요. GPU 클러스터가 주방이고 AI 에이전트가 셰프라면, 사용자 요청이라는 “저녁 피크”가 닥쳤을 때 어떤 일이 일어날까요?

• 탄력적 스케일링 부재 → 시스템 충돌.
• 상태 지속성 부재 → 대화 손실.
• 처리량 최적화 부재 → 높은 지연 시간과 급등하는 클라우드 비용.

컨테이너화된 AI 에이전트를 대규모로 배포하는 것은 단순히 모델을 Docker에 포장하는 것이 아니라, 동적인 자원 관리를 조율하는 일입니다. 이 가이드는 현대 C# 및 Kubernetes를 활용해 단순한 AI 모델을 탄력적이고 클라우드‑네이티브한 서비스로 전환하기 위해 필요한 아키텍처적 기둥들을 상세히 설명합니다.

아키텍처 청사진

1️⃣ 탄력적 스케일링 (Intent‑Based)

표준 Kubernetes 배포에서는 CPU 또는 RAM 사용량을 기준으로 스케일링합니다. AI 에이전트의 경우 이러한 지표는 오해를 불러일으킬 수 있습니다:

• GPU는 대용량 배치를 처리하면서 100 % 활용도를 보이거나, 네트워크 응답을 기다리며 유휴 상태일 수 있습니다.
• 실제 병목 현상은 큐 깊이(GPU를 기다리는 요청 수)와 추론 지연시간(Time‑to‑First‑Token, TTFT)입니다.

System.Diagnostics.Metrics를 사용한 계측

using System.Diagnostics;
using System.Diagnostics.Metrics;

public class InferenceMetrics
{
    private static readonly Meter _meter = new("AI.Agent.Inference");

    // Latency of generating a response (ms)
    private static readonly Histogram<double> _generationLatency =
        _meter.CreateHistogram<double>("agent.generation.latency.ms", "ms",
            "Time taken to generate a response");

    // Number of requests waiting for inference
    private static readonly ObservableGauge<int> _queueDepth =
        _meter.CreateObservableGauge<int>("agent.queue.depth",
            () => RequestQueue.Count, // callback to read current queue size
            "requests",
            "Number of requests waiting for inference");

    public void RecordLatency(double latencyMs) => _generationLatency.Record(latencyMs);
}

장점: 스케일링 트리거를 일반적인 CPU 사용량이 아닌 도메인‑특화 메트릭(지연시간 / 큐 깊이)으로 분리함으로써 Horizontal Pod Autoscaler(HPA)가 선제적으로 스케일링되어 사용자 경험을 유지할 수 있습니다.

2️⃣ 상태 지속성 (단기 메모리)

AI 에이전트는 세션 동안 상태를 유지합니다: 이전 메시지, 도구 출력, 그리고 메모리에 의존합니다. 그러나 컨테이너는 일시적입니다. Pod A가 충돌하면 메모리 내 대화 기록이 사라집니다.

IDistributedCache를 이용한 분산 캐시

using Microsoft.Extensions.Caching.Distributed;
using System.Text.Json;

public interface IAgentStateStore
{
    Task<T?> GetStateAsync<T>(string sessionId, CancellationToken ct);
    Task SetStateAsync<T>(string sessionId, T state, CancellationToken ct);
}

public class RedisAgentStateStore : IAgentStateStore
{
    private readonly IDistributedCache _cache;
    public RedisAgentStateStore(IDistributedCache cache) => _cache = cache;

    public async Task<T?> GetStateAsync<T>(string sessionId, CancellationToken ct)
    {
        byte[]? data = await _cache.GetAsync(sessionId, ct);
        if (data == null) return default;

        // High‑performance deserialization (source‑generated in .NET 8)
        return JsonSerializer.Deserialize<T>(data);
    }

    public async Task SetStateAsync<T>(string sessionId, T state, CancellationToken ct)
    {
        byte[] data = JsonSerializer.SerializeToUtf8Bytes(state);
        var options = new DistributedCacheEntryOptions
        {
            SlidingExpiration = TimeSpan.FromMinutes(30) // evict inactive sessions
        };
        await _cache.SetAsync(sessionId, data, options, ct);
    }
}

Win: Pods는 무상태가 됩니다 – 논리와 모델 가중치만 호스팅합니다. Pod가 충돌하면 다음 요청이 Redis에서 세션 상태를 가져와 손실 없이 계속 진행합니다.

3️⃣ 처리량 최적화 (배칭)

AI 요청을 하나씩 처리하는 것은 요리를 한 접시씩 내는 것과 같으며, 비싼 GPU가 충분히 활용되지 못합니다. 요청 배칭은 여러 요청을 하나의 포워드 패스로 모읍니다.

System.Threading.Channels를 이용한 Producer‑Consumer

using System.Threading.Channels;

public class BatchingService
{
    private readonly Channel<InferenceRequest> _channel;
    private readonly TimeSpan _maxBatchWait = TimeSpan.FromMilliseconds(20);
    private readonly int _maxBatchSize = 32;

    public BatchingService()
    {
        var options = new BoundedChannelOptions(_maxBatchSize * 2)
        {
            FullMode = BoundedChannelFullMode.Wait
        };
        _channel = Channel.CreateBounded<InferenceRequest>(options);
    }

    // Producer: called by the HTTP endpoint
    public async ValueTask EnqueueAsync(InferenceRequest request, CancellationToken ct)
        => await _channel.Writer.WriteAsync(request, ct);

    // Consumer: background worker
    public async Task RunAsync(CancellationToken ct)
    {
        var batch = new List<InferenceRequest>(_maxBatchSize);
        while (!ct.IsCancellationRequested)
        {
            // Wait for at least one item
            if (await _channel.Reader.WaitToReadAsync(ct))
            {
                while (_channel.Reader.TryRead(out var item))
                {
                    batch.Add(item);
                    if (batch.Count >= _maxBatchSize) break;
                }

                // Optional time‑based flush
                var flushTask = Task.Delay(_maxBatchWait, ct);
                var completed = await Task.WhenAny(flushTask,
                    _channel.Reader.WaitToReadAsync(ct).AsTask());

                // Execute batch
                await ProcessBatchAsync(batch, ct);
                batch.Clear();
            }
        }
    }

    private Task ProcessBatchAsync(List<InferenceRequest> batch, CancellationToken ct)
    {
        // TODO: Call the model with the aggregated inputs
        // Record latency metrics, update queue depth, etc.
        return Task.CompletedTask;
    }
}

Win: GPU가 많은 작은 텐서 대신 단일 대형 텐서를 처리하게 되어 처리량이 크게 향상되고 요청당 비용이 감소합니다.

Putting It All Together

1. Expose metrics (InferenceMetrics) → HPA는 지연 시간/큐 깊이를 기준으로 파드를 스케일링합니다.
2. Persist session state (RedisAgentStateStore) → 파드는 무상태를 유지하여 빠른 복구가 가능합니다.
3. Batch incoming requests (BatchingService + Channels) → GPU 활용도를 최대화합니다.

이러한 기반이 마련되면, AI 서비스는 “금요일 밤 러시”를 여유롭게 처리할 수 있으며, 낮은 지연 시간의 응답을 제공하고 대화 컨텍스트를 보존하며 클라우드 비용을 효율적으로 관리합니다. 🚀

private readonly Channel<InferenceRequest> _channel;
private readonly ModelRunner _modelRunner;

public BatchingService(ModelRunner modelRunner)
{
    // Bounded channel prevents memory exhaustion (Back‑pressure)
    _channel = Channel.CreateBounded<InferenceRequest>(new BoundedChannelOptions(1000)
    {
        FullMode = BoundedChannelFullMode.Wait
    });
    _modelRunner = modelRunner;
}

public async ValueTask EnqueueAsync(InferenceRequest request)
{
    await _channel.Writer.WriteAsync(request);
}

public async Task ProcessBatchesAsync(CancellationToken stoppingToken)
{
    await foreach (var batch in ReadBatchesAsync(stoppingToken))
    {
        await _modelRunner.ExecuteBatchAsync(batch);
    }
}

private async IAsyncEnumerable<List<InferenceRequest>> ReadBatchesAsync(
    [EnumeratorCancellation] CancellationToken ct)
{
    var batch = new List<InferenceRequest>(capacity: 32);
    var timer = Task.Delay(TimeSpan.FromMilliseconds(10), ct);

    await foreach (var request in _channel.Reader.ReadAllAsync(ct))
    {
        batch.Add(request);

        // Condition 1: Batch is full
        if (batch.Count >= 32)
        {
            yield return batch;
            batch = new List<InferenceRequest>(32);
            timer = Task.Delay(TimeSpan.FromMilliseconds(10), ct);
        }
        // Condition 2: Timeout (latency optimisation)
        else if (batch.Count > 0 && await Task.WhenAny(timer, Task.CompletedTask) == timer)
        {
            yield return batch;
            batch = new List<InferenceRequest>(32);
            timer = Task.Delay(TimeSpan.FromMilliseconds(10), ct);
        }
    }
}

The Architectural Win

• Throughput – 배칭은 GPU 사이클당 수행되는 작업량을 최대화하여 필요한 파드 수를 줄이고 비용을 낮춥니다.
• Trade‑off – 지연 시간과 처리량 사이의 균형을 batch size와 timeout 파라미터로 조정할 수 있습니다.

이 세 가지 개념이 결합되어 일관되고 자가 치유 가능한 시스템을 형성합니다:

1. Traffic 은 System.Threading.Channels 를 통해 들어오고 큐에 적재됩니다.
2. Batching Service 가 요청을 그룹화하고 Redis에서 Agent State 를 가져옵니다.
3. model 이 배치를 처리하고, Metrics 가 지연 시간을 기록합니다.
4. HPA Controller 가 커스텀 메트릭을 읽어 지연 시간이 급증하면 파드를 확장합니다.
5. 새 파드가 시작되어 Redis에 연결하고 큐 처리에 참여합니다.

AI 에이전트 확장

단순 컨테이너화를 넘어서는 다음이 필요합니다:

• 맞춤 메트릭을 활용한 탄력적 스케일링.
• 분산 캐시(예: Redis)를 통한 상태 지속성.
• 요청 배치를 통한 처리량 최적화.

이를 마스터하면 부서지기 쉬운 프로토타입을 견고하고 클라우드‑네이티브 파워하우스로 변환할 수 있습니다.

최신 .NET 관행

• System.Threading.Channels를 활용하여 역압‑인식 큐 구현.
• System.Diagnostics.Metrics를 사용하여 관용적이고 낮은 오버헤드의 텔레메트리 구현.

Source: (keep this line exactly as it appears in the original if present)

토론 질문

1. Throughput vs. latency – 여러분의 경험에 비추어 볼 때, 배치 처리(Throughput)와 실시간 처리(Latency) 사이의 트레이드‑오프가 사용자‑대면 채팅 에이전트에 있어 가치가 있나요, 아니면 저지연을 어떤 대가를 치르더라도 최우선으로 해야 할까요?
2. State persistence – 컨테이너화된 환경에서 현재 상태를 어떻게 관리하고 있나요? 외부 데이터베이스에 의존하고 있나요, 아니면 파드 라이프사이클 내에서 상태를 효과적으로 유지할 방법을 찾으셨나요?

여기서 보여지는 개념과 코드는 전자책 Cloud‑Native AI & Microservices: Containerizing Agents and Scaling Inference (Leanpub)에서 제시한 포괄적인 로드맵을 직접 인용한 것입니다.