True or False

한 줄로 요약을 하면 timeout 을 설정하자.

현재의 상황

현재 회사에서 IP CAM을 이용하여 CCTV 처럼 활용을 하려고 한다.

처음에는 AWS Media Package 를 사용했지만 비용이 상상이상으로 발생해(하루에 약 15만원 부과??)

자체적으로 구현하기로 하고 자체 서버를 구입해서 해결을 하는 중이다.

원래는 EC2로 할까했지만 계산을 해보니 자체서버가 더욱 더 싸게 먹혔다.

현재의 구현방식

FFmpeg 를 이용해서 24시간 돌아가는 실시간 스트리밍을 해야한다.(무중단 필요) 

그래서 RTSP => HLS 로 변환작업을 FFmpeg 로 하고 AWS S3로 실시간으로 업로드를 진행한다.

AWS S3 주소의 경우에는 백엔드 서버에 보내는 형태로 제공이되어진다.

순서도로 나타내면

1. 업로드 되어질 파일의 주소를 만들고 curl 을 통해서 백엔드 서버에 시작시간과 주소를 보낸다.

2. FFmpeg 를 통해서 1시간 동안 변환을 시작하고 종료가 되어지면 curl 을 통해서 종료시간을 보내고 1로 돌아간다.

3. 1번, 2번과는 별개로 AWS S3 sync 를 이용해서 업로드를 한다.

사건의 발단

기존에는 준비가 다른 외부적요인(서버 설치, IP Cam, 고정 IP 가 지원되는 LteRouter) 가 없어

RTSP 를 제공해주는 정부의 CCTV와 EC2를 이용하여 개발을 했다(shell script를 작성).

그리고 위의 외부적요인이 갖추어지면서 해당환경에 맞추어 1차적으로 개발을 하고 끝났다! 라고 생각을 했다.

그렇게 다음주 월요일에 문제를 발견했는데 주기적으로 ffmpeg 가 1시간 간격으로 돌아서 백엔드에 주소가 있어야 하는데

어느순간부터 시작시간만 있고 종료시간이 없는체 존재하는 데이터들이 있었다.

예시로 들면

이러한 형태로 존재를 했는데 보는 시점은 04:00가 훨씬 지난 시점이다.

한마디로 어디선가 묶여서 curl이 동작을 안하는 것이다.

그래서 해당하는 부분을 확인하기 위해 서버에 접속해 보니 FFmpeg 가 프리징이 걸려 동작을 안하고있었다.

이때부터 약간 머리가 아파오기 시작했다.

하지만 뭐 어쩔 수 있나 해결해야지 하면서 문제를 해결하기 위해 원인을 파악하기 위해 조사해보기 시작했다.

일단 시간은 어느정도 있는 상태였다.

운영체제의 문제?

기존에 AWS에서는 Ubuntu 를 통해서 FFmepg 를 사용했는데

현재는 Window Server를 통해서 FFmpeg 를 사용하고 있다.

그래서 혹시 Window Server의 문제가 아닐까 추측을 하면서 Docker를 통해서 같은 카메라에 FFmpeg를 돌리고 관찰을 해보았다.

금요일날 해당 작업을 하고 주말이 지나고 봤는데 둘다 문제가 없었다. 그렇게 뭐지? 하면서 있던 순간 월요일 오후 쯤에 사건이 발생하는데

Window Server를 통해서 돌고있는 FFmpeg가 프리징현상이 발생한거다. 그래서 옳다구나 Window Server가 문제였구나 하면서

바로 서버의 OS를 Ubuntu 로 변경을 했다(이부분도 삽질을 많이 했다....).

그래서 기쁜 마음으로 Ubuntu에서 FFmpeg 를 사용하고 퇴근을 하고 2~3일이 흐르고 또 사건이 발생한다.

Ubuntu 에서도 동일하게 문제가 발생한 것이다.

Window Server가 문제의 원인이 되어질 수도 있지만 주요원인은 아니었던 것이다.

그러면서 다른 요인을 찾기 위한 여정이 또 시작되었다.

서버의 외부적요인이 문제?

AWS Ec2 에서 FFmpeg 를 돌렸을 때는 문제가 발생을 안했다. 그러니 서버에 들어오는 네트워크에 문제일 수도 있겠다라고 생각을 했고,

또 같이 일하는 분 중 한분이 간헐적으로 네트워크의 끊김이 발생한다는 말을 하였다. 그래서 아!!! 네트워크 애가 문제일 수도 있겠군...

하면서 AWS Ec2 를 만들고 거기에 FFmpeg를 돌리고 자체 서버에서도 동일하게 돌렸다.

그러면서 자체서버만 떨어지면 네트워크의 문제일 것 이다라고 생각하며 또 지켜보고있었는데

이번에는 빠르게 사건이 발생한다. 갑자기 둘 다 프리징 현상이 발생한 것이다.

그러면서 어... 서버의 네트워크의 문제도 아니다?? 그러면 환경요인 중 변경된 것이 하나가 남는데 IP CAM 였다.

IP CAM 너가 범인이니?

IP CAM 이 범인이라고 확신이 되어지는 순간, 먼저 Ec2를 내리고 자체서버에서 FFmpeg 를 실행하고 바로 IP CAM의 인터넷 선을 빼보았다. 그러니 바로 동일한 프리징 현상이 발생을 하는 것이였다. 드디어 주요원인을 발견하는 것이었다.

IP CAM에 들어오는 인터넷이 LTE Router를 통해서 들어오는데 일단

이 Router에서 내부 IP 고정 및 포트포워딩을 했기에 중간에 끊기는 일은 거의 없지만

IP CAM에서 자체적으로 DHCP 를 통해서 할당할려고 그런건지 다른 외부적요인이 있었는지 네트워크가 끊기는 현상이 발생한 것이다.

그래서 원인은 알았으니 이제 해결을 하면되었는데...

해결해보자

그러면서 먼저 생각한게 FFmpeg가 프리징 상태일 때는 CPU Usage 가 0%일테니 이부분을 잡아서 강제 종료시키면 되겠다라고 생각을 했다.

그러면서 유심히 리소스를 모니터하고 있었는데 FFmpeg가 프리징이 아니더라도 중간에 CPU Usage 가 0%인 구간이 발생하고 있었고 그렇게 강제종료를 할 경우 파일에 손상이 일어나 스트리밍파일을 살리는 과정이 번거롭게 추가가 되어지는 것이었다.

그러면서 다른 방법이 없을까 생각하면 찾다가 발견을 했는데 timeout을 설정하면 Input에서 문제가 있거나 본인한테 문제가 있을 때 일정시간이 지나면 자동으로 종료되어지는 옵션이 있었다.

그래서 해당하는 옵션을 적용을 해보니 잘되었다가 또, 어느순간에 안되는 것이었다.

그리고 조금 더 살펴보니 단위의 문제가 있었는데 timeout 의 단위가 Second로 알고있었는데 Micro Second 였다.

그래서 처음에 3초로 설정했다고 생각하는 부분이 알고보니 3Micro Second였던 것이다. 그래서 바로 timeout이 발생해 동작을 안했었다.

그래서 해당하는 부분은 문서를 통해서 확인을 하고 3,000,000으로 설정하니 내가 원하는 방향으로 동작을 했다.

참고

원래 처음 코드에는 timeout 이 있었다. 그런데 해당 옵션이 동작을 안하는 것 같아서 제거를 했었는데

여기에는 여러가지가 복합적인 이유가 있지만 가장 큰 문제는 FFmpeg 문서와 버전이다.

FFmpeg 문서가 그렇게 친절하지 않다보니 해당 옵션에 대한 내용을 찾기도 힘들고 또, 버전도 여러개로 나뉘어져서 있다보니

구글링을 통해 해결할려고 해도 버전이 달라 제대로 적용이 되어지지않는 경우가 허다했다.

그러다보니 timeout은 그냥 동작도 안하니 빼게 된 케이스였는데 이번에 해당 문제를 만나고 적용해보니 제대로 동작을 해서 다행이었다.

만약에 이것도 제대로 동작을 안했으면 어떻게 해야하나 머리를 굴리고 있었을 것 이다.