이중 오케스트레이터 및 패킷 손실 없는 자동 확장 RTSP 스트리밍 아키텍처
감시 플랫폼은 비디오 스트리밍 인프라를 동적으로 확장해야 했습니다. 10대에서 200대 이상의 IP 카메라와 수백 명의 동시 시청자 및 AI 처리 작업자를 처리하면서 확장 작업 중 패킷 손실을 보장하고 절대 변경되지 않는 안정적인 스트림 URL을 유지해야 했습니다.
프로젝트 상담하기
과제
고정된 스트리밍 인프라는 성장하는 감시 플랫폼의 가변적인 수요를 처리할 수 없었습니다:
- 규모 변동성 — 카메라 수와 시청자 수요는 하루 동안 극적으로 변동했습니다 (10배 피크-저점 비율)
- 초과 프로비저닝 비용 — 피크 로드를 위한 프로비저닝은 비피크 시간 동안 70% 이상의 유휴 자원을 의미했습니다
- 확장 중 패킷 손실 — 스트리밍 서버를 추가하거나 제거할 때 스트림 중단이 발생하여 AI 처리 작업자에게 프레임 손실이 발생했습니다
- URL 불안정성 — 특정 서버 IP로 구성된 카메라와 시청자는 인프라가 변경될 때 재구성이 필요했습니다
- 다른 확장 필요 — 카메라 수집과 시청자 분배는 근본적으로 다른 부하 패턴을 가지고 있어 독립적인 확장이 필요했습니다
- AI 작업자 중단 — AI 처리 파이프라인은 소스 스트림 서버가 축소될 때 충돌했습니다
우리의 솔루션
우리는 이중 오케스트레이터 자동 확장 스트리밍 아키텍처를 설계했습니다. 별도의 수집 및 분배 클러스터, 패킷 손실 없는 5단계 우아한 종료, 안정적인 DNS 기반 URL, 자동화된 AI 작업자 재연결을 포함합니다.
아키텍처
- 스트리밍 서버: RTSP/WebRTC/HLS 프로토콜 지원을 위한 MediaMTX
- 수집 클러스터: 카메라 RTSP 스트림을 수신하는 1-10대 서버
- 분배 클러스터: 시청자(WebRTC/HLS) 및 AI 작업자(RTSP)를 제공하는 2-20대 서버
- 이중 오케스트레이터: 수집 및 분배를 위한 독립적인 확장 컨트롤러
- 로드 밸런서: 클러스터별로 프로토콜에 적합한 알고리즘을 사용하는 별도의 로드 밸런서
- 서비스 레지스트리: 서버 상태, 스트림 매핑 및 조정을 위한 Redis
- 건강 모니터링: 자동 복구가 포함된 활성 건강 검사
- DNS 레이어: 로드 밸런서를 가리키는 안정적인 도메인 이름 (URL은 절대 변경되지 않음)
이중 오케스트레이터 설계
왜 두 개의 오케스트레이터인가
수집과 분배는 근본적으로 다른 확장 특성을 가지고 있습니다:
- 수집은 카메라 수와 인바운드 대역폭에 따라 확장됩니다 (예측 가능하며 꾸준히 증가)
- 분배는 시청자 수와 AI 작업자 수요에 따라 확장됩니다 (급증하며 예측 불가능)
별도의 오케스트레이터는 각자가 전문화된 정책, 메트릭 및 임계값으로 독립적으로 확장할 수 있게 하여 한 클러스터의 확장 결정이 다른 클러스터에 영향을 미치지 않도록 합니다.
수집 오케스트레이터
- 주요 메트릭: 서버당 카메라 연결 수
- 보조 메트릭: 인바운드 대역폭 사용량
- 확장: CPU가 임계값을 초과하거나 서버당 카메라 수가 용량을 초과할 때
- 축소: 사용량이 임계값 아래로 떨어지고 안정화 기간이 지속될 때
- 서버 범위: 1에서 10대 서버
분배 오케스트레이터
- 주요 메트릭: 서버당 시청자 + AI 작업자 연결 수
- 보조 메트릭: 아웃바운드 대역폭 사용량
- 확장: CPU가 임계값을 초과하거나 서버당 연결 수가 용량을 초과할 때
- 축소: 사용량이 임계값 아래로 떨어지고 지속적인 기간 동안 (수집보다 더 긴 안정화) 지속될 때
- 서버 범위: 2에서 20대 서버 (고가용성을 위해 최소 2대)
패킷 손실 없는 5단계 우아한 종료
분배 서버가 제거될 예정일 때, 5단계 프로세스는 프레임이 손실되지 않도록 보장합니다:
1단계: 사전 알림서버는 서비스 레지스트리에서 "DRAINING"으로 표시됩니다. 로드 밸런서 가중치가 줄어들어 새로운 연결이 다른 곳으로 라우팅됩니다. Redis pub/sub 알림과 웹훅은 AI 작업자에게 마이그레이션 준비를 알립니다.
2단계: 로드 밸런서 업데이트서버가 로드 밸런서 백엔드 풀에서 제거됩니다. 새로운 연결은 드레이닝 서버에 도달할 수 없습니다. 기존 연결은 중단 없이 계속됩니다.
3단계: AI 작업자 마이그레이션AI 작업자는 드레이닝 서버에서 연결을 끊고 건강한 분배 서버로 다시 연결합니다. 체크포인트 기반 상태 보존은 처리 작업이 중단된 정확한 프레임에서 다시 시작되도록 보장합니다. 총 간격: 약 3초로 프레임 손실 없음.
4단계: 시청자 드레이닝남아 있는 시청자 연결은 구성 가능한 창을 통해 자연스럽게 드레인됩니다. 최신 비디오 플레이어는 동일한 안정적인 URL에 자동으로 다시 연결되며, 이는 건강한 서버로 라우팅됩니다. 대부분의 시청자는 중단을 경험하지 않습니다.
5단계: 정리모든 연결이 닫혔는지 확인합니다. 서버를 서비스 레지스트리에서 제거합니다. 클라우드 인스턴스를 파괴합니다. 확장 메트릭을 기록합니다.
안정적인 URL
URL 아키텍처는 카메라와 클라이언트가 재구성을 필요로 하지 않도록 보장합니다:
- 카메라 게시 대상: 안정적인 수집 도메인 이름
- 시청자/AI 접근 대상: 안정적인 분배 도메인 이름
- DNS 레코드는 로드 밸런서 IP를 가리킵니다 (영구적임)
- 로드 밸런서는 백엔드 서버로의 라우팅을 투명하게 처리합니다
- 백엔드 서버는 URL 변경 없이 추가, 제거 또는 교체될 수 있습니다
서비스 레지스트리 (Redis)
중앙 집중식 Redis 인스턴스는 전체 시스템을 조정합니다:
- 서버 상태 추적 (활성, 드레이닝, 오프라인)
- 스트림-서버 매핑 (어떤 카메라가 어떤 수집 서버에 있는지)
- AI 작업자 상태 및 체크포인트 데이터
- 확장 결정을 위한 서버당 부하 메트릭
- 실시간 조정 이벤트를 위한 pub/sub 채널
AI 클라이언트 재연결
AI 클라이언트 라이브러리는 원활한 재연결을 제공합니다:
- Redis pub/sub를 통해 서버 제거 알림을 수신합니다
- 정기적인 간격으로 자동 프레임 체크포인트
- 알림 시 건강한 분배 서버로 재연결
- 최소한의 간격으로 체크포인트에서 처리 재개
- 재연결 이벤트에 대한 메트릭 보고
건강 모니터링
- 정기적인 간격으로 모든 서버에 대한 활성 건강 검사
- 서버 장애 시 자동 로드 밸런서 업데이트
- 응답하지 않는 서버에 대한 자동 복구 트리거
- 가동 시간 추적 및 가용성 보고
주요 기능
- 이중 오케스트레이터 — 수집 및 분배 클러스터에 대한 독립적인 확장
- 패킷 손실 없음 — AI 작업자 마이그레이션을 포함한 5단계 우아한 종료
- 안정적인 URL — DNS 기반 라우팅은 확장 중 URL이 변경되지 않도록 보장합니다
- AI 작업자 재연결 — ~3초 간격의 체크포인트 기반 마이그레이션 및 프레임 손실 없음
- 독립적인 확장 — 수집 및 분배는 자체 메트릭에 따라 확장됩니다
- 서비스 레지스트리 — 서버 상태 및 스트림 매핑을 위한 Redis 기반 조정
- 건강 모니터링 — 자동 복구가 포함된 활성 검사
- 비용 최적화 — 수요가 낮은 기간 동안 자동 축소
결과
기술 스택
caseStudyDetail.more 사례 연구
더 많은 기술 구현 사례를 살펴보세요
자주 묻는 질문
MicrocosmWorks는 액티브-액티브 듀얼 오케스트레이터 설계를 구현했으며, 이 설계에서 두 오케스트레이터는 스트림 할당 및 워커 상태에 대한 동기화된 상태를 유지합니다. 하나의 오케스트레이터가 실패할 경우 몇 초 이내에 스트림 관리를 살아남은 오케스트레이터로 이전하는 자동 페일오버 기능도 포함되어 있습니다. 이는 전통적인 단일 오케스트레이터 설계가 겪는 단일 실패 지점(Single Point of Failure)을 제거하여, 오케스트레이터 유지보수 또는 예기치 않은 크래시 중에도 제로 패킷 드롭(Zero Packet Drop)을 보장합니다.
MicrocosmWorks는 은퇴하는 워커가 모든 연결이 RTSP TEARDOWN 및 재-SETUP 시퀀스를 통해 새로운 워커로 깔끔하게 마이그레이션될 때까지 할당된 스트림을 계속 제공하는 우아한 드레인 메커니즘을 개발했습니다. 새로운 워커는 스트림 할당을 받기 전에 완전히 초기화되고 헬스 체크되며, 전환은 이전 워커와 새 워커 모두 잠시 동안 동일한 스트림을 제공하여 어떠한 중단도 방지하는 오버랩핑 윈도우를 사용합니다.
MicrocosmWorks는 MediaMTX가 가볍고 오픈 소스이며, 풀 기능을 갖춘 미디어 서버에 비해 스트림당 최소한의 리소스 오버헤드로 RTSP 재스트리밍을 위해 특별히 설계되었기 때문에 이 프로젝트를 위해 MediaMTX를 선택했습니다. 또한, MediaMTX는 API를 통한 동적 스트림 생성을 지원하며, Kubernetes 기반 자동 확장을 위해 컨테이너에서 효율적으로 실행되고, 규모가 커질수록 엄청난 부담이 될 수 있는 Wowza와 같은 상용 대안의 스트림당 라이선스 비용을 피할 수 있습니다.
MicrocosmWorks는 패킷 손실률, 지터, 재연결 횟수, 종단 간 지연 시간을 포함한 스트림별 지표를 추적하는 포괄적인 옵저버빌리티 스택을 배포했으며, 최종 사용자에게 성능 저하가 나타나기 전에 경고를 발생시킵니다. 이 모니터링 시스템은 또한 스케일링 이벤트, 스트림 마이그레이션 기간, 워커 활용도 추세와 같은 오케스트레이터의 의사 결정 지표도 추적하여 선제적인 용량 계획을 가능하게 합니다.
네, MicrocosmWorks는 라이브 뷰어를 위한 동시 RTSP 출력과 객체 스토리지로의 분할 녹화를 지원하도록 워커 노드를 설계했으며, 각 워크로드에 독립적인 리소스를 할당합니다. 녹화는 업로드 전에 세그먼트를 로컬로 버퍼링하는 별도의 쓰기 경로를 사용하므로, 스토리지 I/O 급증이 라이브 스트림 전송에 영향을 미치지 않습니다. 또한 자동 스케일러는 스케일링 결정을 내릴 때 두 워크로드의 결합된 리소스 요구 사항을 고려합니다.