LangSmith 데이터 플레인

LangSmith 데이터 플레인

데이터 플레인은 Agent Server(배포), 지원 인프라, 그리고 LangSmith 컨트롤 플레인에서 업데이트를 지속적으로 폴링하는 "리스너(listener)" 애플리케이션으로 구성돼요.

출처: 문서

본문

서버 인프라

Agent Server 자체 외에, 각 서버에 대한 다음 인프라 구성 요소도 "데이터 플레인"의 넓은 정의에 포함돼요:

• PostgreSQL: 사용자, 런 및 메모리 데이터를 위한 영속성 계층.
• Redis: 워커를 위한 통신 및 임시 메타데이터.
• 시크릿 스토어 (Secrets store): 환경 시크릿의 안전한 관리.
• 오토스케일러 (Autoscalers): 로드에 따라 서버 컨테이너 확장.

"리스너" 애플리케이션

데이터 플레인 "리스너" 애플리케이션은 주기적으로 컨트롤 플레인 API를 호출해 다음을 수행해요:

• 새 배포를 만들어야 하는지 결정.
• 기존 배포를 업데이트해야 하는지(즉, 새 리비전) 결정.
• 기존 배포를 삭제해야 하는지 결정.

즉, 데이터 플레인 "리스너"는 컨트롤 플레인의 최신 상태(원하는 상태)를 읽고, 대기 중인 배포(현재 상태)를 조정해 최신 상태와 일치시키는 조치를 취해요.

PostgreSQL

PostgreSQL은 서버 리소스(스레드, 런, 어시스턴트, 크론)와 장기 메모리 스토어에 저장된 항목을 저장해요. 또한 체크포인트(그래프 실행 상태)의 기본 백엔드이기도 해요. 선택적으로 체크포인트를 MongoDB에 저장할 수 있어요—체크포인터 백엔드 구성을 참고하세요. 체크포인터 백엔드와 관계없이 PostgreSQL은 항상 필요해요.

Redis

Redis는 각 Agent Server에서 서버와 큐 워커가 통신하는 수단이자 임시 메타데이터를 저장하는 데 사용돼요. Redis에는 사용자 또는 런 데이터가 저장되지 않아요.

통신

Agent Server의 모든 런은 각 배포의 일부인 백그라운드 워커 풀에 의해 실행돼요. 해당 런에 대해 일부 기능(취소 및 출력 스트리밍 같은)을 활성화하려면 특정 런을 처리하는 서버와 워커 사이의 양방향 통신 채널이 필요해요. 이 통신을 구성하는 데 Redis를 사용해요.

1. 새 런이 생성되는 즉시 워커를 깨우는 메커니즘으로 Redis 리스트가 사용돼요. 이 리스트에는 센티널 값만 저장되며 실제 런 정보는 없어요. 런 정보는 워커가 PostgreSQL에서 검색해요.
2. 서버가 적절한 워커에 런 취소 요청을 전달하기 위해 Redis 문자열과 Redis PubSub 채널의 조합이 사용돼요.
3. 런을 처리하는 동안 에이전트의 스트리밍 출력을 브로드캐스트하기 위해 워커가 Redis PubSub 채널을 사용해요. 서버의 열려 있는 /stream 요청은 해당 채널을 구독하고 이벤트가 도착하면 응답으로 전달해요. 어떤 이벤트도 어느 시점에 Redis에 저장되지 않아요.

임시 메타데이터

Agent Server의 런은 특정 실패(현재는 런 중 발생하는 일시적인 PostgreSQL 오류만)에 대해 재시도될 수 있어요. 재시도 횟수를 제한하기 위해(현재 런당 3회 시도로 제한) 가져올 때 Redis 문자열에 시도 횟수를 기록해요. 여기에는 ID 외에 런별 정보가 없으며 짧은 지연 후 만료돼요.

데이터 플레인 기능

이 섹션에서는 데이터 플레인의 다양한 기능을 설명해요. 플랫폼별 동작은 Cloud 플랫폼 기능 또는 셀프 호스팅 배포를 참고하세요.

자동 확장 (Autoscaling)

전용(Dedicated) 유형 배포는 컨테이너를 자동으로 확장해요. 확장은 3가지 지표를 기반으로 해요:

1. CPU 사용률
2. 메모리 사용률
3. 대기(진행 중) 런 수

CPU 사용률의 경우 오토스케일러는 75% 사용률을 목표로 해요. 이는 CPU 사용률이 75%이거나 그 근처가 되도록 오토스케일러가 컨테이너 수를 늘리거나 줄인다는 뜻이에요. 메모리 사용률의 경우에도 오토스케일러는 75% 사용률을 목표로 해요.

대기 런 수의 경우 오토스케일러는 대기 런 10개를 목표로 해요. 예를 들어 현재 컨테이너 수가 1개이고 대기 런 수가 20개라면, 오토스케일러는 배포를 2개 컨테이너로 확장해요 (대기 런 20개 / 컨테이너 2개 = 컨테이너당 대기 런 10개).

각 지표는 독립적으로 계산되며, 오토스케일러는 가장 많은 컨테이너 수를 만드는 지표를 기반으로 확장 동작을 결정해요.

이러한 지표가 모든 컨테이너 유형에 적용되지는 않아요. 큐 워커는 대기 런 수에 따라 확장돼요—백로그가 커지면 이를 소진하기 위해 더 많은 워커가 생성돼요. API 서버는 CPU와 메모리에 따라 확장되며 클라이언트 요청 볼륨에 반응해요. 이는 런 제출이 급증해도 스레드 상태 가져오기 같은 읽기 작업이 느려지지 않는다는 뜻이에요. 셀프 호스팅 구성 세부 사항은 확장을 위한 Agent Server 구성을 참고하세요.

축소 동작은 어떤 조치를 취하기 전에 30분 동안 지연돼요. 즉, 오토스케일러가 배포를 축소하기로 결정하면 먼저 30분을 기다린 후 축소해요. 30분 후 지표를 다시 계산하고, 다시 계산된 지표가 현재 컨테이너 수보다 낮은 수를 만든다면 배포를 축소해요. 그렇지 않으면 배포는 확장된 상태로 유지돼요. 이 "쿨다운" 기간은 배포가 너무 자주 확장/축소되지 않도록 보장해요.

MongoDB 체크포인팅

Cloud(외부 관리 MongoDB 인스턴스 포함) 및 Standalone 배포에서 사용 가능해요.

체크포인트 저장을 위한 대체 백엔드로 MongoDB를 사용할 수 있어요. 구성되면 MongoDB는 체크포인트 데이터만 처리해요—다른 모든 서버 리소스에는 PostgreSQL이 계속 필요해요.

설정 지침은 체크포인터 백엔드 구성을 참고하세요.

LangSmith 추적

Agent Server는 자동으로 LangSmith에 트레이스를 보내도록 구성돼요. 각 배포 옵션에 대한 자세한 내용은 아래 표를 참고하세요.

텔레메트리

Agent Server는 자동으로 과금 목적의 텔레메트리 메타데이터를 보고하도록 구성돼요. 각 배포 옵션에 대한 자세한 내용은 아래 표를 참고하세요.

라이선싱

Agent Server는 자동으로 라이선스 키 검증을 수행하도록 구성돼요. 각 배포 옵션에 대한 자세한 내용은 아래 표를 참고하세요.

더 알아보기 (Learn more)

• Agent Server
• 컨트롤 플레인
• 체크포인터 백엔드 구성
• Cloud 플랫폼 기능