초A&G! 녹화 실패 회피를 위한 삽질들

이 카테고리에 몇번 언급했었는데, 저는 일본 클라우드 업체에 VPS 서버를 임대해 이런저런 용도로 쓰고 있습니다.

라디오 감상을 위한 VPN서버(WireGuard), 라디오 방송 아카이브를 위한 녹음/녹화서버 그리고 그 외 공부 용도 등등.

덕분에 해외망이 모뎀같이 느린 유선통신사(티브로드)를 쓰던 시절부터 불편하지 않게 라디오 라이프를 이어 오고 있습니다.

 

다만, 작년 말 정도부터 초A&G!+ 의 새벽 방송 녹화 실패 빈도가 잦아지더군요.

물론 해외 지역제한 없이 생방송을 최소한의 지연시간으로 온라인 송신해 주는건 항상 고맙게 생각하고 있습니다.

그래도 VPS 서비스 제공업체나 문화방송(文化放送)의 시스템 작업 공지가 올라오지도 않았는데 불규칙하게 끊기는 현상이 일어나는건 녹화작업을 관리하는 입장에서는 좀 골치아프더군요.

 

최근 시간이 나서 녹화 실패를 회피하기 위해 이것저것 해봤는데, 그 내용들을 정리해 보았습니다.

관심있는 분들은 열어봐 주시길.

 

 

 

-- 목  차 --

누르시면 바로 이동합니다.

 

1. 원인 분석

2. 도커 이미지 구성요소 최신화

3. 스크립트 동작시간 체크

 

 

1. 원인 분석

 

 

일단은 연결 실패가 원인입니다.

위 내용은 녹화작업시 ffmpeg에 FFREPORT 환경변수를 설정(log level 48)하여 보관중인 디버그 로그의 일부입니다.

이유는 명확치 않지만, 새벽시간(0시 이후) 에는 거의 50% 이상의 높은 확률(평일 5일 중 3일 실패)로 실패하더군요.

 

방송페이지(https://www.uniqueradio.jp/agplayer5/player.php) 의 재생 프레임 안에 있는 m3u8 를 ffmpeg 에 걸고 녹화를 시작하면 1분 정도 주기로 새 방송데이터를 가져오면서 녹화가 진행됩니다.

무슨 이유인지는 모르겠지만 다음 방송데이터를 가져와야 하는데 가져오지 못하면 ffmpeg 가 실패 처리하고 그냥 파일 만들어버리고 끝내면서 일어나는 현상이지요.

 

몇번 ffmpeg 의 재시도 옵션을 찾아서 적용하기도 했습니다만(reconnect_on_network_error 라던가), 로컬PC에서 테스트해봐도 실제 서버에서의 동작도 한번의 연결 실패(Connection timed out)는 기다리며 회피하지만 다음 연결 실패(두번째 이상)때는 그냥 끊고 작업을 끝내버립니다.

작업을 끝낼때 exit 코드가 어떻게 되는지는 체크 못해봤는데, until done 문장으로 회피를 하려고도 해봤는데 성공한것처럼 끝나는지 실패시의 회피 구문을 타지 않더군요.

 

결국 원인만을 어렴풋이 파악한 채 세달이 지났습니다.

그리고 지난 2월 말, 다시 붙잡고 정보를 찾다가 이런걸 발견했습니다.

 

 

2. 도커 이미지 구성요소 최신화

워낙 원인이 불분명하고, 추측할만한 가장 큰 원인이 제 통제권 밖에 있기 때문에 제게는 별로 선택권이 없었습니다.

다만 'Failed to reload playlist 0' 이라는 에러를 검색하다 보니, ffmpeg의 최신 소스로 다시 빌드하고 문제가 해결되었다는 글을 몇개 보게 되었습니다.

참고한 글은 2020년 글이라 현 시점의 저에게는 '구버전의 ffmpeg' 가 문제의 원인은 아니겠지만,

실제 저 역시 도커 이미지를 만들 때 '작업당시 최신 ffmpeg 소스' 를 다운로드 받아 직접 빌드하기에 버그가 수정된 소스를 늦게 반영하여 문제 해결이 늦어질 여지는 항상 있었습니다.

 

그래서 생각나면 수동으로 재빌드하던 도커 이미지를 한달에 한번 자동으로 할 수 있게 스크립트를 만들게 되었습니다.

 

참고로 저는 서버 로컬에 저장된 Dockerfile 을 사용해 녹음/녹화용 도커 이미지를 빌드하고 있습니다.

이 부분에서도 이를 감안해서 작업을 하고 있으니 참고해 주시길.

 

 

대략의 작업은,

-첫째주 토요일일 경우에만 작업하며

-생성되어 있던 도커 이미지를 삭제한 뒤

-Dockerfile 이 있는 경로로 이동해서

-도커 이미지 빌드

 

위 스크립트는 한 이미지를 대상으로 하게 축소했는데, 제 서버에서는 네 이미지를 빌드합니다.

그래도 처음 하나만 빌드에 성공하면 나머지는 끝부분 동작 정도만 달라서 캐시로 끝나지만요. (Dockerfile 의 ffmpeg 빌드 부분 코드를 동일하게 맞춤)

그렇다곤 해도 첫 이미지에서는 ffmpeg 의 소스를 다운로드 받고 직접 빌드하는 작업이 있기 때문에 전체 작업에 대략 1시간 정도는 소요됩니다만.

 

참고로 이 작업은 토요일 새벽에 일어나는데(새벽 5시), 작업 뒤 도커 이미지가 정상적으로 생성되었는지도 나름대로는 중요합니다.

그래야 필요한 이후 작업들이 정상적으로 이뤄질테니까요.

 

그래서 정상여부를 테스트하는 스크립트도 작성하였습니다.

 

 

역시 작업은 아래와 같습니다

-첫째주 토요일일 경우에만 작업하며

-3분간 테스트 녹화를 진행하고

-에러가 발생하면 라인 알림이 발송된다(위 부분에서는 생략함)

-에러가 없다면 테스트 녹화된 파일의 상세 스펙을 로그에 기록한 뒤 삭제한다

 

이번 스크립트 역시 총 4개의 이미지에 대한 테스트를 진행하는데, 여기다 붙히려고 하나를 대상으로 하게끔 축소했습니다.

 

도커 이미지를 사용해서 호스트OS와의 종속성을 줄인건 좋지만, 이게 이미지를 만들어 놓고 계속 쓰는 방식이다 보니 조금만 무심하면 몇개월 전의 구버전 구성요소가 업데이트가 됐으면 일어나지 않았을 문제를 내는 경우가 왕왕 있었습니다.

그래서 가끔 이미지 새로 만들어 주는게 은근 번거로운 일이었는데(현재 VPS 스펙상 첫 이미지 생성에는 25분 이상 걸림) 덕분에 큰 골치가 하나 사라졌습니다.

 

사실 도커 v 옵션을 이용한 파일시스템 마운트를 통해 ubuntu 의 ffmpeg 빌드환경을 만들면 다른 이미지에서도 공통적으로 사용할 수 있도록 마운트가 가능할것 같긴 한데,

그 연구보다는 모든 이미지의 동작을 최대한 통일시켜서 대부분의 작업을 캐시로 수행될 수 있게 한게 제 안에서는 조금 더 마음 편했네요.

나중에 좀 더 시간이 나면 각 도커 이미지에서 빌드하고 있는 ffmpeg 를 공통으로 빌드할 수 있는 이미지를 연구해 보고 싶습니다.

일단 지금은 아니구요(....)

 

하지만 아쉽게도 이 방법으로도 Connection timed out 에러는 사라지지 않았습니다.

그래서 결국 아래 스크립트로 회피하게 되었네요.

 

 

3. 스크립트 동작시간 체크

Linux 에는 $SECONDS 라는 변수가 있습니다. [설명 보기, $SECONDS 검색 필요]

스크립트가 동작한 시간을 카운트해주는 시스템 변수인데, 이번 동작에는 이 변수를 활용했습니다.

어차피 스크립트 안에서 녹화시간을 변수로 지정하고 있으니, 설정한 녹화시간보다 스크립트가 지나치게 빨리 끝나면 강제로 다시 녹화를 하게 만드는거죠.

 

 

아래와 같은 동작을 하는 스크립트입니다.

-처음 지정하는 녹화시간(분) 변수를 활용해 총 동작시간(초)과 조기종료 허용시간(초)을 계산합니다

-처음에는 기존대로 녹화를 진행하고

-녹화가 종료되었을 때 조기종료 허용시간 미만이면 그 시간까지 계속 녹화를 시도합니다. 이상이면 그대로 끝.

-녹화 재시도시에는 다음 동작이 추가됩니다

=> 파일 덮어씌우기를 방지하기 위해 순번을 증가시켜 설정한 이름(PREFIX) 뒤에 추가

=> 총 녹화시간에서 실패 전까지 작업된 녹화시간(분) 만큼 차감한 뒤 남은 시간 녹화

-아래의 경우에는 작업서버 및 초!A&G+ 서버에 대해 필요 이상의 부하를 줄 수 있으므로 강제 종료합니다

=> 재시도 카운트가 15회를 넘어설 경우(7회 이상도 많다고 생각하지만 일단은)

=> 녹화시간이 잘못 계산되어 ffmpeg에 음수 녹화시간(초)가 배정되려 할 때

=> 기타 동작상 에러 등 발생시

 

이 스크립트의 테스트를 위해 약 2주간 수정사항을 반영해가며 새벽 1시 30분에 녹화작업을 하며 관찰했는데, 대충 30초 정도 빨리 녹화작업이 끝나더군요.

그래서 최대 조기종료 허용시간을 35초로 잡고 35초보다 빨리 끝나면 기존에 녹화한 시간의 분을 계산하여 차감한 분 만큼 추가 녹화를 진행합니다.

 

이렇게 만들고 요 며칠 새벽 녹화를 진행해 보니 잘 회피하더군요. 그래서 이렇게 마음 놓고 정리합니다.

아마 이렇게까지 필사적으로 녹화하려는 분은 없겠지만(?) 궁금하면 한번 살펴보시길.

 

혹시 파일 자체가 필요하시거나 글 올라온 오늘(2022.03.09) 이후 시점의 수정사항이 궁금하다면 레포지토리의 파일을 봐 주시면 됩니다[바로가기]

 

 

이번 글은 여기까지.

 

덕분에 본의 아니게 shell 연습까지 하고 있는 느낌입니다.

이참에 다른 언어 익힐겸 shell 말고 다른걸 써볼걸 그랬나 싶기도 하고. 아마 훨씬 고생했겠지만 말이죠(...)

아무튼 관심있는 분들은 잘 부탁드립니다.

 

저는 며칠 뒤에 블루레이 박스 글을 정리해서 들고 오지요.

전 금요일 아침에 사전투표 해서 쉴 생각인데, 사전투표 안하신 분이 계시다면 한표 행사하시고,

금방 다음 글에서 뵙겠습니다.