분산 추적은 셀프 호스팅 서비스 전반에서 하나의 AI 요청을 어떻게 추적할까요?

분산 추적은 서비스 경계를 넘어 공유된 트레이스 식별자를 전달하고, 참여한 각 작업을 인과 관계가 있는 스팬으로 기록하여 하나의 AI 요청을 추적합니다.

셀프 호스팅 AI 요청은 사용자가 응답을 보기 전에 리버스 프록시, 에이전트 서비스, 벡터 저장소, 모델 런타임, 작업 큐, 스토리지 서비스, 도구 엔드포인트를 차례로 거칠 수 있습니다. 이러한 구성 요소는 서로 다른 컨테이너나 머신에서 실행되며 독립적인 로그를 기록할 수 있으므로, 타임스탬프가 비슷하다는 사실만으로 어떤 작업이 하나의 요청에 속하는지 증명할 수 없습니다. 분산 추적을 사용하면 나중에 추측으로 요청을 재구성하는 대신 작업과 함께 요청 식별자가 전달됩니다.

트레이스는 전체 요청에 하나의 공유 식별자를 부여합니다

트레이스는 전체 요청 경로를 나타내고, 각 스팬은 검색, 재순위화, 모델 추론, 도구 호출 또는 응답 직렬화와 같은 제한된 작업을 기록합니다. 이러한 스팬이 하나의 트레이스 식별자를 공유하면, 백엔드는 시간상 가까운 이벤트가 인과적으로 연결되어 있다고 가정하지 않고도 서로 다른 서비스에서 수행된 작업을 하나로 묶을 수 있습니다.

따라서 유용한 단위는 단순한 시간 목록이 아니라 연결된 요청 트리입니다. 하나의 트레이스 ID가 서비스 경계를 넘으면 여러 프로세스에서 수행된 시간 기록을 서로 단절된 로그 레코드가 아니라 하나의 요청으로 재구성할 수 있습니다.

홈 AI 스택에서는 사용자에게 노출된 API에서 루트 스팬이 시작되어 검색, 권한 확인, 모델 작업, 도구 호출로 분기될 수 있습니다. 트레이스는 요청이 느린 이유를 묻기 전에 어떤 작업이 이 요청에 속했는지 알려 줍니다.

모든 서비스 경계에서 컨텍스트를 주입하고 추출해야 합니다

트레이스 연속성은 각 호출자가 현재 컨텍스트를 외부로 전달되는 매체에 주입하고, 각 수신자가 자체 스팬을 만들기 전에 해당 컨텍스트를 추출할 때 유지됩니다. 프록시, 클라이언트 라이브러리 또는 서비스 하나라도 대신 새 트레이스를 시작하면, 실제 요청은 정상적으로 처리되더라도 종단 간 경로가 끊깁니다.

전파 메커니즘은 사용자의 비즈니스 페이로드가 아니라 식별자와 샘플링 상태를 전달합니다. 주입 및 추출 과정을 통해 서로 다른 서비스가 프로세스와 네트워크 경계를 넘는 작업에서도 동일한 요청 식별자를 유지할 수 있습니다.

이는 혼합형 셀프 호스팅 스택에서 중요합니다. 전파 형식이 상호 운용 가능하다면 리버스 프록시, Python 에이전트, 벡터 데이터베이스, Rust 또는 Go 기반 도구 서비스가 하나의 추적 라이브러리를 사용할 필요는 없습니다.

따라서 전파 누락은 다운스트림 서비스가 독립적으로 실행되었다는 증거가 아니라 데이터 품질 문제입니다. 끊어진 트레이스는 식별자가 사라진 경계에서 진단해야 합니다.

부모-자식 관계와 스팬 링크는 서로 다른 인과 구조를 보존합니다

직접적인 동기식 작업은 일반적으로 한 작업이 다음 작업을 시작하고 완료를 기다리므로 부모-자식 체인을 형성합니다. 반면 팬아웃 및 비동기 워크플로는 더 복잡한 관계를 가질 수 있습니다. 트레이스 모델은 모든 다운스트림 작업을 하나의 인위적인 호출 스택에 억지로 넣지 않고 인과 관계를 보존해야 합니다.

서비스 호출이 직접 중첩되는 경우에는 부모-자식 관계가 유용하지만, 비계층적 관계를 위한 스팬 링크를 사용하면 이전 작업에 의해 시작되었지만 하나의 활성 부모 아래에 깔끔하게 중첩되지 않는 작업도 연결할 수 있습니다.

홈 AI 요청은 검색과 권한 확인을 병렬로 시작한 다음 두 작업이 모두 끝날 때까지 기다렸다가 모델 생성을 수행할 수 있습니다. 트레이스는 먼저 시작된 스팬이 다른 작업을 유발한 것처럼 잘못 나타내는 대신 이러한 병렬 구조를 보존해야 합니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

메시지와 함께 컨텍스트가 전달될 때만 큐를 통해 요청을 추적할 수 있습니다

비동기 큐는 프로세스 내부의 직접적인 호출 스택을 끊지만, 트레이스 컨텍스트를 메시지 메타데이터에 저장하면 큐에 들어간 작업을 원래 요청과 계속 연결할 수 있습니다. 그러면 소비자는 나중에 처리를 시작할 때 해당 컨텍스트를 사용해 다음 스팬을 만들거나 명시적인 링크를 생성합니다.

홈 서버가 OCR, 임베딩, 카메라 분석 또는 알림 작업을 대화형 요청 경로에서 의도적으로 분리할 때 이러한 차이가 중요해집니다. 메시지 버스 인계 시 명시적인 전파를 사용하면 스레드 로컬 상태와 직접적인 호출 스택이 더 이상 유지되지 않더라도 트레이스 식별자를 보존할 수 있습니다.

기존 ZimaSpace의 홈 AI 작업 큐 분리 설명에서는 비동기 작업을 운영 측면에서 격리해야 하는 이유를 다룹니다. 분산 추적은 격리된 작업을 해당 작업을 발생시킨 요청과 계속 연결하는 식별자를 제공합니다.

이 식별자가 없으면 느린 백그라운드 단계가 관련 없는 작업처럼 보일 수 있으며, 운영자는 사용자의 요청이 실제로 이어진 지점을 놓칠 수 있습니다.

재구성된 트레이스는 핵심 경로와 누락된 구간을 드러냅니다

스팬이 추적 백엔드에 도착하면 식별자, 타임스탬프, 부모 관계, 상태, 서비스 메타데이터를 조합해 종단 간 요청 화면을 구성할 수 있습니다. 병렬 작업은 서로 겹쳐 실행될 수 있으므로 가장 긴 스팬이 사용자에게 보이는 지연의 원인이라고 단정할 수 없습니다. 중요한 질문은 어떤 의존성 체인이 완료 시점을 결정하는가입니다.

컨텍스트 전파가 누락되면 트레이스가 서로 단절되므로, 깔끔한 워터폴은 이를 생성한 계측만큼만 완전합니다.

샘플링은 또 다른 경계를 만듭니다. 샘플링되지 않은 요청은 나중에 전체 스팬 증거를 제공할 수 없고, 부분적으로만 계측된 서비스는 유효한 트레이스 안에 시야가 가려진 구간을 남길 수 있습니다. 따라서 분산 추적은 인과 관계를 파악하는 데 도움을 주지만, 기록되지 않은 작업에 대한 텔레메트리를 새로 만들어 주지는 않습니다.

모든 서비스 로그를 하나의 데이터베이스에 저장하거나 시간 정보만으로 인과 관계를 증명하려 하지 않고도, 하나의 사용자 요청을 실제 셀프 호스팅 경로를 따라 추적할 수 있다면 이 메커니즘은 성공적으로 작동하는 것입니다.