Server 확장성
서비스에 더 많은 인스턴스를 추가하면 적절한 로드 밸런서 메커니즘이 앞에 배치되는 한 HTTP 로드를 공유하게 됩니다. 대부분의 배포 방식에서는 서비스에 대한 로드 밸런서를 자동으로 구성합니다. “control plane 없는 자체 호스팅” 방식에서는 로드 밸런서를 추가하는 것이 사용자의 책임입니다. 인스턴스가 상태를 유지하지 않기 때문에 모든 로드 밸런싱 전략이 작동하며, 세션 고정성은 필요하지 않거나 권장되지 않습니다. 서버의 모든 인스턴스는 (Redis PubSub을 통해) 모든 queue 인스턴스와 통신할 수 있으므로, 진행 중인 run을 취소하거나 스트리밍하는 요청은 임의의 인스턴스에서 처리될 수 있습니다.Queue 확장성
서비스에 더 많은 인스턴스를 추가하면 각 인스턴스가 설정된 수의 동시 run을 처리하도록 구성되어 있기 때문에(기본값 10) run 처리량이 선형적으로 증가합니다. 각 run에 대한 각 시도는 단일 인스턴스에서 처리되며, Postgres의 MVCC 모델을 통해 정확히 한 번(exactly-once) 의미론이 적용됩니다(충돌 복원력 세부 사항은 아래 섹션 참조). 일시적인 데이터베이스 오류로 인해 실패한 시도는 최대 3번까지 재시도됩니다. 우리는 장기 실행 트랜잭션이나 잠금을 사용하지 않으며, 이를 통해 Postgres 리소스를 보다 효율적으로 사용할 수 있습니다.복원력
run이 queue 인스턴스에서 처리되는 동안, 해당 queue worker에 의해 주기적인 heartbeat 타임스탬프가 Redis에 기록됩니다. 정상 종료 요청(SIGINT)이 수신되면 인스턴스는 종료 모드로 진입하며, 이는- 새로운 HTTP 요청 수락을 중지합니다
- 진행 중인 run에 제한된 시간(초)을 주어 완료하도록 합니다(완료되지 않으면 queue에 다시 넣습니다)
- 인스턴스가 queue에서 더 이상 run을 가져오지 않도록 중지합니다
Postgres 복원력
Postgres 데이터베이스를 관리하는 배포 방식의 경우, 자동 장애 조치를 위한 주기적인 백업과 지속적으로 복제되는 대기 복제본이 있습니다. 이 Postgres 구성은Production deployment types에 대해서만 Cloud deployment option에서 사용할 수 있습니다.
Postgres와의 모든 통신은 재시도 가능한 오류에 대한 재시도를 구현합니다. 데이터베이스 재시작 중과 같이 Postgres를 일시적으로 사용할 수 없는 경우에도 대부분/모든 트래픽이 계속 성공해야 합니다. Postgres의 장기간 장애는 LangGraph Server를 사용할 수 없게 만듭니다.
Redis 복원력
영구 저장이 필요한 모든 데이터는 Redis가 아닌 Postgres에 저장됩니다. Redis는 임시 메타데이터와 인스턴스 간 통신에만 사용됩니다. 따라서 Redis에 대한 내구성 요구 사항은 없습니다. Redis와의 모든 통신은 재시도 가능한 오류에 대한 재시도를 구현합니다. 데이터베이스 재시작 중과 같이 Redis를 일시적으로 사용할 수 없는 경우에도 대부분/모든 트래픽이 계속 성공해야 합니다. Redis의 장기간 장애는 LangGraph Server를 사용할 수 없게 만듭니다.Connect these docs programmatically to Claude, VSCode, and more via MCP for real-time answers.