cloudflare·2026년 7월 30일·4분 읽기큐레이션 요약

대규모 도그푸딩: cdnjs를 Cloudflare의 개발자 플랫폼으로 마이그레이션하기

cdnjs는 2026년 6월 23일부터 Cloudflare Developer Platform만으로 운영되며, 이를 통해 하루 90억 건의 요청을 처리하는 대규모 오픈소스 CDN의 배포 파이프라인까지 단일 플랫폼으로 통합했다. 기존 시스템은 안정적이고 높은 캐시 적중률을 유지했지만, GCP·VM·GitHub·Cloudflare로 분산된 구조 때문에 관측성과 유지보수가 어려웠다. 이번 마이그레이션은 성능 개선보다 배포·처리 과정의 단순화, 추적 가능성, 보안성 향상에 초점을 둔 것이다. ### cdnjs가 여전히 대규모 트래픽을 처리하는 이유 - cdnjs는 JavaScript와 CSS 오픈소스 라이브러리를 무료로 제공하는 커뮤니티 기반 CDN이다. - 사용자는 API 키나 회원가입 없이 `<script>` 태그만으로 jQuery, Bootstrap, Lodash 등을 불러올 수 있다. - 전체 웹사이트의 약 12%, JavaScript CDN 시장의 48.3%가 cdnjs를 사용한다. - 하루 약 90억 건, 초당 평균 10만 8천 건의 요청을 처리하며 330개 이상의 Cloudflare 데이터센터에서 서비스한다. - 캐시 적중률은 98.6%에 달한다. - URL 규칙이 일관되고 버전이 불변이어서 ChatGPT, Claude, Cursor 같은 LLM이 예제 코드에 안정적으로 활용하기 쉽다. - 각 파일에 SRI 해시가 제공되고 미러가 감사 가능해 공급망 공격 대응에도 유리하다. - 무료·무제한 서비스라는 점 역시 cdnjs가 계속 사용되는 중요한 이유다. ### 기존 아키텍처의 배경 - 2020년 파일 제공 영역은 Cloudflare Workers와 KV로 이전됐다. - KV 장애 시에는 베어메탈 오리진을 사용하는 구조로 복원력을 높였다. - Brotli와 gzip으로 모든 자산을 사전 압축해 응답 크기도 줄였다. - 그러나 새 버전 감지, 패키지 다운로드, 압축, 처리 결과 저장을 담당하는 퍼블리싱 파이프라인은 GCP에 남아 있었다. - 당시 Workers에는 장시간 실행 작업, 대용량 아카이브 처리, 다단계 오케스트레이션을 지원할 기능이 충분하지 않았다. - 이에 따라 GCP Functions, VM 기반 `git-sync`, GCS, Pub/Sub, GitHub 저장소가 서로 연결된 형태로 운영됐다. ### 관측성과 데이터 일관성의 문제 - 하나의 패키지 업데이트가 Cloud Functions, GCS 이벤트, Pub/Sub, `git-sync` VM, Workers KV를 거쳤지만 공통 correlation ID가 없었다. - GCP Logging과 Cloudflare Logpush의 로그를 연결할 기준이 없어 장애 원인을 수작업으로 추적해야 했다. - 처리 결과가 KV에는 기록됐지만 GitHub 저장소 반영에 실패하는 부분 성공(partial success)이 발생할 수 있었다. - 두 저장소가 불일치해도 전체 파이프라인 상태를 아는 시스템이나 자동 알림이 없었다. - 파일은 엣지의 KV와 GitHub 저장소에 동시에 존재했지만 어느 쪽도 명확한 단일 원본이 아니었다. ### 이벤트 기반 파이프라인의 한계 - 여러 Cloud Functions가 공유 스토리지에 파일을 기록하고, 스토리지의 새 파일 이벤트가 다음 함수를 호출하는 방식이었다. - 스토리지가 메시지 큐 역할까지 맡으면서 구조가 복잡해졌다. - 명시적인 dead-letter queue가 없어 실패한 작업을 확인하기 어려웠다. - 대기 중인 작업의 backlog를 파악하기 어렵고, 특정 단계부터 깔끔하게 재실행하기도 힘들었다. - npm 업데이트 확인만 해도 알파벳별로 나눈 26개의 Cloud Functions가 필요했다. - 각 함수마다 별도의 배포와 로그가 있어 전체 시스템의 정상 여부를 확인하려면 26개를 모두 점검해야 했다. ### GitHub 저장소의 규모 문제 - `git-sync` VM은 처리된 모든 파일을 GitHub 저장소에 미러링했다. - 저장소의 packed storage가 1.1TB를 넘으면서 GitHub의 tarball·zip 아카이브 생성이 불가능해졌다. - 클론 속도가 느려지고 포크도 사실상 어려워졌다. - 비정상적이거나 처리하기 곤란한 릴리스를 차단하기 위한 `.gitignore` 항목이 274개까지 늘어났다. - GitHub 저장소는 원본 저장소이면서 동시에 배포 미러 역할까지 맡아 장기적인 확장에 부적합해졌다. ### 보안과 운영 부담 - GCP Functions, `git-sync` VM, 컨테이너 이미지, GCS 버킷, 서비스 계정 키 등 관리해야 할 보안 대상이 많았다. - 각 구성 요소마다 패치, 접근 권한 관리, 감사가 필요했다. - 기존 파이프라인을 폐기하면서 최근 발견된 cdnjs 관련 취약점도 함께 줄일 수 있었다. - 시스템 구성 요소가 줄어들어 장애 대응과 보안 관리가 단순해졌다. ### Cloudflare Developer Platform으로의 재구축 - 새 아키텍처는 Workers, Workflows, D1, Queues, Workers Cache, R2, KV, Containers를 사용해 Cloudflare 안에서 전체 파이프라인을 운영한다. - R2가 파일 콘텐츠의 단일 원본(single source of truth)이 됐다. - 실질적인 크기 제한이 없어 기존 KV에 저장하기 어려웠던 소스 맵, 대형 번들, 폰트 패키지도 함께 저장할 수 있다. - R2의 S3 호환 API를 통해 cdnjs 전체 카탈로그를 일반적인 S3 클라이언트로 접근하고 미러링할 수 있다. - 저장소와 처리 시스템을 하나의 플랫폼으로 통합함으로써 배포 상태 추적, 재처리, 장애 분석을 개선할 기반을 마련했다. ### 실용적인 시사점 대규모 서비스에서는 높은 성능이나 캐시 적중률만으로 충분하지 않다. 여러 클라우드와 저장소에 걸친 파이프라인은 부분 성공, 데이터 불일치, 로그 단절 문제를 만들 수 있으므로, 명확한 단일 원본과 공통 추적 ID, 재처리 가능한 작업 큐를 설계하는 것이 중요하다. 또한 플랫폼이 장시간 작업과 대용량 데이터를 지원할 만큼 성숙해졌다면, 분산된 운영 스택을 통합하는 것이 기능 추가와 보안 관리에 큰 이점이 된다.

원문 읽기(새 탭에서 열림)

content-delivery-networkCloudflare Workers서버리스cloudflare-r2+3

netflix·2026년 4월 2일원문

대규모 환경에서의 더 스마트한 라이브 스트리밍: 모든 넷플릭스 라이브 이벤트에 VBR 도입 (새 탭에서 열림)

넷플릭스는 전 세계 라이브 스트리밍 서비스의 효율성과 품질을 최적화하기 위해 기존의 고정 비트레이트(CBR) 방식을 가변 비트레이트(VBR)로 전면 교체했습니다. VBR 도입을 통해 네트워크 트래픽을 평균 15% 절감하고 리버퍼링 현상을 5% 줄이는 성과를 거두었으나, 장면 복잡도에 따라 급변하는 비트레이트 특성상 서버 과부하를 예측하기 어려워지는 기술적 과제에 직면했습니다. 이를 해결하기 위해 넷플릭스는 실시간 트래픽 수치 대신 명목 비트레이트(Nominal Bitrate)를 기준으로 서버 용량을 예약 관리하는 전략을 도입하여 대규모 생중계 환경에서도 시스템 안정성을 확보했습니다. ## 라이브 스트리밍에 VBR을 도입한 이유 * **전송 효율 극대화**: CBR은 정적인 장면에서도 고정된 데이터를 소모하여 대역폭을 낭비하지만, VBR(QVBR)은 장면의 복잡도가 낮을 때 비트레이트를 대폭 낮추고 복잡한 장면에서만 비트를 집중 투입하여 효율을 높입니다. * **사용자 경험 개선**: 데이터 전송량이 평균적으로 감소함에 따라 시작 지연 시간(Start-up delay)이 단축되고, 시간당 리버퍼링 발생 횟수가 약 5% 감소하는 효과를 확인했습니다. * **네트워크 부하 경감**: 전체 이벤트 전송 바이트는 15%, 피크 타임 트래픽은 약 10% 감소하여 넷플릭스의 자체 CDN인 오픈 커넥트(Open Connect)의 운영 효율이 크게 향상되었습니다. ## 가변 비트레이트가 유발하는 시스템 불안정성 * **예측 불가능한 트래픽 패턴**: CBR 환경에서는 현재 트래픽을 통해 서버 수용량을 쉽게 예측할 수 있었으나, VBR은 화면 구성에 따라 비트레이트가 급락하거나 치솟기 때문에 단순 측정만으로는 서버의 실제 여유 자원을 판단하기 어렵습니다. * **서버 과점유(Over-admitting) 위험**: 잔잔한 장면이 이어져 비트레이트가 낮게 유지될 때, 트래픽 스티어링 시스템이 서버가 유휴 상태라고 판단하여 너무 많은 세션을 할당할 수 있습니다. * **동시 스파이크 발생**: 경기 중 꽃가루가 뿌려지거나 카메라가 빠르게 회전하는 등 화면이 복잡해지는 순간, 모든 세션의 비트레이트가 동시에 급증하면서 네트워크 인터페이스 카드(NIC)의 한계를 초과하고 패킷 손실 및 장애를 유발할 수 있습니다. ## 예약 기반 용량 관리를 통한 해결책 * **실제 트래픽 대신 명목 수치 사용**: 서버의 가용 용량을 결정할 때 현재 전송 중인 실제 비트레이트가 아닌, 스트림에 설정된 최대치인 '명목 비트레이트'를 기준으로 계산합니다. * **용량 예약(Capacity Reservation)**: 특정 스트림이 현재 낮은 대역폭을 사용하더라도, 언제든 복잡한 장면에서 높은 비트레이트로 튈 수 있음을 전제하고 미리 용량을 할당해 둡니다. * **안정적인 트래픽 제어**: 이러한 접근 방식을 통해 VBR의 효율성은 그대로 누리면서도, CBR 시절의 예측 가능성을 확보하여 급격한 장면 변화 시에도 서버가 안정적으로 트래픽을 처리할 수 있게 되었습니다. ## 실용적인 결론 대규모 라이브 시스템에서 VBR을 도입할 때는 단순히 인코딩 설정을 바꾸는 것에 그치지 않고, **모니터링 및 트래픽 스티어링 로직을 실제 부하가 아닌 논리적인 예약(Reservation) 기반으로 재설계**해야 합니다. 이는 자원 활용의 극단적인 효율성보다는 시스템의 가용성과 안정성을 우선시하는 전략으로, 대규모 트래픽 스파이크가 빈번한 라이브 환경에서 필수적인 접근입니다.

content-delivery-networklive-streamingaws-elemental-medialivevariable-bitrate+4

netflix·2025년 12월 15일원문

Netflix Live Origin. Xia (새 탭에서 열림)

넷플릭스의 라이브 오리진(Live Origin)은 클라우드 라이브 스트리밍 파이프라인과 자사 콘텐츠 전송 네트워크(CDN)인 오픈 커넥트(Open Connect) 사이에서 콘텐츠 공급을 조율하는 핵심 마이크로서비스입니다. 이 시스템은 다중 파이프라인 구조와 지능적인 세그먼트 선택 로직을 통해 실시간 방송 중 발생할 수 있는 데이터 손실이나 지연을 효과적으로 방지합니다. 결과적으로 넷플릭스는 라이브 환경에서도 VOD 수준의 안정성과 고품질 시청 경험을 전 세계 사용자에게 제공할 수 있게 되었습니다. **다중 파이프라인 기반의 탄력적인 아키텍처** 라이브 스트리밍은 실시간 특성상 프레임 누락이나 세그먼트 손실 같은 결함이 발생할 가능성이 높습니다. 라이브 오리진은 이를 극복하기 위해 다음과 같은 전략을 사용합니다. * **이중화된 파이프라인:** 서로 다른 클라우드 리전에서 독립적으로 운영되는 중복 파이프라인을 운영하여, 한쪽 경로에 결함이 생겨도 다른 경로의 정상 세그먼트를 즉시 선택할 수 있습니다. * **지능적 후보 선택:** 패키저에서 수행된 미디어 검사 메타데이터를 활용하여, 여러 후보 세그먼트 중 가장 품질이 좋은 것을 결정론적 순서에 따라 선택합니다. * **에포크 로킹(Epoch Locking):** 클라우드 인코더 단계부터 적용된 에포크 로킹 기술을 통해 오리진이 여러 파이프라인의 세그먼트 중 최적의 결과물을 일관되게 식별하고 조합할 수 있도록 합니다. **오픈 커넥트와의 스트리밍 최적화** 기존 VOD에 최적화되어 있던 오픈 커넥트(Open Connect) 인프라를 라이브에 맞게 확장하여 효율적인 전송 구조를 구축했습니다. * **요청 병합(Request Collapsing):** 동일한 세그먼트에 대해 수많은 클라이언트 요청이 동시에 몰릴 때, 오리진에는 단 하나의 요청만 보내고 나머지는 응답을 기다리게 하여 서버 부하(Thundering Herd 문제)를 방지합니다. * **세그먼트 템플릿 활용:** 오픈 커넥트 가전(OCA)은 라이브 이벤트 설정 데이터를 기반으로 유효한 세그먼트 범위를 미리 파악하며, 범위를 벗어난 잘못된 요청을 사전에 차단합니다. * **적응형 채우기(Adaptive Fill):** 오리진은 응답 헤더를 통해 OCA에 백업 파이프라인 위치를 알려줍니다. 특정 리전의 오리진에 문제가 발생하면 OCA가 스스로 다른 리전의 오리진으로 전환하여 데이터를 가져옵니다. **효율적인 저장소 관리 및 관찰 가능성** AWS EC2 인스턴스에서 동작하는 라이브 오리진은 대규모 트래픽과 데이터를 관리하기 위해 정교한 리소스 관리 기법을 도입했습니다. * **계층화된 스토리지:** 실시간으로 자주 액세스되는 세그먼트는 RAM에 저장하고, 상대적으로 덜 빈번한 데이터는 SSD에 저장하는 계층 구조를 통해 응답 속도를 극대화했습니다. * **자동 가비지 컬렉션:** 라이브 이벤트의 진행 상황에 맞춰 오래된 세그먼트를 자동으로 삭제하는 시간 기반 가비지 컬렉션을 수행하여 스토리지 공간을 효율적으로 유지합니다. * **실시간 모니터링:** 수천 개의 지표를 실시간으로 수집하여 파이프라인의 건강 상태를 추적하며, 장애 발생 시 즉각적인 대응이 가능한 가시성을 확보하고 있습니다. 라이브 오리진은 단순한 저장소를 넘어 라이브 스트리밍의 안정성을 결정짓는 지능형 브로커 역할을 수행합니다. 실시간 방송의 불확실성을 소프트웨어 계층의 이중화와 지능적 선택 로직으로 해결하고자 하는 기술적 접근은 대규모 라이브 서비스를 설계할 때 중요한 이정표가 됩니다. 특히 클라이언트의 복잡도를 낮추면서 서버 측에서 장애를 복구하는 설계 방식은 사용자 경험을 최우선으로 하는 서비스 기획에 필수적인 요소입니다.

content-delivery-networkAWS마이크로서비스live-streaming+4