2025년 6월 12일, Cloudflare에서는 Workers KV, WARP, Access, Gateway, Images, Stream, Workers AI, Turnstile, Challenges, AutoRAG, Zaraz, 그리고 Cloudflare 대시보드의 일부를 포함한 중요한 다수의 서비스에 영향을 미치는 심각한 서비스 중단을 겪었습니다.
이 중단은 2시간 28분 동안 지속되었으며, 영향을 받은 서비스를 사용하는 전 세계의 모든 Cloudflare 고객에게 영향이 미쳤습니다. 이 중단은 Workers KV 서비스에서 사용하는 기본 스토리지 인프라의 장애로 인한 것이었습니다. 이 인프라는 많은 Cloudflare 제품에 필수적인 종속성으로, 영향을 받는 서비스 전반의 구성, 인증, 자산 전달에 사용됩니다. 이 인프라의 일부는 타사 클라우드 공급자의 지원을 받고 있는데, 오늘 이 공급자에게서 서비스 중단이 발생하여 당사 KV 서비스의 가용성에 직접적인 영향이 미쳤습니다.
이번 중단에 대해 깊이 사과드립니다. 이는 저희 측의 장애였으며, 이번 중단의 직접적인 원인(또는 트리거)은 타사 벤더의 장애였지만, 궁극적으로 저희가 선택한 종속성과 이를 설계하는 방식에 대해 책임이 있습니다.
이번 중단은 공격이나 다른 보안 이벤트의 결과가 아니었습니다. 이 사고로 인해 데이터가 손실되지는 않았습니다. Cloudflare Magic Transit 및 Magic WAN, DNS, 캐시, 프록시, WAF 그리고 관련 서비스는 이 사고의 영향을 직접적으로 받지는 않았습니다.
일반적으로 Cloudflare에서는 자체 플랫폼 구성 요소를 기반으로 서비스를 설계하고 구축하며, 따라서 Cloudflare의 많은 제품은 Workers KV 서비스에 의존하도록 설계되었습니다.
다음 표에는 사용자에게 미치는 영향, 작업 실패, 관찰된 오류율 증가 등 영향을 받은 서비스가 자세히 설명되어 있습니다.
제품/서비스 | 영향 |
|---|
Workers KV
| Workers KV에서는 요청의 90.22%가 실패했습니다. 캐시되지 않은 키-값 쌍이 Workers KV의 원본 스토리지 백엔드에서 값을 검색해야 할 때, 응답 코드 503 또는 500과 함께 요청이 실패했습니다. 나머지 요청은 Workers KV의 캐시(상태 코드 200 및 404)에서 성공적으로 처리되었거나 예상 한도 및/또는 오류 예산 범위 내에서 오류가 반환되었습니다. 이는 Workers KV에 저장된 데이터에는 영향이 미치지 않았습니다. |
Access
| Access는 Workers KV를 사용하여 사용자 신원 정보와 함께 애플리케이션 및 정책 구성을 저장합니다. 사고 동안 Access에서는 모든 애플리케이션 유형(자체 호스팅, SaaS, 인프라 포함)에 대한 ID 기반 로그인이 100% 실패했습니다. 이 사고 동안 WARP 및 Gateway와 같은 다른 서비스에서는 사용자 신원 정보를 사용할 수 없었습니다. Access는 정책 구성이나 사용자의 신원을 가져올 수 없을 때 닫히도록 설계되었습니다. 명령 로깅이 활성화된 활성 인프라 애플리케이션 SSH 세션에서 Workers KV 종속성으로 인해 로그를 저장하지 못했습니다. Access의 도메인 간 신원 시스템(SCIM) 서비스도 사용자 정보를 저장하기 위해 Workers KV 및 Durable Objects(KV에 의존함)에 의존하므로 영향을 받았습니다. 이 사고 동안 Workers KV 업데이트 실패로 인해 사용자 ID가 업데이트되지 않았습니다. 이러한 장애는 ID 공급자에게 500 오류를 반환하게 됩니다. 일부 공급자는 수동 재동기화가 필요할 수 있지만, 대부분의 고객은 ID 공급자의 재시도 로직 덕분에 Access의 SCIM 서비스가 복원된 후 즉시 서비스가 복원되는 것을 경험했을 것입니다. 서비스 인증 기반 로그인(예: 서비스 토큰, Mutual TLS, IP 기반 정책) 및 바이패스 정책은 영향을 받지 않았습니다. 이 시간 동안 Access 정책의 편집이나 변경 사항은 손실되지 않았습니다. |
Gateway
| 이 사고는 IPv4, IPv6, DNS over TLS(DoT), DNS over HTTPS(DoH) 등 대부분의 Gateway DNS 쿼리에 영향을 미치지 않았습니다. 그러나 두 가지 예외가 있었습니다. ID 기반 규칙이 적용된 DoH 쿼리가 실패했습니다. 이는 Gateway에서 필요한 사용자의 신원 정보를 검색하지 못했기 때문에 발생했습니다. 일부 사용자의 경우 인증된 DoH 서비스가 중단되었습니다. 유효한 인증 토큰이 있는 활성 세션의 사용자는 영향을 받지 않았지만, 새 세션을 시작하거나 인증 토큰을 갱신해야 하는 사용자는 영향을 받았습니다. Gateway 프록시, 송신, TLS 복호화를 사용하는 사용자는 연결, 등록, 프록시, 트래픽 기록이 불가능했습니다. 이는 최신 ID 및 장치 상태 정보를 검색하기 위해 Workers KV에 의존하기 때문이었습니다. 이들 작업에는 각각 Workers KV에 대한 호출이 필요하며, 사용할 수 없을 때 Gateway는 트래픽이 고객이 구성한 규칙을 우회하지 않도록 실패 시 닫히게 설계되었습니다. |
WARP
| WARP 클라이언트는 장치 등록 및 인증을 위해 필요한 Access 및 Workers KV에 대한 핵심 종속성으로 인해 영향을 받았습니다. 그 결과, 사고 중에는 새로운 고객이 접속하거나 가입할 수 없었습니다. Gateway 프록시를 통해 라우팅된 기존 WARP 클라이언트 사용자 세션은 Gateway에서 필요한 정책 평가가 수행될 수 없어서 중단되었습니다. 또한 기본 종속성인 Workers KV의 장애로 인해 WARP 긴급 연결 해제 재정의를 사용할 수 없게 되었습니다. 소비자 WARP는 Zero Trust 버전과 유사한 산발적으로 영향을 받았습니다. |
대시보드
| 대시보드 사용자 로그인과 대부분의 기존 대시보드 세션이 불가능했습니다. 이는 중단으로 Turnstile, DO, KV, Access에 영향이 미쳤기 때문이었습니다. 로그인 실패의 구체적인 원인은 다음과 같습니다. 표준 로그인(사용자/비밀번호): Turnstile을 사용할 수 없어서 실패했습니다. Google(OIDC) 로그인: KV 종속성 문제로 실패했습니다. SSO 로그인: Access에 대한 완전한 의존성으로 인해 실패했습니다. Cloudflare v4 API에는 이 사고 동안 영향이 미치지 않았습니다. |
Challenges 및 Turnstile
| Cloudflare Challenges와 Turnstile을 구동하는 Challenge 플랫폼은 사고 기간 동안 Workers KV 및 Durable Objects에 대한 종속성으로 인해 siteverify API 요청의 실패율이 높았고 제한 시간 초과가 많았습니다. 저희는 이와 같은 사고나 중단이 발생할 경우 이러한 호출을 비활성화하기 위한 킬 스위치를 갖추고 있습니다. 저희는 사용자가 진행하는 데 방해가 되지 않도록 이러한 킬 스위치를 활성화했습니다. 특히, 이러한 킬 스위치가 활성화되어 있는 동안 Turnstile의 siteverify API(발급된 토큰의 유효성을 검사하는 API)는 유효한 토큰을 여러 번 사용할 수 있었으며, 이는 악의적인 사용자가 이전에 유효했던 토큰을 사용하여 우회하려고 시도할 수 있는 공격을 허용할 가능성이 있었습니다. Turnstile의 봇 감지 능력에는 영향이 없었습니다. 챌린지를 해결하려고 시도한 봇은 여전히 챌린지에 실패했으므로 토큰을 받지 못했습니다. |
브라우저 격리
| 링크 기반 격리를 통한 기존 브라우저 격리 세션은 정책 Gateway에서 평가에 의존했기 때문에 영향을 받았습니다. Cloudflare Access에 대한 종속성 때문에 새로운 링크 기반 브라우저 격리 세션을 시작할 수 없었습니다. 게이트웨이 종속성으로 인해 Gateway가 시작한 모든 격리 세션이 실패했습니다. |
Images
| Cloudflare Images로의 업로드는 사고 기간 동안 영향을 받았으며, 사고가 최고조에 달했을 때 실패율이 100%에 달했습니다. 전체 이미지 전달 성공률이 약 97%로 감소했습니다. 이미지 변환은 큰 영향을 받지 않았고, Polish는 영향을 받지 않았습니다. |
Stream
| 사고 기간 동안 Stream의 오류율이 90%를 초과했으며, 이는 동영상 재생 목록이 제공될 수 없었기 때문입니다. Stream Live에서 100% 오류율이 관찰되었습니다. 동영상 업로드는 영향을 받지 않았습니다. |
Realtime
| Realtime TURN(NAT 주변 릴레이를 사용한 트래버설) 서비스는 KV를 사용하며, 큰 영향을 받았습니다. 사고 기간 동안 오류율이 100%에 근접했습니다. 기존 연결은 유지되었지만, Realtime SFU 서비스(선택적 포워딩 유닛)에서 새 세션이 생성되지 않았습니다. 이로 인해 영향 기간 동안 트래픽이 정상 트래픽의 20%로 감소했습니다. |
Workers AI
| 사고 기간 동안 Workers AI에 대한 모든 추론 요청이 실패했습니다. Workers AI는 Workers KV에 의존하여 AI 요청에 대한 구성 및 라우팅 정보를 전 세계에 배포합니다. |
Pages 및 Workers 자산
| Cloudflare Pages 및 Workers Assets에서 제공하는 정적 자산(예: HTML, JavaScript, CSS, 이미지 등)은 Workers KV에 저장되고, 캐시되며, 요청 시 검색됩니다. 이 기간 동안 Workers Assets의 평균 오류율이 전체 요청의 약 0.06% 정도 증가했습니다. 사고 기간 동안 Pages의 오류율이 약 100%까지 치솟았고, 모든 Pages 빌드가 완료되지 않았습니다. |
AutoRAG
| AutoRAG는 문서 변환 및 인덱싱 중 벡터 임베딩 생성을 위해 Workers AI 모델에 의존하며, 쿼리 및 검색을 위해 LLM 모델도 사용합니다. AutoRAG는 Workers AI 종속성 때문에 사고 기간 동안 사용할 수 없었습니다. |
Durable Objects
| SQLite로 지원되는 Durable Objects는 Workers KV와 동일한 기본 스토리지 인프라를 공유합니다. 사고 기간 동안 평균 오류율은 22%로 최고조에 달했고, 서비스가 복구되기 시작하면서 2%로 떨어졌습니다. 레거시 키-값 저장소를 사용하는 Durable Object 네임스페이스는 영향을 받지 않았습니다. |
D1
| D1 데이터베이스는 Workers KV 및 Durable Objects와 동일한 기본 스토리지 인프라를 공유합니다. Durable Objects와 유사하게, 사고 기간 동안 평균 오류율이 22%로 최고조에 달했으며, 서비스가 복구되기 시작하면서 2%로 떨어졌습니다. |
Queues 및 이벤트 알림
| 푸시 및 소비를 포함한 Queues 메시지 작업은 사고 기간 동안 사용할 수 없었습니다. Queues는 KV를 사용하여 각 Queue를 대기 중인 메시지를 포함하는 기본 Durable Objects에 매핑합니다. 이벤트 알림은 기본 전달 메커니즘으로 Queues를 사용합니다. |
AI Gateway
| AI Gateway는 Workers 위에 구축되었으며 클라이언트 및 내부 구성을 위해 Workers KV를 사용합니다. 사고 기간 동안 AI Gateway의 오류율은 종속성이 복구될 때까지 요청의 97%에서 최고조에 달했습니다. |
CDN
| 자동화된 트래픽 관리 인프라는 작동되었지만, 영향 기간 동안 효율성이 감소했습니다. 특히 가동 중단으로 인해 Zero Trust 클라이언트의 등록 요청이 크게 증가했습니다. 요청 증가로 인해 여러 Cloudflare 위치에 추가 부하가 발생하여 자동 트래픽 관리 시스템이 응답을 시작했습니다. 이러한 상황에 대응하여 시스템에서는 유입되는 CDN 트래픽을 인근 위치로 재라우팅하여 고객에 대한 영향을 줄였습니다. 트래픽의 일부가 예상대로 다시 라우팅되지 않아 현재 조사 중입니다. 이 문제의 영향을 받는 CDN 요청은 대기 시간이 증가하고, HTTP 499 오류 및/또는 HTTP 503 오류가 발생할 수 있습니다. 영향을 받은 Cloudflare 서비스 지역에는 상파울루, 필라델피아, 애틀랜타, 롤리가 포함되었습니다. |
Workers/Workers for Platforms
| Workers 및 Workers for Platforms는 업로드를 위해 타사 서비스에 의존합니다. 사고 기간 동안 Workers의 전체 오류율이 전체 요청의 약 2%까지 증가했습니다. Workers for Platforms는 같은 기간 동안 전체 오류율이 전체 요청의 약 10%로 최고치를 기록했습니다. |
Workers Builds(CI/CD)
| 18:03 UTC부터 Access가 중단되어 Workers Builds가 새로운 소스 코드 관리 푸시 이벤트를 수신할 수 없었습니다. 사고 기간 동안 새로운 Workers Builds의 100%가 실패했습니다. |
브라우저 렌더링
| 브라우저 렌더링은 브라우저 인스턴스 인프라를 위해 브라우저 격리에 의존합니다. REST API에 대한 요청과 Workers 브라우저 바인딩을 통한 요청은 사고 기간 동안 100% 영향을 받았습니다. |
Zaraz
| 사고 기간 동안 요청의 100%가 영향을 받았습니다. Zaraz는 웹 사이트의 아이볼 트래픽을 처리할 때 Workers KV 설정에 의존합니다. 동일한 종속성으로 인해 이 기간 동안 Zaraz 구성 업데이트를 저장하려는 시도는 실패했지만, 모니터링에 따르면 단 한 명의 사용자만 영향을 받은 것으로 나타났습니다. |
Workers KV는 우리가 '코어리스' 서비스라고 부르는 방식으로 구축되었으며, 이는 서비스가 전 세계 각 위치에서 독립적으로 실행되기 때문에 단일 장애 지점이 없음을 의미합니다. 하지만 현재 Workers KV는 데이터에 대한 신뢰할 수 있는 소스를 제공하기 위해 중앙 데이터 저장소에 의존합니다. 해당 저장소의 장애로 인해 Cloudflare의 서비스 전반에서 사용되는 KV 네임스페이스에 대한 콜드 리딩 및 라이팅이 완전히 중단되었습니다.
Workers KV는 중앙 저장소를 위해 훨씬 더 견고한 인프라로 전환되는 중입니다. 유감스럽게도 이번 사건 중에 노출된 커버리지의 격차가 있었습니다. Workers KV는 저희가 데이터 일관성 문제(원래 데이터 동기화 아키텍처로 인한)를 방지하고 데이터 레지던시 요구 사항에 대한 지원을 개선하기 위해 Cloudflare R2로 마이그레이션하는 등 KV의 백엔드 아키텍처를 재설계하는 과정에서 스토리지 공급자를 제거했습니다.
저희 원칙 중 하나는 Cloudflare 서비스를 최대한 자체 플랫폼에 구축하는 것이며, Workers KV도 예외가 아닙니다. 당사의 많은 내부 및 외부 서비스는 Workers KV에 크게 의존하고 있습니다. Workers KV는 일반적인 상황에서 서비스 팀이 자체 스토리지 서비스를 구축하려고 시도하는 대신 가능한 가장 견고한 서비스를 제공하는 데 도움이 됩니다. 이 경우 Workers KV의 장애로 인한 연쇄적인 영향으로 문제가 악화되었고 피해 반경이 크게 넓어졌습니다.
초기 영향, 조사, 근본 원인, 수정 등이 포함된 사고 타임라인이 아래에 자세히 나와 있습니다.
스토리지 인프라에 대한 Workers KV 오류율. 사고 기간 동안 KV 요청의 91%가 실패했습니다.
Cloudflare Access 요청의 성공 비율. Cloudflare Access는 Workers KV에 직접 의존하며 시간에 따른 Workers KV 가용성을 측정하는 좋은 프록시 역할을 합니다.
언급된 모든 타임스탬프는 협정 세계시(UTC) 기준입니다.
시간 | 이벤트 |
|---|
2025년 6월 12일 17시 52분 | 사고 시작
Cloudflare WARP 팀에서 새 장치 등록 실패를 확인하고 조사를 시작하며 사고를 선언합니다. |
2025년 6월 12일 18시 05분 | Cloudflare Access 팀은 오류율이 급격히 증가하여 경고를 받았습니다. 여러 서비스의 서비스 수준 목표가 목표치보다 낮아지면 해당 팀에 경고가 발생합니다. |
2025년 6월 12일 18시 06분 | 여러 서비스별 사고가 공유된 원인(Workers KV 사용 불가)을 확인하면 단일 사고로 통합됩니다. 사고 우선순위가 P1으로 상향 조정되었습니다. |
2025년 6월 12일 18시 21분 | 영향의 심각성이 명확해짐에 따라 사고 우선순위가 P1에서 P0으로 상향 조정되었습니다. |
2025년 6월 12일 18시 43분 | Cloudflare Access는 Workers KV 엔지니어링 팀과 함께 다른 백엔드 데이터 저장소로 마이그레이션하여 Workers KV 종속성을 제거하는 옵션을 탐색하기 시작했습니다. 이는 스토리지 인프라가 계속 다운될 경우를 대비한 사전 조치였습니다. |
2025년 6월 12일 19시 09분 | Zero Trust Gateway가 ID 또는 Device Posture를 참조하는 규칙을 점진적으로 저하시켜 Workers KV에 대한 종속성을 제거하기 시작했습니다. |
2025년 6월 12일 19시 32분 | Access 및 Workers Device Posture가 타사 서비스가 다시 온라인 상태가 될 때까지 Workers KV의 부하를 줄이기 위해 ID 및 Device Posture 요청을 강제로 중단합니다. |
2025년 6월 12일 19시 45분 | Cloudflare 팀에서는 대체 백엔드 데이터 저장소에 Workers KV 릴리스를 배포하고, 중요 서비스가 해당 저장소에 구성 데이터를 기록할 수 있도록 하는 경로를 계속 작업하고 있습니다. |
2025년 6월 12일 20시 23분 | 스토리지 인프라가 복구되기 시작하면서 서비스도 복구되기 시작합니다. 캐시를 다시 채우는 서비스의 유입으로 인해 무시할 수 없는 오류율과 인프라 속도 제한이 계속 발생합니다. |
2025년 6월 12일 20시 25분 | 타사 서비스가 복구되면서 Access 및 Device Posture가 복구되어 Workers KV를 호출합니다. |
2025년 6월 12일 20시 28분 | 영향 종료
서비스 수준 목표가 사고 이전 수준으로 돌아갑니다. Cloudflare 팀에서는 종속 시스템이 복구되는 동안 서비스가 저하되지 않도록 시스템을 지속해서 모니터링합니다. |
| 사고 종료
Cloudflare 팀에서는 영향을 받은 모든 서비스가 정상 기능으로 복귀하는 것을 확인했습니다. 서비스 수준 목표 경고가 복구되었습니다. |
저희는 Workers KV 및 스토리지 인프라에 의존하는 서비스의 복원력을 개선하기 위하여 즉각적인 조치를 취하고 있습니다. 여기에는 이 사건의 결과로 가속화되고 있는 기존에 계획된 작업이 포함됩니다.
여기에는 우리가 소유하지 않은 스토리지 인프라에 대한 단일 의존성을 피하고, Access, Gateway, WARP 등의 중요한 서비스를 복구하는 능력을 향상시키기 위한 여러 작업 흐름이 포함됩니다
구체적으로는 다음과 같습니다.
(적극적으로 진행 중): Workers KV 저장 공간의 이중화를 개선하기 위한 작업을 추진하여 단일 공급자에 대한 의존성을 제거합니다. 사고가 계속될 경우에 대비하여 사고 기간 동안 중요한 KV 네임스페이스를 전환하고 자체 인프라로 백필하는 작업을 시작했습니다.
(적극적으로 진행 중): 이 사고로 영향을 받은 개별 제품에 대한 단기적인 피해 범위 수정 조치로, 각 제품이 타사 종속성을 포함한 단일 장애점으로 인한 서비스 손실에 대해 복원력을 갖출 수 있도록 합니다.
(적극적으로 진행 중): 스토리지 인프라 사고 중 네임스페이스를 점진적으로 다시 활성화할 수 있는 도구를 구현 중입니다. 이렇게 하면 캐시를 다시 채울 때 자체 인프라에 대한 서비스 거부 위험 없이 Access 및 WARP를 포함한 주요 종속성을 시작할 수 있습니다.
이 목록은 완전한 것이 아닙니다. 저희 팀에서는 계속해서 설계 결정을 재검토하고, 앞으로 이와 같은 사고를 완화하기 위해 단기(즉시) 및 장기적으로 인프라 변경을 평가해야 합니다.
이 사고는 심각한 중단이었으며, 우리는 크고 작은 모든 조직과 기관에서 웹 사이트, 애플리케이션, zero trust, 네트워크 인프라를 보호하고/보호하거나 운영하기 위해 저희에게 의존하고 있다는 점을 이해하고 있습니다. 다시 한 번 이번 영향에 대해 깊이 사과드립니다. 저희는 서비스 복원력을 개선하기 위해 열심히 노력하고 있습니다.