[FFmpeg] ffmpeg의 DNS 캐싱 문제

ㅁ 들어가며

 ffmpeg로 HLS 서비스를 운영하면서 원천 스트림의 DNS 캐싱 문제(예: 원천 스트림의 IP가 변경되었는데 ffmpeg가 계속 이전 IP로 접속을 시도하는 현상)는 꽤 흔히 발생할 수 있다. ffmpeg 프로세스가 기동된 상태에서는 내부적으로 한번 해석된 DNS 정보를 계속 사용하기 때문에, 원천 스트림의 IP가 바뀌어도 실시간으로 반영되지 않는다. 이로 인해 스트림 장애가 발생할 수 있다.

 

ㅁ 원인 요약

ㅇ ffmpeg는 입력 스트림 URL의 DNS를 최초 연결 시점에만 해석

ㅇ 프로세스가 살아있는 동안에는 동일한 IP로만 재접속을 시도

ㅇ 원천 도메인의 IP가 바뀌면, ffmpeg는 변경된 IP를 반영하지 못해 연결 오류가 발생

 

ㅁ 해결 방법

ㅇ ffmpeg 프로세스 재시작

 - 가장 확실한 방법으로, ffmpeg 프로세스를 주기적으로 재시작하는 것이 일반적이다.

 

ㅇOS 레벨 DNS 캐시 삭제

 - 일부 환경에서는 OS 레벨에서 DNS 캐시를 삭제하는 것으로 문제를 완화할 수 있다.

 - 하지만 대부분의 경우 ffmpeg 프로세스가 이미 IP를 캐싱하고 있기 때문에, 프로세스를 재시작하지 않으면 효과가 없다.

 

ㅇ ffmpeg 옵션 및 환경설정

 - ffmpeg 자체에는 DNS TTL을 제어하거나 주기적으로 DNS를 재조회하는 옵션이 없다.

 - 일부 ffmpeg 빌드에서 사용하는 라이브러리가 시스템 DNS 리졸버를 사용한다면, 라이브러리 자체의 옵션이나 환경변수로 동작을 조정할 수 있지만, 공식적으로 지원되는 방식은 아니다.

 

ㅇ 외부 프록시/리버스 프록시 활용

 - 원천 스트림 앞단에 nginx 등 리버스 프록시를 두고, ffmpeg는 항상 프록시의 고정 도메인(IP)만 바라보게 하는 방법도 있다.

 - 프록시 서버가 원천 도메인에 대한 DNS를 주기적으로 재조회하여 연결을 관리하게 할 수 있다.

 

ㅁ 마무리

ffmpeg 프로세스가 DNS 정보를 캐싱하는 구조적 한계 때문에, 프로세스 재시작이 가장 확실한 해결책입이다.

장애 감지 및 자동 재시작 로직을 운영에 포함시키는 것이 실무적으로 가장 널리 쓰이는 방법이다.

장기적으로는 리버스 프록시 도입 등 인프라 구조 개선도 고려해볼 수 있다.

 

 

ㅁ 함께 보면 좋은 사이트

ㅇ ffmpeg로 hls 만들기, 옵션정리

ㅇ [FFmpeg] FFprobe 사용법: 멀티미디어 파일 분석하기