온프레미스 Triton 엔진 동시처리 검증 및 Envoy LB 구성

Source

  • Field Notes/ReturnZero/Daily Notes/Day 720. 2023-06-20.md

Summary

GPU 자원이 넉넉한 환경에서 Triton 엔진의 동시 처리 역량(Concurrency)을 검증하기 위해 Load Balancer 구성을 시도했다. HTTP 기반인 Nginx는 WebSocket/GRPC 처리에 부적합하여 Envoy로 전환했으나, Docker Compose 설정 및 호스트 주소 지정 문제로 초기 실패했다. 이후 Homura의 설정을 참고하여 Triton 인스턴스를 별도 서비스로 정의하고 Envoy 설정을 수정하며 문제를 해결했다. 또한, 동시 접속 채널 수를 정확히 카운팅하기 위해 Go 언어의 atomic 연산(AddInt32, CompareAndSwapInt32)을 활용하여 Race Condition을 해결하는 코드 로직을 정리했다. 향후 Open API 레벨의 제한은 복잡하므로 엔진 레벨에서 Resource Exhausted 또는 채널 수 제한 메시지를 내려주는 방식으로 통제할 계획이다.

Key Points

  • Triton 엔진의 동시 처리 성능 테스트를 위해 LB 구성 필요 (Nginx는 HTTP/HTTPS만 지원하므로 부적합)
  • Envoy를 LB로 사용하며, Docker Compose에서 각 Triton 인스턴스를 별도 서비스로 정의해야 함
  • Envoy 설정 시 Triton host 주소(localhost vs service name) 및 WebSocket/GRPC 포트 매핑이 핵심 포인트
  • 동시 접속 수(streamCount) 및 최대 기록(maxStreamCountRecord) 관리를 위해 Go atomic 연산 사용
  • Race Condition 해결을 위해 atomic.CompareAndSwapInt32(CAS)를 활용한 무한 루프 로직 구현
  • Open API 레벨의 접속 제한은 구현 난이도가 높아, 엔진 레벨에서 에러 메시지를 내려주는 방식으로 대체 계획