2025년 11월 18일 Cloudflare Global Network 오류(비교)

보기 RAW Blame 되돌리기 비교

 r92 vs r93
 ...
 [[파일:클플 오류1.png|width=100%]]
-년 11월 18일 11:20 UTC에(이 블로그의 모든 시간은 UTC 기준), Cloudflare 네트워크에서 핵심 트래픽 전달에 심각한 장애가 발생하기 시작했습니다. 이로 인해 인터넷 사용자가 고객 사이트에 접속하려고 하면, Cloudflare 네트워크 내부에서 문제가 발생했다는 오류 페이지가 표시되었습니다.
+년 11월 18일 11시 20분 UTC(본 블로그의 모든 시간은 UTC 기준), Cloudflare 네트워크에서 핵심 네트워크 트래픽 전송에 심각한 오류가 발생하기 시작했습니다. 이로 인해 고객사의 사이트에 접속하려는 인터넷 사용자에게 Cloudflare 네트워크 오류를 나타내는 오류 페이지가 표시되었습니다.
 [[파일:클플 오류2.png|width=100%]]
-'''이 문제는 사이버 공격이나 악의적 활동과는 직접적·간접적으로도 관련이 없었습니다.''' 대신, 데이터베이스 시스템 중 하나의 권한 변경으로 인해, Bot Management 시스템에서 사용하는 “feature file”에 여러 항목이 출력되면서 문제가 발생했습니다. 그 결과, 해당 feature file의 크기가 두 배로 늘어났고, 이 커진 파일이 네트워크를 구성하는 모든 머신에 전파되었습니다.
+'''이번 문제는 직간접적으로 사이버 공격이나 어떠한 종류의 악의적인 활동으로 인해 발생한 것이 아닙니다.''' 정확히는, 문제가 네트워크 자체에서 발생한 것이 아니라 데이터베이스 시스템 중 하나의 권한 변경 때문에 촉발되었습니다. 그 결과 데이터베이스가 Bot Management 시스템에서 사용하는 “피처 파일(feature file)”에 여러 항목을 잘못 출력하게 되었습니다. 결과적으로 해당 피처 파일의 크기가 두 배로 늘어났습니다. 예상보다 큰 피처 파일이 네트워크를 구성하는 모든 컴퓨터에 전파되었습니다.
-이 머신들에서 트래픽을 라우팅하는 소프트웨어는 Bot Management 시스템을 최신 위협에 맞게 유지하기 위해 이 feature file을 읽습니다. 그런데 이 소프트웨어에는 파일 크기에 제한이 있었고, 두 배로 커진 파일 크기가 그 한계를 초과하면서 소프트웨어가 실패하게 된 것입니다.
+Cloudflare 네트워크 전반의 트래픽을 라우팅하는 이 장비들의 소프트웨어는 지속적으로 변화하는 위협에 대응하기 위해 Bot Management 시스템을 최신 상태로 유지해야 합니다. 이 소프트웨어가 바로 그 목적을 위해 해당 피처 파일을 읽습니다. 이 소프트웨어는 피처 파일의 크기가 두 배 미만으로 제한되어 있었기 때문에 결국 소프트웨어에 오류가 발생했습니다.
-처음에는 우리가 관찰한 증상이 대규모 DDoS 공격 때문이라고 잘못 의심했지만, 이후 핵심 원인을 정확히 파악하여 예상보다 커진 feature file의 전파를 중단하고 이전 버전으로 교체할 수 있었습니다. 14:30경에는 핵심 트래픽이 대부분 정상적으로 흐르기 시작했고, 그 후 몇 시간 동안 네트워크 각 부분에 급격히 몰린 트래픽을 완화하는 작업을 진행했습니다. 17:06에는 Cloudflare의 모든 시스템이 정상적으로 작동했습니다.
+처음에 나타난 증상 때문에 대규모 DDoS 공격으로 인한 것으로 잘못 판단했지만, 핵심 문제를 정확히 파악하여 예상보다 큰 피처 파일의 확산을 막고 이전 버전의 파일로 교체했습니다. 오후 2시 30분까지 핵심 트래픽은 대체로 정상적으로 흘렀습니다. 이후 몇 시간에 걸쳐 트래픽이 다시 온라인 상태로 돌아오면서 네트워크 여러 부분에서 증가된 부하를 완화하는 작업이 진행되었습니다. 17시 06분 현재 Cloudflare의 모든 시스템은 정상적으로 작동하고 있습니다.
-고객과 인터넷 전반에 끼친 영향에 대해 사과드립니다. Cloudflare가 인터넷 생태계에서 중요한 역할을 하는 만큼, 시스템 장애는 용납될 수 없습니다. 네트워크가 일정 시간 동안 트래픽을 라우팅할 수 없었던 상황은 팀의 모든 구성원에게 깊은 고통이었습니다. 오늘 여러분을 실망시킨 것을 알고 있습니다.
+고객과 인터넷에 피해를 끼쳐드려 진심으로 송구스럽게 생각합니다. 인터넷 생태계에서 Cloudflare의 중요성을 감안할 때, 당사 시스템의 모든 중단은 용납할 수 없습니다. 당사 네트워크가 트래픽을 라우팅할 수 없었던 기간이 발생했다는 사실은 모든 팀원에게 매우 고통스러운 일입니다. Cloudflare가 고객을 실망시켰다는 사실을 잘 알고 있습니다.
-이 글은 정확히 어떤 일이 일어났고, 어떤 시스템과 프로세스가 실패했는지를 자세히 설명하는 내용입니다. 또한 이번과 같은 장애가 다시 발생하지 않도록 하기 위한 계획의 시작점이기도 하지만, 끝은 아닙니다.
+이 게시물은 정확히 무슨 일이 일어났고 어떤 시스템과 프로세스가 오류를 겪었는지에 대한 심층적인 이야기입니다. 또한, 이번과 같은 서비스 중단이 재발하지 않도록 하기 위한 노력의 시작이며, 결코 끝이 아닙니다.
-'''{{{+5 장애 상황}}}'''
-아래 차트는 Cloudflare 네트워크에서 발생한 5xx HTTP 상태 코드의 양을 보여줍니다. 정상적으로는 이 수치가 매우 낮아야 하는데, 장애가 시작되기 전까지는 정상적으로 낮은 상태였습니다.
+'''{{{+5 서비스 중단}}}'''
+아래 차트는 Cloudflare 네트워크에서 발생한 5xx 오류 HTTP 상태 코드의 발생량을 보여줍니다. 일반적으로 이 값은 매우 낮아야 하며, 중단이 시작되기 직전까지는 낮았습니다.
 [[파일:클플 오류3.png|width=100%]]
-:20 이전의 수치는 네트워크 전반에서 관찰된 5xx 오류의 정상 기준선입니다. 이후 급증과 변동은 잘못된 feature file을 로드하면서 시스템이 실패한 것을 보여줍니다. 흥미로운 점은 시스템이 잠시 회복되기도 했다는 것으로, 내부 오류에서는 매우 드문 현상이었습니다.
+:20 이전의 발생량은 Cloudflare 네트워크 전반에서 관찰된 예상되는 5xx 오류의 기준치를 나타냅니다. 급증과 그 이후의 변동은 잘못된 피처 파일을 로드하여 시스템 오류가 발생했음을 보여줍니다. 주목할 점은, 그 후 시스템이 일정 시간 동안 자체적으로 복구되는 현상을 보였다는 것입니다. 내부 오류 상황에서는 매우 이례적인 일이었습니다.
-설명하자면, 이 파일은 ClickHouse 데이터베이스 클러스터에서 5분마다 쿼리를 통해 생성되었고, 권한 관리를 개선하기 위해 점진적으로 업데이트되고 있었습니다. 잘못된 데이터는 업데이트된 클러스터 일부에서 쿼리가 실행될 때만 생성되었습니다. 따라서 매 5분마다 정상 또는 잘못된 구성 파일 세트가 생성되어 빠르게 네트워크 전체에 전파될 가능성이 있었던 것입니다.
+설명에 따르면, 해당 파일은 ClickHouse 데이터베이스 클러스터에서 실행되는 쿼리에 의해 5분마다 생성되고 있었으며, 이는 권한 관리를 개선하기 위해 점진적으로 업데이트되고 있던 과정이었습니다. 쿼리가 업데이트된 클러스터 부분에서 실행된 경우에만 잘못된 데이터가 생성되었습니다. 그 결과, 매 5분마다 올바른 구성 파일 또는 문제가 있는 구성 파일이 생성될 가능성이 있었고, 이 파일들이 네트워크 전반에 빠르게 전파되었습니다.
-이런 변동 때문에 정확히 무슨 일이 일어나고 있는지 파악하기 어려웠습니다. 시스템이 때로는 정상 구성 파일을, 때로는 잘못된 구성 파일을 네트워크에 배포하면서 회복했다가 다시 실패했기 때문입니다. 처음에는 공격 때문일 수 있다고 생각했지만, 결국 모든 ClickHouse 노드가 잘못된 구성 파일을 생성하게 되었고, 변동은 실패 상태로 안정화되었습니다.
+이러한 변동 때문에 상황이 명확하지 않았습니다. 시스템 전체가 회복되었다가 다시 실패하는 현상이 반복되었는데, 이는 네트워크에 때로는 올바른, 때로는 문제가 있는 구성 파일이 배포되었기 때문입니다. 처음에는 이 현상 때문에 공격이 원인인 것으로 판단했습니다. 결국 모든 ClickHouse 노드가 문제가 있는 구성 파일을 생성하게 되었고, 변동은 장애 상태로 안정화되었습니다.
-오류는 근본 원인이 확인되고 해결되기 시작한 14:30까지 계속되었습니다. 문제는 잘못된 feature file의 생성과 전파를 중단하고, 알려진 정상 파일을 feature file 배포 큐에 수동으로 삽입한 후, 핵심 프록시를 강제로 재시작함으로써 해결했습니다.
+오류는 근본 원인이 확인되고 해결되기 시작한 14:30까지 계속되었습니다. 문제 해결 방법은 잘못된 피처 파일의 생성과 전파를 중단하고, 확인된 정상 파일을 피처 파일 배포 큐에 수동으로 삽입한 뒤, 핵심 프록시를 강제로 재시작하는 것이었습니다.
-위 차트에서 남아 있는 긴 꼬리는, 문제가 발생한 나머지 서비스들을 팀이 재시작하는 과정이며, 17:06에 5xx 오류량이 정상으로 돌아왔습니다.
+위 차트에서 남아 있는 긴 꼬리 구간은 문제가 발생한 나머지 서비스들을 우리 팀이 재시작하는 과정을 보여주며, 5xx 오류 발생량은 17:06에 정상 수준으로 회복되었습니다.
-영향을 받은 서비스는 다음과 같습니다:
+다음 서비스에 영향이 있었습니다.
 {{{#!wiki style="margin: -5px 0px -10px 0px"
 ||<tablewidth=100%><tablebordercolor=#000,#fff><tablebgcolor=#ffffff,#1c1d1f><colcolor=#000,#fff><width=40%> '''서비스 / 제품''' ||<width=60%><colcolor=#000,#fff> '''{{{#fff,#fff 영향 설명}}}''' ||
-|| 핵심 CDN 및 보안 서비스 || HTTP 5xx 상태 코드. 이 글 상단의 스크린샷은 최종 사용자에게 표시된 일반적인 오류 페이지를 보여줍니다. ||
-|| Turnstile || Turnstile 로드 실패 ||
-|| Workers KV || Workers KV에서 HTTP 5xx 오류가 크게 증가했습니다. 이는 핵심 프록시가 실패하면서 KV의 “프론트엔드” 게이트웨이에 대한 요청이 실패했기 때문입니다. ||
-|| 대시보드 || 대시보드는 대부분 정상적으로 작동했지만, 로그인 페이지에서 Turnstile을 사용할 수 없어서 대부분의 사용자가 로그인할 수 없었습니다. ||
-|| 이메일 보안 || 이메일 처리와 전달에는 영향이 없었지만, IP 평판 소스에 대한 일시적인 접근 불가가 발생하여 스팸 탐지 정확도가 떨어지고 일부 신규 도메인 탐지가 작동하지 않았습니다. 다만 고객에게 심각한 영향은 없었습니다. 또한 일부 Auto Move 작업이 실패했지만, 영향을 받은 모든 메시지는 검토 및 복구되었습니다. ||
-|| Access || 인증 실패가 대부분 사용자에게 광범위하게 발생했으며, 사건 시작 시점부터 13:05 롤백이 시작될 때까지 지속되었습니다. 기존 Access 세션은 영향을 받지 않았습니다.
+|| 핵심 CDN 및 보안 서비스 || HTTP 5xx 상태 코드 이 게시물 상단의 스크린샷은 최종 사용자에게 전달되는 일반적인 오류 페이지입니다. ||
+|| Turnstile || Turnstile 로드에 실패했습니다. ||
+|| Workers KV || Workers KV는 핵심 프록시의 장애로 인해 KV “프론트엔드” 게이트웨이에 대한 요청이 실패하면서, HTTP 5xx 오류가 평소보다 크게 증가했습니다. ||
+|| 대시보드 || 대시보드는 대부분 작동했지만, 로그인 페이지에서 Turnstile을 사용할 수 없어 대부분의 사용자가 로그인할 수 없었습니다. ||
+|| 이메일 보안 || 이메일 처리 및 전송에는 영향이 없었지만, IP 평판 소스에 대한 일시적 접근 불가가 발생하여 스팸 탐지 정확도가 떨어지고 일부 신규 도메인 연령 감지가 작동하지 않았습니다. 다행히 고객에게 심각한 영향은 없었습니다. 또한 일부 자동 이동 작업에서 오류가 발생했습니다. 영향을 받은 모든 메시지는 검토 및 수정되었습니다. ||
+|| Access || 인증 실패는 대부분 사용자에게 광범위하게 발생했으며, 사고 시작 시점부터 13:05 롤백이 시작될 때까지 계속되었습니다. 기존의 Access 세션은 영향을 받지 않았습니다.
-모든 실패한 인증 시도는 오류 페이지를 반환했으므로, 인증이 실패하는 동안 사용자는 대상 애플리케이션에 도달하지 못했습니다. 이 기간 동안 성공한 로그인은 정상적으로 기록되었습니다.
+모든 인증 실패 시도는 오류 페이지로 이어졌기 때문에, 인증이 실패하는 동안 해당 사용자들은 목표 애플리케이션에 전혀 접속하지 못했습니다. 이 기간 동안의 성공적인 로그인은 이번 사고 중에도 정상적으로 기록되었습니다.
-그 시점에 시도된 모든 Access 구성 업데이트는 전면 실패하거나 매우 느리게 전파되었으며, 현재 모든 구성 업데이트는 복구되었습니다. ||
+당시 시도된 Access 구성 업데이트는 완전히 실패했거나, 전파가 매우 느리게 이루어졌을 가능성이 있습니다. 이제 모든 구성 업데이트가 복구되었습니다. ||
 }}}
-HTTP 5xx 오류가 발생한 것뿐만 아니라, 장애 기간 동안 CDN 응답 지연(latency)도 크게 증가했습니다. 이는 디버깅 및 모니터링 시스템이 많은 CPU를 사용했기 때문인데, 이 시스템들은 잡히지 않은 오류를 자동으로 추가 디버깅 정보와 함께 처리하도록 설계되어 있습니다.
+영향 기간 동안 HTTP 5xx 오류가 발생하는 것뿐만 아니라, CDN 응답 지연도 크게 증가했습니다. 이는 자동으로 잡히지 않은 오류에 추가 디버깅 정보를 붙이는 디버깅 및 관측 시스템이 많은 CPU를 사용했기 때문입니다.
-'''{{{+5 Cloudflare가 요청을 처리하는 방식과, 오늘 이 과정에서 무엇이 잘못되었는지에 대한 내용.}}}'''
+'''{{{+5 Cloudflare가 요청을 처리하는 방식과 오늘 발생한 문제점}}}'''
-Cloudflare로 들어오는 모든 요청은 네트워크에서 정해진 경로를 거칩니다. 요청은 브라우저에서 웹페이지를 불러오거나, 모바일 앱이 API를 호출하거나, 다른 서비스에서 자동으로 들어오는 트래픽일 수 있습니다.
+Cloudflare로 향하는 모든 요청은 명확하게 정의된 경로를 거칩니다. 이는 웹페이지를 로드하는 브라우저, API를 호출하는 모바일 애플리케이션, 혹은 다른 서비스에서 오는 자동화 트래픽일 수 있습니다. 이러한 요청은 먼저 HTTP 및 TLS 계층에서 종료되고, 이후 핵심 프록시 시스템("Frontline", 줄여서 FL)을 거쳐, 마지막으로 Pingora를 통해 캐시 조회를 수행하거나 필요 시 원본 서버에서 데이터를 가져옵니다.
-이 요청들은 먼저 HTTP와 TLS 계층에서 처리되고, 그다음 핵심 프록시 시스템(“Frontline”, 줄여서 FL)을 통과하며, 필요하면 Pingora를 통해 캐시를 조회하거나 원본 서버에서 데이터를 가져옵니다.
+핵심 프록시의 작동 방식에 대한 자세한 내용은 [[https://blog.cloudflare.com/20-percent-internet-upgrade/|여기]]에서 확인할 수 있습니다.
-핵심 프록시가 작동하는 방식에 대해서는 [[https://blog.cloudflare.com/20-percent-internet-upgrade/|여기서]] 이전에 더 자세히 공유한 바 있습니다.
 [[파일:클플 오류4.png|width=100%]]
-요청이 핵심 프록시를 통과하는 동안, Cloudflare는 네트워크에서 제공하는 다양한 보안 및 성능 기능을 실행합니다. 프록시는 각 고객의 고유한 구성과 설정을 적용하며, WAF 규칙 적용, DDoS 방어, 트래픽을 Developer Platform이나 R2로 라우팅하는 작업 등을 수행합니다. 이는 도메인별 모듈을 통해 이루어지며, 모듈이 프록시를 통과하는 트래픽에 구성과 정책 규칙을 적용합니다.
+요청이 핵심 프록시를 통과하는 동안, 우리는 네트워크에서 제공되는 다양한 보안 및 성능 관련 제품을 실행합니다. 프록시는 각 고객의 고유한 구성과 설정을 적용하며, 여기에는 WAF 규칙 및 DDoS 방어 적용, 그리고 트래픽을 Developer Platform과 R2로 라우팅하는 작업이 포함됩니다. 이는 도메인별 모듈 세트를 통해 이루어지며, 이 모듈들이 핵심 프록시를 통과하는 트래픽에 고객 구성과 정책 규칙을 적용합니다.
-그 모듈 중 하나인 Bot Management가 오늘 장애의 원인이었습니다.
+해당 모듈 중 하나인 Bot Management 기능이 오늘 발생한 서비스 중단의 원인이었습니다.
-Cloudflare의 [[https://www.cloudflare.com/ko-kr/application-services/products/bot-management/|Bot Management]]에는, 그 외 여러 시스템과 함께, 네트워크를 통과하는 모든 요청에 대해 봇 점수(bot score)를 생성하는 머신러닝 모델이 포함되어 있습니다. 고객들은 이 봇 점수를 사용해 어떤 봇이 사이트에 접근할 수 있는지 제어합니다.
+Cloudflare의 [[https://www.cloudflare.com/ko-kr/application-services/products/bot-management/|Bot Management]] 기능에는 네트워크를 통과하는 모든 요청을 대상으로 봇 점수를 생성하는 데 사용되는 머신 러닝 모델을 비롯한 다양한 시스템이 포함되어 있습니다. 고객은 봇 점수를 사용하여 어떤 봇이 사이트에 액세스하도록 허용할지 여부를 제어합니다.
-이 모델은 “feature” 구성 파일을 입력으로 사용합니다. 여기서 feature란 요청이 자동화된 것인지 아닌지를 판단하기 위해 머신러닝 모델이 사용하는 개별 특성을 말하며, feature 구성 파일은 이러한 개별 feature들의 모음입니다.
+이 모델은 “피처” 구성 파일을 입력으로 사용합니다. 여기서 피처란, 요청이 자동화된 것인지 여부를 예측하기 위해 머신러닝 모델이 사용하는 개별 특성을 의미합니다. 피처 구성 파일은 이러한 개별 피처들의 집합입니다.
-이 feature 파일은 몇 분마다 갱신되어 전체 네트워크에 배포되며, 인터넷 트래픽의 변동에 신속히 대응할 수 있게 해줍니다. 새로운 유형의 봇이나 공격에 빠르게 대응해야 하기 때문에, 이 파일은 자주 그리고 빠르게 배포되는 것이 매우 중요합니다.
+이 피처 파일은 몇 분마다 갱신되어 네트워크 전체에 배포되며, 인터넷 전반의 트래픽 변화에 대응할 수 있게 해줍니다. 또한 새로운 유형의 봇과 봇 공격에 대응할 수 있도록 해주기 때문에 악성 행위자가 빠르게 전략을 바꾸는 상황에서 자주 그리고 신속하게 배포되는 것이 매우 중요합니다.
-그런데 이 파일을 생성하는 기반 ClickHouse 쿼리 동작이 변경되면서, feature 행이 중복되어 파일 크기가 증가했습니다. 이전에는 고정 크기였던 feature 파일이 커지면서, 봇 모듈에서 오류가 발생하게 된 것입니다.
+아래에서 설명할 ClickHouse 쿼리 동작의 변경으로 인해 이 파일이 중복된 “피처” 행을 많이 포함하게 되었습니다. 이로 인해 기존에 고정 크기였던 피처 구성 파일의 크기가 변경되었고, 그 결과 봇 모듈에서 오류가 발생했습니다.
-그 결과, 봇 모듈에 의존하는 모든 트래픽에 대해 고객 트래픽을 처리하는 핵심 프록시 시스템에서 HTTP 5xx 오류가 반환되었습니다. 이 영향은 또한 핵심 프록시에 의존하는 Workers KV와 Access에도 미쳤습니다.
+그 결과, 봇 모듈에 의존하는 모든 트래픽에 대해, 고객 트래픽 처리를 담당하는 핵심 프록시 시스템에서 HTTP 5xx 오류 코드가 반환되었습니다. 이로 인해 핵심 프록시에 의존하는 Workers KV와 Access에도 영향이 미쳤습니다.
-이번 사건과 관련은 없지만, 현재 고객 트래픽을 내부적으로 FL2라고 부르는 새로운 프록시 서비스로 이전하고 있었습니다. 두 버전 모두 문제의 영향을 받았지만, 관찰된 영향은 달랐습니다.
+이번 사고와는 관련 없이, 우리는 고객 트래픽을 내부적으로 FL2라고 부르는 새로운 프록시 서비스 버전으로 이전하고 있습니다. 두 버전 모두 해당 문제의 영향을 받았지만, 관찰된 영향은 서로 달랐습니다.
-새로운 FL2 프록시 엔진을 사용하는 고객은 HTTP 5xx 오류를 경험했습니다. 기존 FL 프록시 엔진을 사용하는 고객은 오류는 없었지만, 봇 점수가 올바르게 생성되지 않아 모든 트래픽이 봇 점수 0으로 처리되었습니다. 봇 차단 규칙을 적용한 고객은 많은 오탐(false positive)을 경험했을 것입니다. 봇 점수를 규칙에서 사용하지 않은 고객은 영향을 받지 않았습니다.
+새로운 FL2 프록시 엔진을 사용하는 고객은 HTTP 5xx 오류를 관찰했습니다. 기존 프록시 엔진인 FL을 사용하는 고객은 오류는 발생하지 않았지만, 봇 점수가 제대로 생성되지 않아 모든 트래픽에 봇 점수가 0으로 부여되었습니다. 봇 차단 규칙을 적용한 고객은 많은 수의 오탐(false positive)을 경험했을 것입니다. 규칙에서 봇 점수를 사용하지 않던 고객은 아무런 영향도 받지 않았습니다.
-또한 우리를 혼란스럽게 하고 이번 사건이 공격일 수 있다고 생각하게 만든 증상 중 하나는 Cloudflare 상태 페이지가 다운된 것이었습니다. 상태 페이지는 Cloudflare 인프라와 전혀 의존성이 없는 외부에서 호스팅되고 있었습니다. 우연의 일치였지만, 일부 팀은 공격자가 시스템과 상태 페이지를 동시에 대상으로 하고 있다고 오인하게 되었습니다. 당시 상태 페이지를 방문한 사용자는 오류 메시지를 보게 되었습니다.
+우리를 혼란스럽게 하고 이번 사건이 공격일 수 있다는 착각을 갖게 만든 또 다른 증상은 Cloudflare 상태 페이지가 다운된 것이었습니다. 상태 페이지는 Cloudflare 인프라와 전혀 연동되지 않고, Cloudflare에 의존하지 않는 별도의 환경에서 호스팅됩니다. 결국 이는 단순한 우연이었지만, 문제를 진단하던 일부 팀원들이 공격자가 우리 시스템과 상태 페이지를 동시에 노리고 있다고 오인하게 만들었습니다. 당시 상태 페이지를 방문한 이용자들은 다음과 같은 오류 메시지를 확인했습니다.
 [[파일:클플 오류5.png|width=100%]]
-내부 사고 채팅방에서는, 이번 문제가 최근 발생한 대규모 [[https://blog.cloudflare.com/defending-the-internet-how-cloudflare-blocked-a-monumental-7-3-tbps-ddos/|Aisuru DDoS]] 공격의 연장일 수 있다는 우려가 있었습니다.
+내부 사고 대응 채팅방에서 우리는 이것이 최근에 빈번하게 발생한 대량의 [[https://blog.cloudflare.com/defending-the-internet-how-cloudflare-blocked-a-monumental-7-3-tbps-ddos/|Aisuru DDoS 공격]]의 연장선일 수 있다고 우려했습니다.
 [[파일:클플 오류6.png|width=100%]]
-'''{{{+5 쿼리 동작 변경}}}'''
+'''{{{+5 쿼리 동작의 변경}}}'''
-앞서 언급했듯, 기본 쿼리 동작 변경으로 인해 feature 파일에 중복된 행이 많이 포함되게 되었습니다. 문제의 데이터베이스 시스템은 ClickHouse 소프트웨어를 사용합니다.
+앞서 언급했듯이, 기본 쿼리 동작의 변경으로 인해 피처 파일에 중복된 행이 다수 포함되게 되었습니다. 해당 데이터베이스 시스템은 ClickHouse 소프트웨어를 사용합니다.
-참고로, ClickHouse 분산 쿼리가 어떻게 작동하는지 이해하면 도움이 됩니다. ClickHouse 클러스터는 여러 샤드(shard)로 구성됩니다. 모든 샤드에서 데이터를 쿼리하려면, default라는 데이터베이스에 있는 “Distributed” 엔진 기반의 분산 테이블을 사용합니다. Distributed 엔진은 r0 데이터베이스의 기본 테이블을 쿼리하는데, 이 기본 테이블이 각 ClickHouse 샤드에 데이터가 실제로 저장되는 곳입니다.
+맥락을 이해하기 위해서는 ClickHouse의 분산 쿼리 동작 방식을 아는 것이 도움이 됩니다. ClickHouse 클러스터는 여러 샤드(shard)로 구성됩니다. 모든 샤드의 데이터를 쿼리하기 위해 우리는 default라고 하는 데이터베이스에서 분산 테이블(테이블 엔진 Distributed를 통해 구동)을 사용합니다. 이 Distributed 엔진은 데이터베이스 r0에서 기본 테이블을 쿼리합니다. 기본 테이블이 ClickHouse 클러스터의 각 샤드에서 데이터가 저장되는 위치입니다.
-Distributed 테이블에 대한 쿼리는 공유 시스템 계정을 통해 실행됩니다. 분산 쿼리의 보안과 신뢰성을 개선하기 위한 노력의 일환으로, 향후에는 초기 사용자 계정으로 쿼리를 실행하도록 작업이 진행되고 있습니다.
+분산 테이블에 대한 쿼리는 공유 시스템 계정을 통해 실행됩니다. 분산 쿼리의 보안과 안정성을 개선하기 위한 노력의 일환으로, 앞으로는 초기 사용자 계정으로 실행되도록 변경 작업이 진행 중입니다.
-오늘 이전에는, ClickHouse 사용자가 시스템 테이블(system.tables, system.columns 등)을 통해 테이블 메타데이터를 쿼리할 때 default 데이터베이스의 테이블만 볼 수 있었습니다.
+오늘 이전까지, ClickHouse 사용자는 default 데이터베이스에 있는 테이블만 system.tables 또는 system.columns 같은 ClickHouse 시스템 테이블에서 테이블 메타데이터를 조회할 때 확인할 수 있었습니다.
-사용자들이 이미 r0 기본 테이블에 암묵적으로 접근할 수 있었기 때문에, 11:05에 이 접근을 명시적으로 허용하도록 변경했습니다. 이를 통해 사용자가 해당 테이블의 메타데이터도 볼 수 있게 되었고, 모든 분산 서브쿼리가 초기 사용자 계정에서 실행되도록 하여, 쿼리 제한과 접근 권한을 더 세밀하게 평가할 수 있게 되었습니다. 이렇게 하면 한 사용자의 잘못된 서브쿼리가 다른 사용자에게 영향을 미치는 것을 방지할 수 있습니다.
+사용자가 이미 r0의 기본 테이블에 대한 암묵적 접근 권한을 가지고 있기 때문에, 11:05에 이 접근 권한을 명시적으로 표시하도록 변경하여 사용자가 이 테이블들의 메타데이터도 확인할 수 있도록 했습니다. 모든 분산 서브쿼리가 초기 사용자 계정으로 실행되도록 보장함으로써, 쿼리 제한과 접근 권한을 더 세밀하게 평가할 수 있게 되었고, 한 사용자의 잘못된 서브쿼리가 다른 사용자에게 영향을 미치는 것을 방지할 수 있습니다.
-하지만 이 변경으로 인해, 이전에는 “default” 데이터베이스만 포함될 것이라고 가정했던 쿼리 결과가 이제 모든 사용자가 접근할 수 있는 정확한 테이블 메타데이터를 반환하게 되었습니다.
+위에서 설명한 변경으로 모든 사용자가 접근 가능한 테이블에 대한 정확한 메타데이터를 확인할 수 있게 되었습니다. 불행히도, 과거에는 다음과 같은 가정이 있었는데, 쿼리 결과에 반환되는 열 목록이 “default” 데이터베이스만 포함될 것이라는 가정이었습니다.
 {{{SELECT
      name,
 ...
      table = 'http_requests_features'
 order by name;}}}
-쿼리가 데이터베이스 이름을 필터링하지 않는 점에 주목해야 합니다. ClickHouse 클러스터 사용자들에게 명시적 권한을 점진적으로 적용하는 과정에서, 11:05 변경 이후 위 쿼리는 r0 데이터베이스에 저장된 기본 테이블 때문에 컬럼이 “중복”되어 반환되기 시작했습니다.
+쿼리가 데이터베이스 이름을 필터링하지 않는다는 점에 주목하세요. 특정 ClickHouse 클러스터 사용자에게 명시적 권한을 점진적으로 배포하는 과정에서, 11:05 변경 이후 위 쿼리는 “중복” 열을 반환하기 시작했는데, 이는 r0 데이터베이스에 저장된 기본 테이블에 대한 열이 포함되었기 때문입니다.
-안타깝게도, 이 쿼리는 Bot Management의 feature file 생성 로직에서 각 입력 “feature”를 구성하는 데 사용되는 쿼리 유형이었습니다.
+안타깝게도, 이 쿼리가 바로 앞서 언급한 피처 파일의 각 입력 “피처”를 생성하기 위해 Bot Management에서 수행하는 로직에 사용되는 쿼리였습니다.
-위 쿼리는 (단순화한 예시처럼) 컬럼 테이블을 반환하게 됩니다.
+위 쿼리는 다음과 같이 열 테이블을 반환했습니다(단순화된 예시).
 [[파일:클플 오류7.png|width=100%]]
-하지만 사용자에게 추가 권한을 부여한 결과, 이제 쿼리 응답에는 r0 스키마의 모든 메타데이터가 포함되게 되었고, 그로 인해 응답 행 수가 사실상 두 배 이상 늘어나 최종 파일 출력에서 feature 수에도 영향을 미쳤습니다.
+그러나 사용자에게 추가 권한이 부여됨에 따라, 쿼리 응답에는 이제 r0 스키마의 모든 메타데이터가 포함되었고, 그 결과 응답의 행 수가 사실상 두 배 이상으로 증가하여 최종 파일 출력의 행 수(즉, 피처 수)에 영향을 미쳤습니다.
 '''{{{+5 메모리 사전 할당}}}'''
-프록시 서비스에서 실행되는 각 모듈에는 메모리 사용을 무한대로 늘어나지 않도록 제한하고, 성능 최적화를 위해 메모리를 사전 할당(preallocation) 하는 여러 제한이 설정되어 있습니다.
+당사 프록시 서비스에서 실행되는 각 모듈에는 무제한 메모리 사용을 방지하고, 성능 최적화를 위해 메모리를 사전 할당하기 위한 여러 제한이 설정되어 있습니다. 이번 사례에서는 Bot Management 시스템에 런타임에 사용할 수 있는 머신러닝 피처 수에 대한 제한이 있었습니다. 현재 이 제한은 200으로 설정되어 있으며, 이는 우리가 현재 사용하는 약 60개의 피처보다 훨씬 높은 수치입니다. 다시 말하지만, 이 제한은 성능상의 이유로 피처에 대한 메모리를 사전 할당하기 위해 존재합니다.
-이번 경우, Bot Management 시스템에는 런타임에 사용할 수 있는 머신러닝 feature 수에 제한이 있었는데, 현재 이 제한은 200으로 설정되어 있으며, 실제 사용 중인 feature 수는 약 60개였습니다. 이 제한은 성능을 위해 feature에 대해 메모리를 미리 할당하기 때문에 존재합니다.
+개 이상의 피처를 가진 잘못된 파일이 서버로 전파되었을 때, 이 제한에 도달하여 시스템이 패닉 상태에 빠졌습니다. 아래는 FL2 Rust 코드로, 해당 검사를 수행하며 처리되지 않은 오류의 원인이 된 부분입니다.
-그런데 잘못된 파일에 200개 이상의 feature가 포함되어 서버에 배포되면서, 이 제한을 초과하게 되었고, 시스템이 panic 상태에 빠지게 되었습니다. 이 확인을 수행하고 처리되지 않은 오류의 원인이 된 FL2 Rust 코드가 아래에 표시됩니다.
 [[파일:클플 오류8.png|width=100%]]
-이로 인해 다음과 같은 panic이 발생했고, 결국 HTTP 5xx 오류로 이어졌습니다.
+이로 인해 다음과 같은 패닉이 발생했으며, 이는 5XX 오류로 이어졌습니다.
 {{{thread fl2_worker_thread panicked: called Result::unwrap() on an Err value}}}
-'''{{{+5 사건 발생 동안의 기타 영향}}}'''
+'''{{{+5 사고 중 발생한 기타 영향}}}'''
-사건 발생 동안 핵심 프록시에 의존하는 다른 시스템들도 영향을 받았습니다. 여기에는 Workers KV와 Cloudflare Access가 포함됩니다. 팀은 13:04에 Workers KV를 패치하여 핵심 프록시를 우회하도록 했고, 이후 이들 시스템과 Workers KV에 의존하는 모든 하위 시스템(예: Access)에서 오류율이 줄어들었습니다.
+사고 중에 핵심 프록시를 사용하는 다른 시스템도 영향을 받았습니다. 여기에는 Workers KV와 Cloudflare Access가 포함되었습니다. 팀은 13:04에 Workers KV에 패치를 적용하여 핵심 프록시를 우회함으로써, 이 시스템들에 대한 영향을 줄일 수 있었습니다. 결과적으로 Workers KV에 의존하는 모든 다운스트림 시스템(Access 자체 등)에서 오류율 감소가 관찰되었습니다.
-또한 Cloudflare Dashboard도 영향을 받았는데, 내부적으로 Workers KV를 사용하고 로그인 과정에 Cloudflare Turnstile이 포함되어 있었기 때문입니다.
+Cloudflare 대시보드 역시 내부적으로 Workers KV가 사용되고 로그인 절차의 일부로 Cloudflare Turnstile이 배포되어 영향을 받았습니다.
-이번 장애로 Turnstile도 영향을 받아, 활성 대시보드 세션이 없는 고객은 로그인할 수 없었습니다. 이로 인해 11:30 ~ 13:10과 14:30 ~ 15:30 두 시간대에 가용성이 감소했습니다.
+Turnstile이 이번 중단 사태의 영향을 받았으며, 그 결과 활성 대시보드 세션이 없는 고객은 로그인할 수 없었습니다. 아래 그래프에서 볼 수 있듯이, 11:30~13:10 그리고 14:40~15:30의 두 기간 동안 가용성이 감소한 것으로 나타났습니다.
 [[파일:클플 오류9.png|width=100%]]
-첫 번째 기간인 11:30~13:10은 Workers KV에 대한 영향 때문이었으며, 일부 제어 플레인 및 대시보드 기능이 이에 의존하고 있었습니다. 13:10에 Workers KV가 핵심 프록시 시스템을 우회하도록 설정되면서 복구되었습니다.
+첫 번째 구간인 11:30~13:10은 일부 제어판 및 대시보드 기능이 의존하는 Workers KV에 대한 영향 때문이었습니다. 이는 13:10에 Workers KV가 핵심 프록시 시스템을 우회하면서 복구되었습니다. 대시보드에 대한 두 번째 영향 구간은 피처 구성 데이터를 복원한 이후 발생했습니다. 로그인 시도 백로그가 대시보드를 압도하기 시작했습니다. 이 백로그는 재시도 시도와 결합되어 대기 시간을 높여 대시보드 가용성을 저하시켰습니다. 제어판 동시 처리를 확장함으로써, 대시보드 가용성은 약 15:30경에 회복되었습니다.
-대시보드에 대한 두 번째 영향 기간은 feature configuration 데이터를 복원한 후 발생했습니다. 로그인 시도의 누적(backlog)이 대시보드를 압도하기 시작했고, 이 누적과 재시도 시도가 결합되면서 지연(latency)이 증가하고 대시보드 가용성이 감소했습니다. 제어 플레인 동시성(concurrency)을 확장하여 약 15:30에 가용성이 회복되었습니다.
+'''{{{+5 복원 및 후속 조치}}}'''
+시스템이 다시 정상적으로 온라인 상태를 회복함에 따라, 앞으로 이와 같은 장애에 대비해 시스템을 강화하는 작업이 이미 시작되었습니다. 특히 다음 작업에 착수 중입니다.
-'''{{{+5 복구 조치 및 후속 조치 단계}}}'''
-시스템이 정상적으로 온라인 상태로 복구된 지금, 앞으로 이런 장애에 대비해 시스템을 강화하는 작업이 이미 시작되었습니다. 특히 다음과 같은 조치를 진행 중입니다:
+ * Cloudflare에서 생성된 구성 파일 수집 과정을, 사용자 생성 입력 처리 시와 동일한 방식으로 강화
+ * 기능에 대한 더 많은 글로벌 킬 스위치 활성화
+ * 핵심 덤프나 기타 오류 보고가 시스템 자원을 과도하게 점유하는 것을 방지
+ * 모든 핵심 프록시 모듈에서 오류 조건에 대한 실패 모드 검토
- * Cloudflare가 생성한 구성 파일도, 사용자 입력처럼 엄격하게 검증하고 처리하도록 강화하고 있습니다.
- * 기능별로 더 많은 글로벌 킬 스위치를 활성화하여, 문제가 발생했을 때 신속히 시스템을 차단할 수 있도록 하고 있습니다.
- * 코어 덤프나 기타 오류 보고가 시스템 자원을 과도하게 사용하지 않도록 제한하고 있습니다.
- * 모든 핵심 프록시 모듈에서 오류 조건에 대한 실패 방식(failure mode)을 검토하고 있습니다.
+오늘은 Cloudflare에 [[https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/|2019년 이후]] 최악의 장애가 발생했습니다. 가동이 중단되어 [[https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/|대시보드를 사용할 수 없게]] 되었습니다. 이로 인해 잠시 동안 [[https://blog.cloudflare.com/cloudflare-service-outage-june-12-2025/|새로운 기능들]]이 구동되지 않는 문제가 생기기도 했습니다. 하지만 지난 6년 넘게, 핵심 트래픽 대부분이 네트워크를 통해 흐르지 못하게 만드는 다른 중단은 없었습니다.
-오늘은 [[https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/|2019년 이후]] Cloudflare의 최악의 장애였습니다. 이전에도 [[https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/|대시보드가 사용 불가능]]해지거나, [[https://blog.cloudflare.com/cloudflare-service-outage-june-12-2025/|새로운 기능이 잠시 제공되지 못한 장애]]는 있었지만, 지난 6년 이상 동안 핵심 트래픽 대부분이 네트워크를 통해 흐르지 못한 장애는 이번이 처음입니다.
+오늘과 같은 서비스 중단은 결코 용납할 수 없습니다. Cloudflare는 트래픽 흐름이 항상 유지되도록 하기 위해 장애 복원력이 뛰어난 시스템을 설계했습니다. 과거에 서비스 중단이 발생했을 때에도 항상 더 새롭고 복원력이 뛰어난 시스템을 구축해 왔습니다.
-오늘과 같은 장애는 용납될 수 없습니다. Cloudflare는 항상 트래픽이 계속 흐르도록 시스템을 높은 수준으로 내결함성(resilience)을 갖추도록 설계해왔습니다. 과거의 장애에서도 항상 더 견고한 시스템을 구축하는 계기가 되었습니다.
+Cloudflare 팀 전체를 대표하여 오늘 인터넷에 불편을 끼쳐드린 점 진심으로 다시금 사과드립니다.
-Cloudflare 전체 팀을 대표하여, 오늘 인터넷에 끼친 불편과 혼란에 대해 사과드립니다.
 {{{#!wiki style="margin: -5px 0px -10px 0px"
 ||<tablewidth=100%><tablebordercolor=#000,#fff><tablebgcolor=#ffffff,#1c1d1f><colcolor=#000,#fff><width=10%> '''시간''' ||<width=45%><colcolor=#000,#fff> '''상태''' ||<width=45%><colcolor=#000,#fff> '''설명''' ||
-|| 11:05 || 정상 || 데이터베이스 접근 제어 변경이 배포. ||
-|| 11:28 || 영향 시작. || 배포가 고객 환경에 도달하며, 고객 HTTP 트래픽에서 처음으로 오류가 관찰. ||
-|| 11:32-13:05 || 팀이 Workers KV 서비스에서 트래픽 증가와 오류 발생을 조사. || 초기 증상은 Workers KV 응답 속도 저하로, 다른 Cloudflare 서비스에 하류 영향(downstream impact)을 주는 것으로 나타났습니다.
+|| 11:05 || 정상 || 데이터베이스 접근 제어 변경 배포. ||
+|| 11:28 || 영향 시작. || 배포가 고객 환경에 적용된 후, 고객 HTTP 트래픽에서 첫 번째 오류 발견. ||
+|| 11:32-13:05 || 팀이 Workers KV 서비스의 트래픽 증가 및 오류를 조사. || 초기 증상으로 Workers KV 응답률 저하가 나타났으며, 이는 다른 Cloudflare 서비스에 다운스트림 영향을 미침.
-Workers KV 서비스를 정상 수준으로 복구하기 위해 트래픽 조정과 계정 제한과 같은 완화 조치가 시도되었습니다.
+Workers KV 서비스를 정상 운영 수준으로 복구하기 위해 트래픽 조작 및 계정 제한 등의 완화 조치 시도.
-첫 번째 자동화 테스트에서 11:31에 문제를 감지했고, 11:32에 수동 조사가 시작되었습니다. 사건 대응 콜은 11:35에 생성되었습니다. ||
-|| 13:05 || Workers KV와 Cloudflare Access에 대한 우회(bypass)가 구현되어, 영향이 감소. || 조사 과정에서 Workers KV와 Cloudflare Access에 대해 내부 시스템 우회(bypass)를 사용하여 이전 버전의 핵심 프록시로 되돌렸습니다. 이전 프록시 버전에서도 문제가 존재했지만, 아래 설명과 같이 영향은 더 적었습니다. ||
-|| 13:37 || 작업은 Bot Management 구성 파일을 마지막으로 정상 작동하던 버전으로 롤백하는 데 집중되었습니다. || 우리는 Bot Management 구성 파일이 이번 사건의 원인(trigger)임을 확신했습니다. 팀은 여러 작업 흐름(workstream)으로 서비스를 복구하는 방법을 진행했으며, 가장 신속한 방법은 파일의 이전 버전을 복원하는 것이었습니다. ||
-|| 14:24 || 새로운 Bot Management 구성 파일의 생성 및 전파를 중단. || 우리는 Bot Management 모듈이 500 오류의 원인임을 확인했고, 이는 잘못된 구성 파일 때문이었습니다. 이에 따라 새로운 Bot Management 구성 파일의 자동 배포를 중단했습니다. ||
-|| 14:24 || 새 구성 파일 테스트가 완료. || 이전 버전의 구성 파일을 사용하여 성공적으로 복구되는 것을 확인한 후, 글로벌 배포 속도를 높이는 데 집중했습니다. ||
-|| 14:30 || 주요 영향이 해결되었고, 하류에 영향을 받던 서비스들도 오류가 감소하기 시작. || 정상적인 Bot Management 구성 파일이 전 세계적으로 배포되었고, 대부분의 서비스가 정상적으로 작동하기 시작했습니다. ||
-|| 17:06 || 모든 서비스가 정상화되었고, 영향은 종료되었습니다. || 모든 하위 서비스가 재시작되었고, 모든 운영이 완전히 복구되었습니다. ||
+첫 번째 자동 테스트에서 11시 31분에 문제가 발견되었고, 11시 32분에 수동 조사를 시작. 11시 35분에 사고 대응 회의 소집. ||
+|| 13:05 || Workers KV 및 Cloudflare Access 우회 구현 - 영향 감소. || 조사 과정에서, Workers KV와 Cloudflare Access에 대한 내부 시스템 우회를 사용하여 이전 버전의 핵심 프록시로 복귀. 이번 문제는 이전 프록시 버전에서도 존재했지만, 아래에 설명된 것처럼 영향은 더 적었음. ||
+|| 13:37 || 작업은 Bot Management 구성 파일을 마지막으로 확인된 정상 버전으로 롤백하는 데 집중. || 이번 사고의 원인은 명백히 Bot Management 구성 파일임. 팀은 여러 작업 흐름에서 서비스 복구 방법을 모색했으며, 가장 빠른 작업 흐름은 파일의 이전 버전 복원이었음. ||
+|| 14:24 || 새 Bot Management 구성 파일의 생성 및 전파 중단. || 500 오류의 원인이 Bot Management 모듈에 있으며, 이는 잘못된 구성 파일로 인해 발생했음을 확인. 새 Bot Management 구성 파일의 자동 배포가 중단. ||
+|| 14:24 || 새 파일 테스트 완료. || 이전 버전의 구성 파일을 사용하여 성공적으로 복구된 것을 확인한 후, 전역적으로 수정 사항을 신속하게 적용하는 데 집중.||
+|| 14:30 || 주요 영향 해결. 다운스트림 영향 서비스에서 오류 감소가 관찰되기 시작. || 올바른 Bot Management 구성 파일이 전역에 배포되었으며 대부분의 서비스가 올바르게 작동하기 시작. ||
+|| 17:06 || 모든 서비스 해결. 영향 종료. || 모든 다운스트림 서비스가 재시작되었으며 모든 작동이 완전히 복원됨. ||
 }}}
 Cloudflare의 Connectivity Cloud는 [[https://www.cloudflare.com/ko-kr/network-services/|기업 전체 네트워크]]를 보호하고, [[https://workers.cloudflare.com/|고객이 인터넷 규모의 애플리케이션을 효율적으로 구축하도록]] 돕습니다. 또한 [[https://www.cloudflare.com/performance/accelerate-internet-applications/|모든 웹사이트나 인터넷 애플리케이션 속도를 가속화]]하고, [[https://www.cloudflare.com/ko-kr/ddos/|DDoS 공격을 막으며]], [[https://www.cloudflare.com/application-services/products/|해커로부터 보호]]하고, [[https://www.cloudflare.com/products/zero-trust/|Zero Trust 환경 구축에도 도움]]을 줍니다.
 ...