t.taeyun.blog
검색

하나의 프로젝트,
여러 번의 선택.

서로 이어지는 글을 프로젝트별로 모았습니다.

41편의 기록

PokeClip

라이브 스트림을 받고, 저장하고, 다시 재생하기까지. 미디어 인프라의 설계와 복구 기록.

시리즈 읽기 ↗16편의 기록

MediaMTX

설정과 인증, 녹화와 종료 처리. 사용 중 만난 문제를 공개 기여로 연결한 과정.

시리즈 읽기 ↗7편의 기록

Shakedown

분석 결과를 서비스의 배포와 복구로 연결한 해커톤 기록.

시리즈 읽기 ↗

문제를 따라 읽기

이벤트가 사라진 뒤의 복구

저장된 파일, 인덱스, 재시작이 서로 어긋날 때 무엇을 기준으로 복구할까요.

  1. 부분 목록으로 방송을 지우지 않기: 폐기한 경로 조정 설계에서 남은 판단
  2. 276개 파일을 회수해도 p95만으로는 부족했습니다: 알림 유실을 견디는 인덱서
  3. S3에는 올라갔는데 DB는 pending: 업로드 복구의 기준을 정하다
  4. 컨테이너는 살아 있고 설정 파일은 사라졌다: PokeClip Media 호스트의 재시작 경계

인증 다음의 권한 경계

사용자를 확인하는 일부터 요청 대상과 작업 권한을 일치시키는 일까지.

  1. PokeClip의 DB 인증을 공통 모듈로 묶기: RDS IAM, TLS, 연결 풀의 경계
  2. OBS 안에 OAuth를 다시 만들지 않고 계정을 연결하는 방법
  3. MediaMTX 앞 nginx가 확인해야 했던 것: 허용한 방송과 요청한 방송의 일치
  4. 편집을 맡긴다고 채널 게시까지 맡기는 것은 아니다
  5. 해시로 충분한 값과 다시 읽어야 하는 비밀: SRT 키 저장을 바꿀 계획

라이브를 다시 재생하기까지

라이브와 DVR의 책임을 나누고 URL·구간·매니페스트의 계약을 연결합니다.

  1. PokeClip의 Live와 DVR을 나누고, 다시 이어 붙이는 조건
  2. 끝난 재생목록은 다시 열지 않기로 했습니다
  3. 6초 창 때문에 라이브러리를 포크할 필요가 있을까
  4. 12번이 준비돼도 11번을 건너뛰면 안 됩니다: HLS 목록 경계 검증
  5. 늦게 끝난 writer가 새 재생목록을 덮는다면
  6. 3.9초부터 자르면 첫 조각이 빠진다: 조회 계약과 8,020개 경계 검증

재생 실패에서 원인까지

검은 화면과 오디오 간격을 증거로 좁혀 가는 디버깅 기록.

  1. 오류는 0건인데 61.94초가 보이지 않았습니다
  2. 200인데 검은 화면이었다: 세 원인이 겹친 HLS 재생 문제 추적
  3. 재접속의 0.2초 빈틈: 타임스탬프와 불연속 태그를 함께 바꾸기
  4. 재포장 23.43→3.05ms: 같은 I/O 범위로 다시 측정한 이유
  5. 오디오 6개가 보인다고 검증이 끝난 것은 아니었다

픽셀에서 재생 버퍼까지

압축한 영상이 세그먼트와 CDN을 거쳐 재생되는 흐름을 따라갑니다.

  1. 1080p 영상의 데이터량부터 다시 계산하기 — 스트리밍의 기초 4가지
  2. 373MB/s에서 6Mbps로 — 조건을 명시하고 이해하는 H.264 압축
  3. 라이브 영상이 그냥 파일이라고? — HLS의 미친 발상
  4. HLS와 DASH가 미디어 조각을 공유하는 방법 — CMAF
  5. 시청자 수와 비트레이트로 계산하는 CDN 전송량과 비용
  6. 버퍼링은 왜 생기나 — TCP HoL Blocking부터 Origin Shield까지

MediaMTX의 시작과 종료

콜백, 출력, 감시 작업이 종료 시점에 남기는 문제와 기여 기록.

  1. 시작조차 못 한 명령은 stderr를 남길 수 없다: 빠진 7종 훅 콜백
  2. 실패한 명령이 종료 코드 0으로 보인 이유: 빠진 return 하나의 영향
  3. 훅 로그를 더 모으면 종료도 더 기다릴까: 유실률과 역압력 실험
  4. Close가 반환했는데 인증서 watcher는 살아 있었다
  5. MediaMTX 종료가 멈춘 이유: 시작하지 않은 인증서 감시 작업을 기다리고 있었다

배포 이후에도 돌아오는 서비스

Shakedown의 배포·재시작·데이터베이스 복원 판단을 이어 읽습니다.

  1. 선택한 배포 계획을 AWS에 적용하고, 장애 뒤 복구까지 확인하기
  2. TLS로 연결됐는데도 더 확인한 것: MySQL 호스트 검증과 MongoDB 장애 전환
  3. 백업이 있다는 말 대신 복원한 데이터로 확인했습니다
  4. 재부팅 후에는 살아나고, 삭제 후에는 살아나지 않아야 했습니다