클라우드 컴퓨팅 및 데이터 센터

프로덕션 부하에서 블로그를 마이그레이션하기 전에 Cloudflare가 EmDash 플랫폼을 테스트한 방법

Cloudflare Blog는 Astro를 기반으로 구축된 콘텐츠 관리 시스템인 EmDash로 마이그레이션하면서, 마이그레이션 위험을 줄이기 위해 다중 캐시 계층, 부하 테스트, 점진적 배포를 사용했다. 회사는 초기 결과로 초당 최대 850건의 요청을 처리했으며, 에이전트를 통해 콘텐츠에 접근하고 관리하기 위한 MCP도 시험했다고 밝혔다.

2026-08-24
4 분 읽기
10 조회수
فريق تحرير certi.news
프로덕션 부하에서 블로그를 마이그레이션하기 전에 Cloudflare가 EmDash 플랫폼을 테스트한 방법

Cloudflare는 8월 12일 블로그를 EmDash로 마이그레이션했다. EmDash는 Astro 및 Cloudflare와 함께 작동하도록 구축된 콘텐츠 관리 시스템으로, 이 프로젝트는 단순한 인터페이스 재설계에 그치지 않았다. 회사는 실제 프로덕션 트래픽에서 새 플랫폼을 테스트하기 위해 블로그를 ‘제로 클라이언트’로 활용했으며, 확장성, 응답 속도, 기존 시스템에서의 안전한 전환에 초점을 맞췄다.

Cloudflare에 따르면 마이그레이션 과정에서 블로그의 규모와 복잡성에 따른 요구 사항이 드러났고, 팀은 EmDash를 더 넓은 범위에 출시하기 전에 개선할 수 있었다. 결과와 측정값은 회사 자체에서 제공한 것이므로, 이는 플랫폼에 대한 독립적인 테스트가 아니라 한 회사가 공개한 운영 경험을 의미한다.

성능 테스트에 앞선 플랫폼 테스트

팀은 실용적인 질문에서 시작했다. EmDash가 실제로 Cloudflare의 요구 사항에 맞는가? 이를 위해 게시물 생성, 게시, 게시 취소, 예약, 미디어 추가와 같은 기본 경로를 테스트했으며, 콘텐츠 엔터티 검색과 작성자 이름 관리도 확인했다.

가장 큰 격차는 대규모 미디어와 콘텐츠 처리, 번역 세부 사항, 검색엔진 최적화, 콘텐츠 보안 정책(CSP)에서 나타났다. 또한 관리 편집기에는 사용자 지정 HTML 블록을 찾고 콘텐츠 편집기 내부의 오류를 처리하며, 긴 게시물을 편집하는 동안 서식 표시줄을 계속 표시하기 위한 개선이 필요했다.

예약 게시물은 발견된 문제 중 가장 두드러졌다. EmDash 0.19.0이 출시될 때까지도 작동하지 않았기 때문이다. 이 사례는 새 시스템에 의존하기 전에 전체 운영 경로를 테스트하는 것이 중요하다는 점을 보여준다. 콘텐츠를 생성하거나 즉시 게시하는 테스트에서는 이 결함이 반드시 드러나지 않았을 수 있다.

변동하는 트래픽을 모방한 부하 테스트

Cloudflare Blog의 일반적인 트래픽은 초당 약 75건의 요청이었지만, 새 게시물이 확산될 때나 특정 게시 시간과 무관한 급증으로 인해 초당 5,000건을 넘을 수 있었다. 이에 팀은 오픈 소스 도구인 k6를 사용해 테스트를 설계했다. 테스트에는 기준선의 세 배까지 부하를 점진적으로 늘리는 방식, 0에서 시작해 10분 동안 초당 100건의 요청에 도달하는 방식, 초당 7,000건의 요청을 1분 동안 즉시 발생시키는 폭발 테스트가 포함됐다.

실패 기준은 세 가지 지표를 기반으로 했다. HTTP 5xx 오류가 0.01%를 초과하지 않아야 하고, 요청의 95%에 대한 응답 시간이 500밀리초를 초과하지 않아야 하며, 99%에 대한 응답 시간이 1초를 초과하지 않아야 했다. 이러한 한도는 ‘플랫폼이 빠른가?’라는 질문을 측정 가능한 운영 조건으로 바꿨다.

다중 계층 구조와 명확한 롤백 경로

Cloudflare는 Workers Cache 뒤에서 Cloudflare Worker로 EmDash를 실행하고, Workers KV를 기반으로 EmDash에 새 객체 저장소를 사용했으며, PlanetScale과 Hyperdrive를 통합했다. 회사의 데이터에 따르면 캐시 계층은 정적 파일의 99.5%를 캐시에서 제공했고 전체 요청의 약 70%도 캐시에서 처리해 데이터베이스에 가해지는 부담을 줄였다.

전환 중 서비스 중단을 방지하기 위해 팀은 기존 블로그와 새 사이트 사이에서 요청을 분배하는 Proxy Worker를 만들었다. 이 Worker는 쿠키를 통해 실험 버전을 지정했으며, 새 사이트에서 500 오류가 발생하면 요청을 기존 시스템으로 되돌릴 수 있었다. 또한 공개 도메인, DNS 및 TLS 처리, 외부 HTTP 연결을 거치지 않도록 NEW_BLOG 서비스 바인딩을 통해 Workers 간 직접 연결을 사용했다.

점진적 배포는 트래픽의 1%에서 시작해 5%, 15%로 증가한 뒤 하루가 끝날 때 100%에 도달했다. 이를 통해 대다수 독자를 불안정한 변경에 노출하지 않고 실제 부하를 모니터링하며 엣지 케이스를 발견할 수 있었다.

실제로 무엇이 바뀌었나?

Cloudflare는 새 구조가 이전 플랫폼에 비해 더 안정적인 응답 시간을 유지했으며, 초당 최대 850건의 요청을 처리하는 동안 성능 향상과 제한적인 오류가 나타났다고 밝혔다. Agents Week 동안 9일에 걸쳐 18개의 블로그 게시물이 게시되어 약 300만 회의 조회를 기록했고, 새 Worker는 눈에 띄는 문제 없이 초당 최대 450건의 요청을 처리했다. 회사에 따르면 통합 DDoS 보호 기능은 8월 10일 초당 28,000건의 요청에 달한 공격도 흡수했다.

변경 사항에는 Kumo 디자인 시스템의 패턴에 따라 다시 구축한 인터페이스도 포함됐다. 시스템 설정과 수동 전환 버튼을 기반으로 밝은 모드와 어두운 모드를 기본 지원한다. 이메일 구독 요청은 글의 끝으로 이동했고, 탐색과 공유를 개선하기 위해 ‘이 페이지에서’ 목차와 ‘온라인에서 토론’ 옵션이 추가됐다.

새로운 EmDash 인터페이스와 AI 검색 엔드포인트를 통해 Cloudflare Blog용 MCP 서버를 몇 시간 만에 만들 수 있었다. 이 서버에는 게시물을 검색하고 나열하며 가져오고 태그를 나열하는 도구가 포함됐다. 또한 출처에 따르면 EmDash 전용 MCP 서버는 작성자가 추가 비용 없이 콘텐츠를 탐색하고 생성하며 편집하고 게시하고 예약하고 파일을 제거할 수 있도록 한다.

편집 경험 자체는 여전히 완성되지 않았다. Cloudflare는 예약 게시물과 관련된 사소한 문제와 오류를 계속 기록했으며, 이를 EmDash 팀에 전달했고 Birthday Week 전에 수정될 것으로 예상한다고 밝혔다. 따라서 이 사례는 플랫폼에 제약이 없다는 증거가 아니다. 다만 성능보다 먼저 콘텐츠 경로를 테스트하고, 명확한 실패 임계값을 정하고, 롤백 경로를 구축한 뒤, 한 번에 전면 전환하는 대신 배포 범위를 점진적으로 확대하는 실천 방법을 보여준다.

뉴스 출처
Cloudflare Blog
원문 보기 ↗
ف
작성자

فريق تحرير certi.news

같은 카테고리

추천 기사

모든 뉴스 보기