자체 호스팅 LangSmith 인스턴스는 대량의 trace와 사용자를 처리할 수 있습니다. 자체 호스팅 배포의 기본 구성은 상당한 부하를 처리할 수 있으며, 더 높은 확장성을 달성하기 위해 배포를 구성할 수 있습니다. 이 페이지에서는 확장 고려 사항을 설명하고 자체 호스팅 인스턴스를 구성하는 데 도움이 되는 몇 가지 예제를 제공합니다. 예제 구성은 확장을 위한 LangSmith 구성 예제를 참조하세요.

​
요약

아래 표는 다양한 부하 패턴(읽기 / 쓰기)에 대한 여러 LangSmith 구성을 비교한 개요를 제공합니다:
낮음 / 낮음낮음 / 높음높음 / 낮음중간 / 중간높음 / 높음
55502050
101000101001000
Frontend replica1 (기본값)4224
Platform backend replica3 (기본값)203 (기본값)3 (기본값)20
Queue replica3 (기본값)160610160
Backend replica2 (기본값)5401650
Redis 리소스8 Gi (기본값)200 Gi external8 Gi (기본값)13Gi external200 Gi external
ClickHouse 리소스4 CPU
16 Gi (기본값)		10 CPU
32Gi memory		8 CPU
16 Gi per replica		16 CPU
24Gi memory		14 CPU
24 Gi per replica
ClickHouse 설정Single instanceSingle instance3-node Single instance3-node
2 CPU
8 GB memory
10GB storage (external)		2 CPU
8 GB memory
10GB storage (external)		2 CPU
8 GB memory
10GB storage (external)		2 CPU
8 GB memory
10GB storage (external)		2 CPU
8 GB memory
10GB storage (external)
Blob storageDisabledEnabledEnabledEnabledEnabled
아래에서는 읽기 및 쓰기 경로에 대한 자세한 내용을 설명하고 자체 호스팅 LangSmith 인스턴스를 시작하기 위한 values.yaml 스니펫을 제공합니다.

​
Trace 수집 (쓰기 경로)

쓰기 경로에 부하를 주는 일반적인 사용:
  • Python 또는 JavaScript LangSmith SDK를 통한 trace 수집
  • @traceable wrapper를 통한 trace 수집
  • /runs/multipart endpoint를 통한 trace 제출
trace 수집에서 중요한 역할을 하는 서비스:
  • Platform backend service: trace 수집을 위한 초기 요청을 받고 trace를 Redis queue에 배치
  • Redis cache: 지속되어야 하는 trace를 queue에 저장하는 데 사용
  • Queue service: 쿼리를 위해 trace를 지속
  • ClickHouse: trace에 사용되는 영구 저장소
쓰기 경로(trace 수집)를 확장할 때 위에 나열된 네 가지 서비스/리소스를 모니터링하는 것이 도움이 됩니다. 다음은 trace 수집 성능을 향상시킬 수 있는 일반적인 변경 사항입니다:
  • ClickHouse가 리소스 한계에 도달하는 경우 더 많은 리소스(CPU 및 메모리)를 제공합니다.
  • 수집 요청이 응답하는 데 오래 걸리는 경우 platform-backend pod 수를 늘립니다.
  • trace가 Redis에서 충분히 빠르게 처리되지 않는 경우 queue service pod replica를 늘립니다.
  • 현재 Redis 인스턴스가 리소스 한계에 도달하는 것을 발견하면 더 큰 Redis cache를 사용합니다. 이것은 수집 요청이 오래 걸리는 이유일 수도 있습니다.

​
Trace 쿼리 (읽기 경로)

읽기 경로에 부하를 주는 일반적인 사용:
  • 프론트엔드에서 tracing project 또는 개별 trace를 보는 사용자
  • trace 정보를 쿼리하는 데 사용되는 스크립트
  • /runs/query 또는 /runs/<run-id> api endpoint 호출
trace 쿼리에서 중요한 역할을 하는 서비스:
  • Backend service: 요청을 받고 ClickHouse에 쿼리를 제출한 다음 요청에 응답
  • ClickHouse: trace를 위한 영구 저장소. trace 정보를 요청할 때 쿼리되는 주요 데이터베이스입니다.
읽기 경로(trace 쿼리)를 확장할 때 위에 나열된 두 가지 서비스/리소스를 모니터링하는 것이 도움이 됩니다. 다음은 trace 쿼리 성능을 향상시킬 수 있는 일반적인 변경 사항입니다:
  • backend service pod 수를 늘립니다. backend service pod가 1 core CPU 사용량에 도달하는 경우 가장 효과적입니다.
  • ClickHouse에 더 많은 리소스(CPU 또는 메모리)를 제공합니다. ClickHouse는 매우 리소스 집약적일 수 있지만 더 나은 성능으로 이어질 것입니다.
  • replicated ClickHouse cluster로 이동합니다. ClickHouse replica를 추가하면 읽기 성능에 도움이 되지만 5개 미만의 replica를 유지하는 것을 권장합니다(3개로 시작).
이것이 helm chart 값으로 어떻게 변환되는지에 대한 보다 정확한 지침은 다음 섹션의 예제를 참조하세요. LangSmith 인스턴스가 특정 부하 패턴을 처리할 수 없는 이유를 확실하지 않은 경우 LangChain 팀에 문의하세요.

​
확장을 위한 LangSmith 구성 예제

아래에서는 예상되는 읽기 및 쓰기 부하를 기반으로 한 몇 가지 LangSmith 구성 예제를 제공합니다. 읽기 부하(trace 쿼리)의 경우:
  • 낮음은 대략 5명의 사용자가 동시에 trace를 보는 것을 의미합니다(초당 약 10개의 요청)
  • 중간은 대략 20명의 사용자가 동시에 trace를 보는 것을 의미합니다(초당 약 40개의 요청)
  • 높음은 대략 50명의 사용자가 동시에 trace를 보는 것을 의미합니다(초당 약 100개의 요청)
쓰기 부하(trace 수집)의 경우:
  • 낮음은 초당 최대 10개의 trace가 제출되는 것을 의미합니다
  • 중간은 초당 최대 100개의 trace가 제출되는 것을 의미합니다
  • 높음은 초당 최대 1000개의 trace가 제출되는 것을 의미합니다
정확한 최적 구성은 사용량과 trace payload에 따라 다릅니다. 위의 정보와 특정 사용량을 결합하여 아래 예제를 사용하여 적합하다고 판단되는 대로 LangSmith 구성을 업데이트하세요. 질문이 있으시면 LangChain 팀에 문의하세요.

​
낮은 읽기, 낮은 쓰기

기본 LangSmith 구성이 이 부하를 처리합니다. 여기서는 사용자 정의 리소스 구성이 필요하지 않습니다.

​
낮은 읽기, 높은 쓰기

매우 높은 규모의 trace 수집이 있지만 프론트엔드에서 trace를 쿼리하는 사용자는 한 자릿수입니다. 이를 위해 다음과 같은 구성을 권장합니다: 
config:
  blobStorage:
    # Please also set the other keys to connect to your blob storage. See configuration section.
    enabled: true
  settings:
    redisRunsExpirySeconds: "3600"
# ttl:
#   enabled: true
#   ttl_period_seconds:
#     longlived: "7776000"  # 90 days (default is 400 days)
#     shortlived: "604800"  # 7 days (default is 14 days)

frontend:
  deployment:
    replicas: 4 # OR enable autoscaling to this level (example below)
# autoscaling:
#   enabled: true
#   maxReplicas: 4
#   minReplicas: 2

platformBackend:
  deployment:
    replicas: 20 # OR enable autoscaling to this level (example below)
# autoscaling:
#   enabled: true
#   maxReplicas: 20
#   minReplicas: 8

## Note that we are actively working on improving performance of this service to reduce the number of replicas.
queue:
  deployment:
    replicas: 160 # OR enable autoscaling to this level (example below)
# autoscaling:
#   enabled: true
#   maxReplicas: 160
#   minReplicas: 40

backend:
  deployment:
    replicas: 5 # OR enable autoscaling to this level (example below)
# autoscaling:
#   enabled: true
#   maxReplicas: 5
#   minReplicas: 3

## Ensure your Redis cache is at least 200 GB
redis:
  external:
    enabled: true
    existingSecretName: langsmith-redis-secret # Set the connection url for your external Redis instance (200+ GB)

clickhouse:
  statefulSet:
    persistence:
      # This may depend on your configured TTL (see config section).
      # We recommend 600Gi for every shortlived TTL day if operating at this scale constantly.
      size: 4200Gi # This assumes 7 days TTL and operating a this scale constantly.
    resources:
      requests:
        cpu: "10"
        memory: "32Gi"
      limits:
        cpu: "16"
        memory: "48Gi"

commonEnv:
  - name: "CLICKHOUSE_ASYNC_INSERT_WAIT_PCT_FLOAT"
    value: "0"

​
높은 읽기, 낮은 쓰기

상대적으로 낮은 규모의 trace 수집이 있지만 많은 프론트엔드 사용자가 trace를 쿼리하거나 /runs/query 또는 /runs/<run-id> endpoint를 자주 호출하는 스크립트가 있습니다. 이를 위해 낮은 지연 시간으로 높은 읽기 규모를 가능하게 하는 replicated ClickHouse cluster를 설정하는 것을 강력히 권장합니다. replicated ClickHouse cluster를 설정하는 방법에 대한 자세한 지침은 external ClickHouse 문서를 참조하세요. 이 부하 패턴의 경우 3 node replicated 설정을 사용하는 것을 권장하며, cluster의 각 replica는 8+ core 및 16+ GB 메모리의 리소스 요청과 12 core 및 32 GB 메모리의 리소스 제한을 가져야 합니다. 이를 위해 다음과 같은 구성을 권장합니다: 
config:
  blobStorage:
    # Please also set the other keys to connect to your blob storage. See configuration section.
    enabled: true

frontend:
  deployment:
    replicas: 2

queue:
  deployment:
    replicas: 6 # OR enable autoscaling to this level (example below)
# autoscaling:
#   enabled: true
#   maxReplicas: 6
#   minReplicas: 4

backend:
  deployment:
    replicas: 40 # OR enable autoscaling to this level (example below)
# autoscaling:
#   enabled: true
#   maxReplicas: 40
#   minReplicas: 16

# We strongly recommend setting up a replicated clickhouse cluster for this load.
# Update these values as needed to connect to your replicated clickhouse cluster.
clickhouse:
  external:
    # If using a 3 node replicated setup, each replica in the cluster should have resource requests of 8+ cores and 16+ GB memory, and resource limit of 12 cores and 32 GB memory.
    enabled: true
    host: langsmith-ch-clickhouse-replicated.default.svc.cluster.local
    port: "8123"
    nativePort: "9000"
    user: "default"
    password: "password"
    database: "default"
    cluster: "replicated"

​
중간 읽기, 중간 쓰기

이것은 LangSmith의 대부분의 사용 패턴을 처리할 수 있는 좋은 전반적인 구성입니다. 내부 테스트에서 이 구성을 통해 초당 100개의 trace 수집과 초당 40개의 읽기 요청으로 확장할 수 있었습니다. 이를 위해 다음과 같은 구성을 권장합니다: 
config:
  blobStorage:
    # Please also set the other keys to connect to your blob storage. See configuration section.
    enabled: true
  settings:
    redisRunsExpirySeconds: "3600"

frontend:
  deployment:
    replicas: 2

queue:
  deployment:
    replicas: 10 # OR enable autoscaling to this level (example below)
# autoscaling:
#   enabled: true
#   maxReplicas: 10
#   minReplicas: 5

backend:
  deployment:
    replicas: 16 # OR enable autoscaling to this level (example below)
# autoscaling:
#   enabled: true
#   maxReplicas: 16
#   minReplicas: 8

redis:
  statefulSet:
    resources:
      requests:
        memory: 13Gi
      limits:
        memory: 13Gi

  # -- For external redis instead use something like below --
  # external:
  #   enabled: true
  #   connectionUrl: "<URL>" OR existingSecretName: "<SECRET-NAME>"

clickhouse:
  statefulSet:
    persistence:
      # This may depend on your configured TTL.
      # We recommend 60Gi for every shortlived TTL day if operating at this scale constantly.
      size: 420Gi # This assumes 7 days TTL and operating a this scale constantly.
    resources:
      requests:
        cpu: "16"
        memory: "24Gi"
      limits:
        cpu: "28"
        memory: "40Gi"

commonEnv:
  - name: "CLICKHOUSE_ASYNC_INSERT_WAIT_PCT_FLOAT"
    value: "0"
위의 구성으로도 여전히 느린 읽기가 발생하는 경우 replicated Clickhouse cluster 설정으로 이동하는 것을 권장합니다

​
높은 읽기, 높은 쓰기

매우 높은 trace 수집 속도(초당 1000개의 trace 제출에 근접)와 프론트엔드에서 trace를 쿼리하는 많은 사용자(50명 이상) 및/또는 /runs/query 또는 /runs/<run-id> endpoint에 지속적으로 요청하는 스크립트가 있습니다. 이를 위해 높은 쓰기 규모에서 읽기 성능 저하를 방지하기 위해 replicated ClickHouse cluster를 설정하는 것을 매우 강력히 권장합니다. replicated ClickHouse cluster를 설정하는 방법에 대한 자세한 지침은 external ClickHouse 문서를 참조하세요. 이 부하 패턴의 경우 3 node replicated 설정을 사용하는 것을 권장하며, cluster의 각 replica는 14+ core 및 24+ GB 메모리의 리소스 요청과 20 core 및 48 GB 메모리의 리소스 제한을 가져야 합니다. 또한 ClickHouse의 각 node/instance가 활성화한 TTL의 각 일에 대해 600 Gi의 볼륨 스토리지를 갖는 것을 권장합니다(아래 구성에 따라). 전반적으로 다음과 같은 구성을 권장합니다: 
config:
  blobStorage:
    # Please also set the other keys to connect to your blob storage. See configuration section.
    enabled: true
  settings:
    redisRunsExpirySeconds: "3600"
# ttl:
#   enabled: true
#   ttl_period_seconds:
#     longlived: "7776000"  # 90 days (default is 400 days)
#     shortlived: "604800"  # 7 days (default is 14 days)

frontend:
  deployment:
    replicas: 4 # OR enable autoscaling to this level (example below)
# autoscaling:
#   enabled: true
#   maxReplicas: 4
#   minReplicas: 2

platformBackend:
  deployment:
    replicas: 20 # OR enable autoscaling to this level (example below)
# autoscaling:
#   enabled: true
#   maxReplicas: 20
#   minReplicas: 8

## Note that we are actively working on improving performance of this service to reduce the number of replicas.
queue:
  deployment:
    replicas: 160 # OR enable autoscaling to this level (example below)
# autoscaling:
#   enabled: true
#   maxReplicas: 160
#   minReplicas: 40

backend:
  deployment:
    replicas: 50 # OR enable autoscaling to this level (example below)
# autoscaling:
#   enabled: true
#   maxReplicas: 50
#   minReplicas: 20

## Ensure your Redis cache is at least 200 GB
redis:
  external:
    enabled: true
    existingSecretName: langsmith-redis-secret # Set the connection url for your external Redis instance (200+ GB)

# We strongly recommend setting up a replicated clickhouse cluster for this load.
# Update these values as needed to connect to your replicated clickhouse cluster.
clickhouse:
  external:
    # If using a 3 node replicated setup, each replica in the cluster should have resource requests of 14+ cores and 24+ GB memory, and resource limit of 20 cores and 48 GB memory.
    enabled: true
    host: langsmith-ch-clickhouse-replicated.default.svc.cluster.local
    port: "8123"
    nativePort: "9000"
    user: "default"
    password: "password"
    database: "default"
    cluster: "replicated"

commonEnv:
  - name: "CLICKHOUSE_ASYNC_INSERT_WAIT_PCT_FLOAT"
    value: "0"
Kubernetes cluster가 권장 크기로 확장할 수 있는 충분한 리소스로 구성되어 있는지 확인하세요. 배포 후 Kubernetes cluster의 모든 pod는 Running 상태여야 합니다. Pending 상태에 있는 pod는 node pool 한계에 도달했거나 더 큰 node가 필요함을 나타낼 수 있습니다.또한 cluster에 배포된 모든 ingress controller가 병목 현상을 방지하기 위해 원하는 부하를 처리할 수 있는지 확인하세요.
Edit the source of this page on GitHub.
Connect these docs programmatically to Claude, VSCode, and more via MCP for real-time answers.
⌘I