서버 확장성
서비스에 더 많은 인스턴스를 추가하면 적절한 로드 밸런서 메커니즘이 앞에 배치되는 한 HTTP 부하를 공유하게 됩니다. 대부분의 배포 방식에서는 서비스를 위한 로드 밸런서를 자동으로 구성합니다. “컨트롤 플레인 없는 자체 호스팅” 방식에서는 로드 밸런서를 추가하는 것이 사용자의 책임입니다. 인스턴스가 상태를 유지하지 않기 때문에 어떤 로드 밸런싱 전략도 작동하며, 세션 고정성은 필요하지도 않고 권장되지도 않습니다. 서버의 모든 인스턴스는 (Redis PubSub을 통해) 모든 큐 인스턴스와 통신할 수 있으므로, 진행 중인 실행을 취소하거나 스트리밍하는 요청은 임의의 인스턴스에서 처리될 수 있습니다.큐 확장성
서비스에 더 많은 인스턴스를 추가하면 실행 처리량이 선형적으로 증가합니다. 각 인스턴스는 설정된 수의 동시 실행을 처리하도록 구성되기 때문입니다 (기본값 10개). 각 실행의 각 시도는 단일 인스턴스에서 처리되며, 정확히 한 번(exactly-once) 의미론은 Postgres의 MVCC 모델을 통해 적용됩니다 (충돌 복원력 세부 사항은 아래 섹션 참조). 일시적인 데이터베이스 오류로 인해 실패한 시도는 최대 3번까지 재시도됩니다. 우리는 장기 실행 트랜잭션이나 락을 사용하지 않으며, 이를 통해 Postgres 리소스를 보다 효율적으로 활용할 수 있습니다.복원력
실행이 큐 인스턴스에서 처리되는 동안, 해당 큐 워커는 Redis에 주기적인 하트비트 타임스탬프를 기록합니다. 우아한 종료 요청(SIGINT)을 받으면 인스턴스는 종료 모드로 전환되며, 이때:- 새로운 HTTP 요청 수락을 중지합니다
- 진행 중인 실행에 제한된 시간(초)을 부여하여 완료하도록 합니다 (완료되지 않으면 큐에 다시 넣습니다)
- 큐에서 더 이상 실행을 가져오는 것을 중지합니다
Postgres 복원력
Postgres 데이터베이스를 관리하는 배포 방식의 경우, 자동 장애 조치를 위한 정기 백업과 지속적으로 복제되는 대기 복제본을 갖추고 있습니다. 이 Postgres 구성은Production 배포 유형에 대해서만 클라우드 배포 옵션에서 사용할 수 있습니다.
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.