실시간 통신, 미디어 처리, AI 통합에 대한 심층 분석.
Agora SDK를 중심으로 프로덕션 레벨의 구현을 다룹니다.
primary 카테고리 또는 태그로 Backend에 속한 글을 모두 표시합니다.
인증서의 Not After 확인, 고객 제공 인증서와 관리형 인증서의 갱신 책임, ACME DNS-01 challenge를 설명합니다. `_acme-challenge` TXT 값과 CNAME 위임을 구분하고 `dig`·`openssl`로 DNS propagation, certificate chain, CAA 영향을 확인하는 운영 절차를 정리했습니다.
일반 APNs 알림과 PushKit VoIP push의 token·topic·payload·처리 수명주기를 구분합니다. PushKit callback에서 CallKit 통화를 보고하고 RTC 연결을 시작하는 흐름, server-side push 인증, Apple 정책상 주의사항을 공식 문서 기준으로 설명합니다. 관리형 알림 연동과 직접 구축의 책임 범위도 비교합니다.
TTFB를 DNS 조회, connection, TLS handshake, request 전송, server 처리, first-byte 전송 구간으로 나눕니다. curl timing 값과 browser Network panel을 함께 읽고 connection reuse·HTTP version·cache 상태를 기록해 병목을 구분합니다. ICMP ping만으로 HTTP 지연 원인을 판단할 수 없는 이유도 설명합니다.
녹화 파일을 중간 위치로 탐색할 때 멈추는 문제를 MP4 index, HLS playlist 종료 상태, timestamp discontinuity 관점에서 진단합니다. `ffprobe`, manifest 검사, ffmpeg remux가 각각 확인하거나 복구할 수 있는 범위를 구분하고, 원본 segment 누락처럼 후처리로 복구할 수 없는 경우도 명시합니다.
Google TTS 결과를 R2에 캐시하고 브라우저에 전달하는 서버 파이프라인을 다룹니다. 음성 출력에 영향을 주는 모든 설정을 canonical JSON으로 묶어 캐시 키를 만들고, 동시 cache miss와 stale metadata를 처리하며, R2 저장 후 DB를 갱신하는 순서를 설명합니다. 인증·rate limit·내구성 있는 후속 작업까지 포함한 운영 기준도 함께 정리했습니다.
Individual recording 결과를 참가자별 VOD나 하나의 composite 화면으로 후처리하는 FFmpeg 파이프라인을 설명합니다. M3U8과 TS를 점검하고 기록된 track의 시작 시각을 맞춘 뒤, audio-only·video-only 입력과 참가자 수를 검증해 레이아웃을 구성합니다. 입력값 제한, 경로 검증, 실패 복구를 포함한 자동화 기준도 함께 다룹니다.
FFmpeg에서 컨테이너, 코덱, 스트림을 구분하고 probe·demux·decode·filter·encode·mux 단계가 어떻게 연결되는지 설명합니다. `-c copy`는 입력 코덱과 출력 컨테이너, timestamp와 keyframe 조건이 맞을 때만 안전합니다. remux, transcoding, stream mapping, seek, concat을 선택하는 기준을 실제 명령으로 정리했습니다.
Cloud Recording 결과에 포함된 M3U8 재생목록과 MPEG-TS 세그먼트를 읽는 방법을 설명합니다. MP4의 `moov` 위치와 fragmented MP4를 구분하고, TS packet·PES·codec frame의 관계, HLS 태그, target duration 규칙을 살펴봅니다. Agora의 track event와 slice 파일명은 공식 형식에 맞춰 해석합니다.
Individual, Composite(`mix`), Web page recording의 출력과 처리 범위를 비교합니다. Individual은 참가자별 track 후처리에, Composite는 서버 합성과 고정 레이아웃 출력에, Web page recording은 웹 화면 캡처에 맞습니다. 과금은 모드 이름이 아니라 스트림 수·시간·합산 해상도 등 공식 가격 기준으로 확인해야 합니다.
데이터 위치·처리자·보유 방식에 대한 계약이나 규제 요구가 Cloud Recording의 데이터 흐름과 맞지 않을 때 On-Premise Recording을 검토할 수 있습니다. 이 글은 배포 위치, 운영 책임, 후처리 통제 범위를 Cloud 방식과 비교하고 raw-data callback은 사용하는 SDK 버전의 API 계약으로 확인해야 한다는 기준을 제시합니다.
WebRTC는 미디어 저장 방식을 정의하지 않으므로 녹화가 필요하면 별도 파이프라인을 설계해야 합니다. 이 글은 브라우저 `MediaRecorder`, 자체 미디어 서버, Agora Cloud Recording의 통제 범위와 운영 부담을 비교합니다. Cloud Recording의 non-streaming client 모델, `acquire → start → query → stop` 수명주기, REST 인증과 RTC token의 역할도 구분합니다.
Cloud Recording 산출물이 object storage에 기록되는 방식과 장애 후 처리 절차를 설명합니다. TS·M3U8·MP4의 분할 조건, recording server failover 시 생성되는 backup playlist, stop·query 응답의 file list를 구분합니다. 애플리케이션에서는 사용자 소유권을 확인한 뒤 저장된 object key로 짧은 수명의 presigned URL을 발급해야 합니다.
Cloud Recording의 non-streaming client가 RTC channel에 참여해 media를 기록하는 방식과 `acquire → start → query → stop` 수명주기를 설명합니다. REST 인증과 RTC token을 구분하고, individual·composite·web page recording mode, object storage 설정, resource 만료와 stop 처리를 구현 예제로 다룹니다.