OpenTelemetry는 로컬 AI 지연 시간을 스토리지 및 네트워크 스팬과 어떻게 연결하나요?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How Does OpenTelemetry Connect Local AI Latency to Storage and Network Spans? - Zima Store Online

OpenTelemetry는 각 작업을 공유 컨텍스트와 일관된 의미 속성을 포함한 시간 측정 스팬으로 표현하여 로컬 AI 지연 시간을 스토리지 및 네트워크 작업과 연결합니다.

집에서 사용하는 AI의 4초 응답 중 토큰 생성에 소요되는 시간은 일부에 불과하고, 나머지는 벡터 검색, 파일 시스템 또는 데이터베이스 읽기, 대기열 대기, HTTP 호출, 도구 실행 과정에서 사라질 수 있습니다. OpenTelemetry 자체가 이러한 종속 요소를 더 빠르게 만들어 주는 것은 아닙니다. 대신 호환 가능한 텔레메트리를 제공하여 하나의 요청을 실제 벽시계 시간(wall-clock time)을 소비한 계층별로 분해할 수 있게 합니다.

의미 규약은 서로 다른 서비스에 비교 가능한 어휘를 제공합니다

모든 서비스가 자체 스팬 이름과 속성 키를 만들면 동일한 작업이 모델 서버, 데이터베이스 클라이언트, 도구 게이트웨이에서 서로 관련 없는 작업처럼 보일 수 있어 트레이스를 조회하기가 어려워집니다. 의미 규약은 반복적으로 발생하는 작업 유형에 공통 이름과 속성을 정의하여 이러한 모호함을 줄입니다.

일관된 어휘를 사용하면 먼저 각 라이브러리의 비공개 스키마를 정규화하지 않고도 지연 시간을 분석하고 작업을 비교할 수 있습니다. 공유 의미 어휘를 사용하면 각 라이브러리의 비공개 필드 이름을 먼저 변환하지 않아도 서로 다른 구성 요소의 스팬을 더 쉽게 집계하고 해석할 수 있습니다.

로컬 AI 스택에서 중요한 결과는 모든 것을 하나로 합치는 것이 아니라 분리하는 것입니다. 모델 생성은 모델 작업으로, 데이터베이스 쿼리는 스토리지 작업으로, HTTP 호출은 네트워크 종속 요소로 남아야 하며, 이 세 작업이 하나의 트레이스에 함께 나타나더라도 각각의 성격은 유지되어야 합니다.

GenAI 스팬은 모델 작업을 에이전트 및 도구 작업과 분리합니다

모델 호출, 에이전트 실행, 도구 실행은 동일한 요청에 기여하면서도 지연 시간과 리소스 사용 양상이 서로 다를 수 있습니다. 따라서 전체 체인을 하나의 일반적인 ‘AI’ 스팬으로 처리하면 실제로 어디에 시간이 사용되었는지 파악하기 어렵습니다. GenAI 전용 계측은 각 단계를 구분하는 작업 수준의 필드를 제공합니다.

GenAI 작업 및 도구 활동에 관한 발전 중인 규약은 모델 및 에이전트 워크플로의 텔레메트리를 표준화하면서도 애플리케이션이 자체 통합 스팬을 추가할 수 있도록 합니다.

이러한 구분은 홈 서버에서 특히 중요합니다. 빠른 로컬 모델도 느린 검색이나 원격 도구 호출 뒤에 위치할 수 있기 때문입니다. 트레이스는 모델에 소요된 시간을 모델에 귀속하고, 오케스트레이션 지연은 이를 만든 계층에 귀속해야 합니다.

GenAI 영역의 일부 규약은 아직 발전 중이므로 구현 시 스키마 버전을 기록하고 모든 라이브러리가 동일한 속성을 자동으로 생성한다고 가정하지 않아야 합니다.

데이터베이스 및 스토리지 스팬은 검색 및 I/O 대기를 드러냅니다

비공개 RAG와 홈 자동화는 모델이 답변하기 전에 벡터 스토어, SQL 데이터베이스, 메타데이터 카탈로그 또는 파일 시스템 기반 서비스를 자주 이용합니다. 추론이 빠르더라도 이러한 작업이 지연 시간의 대부분을 차지할 수 있습니다. 이를 별도의 스팬으로 계측하면 넓은 에이전트 작업 안에서 스토리지 시간이 사라지는 것을 방지할 수 있습니다.

데이터베이스 트레이싱은 전체 비공개 문서를 텔레메트리에 넣지 않고도 작업 시간, 대상 시스템, 비식별화된 쿼리 메타데이터를 보여줄 수 있습니다. 데이터베이스 호출을 스팬으로 표현하면 SQL 및 NoSQL 작업이 자체 시간 정보와 제한된 작업 메타데이터를 전달하므로 에이전트 전체 타이머 안에서 사라지지 않습니다.

홈 지식 베이스에서 긴 검색 스팬은 모델 생성이 아니라 디스크 경합, 인덱스 작업, 느린 원격 NAS 마운트 또는 데이터베이스 대기열 때문일 수 있습니다. 이는 최종 API 응답만 측정하는 것보다 더 정확한 진단을 가능하게 합니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

클라이언트 및 서버 스팬은 네트워크 종속 요소의 범위를 정합니다

네트워크 지연은 일반적으로 하나의 보편적인 ‘네트워크 지연 시간’ 스팬이 아니라 클라이언트-서버 작업의 일부로 나타납니다. 따라서 유용한 비교 대상은 호출자가 기다린 시간과 수신자가 처리한 시간입니다. 서로 대응하는 스팬을 사용하면 요청이 서버에 도착하기 전에 시간이 누적되었는지, 서버 내부에서 발생했는지, 응답이 서버를 떠난 후 발생했는지를 확인할 수 있습니다.

분산 트레이싱 지침은 계측과 컨텍스트 전파를 통해 서비스 간 요청 경로를 재구성하는 과정의 일부로 클라이언트 및 서버 스팬 관계를 설명합니다.

이는 MCP 또는 HTTP 도구에서 특히 유용합니다. 클라이언트 스팬은 긴데 하위 서비스의 처리 스팬은 훨씬 짧다면 서비스 주변의 전송, 프록시, 연결 설정 또는 대기열을 의심할 수 있습니다. 반대로 서버 스팬이 길다면 해당 종속 요소 자체의 작업에 주의를 기울여야 합니다.

ZimaSpace의 MCP 도구 지연 시간 분석은 가능한 지연 계층을 설명합니다. OpenTelemetry 트레이싱은 실제 실행 하나에서 어느 계층이 가장 큰 비중을 차지했는지 요청별 증거를 제공합니다.

메트릭은 느려진 요청 집단을 가리키고, 트레이스는 하나의 사례를 설명합니다

집계된 지연 시간 메트릭은 서비스가 전반적으로 느려지고 있는지 알려주는 반면, 트레이스는 특정 대표 요청에 지연이 어떻게 누적되었는지 설명합니다. p95 급증을 추가적인 집계 차트가 아니라 구체적인 요청 경로로 분석해야 할 때 두 관점을 연계하면 유용합니다.

엑셈플러와 트레이스에서 파생된 메트릭은 분포를 개별 요청의 증거와 연결할 수 있습니다. 엑셈플러를 사용하면 모든 요청 속성을 메트릭 레이블로 변환하지 않고도 집계된 지연 시간 분포를 대표 요청 트레이스와 연결할 수 있습니다.

따라서 홈 서버는 검색 또는 도구 호출 지연 시간 증가를 기준으로 알림을 보내고, 동일한 요청의 모델, 스토리지, 네트워크 스팬을 포함한 대표 트레이스를 확인할 수 있습니다.

비공개 콘텐츠가 디버깅 데이터가 되기 전에 유용한 텔레메트리를 멈춰야 합니다

속성을 추가하면 진단 기능이 향상될 수 있지만, 텔레메트리 자체에 파일 이름, 프롬프트, 문서 발췌문, 가구 구성원의 신원 정보 또는 제한 없는 고카디널리티 값이 포함되기 시작하면 문제가 됩니다. 비공개 AI 스택에는 느린 작업을 식별할 수 있을 만큼의 컨텍스트가 필요하지만, 해당 작업이 처리한 민감한 콘텐츠까지 복사해서는 안 됩니다.

AI 관측성에는 의도적인 계측 경계가 필요합니다. 텔레메트리 구조와 모델 품질 평가는 서로 다른 문제를 해결하기 때문입니다. 텔레메트리와 평가를 분리하면 민감한 프롬프트 콘텐츠가 일상적인 성능 메타데이터가 되는 것을 방지할 수 있습니다.

샘플링, 내보내기 양, 속성 선택에도 오버헤드가 발생하므로 가능한 모든 스팬을 영구적으로 보존하는 것이 목표는 아닙니다. 유용한 지점은 모델, 검색, 스토리지, 네트워크 지연을 구분할 수 있을 만큼 상세하면서도 홈 관측성 서버에 안전하게 보관할 수 있는 트레이스를 확보하는 것입니다.

카디널리티도 또 다른 보존 경계입니다. 제한된 수의 속성만으로도 그룹화와 필터링을 지원할 수 있지만, 고유한 프롬프트 텍스트, 전체 경로, 문서 본문 또는 요청별 식별자를 메트릭 레이블에 복사하면 해당 값이 민감하지 않더라도 관측성 스토리지가 비싸지고 조회하기 어려워질 수 있습니다.