https://livekit.io logo
Join Slack
Powered by
- `agent_name`을 명시한 dispatch와 automatic dispatch의...
# ask-ai
s
• `agent_name`을 명시한 dispatch와 automatic dispatch의 routing 차이는 정확히 무엇인가? • accepted job이 새 process에서 돈다면, 한 worker server의 동시 처리 한계는 어떤 기준으로 잡는 것이 좋은가? • `load_fnc`를 CPU 대신 
active_jobs
기반으로 바꾸는 권장 패턴이 있는가? • draining 상태에서 in-flight tool call / speech generation은 어떤 종료 순서를 따라야 하는가? • self-hosted autoscaling에서 scale-out 신호를 job acceptance 이전에 넣으려면 어떤 metric 조합이 가장 안정적인가? • `load_threshold`와 `num_idle_processes`를 함께 설계할 때 권장 값 범위가 있는가?
✅ 1
t
Thanks for reaching out, taeun. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
감사합니다 — 질문하신 각 항목에 대해 요약된 권장사항과 실무 팁을 아래에 정리했습니다. (각 항목에 대해 어떤 부분을 더 깊게 원하시는지 알려주시면 예시 설정이나 코드 스니펫을 추가로 드리겠습니다.) 1) `agent_name`을 명시한 dispatch vs automatic dispatch의 routing 차이 • Automatic dispatch: 방 생성 시 자동으로 에이전트가 배정됨. 특정 이름을 지정하지 않으며, 등록된 에이전트 풀에서 자동 라우팅이 이루어짐. • 
agent_name
명시: 자동 배정이 비활성화되고, 요청에 명시된 `agent_name`과 일치하는 에이전트 인스턴스만 라우팅 대상이 됨. 동일한 이름을 가진 여러 인스턴스가 있으면 그들 사이에서 로드 밸런싱이 발생함. • 요약: 자동은 풀 기반 전체 라우팅, 명시는 이름 기반의 명시적 라우팅(그리고 더 세밀한 제어). 2) accepted job이 새 process에서 돈다면 한 worker server의 동시 처리 한계 기준 • 동시 처리 한계는 CPU·메모리·네트워크, 그리고 각 job의 리소스 프로파일에 따라 결정해야 함. • 실무 권장 기준(일반적 출발점): 4코어/8GB급 머신에서 10~25 동시 세션 범위. (서비스 특성에 맞춰 벤치마크 권장) • 판단 기준: 평균 CPU 이용률, 메모리 사용량, I/O 대기, 그리고 지연(응답시간) SLA를 모니터링해 임계값 도달 시 제한. • 권장 절차: 부하 테스트로 job 유형별 리소스 소비를 측정 → 안전 마진 적용 → `load_fnc`나 active_jobs 기반으로 제어. 3) `load_fnc`를 CPU 대신 
active_jobs
기반으로 바꾸는 권장 패턴 • 간단한 패턴: a. 현재 활성 job 수를 읽어 normalized load(0..1)로 반환. b. 최대 동시 job 수 N을 정하고 load = min(active_jobs / N, 1.0). c. `load_threshold`를 그에 맞춰 설정(예: N이 10이면 threshold 0.9 → 9 jobs 허용). • 장점: 예측 가능한 동시성 제어, CPU 스파이크에 덜 민감. • 보완: 일부 job이 고비용일 수 있으니 active_jobs 외에 가중치(예: job.type별 weight)를 두어 계산할 수 있음. 4) draining 상태에서 in-flight tool call / speech generation의 종료 순서 • 권장 종료 흐름: a. draining 진입 → 새 job 수락 중지(WS_FULL 등 상태 전환). b. 기존 in-flight job은 
drain_timeout
내에 정상 완료 대기. c. job 내부의 tool call / TTS/STT는 정상 종료를 우선 시도(플레이아웃·저장 등 정리). d. 
drain_timeout
초과 시 강제 종료(타임아웃 후 cleanup). • 구현 팁: 드레인 시점에 각 job의 cleanup/interrupt 핸들러를 호출하고, 장기 작업(예: 대용량 음성 합성)은 체크포인트/부분 완료 정책을 갖추는 것이 안전. 5) self-hosted autoscaling에서 scale-out 신호를 job acceptance 이전에 넣으려면 어떤 metric 조합이 안정적인가 • 추천 조합: ◦ 기본: 
load_fnc
기반 metric (active_jobs 또는 CPU) + trend(최근 N초간 증가율). ◦ 안전 장치: queue length (대기중인 job 수) + 평균 job 수락 레이트 증가. ◦ 설정 원칙: scale-up 트리거는 `load_threshold`보다 낮은 선에서 작동하도록(예: threshold=0.7이면 scale-up 트리거 0.5) — 인스턴스가 준비되도록 여유 확보. ◦ cooldown과 provisioning 지연 고려: 짧은 cooldown으로 빠른 확장, 축소는 드레인 타임을 반영해 더 긴 cooldown. 6) `load_threshold`와 `num_idle_processes`를 함께 설계할 때 권장 값 범위 • 기본 가이드라인: ◦ `load_threshold`: 일반적으로 0.7(70%)를 출발점으로, active_jobs 기반이면 0.8~0.9로 높여 동시성 활용을 늘릴 수 있음. ◦ `num_idle_processes`: 1~3 정도를 권장(스파이크 시 스타트업 레이턴시를 줄이기 위함). 대형 배포는 더 높게 설정 가능. • 조합 예시: ◦ 빠른 응답 우선: load_threshold = 0.7, num_idle_processes = 2 ◦ 높은 자원 효율 우선: load_threshold = 0.9, num_idle_processes = 1 • 테스트 권장: 실제 트래픽 패턴으로 A/B 테스트하여 latency·cost·error rate 관찰 후 조정. 원하시면 다음 중 어떤 추가 정보를 드릴까요? • 현재 환경(머신 스펙, 평균 job 프로파일)을 알려주시면 권장 N값 및 예시 
load_fnc
코드를 제안드리겠습니다. • 드레인/오토스케일링에 대한 구체적 config 예시(yaml/code) 필요하시면 제공해드리겠습니다. Sources: Agent dispatch | LiveKit Documentation | Voice Agent Architecture: STT, LLM, and TTS Pipelines Explained | LiveKit | Self-hosted deployments | LiveKit Documentation | Server options | LiveKit Documentation | Deployment reliability on LiveKit Cloud | LiveKit, with interactive elements
s
load_threshold
가 0.7이 넘으면, Task 가 새롭게 할당되어서, EC2라던지 healthy status가 되기 전까지는, call은 queue 상태에 머물게 되는건가 아니면 시도를 하고 fail을 하게 되는건가?
t
좋은 질문입니다 — `load_threshold`가 임계값(예: 0.7)을 초과했을 때 새로 들어오는 Task의 처리 방식에 대해 답변드립니다. • 기본 동작: worker가 현재 부하(=
load_fnc
반환값)가 `load_threshold`를 넘으면 그 worker는 새로운 job을 수락하지 않습니다. 따라서 해당 worker로 라우팅된 job은 즉시 실패하지 않고, 라우팅 레이어(또는 클라이언트 측)에서 대기(큐) 상태가 되어 다른 수락 가능한 인스턴스가 있거나 스케일아웃으로 새 인스턴스가 준비될 때까지 대기합니다. • 스케일링/프로비저닝 지연 중: 새 인스턴스가 프로비저닝되어 healthy 상태가 되기 전까지는 해당 job들이 큐에 머무르는 것이 권장된 흐름입니다. 즉시 시도하여 실패하는 동작은 표준 동작이 아닙니다. • 예외/주의사항: ◦ 라우팅 로직이나 클라이언트 구현에 따라 큐잉 대신 재시도/타임아웃 정책을 잘 설정해야 합니다(예: 대기 한계, 재시도 간격). ◦ autoscaler가 충분히 빠르게 scale-out 하지 않거나 큐 길이가 길어지면 타임아웃/실패가 발생할 수 있으므로, 앞서 권장한대로 scale-up 트리거를 `load_threshold`보다 낮게 두고 `num_idle_processes`를 유지하는 것이 안전합니다. 원하시면 현재 설정(autoscale 임계값·timeout·재시도 정책)을 공유해 주시면, 해당 환경에 맞춘 권장 큐·타임아웃 값과 구성 예시를 제안드리겠습니다. , with interactive elements
s
• 현재 환경(머신 스펙, 평균 job 프로파일)을 알려주시면 권장 N값 및 예시 
load_fnc
코드를 제안드리겠습니다. • 드레인/오토스케일링에 대한 구체적 config 예시(yaml/code) 필요하시면 제공해드리겠습니다. algorithmic solution
t
아래에 알고리즘적 솔루션(권장 N값 산정 방법, 
load_fnc
예시 코드, 드레인·오토스케일링 샘플 YAML)을 간결히 제시합니다. (공유하신 머신 스펙·job 프로파일에 맞춰 값 조정 가능하니 원하시면 스펙 알려주세요.) 1) 권장 N값 산정 알고리즘 (동시 job 최대치 N) • 입력: CPU 코어 수 C, 메모리 M(GB), job 평균 CPU 비율 c_mean, job 평균 메모리 m_mean, 안전계수 S(권장 0.7~0.9) • 계산: ◦ N_cpu = floor((C * S) / c_mean) ◦ N_mem = floor((M * S) / m_mean) ◦ N = max(1, min(N_cpu, N_mem)) • 설명: CPU나 메모리 중 더 제한적인 리소스를 기준으로 N을 정함. I/O나 네트워크가 병목이면 추가적으로 I/O 기반 제한을 고려. 2) 
load_fnc
예시 (Python, active_jobs 기반, job type weight 지원)
Copy code
# 예시: AgentServer 인터페이스가 .active_jobs (list of Job) 를 제공한다고 가정
JOB_TYPE_WEIGHTS = {
    "light": 1.0,
    "medium": 2.5,
    "heavy": 5.0,
}

MAX_CONCURRENCY = N  # 위 산정 알고리즘으로 결정한 값

def compute_load(agent_server) -> float:
    # active_jobs에서 가중치 합 계산
    total_weight = 0.0
    for job in agent_server.active_jobs:
        w = JOB_TYPE_WEIGHTS.get(job.type, 1.0)
        total_weight += w
    normalized = min(total_weight / MAX_CONCURRENCY, 1.0)
    return normalized

# server 설정 예시
server.load_fnc = compute_load
server.load_threshold = 0.9  # 허용 비율 (예: MAX_CONCURRENCY의 90%)
3) 드레인 및 in-flight 종료 알고리즘 (순서) • 목표: 안전한 완료 우선, 장기 작업 강제 타임아웃으로 보호 1. 관리자 signal → worker 상태 = DRAINING; 새 job 수락 차단. 2. 모든 in-flight job에 shutdown_deadline = now + drain_timeout 전파. 3. 각 job: a. 정상 완료 가능한 작업(도구 호출, 음성 합성 등)은 완료 시도. b. 주기적으로 interrupted 플래그 체크; 외부 인터럽트 시 graceful checkpoint/flush 수행. 1. drain_timeout 도달 시 미완료 job은 강제 중단 후 partial result 저장/rollback 수행. 2. 모든 job 종료 후 worker 종료(또는 재시작). 4) self-hosted autoscaling 트리거 알고리즘 (scale-out을 job acceptance 이전에 신호) • 목적: 인스턴스가 준비되기 전에 미리 스케일아웃 시작 • 지표 조합 & 로직: ◦ primary_metric = weighted_load = alpha * normalized_active_jobs + beta * normalized_cpu ▪︎ 권장 가중치: alpha=0.7, beta=0.3 (active_jobs 우선) ◦ trend = derivative(weighted_load) over T seconds (예: T=30s) ◦ queue_len = number of queued jobs awaiting acceptance ◦ scale_up 조건 (발생 즉시 신규 인스턴스 프로비저닝): ▪︎ weighted_load > scale_up_load_threshold OR ▪︎ queue_len >= queue_threshold OR ▪︎ (weighted_load > load_threshold_for_warning AND trend > trend_threshold) ◦ 추천 값 예시: ▪︎ load_threshold = 0.7 (worker 단위 수락 임계) ▪︎ scale_up_load_threshold = 0.5 (클러스터 단위 선행 트리거) ▪︎ queue_threshold = 3 ▪︎ trend_threshold = 0.05 (단위: 정규화된 load 초당 증가) ◦ cooldown/provisioning: ▪︎ scale_up_cooldown = 30s ▪︎ scale_down_cooldown = drain_timeout + 60s 5) 샘플 YAML (autoscaler + worker 설정, 간단화)
Copy code
worker:
  max_concurrency_N: 12    # 산정된 N
  load_threshold: 0.9
  num_idle_processes: 2
  drain_timeout_seconds: 1800  # 30m

autoscaler:
  metrics:
    - name: normalized_active_jobs
    - name: normalized_cpu
    - name: queued_jobs
  weighted_load:
    alpha: 0.7
    beta: 0.3
  thresholds:
    cluster_scale_up: 0.5
    cluster_scale_down: 0.2
    queue_scale_up: 3
  trend:
    window_seconds: 30
    trend_threshold: 0.05
  cooldowns:
    scale_up_seconds: 30
    scale_down_seconds: 2100  # drain_timeout + buffer
6) 운영 권장 체크리스트 (간단) • 먼저 job 프로파일별 CPU/메모리 측정·부하 테스트 수행. • N 산정 후 `load_fnc`와 `load_threshold`로 시뮬레이션(스테이징). • autoscaler 트리거를 load_threshold보다 보수적으로 설정해 프로비저닝 여유 확보. • drain_timeout과 scale-down cooldown을 연동하여 premature termination 방지. 원하시면 귀하의 머신 스펙(C, M), 평균 job별 c_mean/m_mean 또는 샘플 트래픽 패턴(초당 job 수, 평균 처리시간)을 주시면, N 값 계산과 구체적 수치를 반영한 
load_fnc
및 YAML을 바로 맞춤 제안드리겠습니다. , with interactive elements
s
여기서 suggested default ec2 instance type은 무엇을 고르게 될까? top 3, 그리고 1개 best option
t
요청하신 LiveKit 워커용 권장 EC2 인스턴스 타입 — Top 3와 베스트 옵션을 정리해 드립니다. • Best (추천 1): c6i / c7i (Compute-optimized) ◦ 이유: 지속적이고 예측 가능한 CPU 성능 제공. VAD/turn detection/실시간 추론 같은 CPU 집약적 작업에 최적. • 대안 1 (추천 2): m5 / m5.large (General purpose) ◦ 이유: CPU·메모리 균형형으로 안정적 운영에 적합. 버스트형보다 안정적임. • 대안 2 (추천 3): c5 (Compute-optimized) ◦ 이유: 고정된 연산 성능이 필요할 때 비용 대비 성능이 좋은 선택. 피해야 할 타입 • t3 / t4g (burstable): CPU 크레딧 소진 시 스로틀링으로 지연·타임아웃 발생 가능 — 실시간 워커에는 권장하지 않음. 원하시면 귀하의 워크로드(코어/메모리, 평균 job 프로파일)에 맞춰 구체적 인스턴스 사이즈 추천(예: c6i.large vs c6i.xlarge)도 제안드리겠습니다. Sources: LiveKit turn detector plugin | LiveKit Documentation | Troubleshooting Latency and Timeout Errors with Turn Detection on AWS | Self-hosted deployments | LiveKit Documentation, with interactive elements
s
c8i는? 그리고 size suggestion까지 한다면?
t
좋은 요청입니다 — c8i에 대한 적합성과 사이즈 권장안을 근거를 보수적으로 표현해 정리합니다. • c8i 적합성: c8i도 compute‑optimized 계열로 실시간 추론·VAD·turn detection 등 CPU 집약적 워크로드에 적합합니다. 특정 리전과 워크로드에 따라 c8i가 더 높은 단일 스레드 성능을 제공할 수 있으므로, 실제 운영에서는 벤치마크로 확인하는 것을 권장합니다. • 사이즈 권장 (일반 가이드; 실제 권장은 job 프로파일·동시성에 따라 조정) ◦ 소규모 / 개발·저부하: ▪︎ c8i.large (2 vCPU, 4 GiB) — 가벼운 테스트용 ◦ 중간형 / 소형 프로덕션 (권장 시작점): ▪︎ c8i.xlarge (4 vCPU, 8 GiB) — 보편적 출발점 (예: 10~25 동시 세션 기준 시작) ◦ 프로덕션 / 고부하: ▪︎ c8i.2xlarge (8 vCPU, 16 GiB) — 더 많은 동시 세션과 여유 리소스 필요 시 ◦ 대규모 / 매우 높은 동시성: ▪︎ c8i.4xlarge 이상 (16+ vCPU) — 고동시성·저지연 요구가 클 때 원하시면 예상 동시성, 평균 job의 vCPU·메모리 소모, p95 허용 지연을 알려주세요. 해당 값으로 구체적 N(동시 job) 산정과 비용·성능 균형을 반영한 권장 인스턴스 사이즈를 제안드리겠습니다. , with interactive elements
s
평균 job의 vCPU 및 메모리 소모 그리고 p95 trace/log strategy
t
감사합니다 — 적절한 N 산정과 c8i 사이즈 추천을 해드리려면 아래 값을 알려주세요. • 평균 job의 vCPU 사용량 (예: 0.4 vCPU) • 평균 job의 메모리 사용량 (MB 또는 GB) • p95 지연 목표(예: 응답 ≤ 300ms) • 현재 기대 동시접속(초당 도착률 또는 최대 동시 job 수 추정) • (선택) 장기 작업 비율(예: 전체 job 중 heavy 작업 비율) 이 값들 받으면 N 계산, 권장 c8i 사이즈(예: c8i.xlarge/c8i.2xlarge 등)와 예시 `load_fnc`/설정값을 바로 제안드리겠습니다. , with interactive elements
s
how to get these?
t
좋은 질문입니다 — 평균 vCPU/메모리 소모와 p95 지연을 측정하고 추적하는 실무 절차와 도구를 간단히 정리합니다. 1) 준비 • 스테이징 환경: 실제 서비스와 동일한 워크플로( STT/LLM/TTS 파이프라인 )로 구성. • 테스트 시나리오: 정상·heavy·혼합 트래픽 시나리오(초당 도착률, 평균 처리시간)를 정의. 2) vCPU 및 메모리 측정 (per-job) • 방식: ◦ 단일 인스턴스에서 부하 생성기(예: Locust, k6 또는 자체 스크립트)로 동시 N개의 job을 시뮬레이션. ◦ OS 레벨 수집: `top`/`htop`, 
pidstat
, 
ps
또는 `docker stats`로 프로세스별 CPU%와 RSS 메모리 측정. ◦ 샘플링: 1s~5s 간격으로 1~5분간 수집. • 계산: ◦ 평균 vCPU per job = (평균 CPU 사용률(core 단위) / 동시 job 수) ◦ 평균 메모리 per job = (평균 RSS 메모리 / 동시 job 수) • 팁: job 유형별( light/medium/heavy )로 나눠 각각 측정하고 가중 평균 계산. 3) p95 latency 및 트레이스/로그 전략 • 수집 포인트: ◦ 사용자 오디오 송신 완료 → STT first partial → LL M time-to-first-token (TTFT) → TTS time-to-first-audio (TTFB) → 플레이아웃 시작 • 측정 방법: ◦ 애플리케이션 레벨에서 각 단계 진입·종료 타임스탬프 기록(밀리초). ◦ 분산 트레이싱 도구 사용: OpenTelemetry + Jaeger/Zipkin 또는 Datadog/AWS X-Ray. ◦ 메트릭 집계: Prometheus + Grafana 또는 APM에서 p50/p95/p99 집계. • p95 확보: ◦ 로그/트레이스로 각 요청의 전체 경로(trace)와 단계별 latency를 확인해 병목 식별. ◦ 알람: p95 > 목표 임계 시 (예: 300ms) 경고. • 예시 메트릭: ◦ metrics.llm_ttft_ms, metrics.tts_ttfb_ms, metrics.stt_first_partial_ms, metrics.end_to_playout_ms 4) 운영 자동화(단계) • 자동화 스크립트로 부하 테스트(변수: 동시성, 입/출력 길이) 반복 실행. • 각 테스트마다: ◦ CPU/memory 프로파일링 결과 저장(CSV) ◦ 지연 히스토그램 및 p95 계산 • 최종 산출물: job 유형별 평균 vCPU, 평균 메모리, p95 latency 표 5) 간단한 툴/커맨드 예시 • Docker 환경: docker stats --no-stream --format "{{.Name}} {{.CPUPerc}} {{.MemUsage}}" • Linux 프로세스: pidstat -u -r 1 60 (CPU/메모리 1s 샘플 60회) • 수집·전송: OpenTelemetry SDK로 span 생성, Prometheus client로 histogram 관측치 전송 원하시면 귀하의 환경(사용중인 오케스트레이션, 애플리케이션 언어, STT/LLM/TTS 구성)을 알려주시면, 구체적 스크립트(부하 생성기 스크립트, p95 계산용 Prometheus 쿼리, OpenTelemetry span 예시)를 바로 드리겠습니다. Sources: Self-hosted deployments | LiveKit Documentation | Voice Agent Architecture: STT, LLM, and TTS Pipelines Explained | LiveKit | Voice Agent Architecture: STT, LLM, and TTS Pipelines Explained | LiveKit | Troubleshooting Latency and Timeout Errors with Turn Detection on AWS | LiveKit turn detector plugin | LiveKit Documentation, with interactive elements
3 Views
Open in Slack
PreviousNext
Powered by