Reddit

The Cloudflare Blog – Brought to you by EmDash

Cloudflare 블로그, EmDash로 옮겼습니다

Cloudflare가 블로그를 Astro와 Cloudflare에 맞춰 만든 CMS EmDash로 이전한 과정을 공개했습니다. k6 부하 테스트와 단계적 트래픽 전환으로 무중단 이전을 진행했고, 새 캐시 구조로 요청의 70%를 캐시에서 처리하며 최대 850 RPS까지 성능과 안정성을 확인했습니다.

에디터 노트

이 글은 CMS 홍보가 아니라 'Customer Zero'라는 사내 강령의 실행 기록에 가깝습니다. Cloudflare는 외부 업체를 쓸 때 입증 책임을 묻듯 EmDash를 자사 블로그에 먼저 적용해 결함을 드러냈습니다. 예약 발행이 0.19.0까지 고장 났다는 사실까지 적었습니다. 제품을 팔면서 버그 목록을 공개하는 건 보기 드문 자신감입니다. 무중단 이전의 방법론도 구체적입니다. 버전 쿠키를 둔 프록시 Worker로 구·신 사이트를 나누고, 서비스 바인딩으로 DNS·TLS를 거치지 않았으며, 1%에서 시작해 당일 100%로 전환했습니다. 다만 Reddit의 첫 반응은 차가웠습니다. 낮은 대비의 회색 본문이 "2010년대 초반 웹 디자인 악몽"이라는 조롱을 받았습니다. 성능은 합격, 글씨는 재시험인 셈입니다.

AI 요약

Cloudflare가 블로그를 기존 CMS에서 EmDash로 이전했습니다. EmDash는 Astro와 Cloudflare 환경에 맞춰 만든 콘텐츠 관리 시스템(CMS)입니다. 블로그 개편은 외관 변경뿐 아니라 운영 환경을 새 플랫폼으로 옮기는 프로젝트였습니다. Cloudflare는 자사 제품을 먼저 직접 사용하고 검증하는 방식을 ‘Customer Zero’라고 부르며, 이번 이전도 EmDash를 내부에서 먼저 운영하는 사례로 설명합니다.

실제 사용 흐름과 초기 결함

이전 검토는 두 가지 질문에서 출발했습니다. EmDash가 Cloudflare의 업무에 맞는지, 그리고 블로그 트래픽을 감당할 수 있는지입니다. 게시물 작성과 발행 취소, 예약 발행, 미디어 추가 등 일반적인 작업을 시험했습니다. 전반적으로 사용 흐름은 잘 작동했지만, Cloudflare 블로그의 콘텐츠와 미디어 규모, 콘텐츠 검색, 작성자 표시에서 부족한 점이 드러났습니다. 현지화, 검색엔진 최적화(SEO), 콘텐츠 보안 정책(CSP)도 조정이 필요했습니다. 편집기에서는 사용자 지정 HTML 블록을 찾기 어렵고, 본문 편집기 버그와 긴 글에서 서식 도구 모음이 사라지는 문제도 확인했습니다.

가장 큰 누락은 예약 게시였습니다. 이 기능은 EmDash 0.19.0 전까지 작동하지 않았습니다. Cloudflare는 초기 버전에서 생길 수 있는 문제로 보면서도, 예약 시간이 지난 뒤 발견하고 싶지는 않았다고 밝혔습니다.

k6 부하 테스트와 운영 구조

블로그는 평상시 초당 약 75건의 요청(RPS)을 받으며, 게시물 인기에 따라 5,000 RPS를 넘는 급증도 발생합니다. Cloudflare는 오픈소스 부하 테스트 도구 k6로 세 가지 상황을 시험했습니다. 평상시 기준의 세 배까지 점진적으로 부하를 올리는 램프 테스트, 10분 동안 0에서 100 RPS까지 올리며 한계를 찾는 브레이크포인트 테스트, 즉시 7,000 RPS를 보내는 버스트 테스트입니다.

요청 중 0.01%를 넘는 비율로 5xx 오류가 나면 가용성 기준을 통과하지 못한 것으로 봤습니다. 지연 시간은 95백분위수(P95)가 500ms 미만, 99백분위수(P99)가 1,000ms 미만이어야 했습니다. 테스트와 내부 검토를 거쳐 EmDash를 Cloudflare Worker에서 실행하고 Workers Cache 뒤에 배치했습니다. Cloudflare는 Workers Cache를 적용한 대형 사이트 중 자신들이 첫 사례라고 설명합니다. Workers KV 기반 EmDash 객체 캐시도 추가했으며, 데이터베이스 연결에는 PlanetScale과 Cloudflare의 Hyperdrive 통합을 사용했습니다.

여러 캐시 계층을 둔 결과 정적 파일의 99.5%를 캐시에서 제공하고, 전체 요청의 70%를 캐시에서 처리합니다. 새 구조는 최대 850 RPS를 처리하는 동안 성능 개선과 적은 오류를 보였습니다. 기존 환경에서는 부하에 따라 응답 지연이 간헐적으로 튀었지만, 새 환경에서는 응답 시간이 비교적 일정했다고 밝혔습니다.

무중단 이전과 디자인 개편

Cloudflare는 장애가 생기면 기존 블로그로 되돌릴 수 있도록 프록시 Worker를 만들었습니다. 요청에 버전 쿠키를 설정해 신·구 사이트로 트래픽을 나누고, 새 사이트에서 500 오류가 나면 기존 사이트로 전환했습니다. 프록시 Worker와 새 블로그 Worker는 서비스 바인딩으로 직접 연결했습니다. 공용 호스트 이름과 DNS, TLS, 외부 HTTP 연결을 거치지 않아 프록시 구간의 지연을 줄였습니다.

출시 당일에는 트래픽 1%부터 시작해 5%, 15% 순으로 비율을 높이며 시스템 상태를 확인했고, 당일 100% 이전을 마쳤습니다. 프런트엔드는 Kumo 디자인 시스템의 패턴에 맞춰 다시 구성했습니다. 시스템 설정에 따른 라이트·다크 모드와 수동 전환 기능을 넣고, 긴 기술 글을 위한 목차와 온라인 토론 링크도 추가했습니다. 검색창으로 오인받던 이메일 구독 입력란은 글 하단으로 옮겼습니다.

블로그 검색과 편집을 위한 MCP

독자는 블로그용 Model Context Protocol(MCP) 서버를 통해 게시물 검색, 목록 조회, 글 가져오기, 태그 목록 조회를 에이전트에서 사용할 수 있습니다. Cloudflare는 EmDash API와 AI 검색 엔드포인트를 활용해 MCP 서버를 몇 시간 만에 만들었다고 설명합니다. 작성자용 EmDash MCP 서버도 있어 콘텐츠 탐색과 작성·수정, 게시·예약, 파일 삭제 등을 처리합니다.

Agents Week에는 9일 동안 새 글 28편을 게시했고, 약 300만 페이지뷰를 기록했습니다. 블로그 Worker는 최대 450 RPS를 별다른 문제 없이 처리했습니다. 8월 10일에는 28,000 RPS 규모의 DDoS 공격도 Cloudflare의 기본 DDoS 방어 기능으로 흡수했다고 밝혔습니다. 편집기와 예약 게시 관련 문제는 추가로 발견해 EmDash 팀에 전달했습니다.

Reddit 반응

  • @u/rotationalsymmetry — 그리고 개편한 블로그 전체에 대비가 아주 낮은 회색 글꼴을 썼네요. 전형적입니다. 2010년대 초반 웹 디자인의 악몽이 아직 사라지지 않아 다행입니다.
  • @u/Vimda — Cloudflare 블로그는 WordPress가 아니라 Ghost 사이트였습니다.

원문: Cloudflare Blog / 번역·요약: Trawling