사례4건

4건 중 1~4번째

1. IL-0281 PostHog US 리전 Logs 제품의 ClickHouse 클러스터가 S3 에 둔 로그 데이터를 거의 다 지워 3일보다 오래된 로그가 사라졌다

   PostHog2026

   증상

   Logs 클러스터의 노드 하나가 죽었고, 다시 시작하는 중에 찾을 수 없는 데이터가 너무 많아 뜨지 못했다. 엔지니어가 확인해 보니 S3 에 저장된 데이터 대부분이 없었다.

   데이터 유실

   촉발

   인덱스를 materialize 하는 일상적인 mutation 이 끝나면서 ClickHouse 의 zero-copy replication 버그가 터졌고, 복제본 하나가 데이터베이스의 모든 데이터 파트를 더는 아무도 참조하지 않는다고 잘못 판단했다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스데이터베이스 복제오브젝트 스토리지데이터베이스 백업과 스냅숏

   기여 요인

   모니터링 사각지대단일 장애점미검증 백업

   감지

   19:40 UTC 에 클러스터 노드 하나가 죽었고, 재시작하다 없는 데이터가 많아 뜨지 못했다. 엔지니어가 이를 조사하다 S3 에 저장된 데이터 대부분이 없는 것을 발견했다. 그 전 8시간 동안 자동 알람은 하나도 울리지 않았다.

   조치

   • zero-copy replication 을 쓰지 않는 새 테이블로 전환하고 최근 메시지를 따라잡았다.
   • 보존 기간 3일인 Kafka 기록에서 데이터를 새 테이블로 백필했다. 2월 20일 10:05 UTC 에 시작해 12:21 에 끝났다.

   후속 조치

   • 모든 클러스터에서 Zero Copy Replication 을 바로 끈다.
   • Logs ClickHouse 설정 전체를 감사하고 운영 환경에서 실험 기능을 쓰지 않게 한다.
   • 저장소 버킷에 S3 Versioning 을 켜서 데이터베이스가 버그로 파괴적인 명령을 내도 객체를 되살릴 수 있게 한다.
   • 제품을 정식 출시하기 전에 설정과 데이터 무결성 전략을 표본 점검한다. 이 점검으로 단일 장애 지점을 찾아 고친다.

   교훈

   Logs 제품을 따로 떼어 둔 덕분에 다른 제품과 기능은 전혀 영향을 받지 않았고, Kafka 보존 기간 3일 덕분에 최근 데이터는 잃지 않았다. 반면 MVP 와 알파 단계에 쓰려던 실험 설정이 운영 환경까지 그대로 남았다. PostHog 는 들어오는 데이터와 핫 데이터의 상태만 감시해 과거 데이터가 지워지는 것을 보지 못했다. 공유 저장소를 쓰면서 데이터 내구성을 데이터베이스 복제에만 맡겨 단일 장애 지점이 생겼고, S3 Versioning 이 없어 지워진 파일을 되살릴 수 없었다.

   사례 보기
2. IL-0378 Cloudflare R2 객체 스토리지에서 1시간 7분 동안 쓰기가 모두 실패하고 읽기가 전 세계에서 약 35% 실패했다

   Cloudflare2025

   증상

   21:45 UTC 에 R2 전역 가용성 알림이 울렸다. 알림은 오류 예산 소진율 2% 를 가리켰고, R2 의 읽기와 쓰기 가용성 지표가 조금씩 계속 내려가고 있었다.

   자격 증명 획득 실패오류율 상승

   촉발

   R2 엔지니어링 팀이 R2 Gateway 서비스의 스토리지 인프라 자격 증명을 교체하면서 wrangler secret put 과 wrangler deploy 에 --env 인자를 빠뜨렸다. 새 자격 증명은 운영 Worker 가 아니라 기본 환경 Worker 에 들어갔고, 그 뒤 스토리지 인프라에서 옛 자격 증명을 지웠다.

   원인

   운영 실수

   구성 요소

   오브젝트 스토리지

   기여 요인

   미검증 가정모니터링 사각지대늦게 드러난 변경

   감지

   21:45 UTC 에 R2 전역 가용성 알림이 울렸다. 알림은 오류 예산 소진율 2% 를 가리켰고, R2 엔지니어링 팀은 운영 대시보드와 로그를 보기 시작했다.

   조치

   • 22:45 UTC 에 올바른 운영 R2 Gateway Worker 에 자격 증명을 배포했고, R2 가용성이 돌아왔다.

   후속 조치

   • R2 Gateway Worker 가 스토리지 인프라 인증에 쓰는 자격 증명 ID 의 끝자리를 로그 태그에 넣어, 어떤 자격 증명을 쓰는지 바로 확인할 수 있게 했다.
   • 옛 토큰을 지우기 전에 새 토큰 ID 의 끝자리가 스토리지 인프라 로그와 맞는지 반드시 확인하도록 내부 절차를 바꿨다.
   • 키 교체를 wrangler 명령을 손으로 치는 대신 핫픽스 배포 도구로만 하도록 했다. 이 도구는 환경 설정을 강제하고 다른 안전 검사도 한다.
   • 변경을 적어도 두 사람이 확인한다는 관행을 관련 표준 운영 절차에 명시했다.
   • 엔드포인트를 감시하는 기존 폐루프 상태 검사 시스템을 넓힌다. 이 시스템이 새 키를 시험하고, 그 상태를 알림 플랫폼으로 자동 보고하고, 게이트웨이 Worker 를 배포하기 전에 새 키가 전역으로 퍼졌는지 확인하게 한다.
   • 분산 스토리지 엔드포인트의 문제를 빨리 가려내도록, 관측 플랫폼에 캐시를 거치지 않은 업스트림 성공률 화면을 더한다.

   교훈

   이번 장애는 사람의 실수로 일어났고, R2 Gateway Worker 가 어떤 자격 증명으로 스토리지 인프라에 인증하는지 볼 수 없어서 더 길어졌다. Cloudflare 는 옛 자격 증명을 지운 뒤 가용성 지표에 기대지 말고, R2 Gateway 서비스가 실제로 어떤 토큰을 쓰는지 직접 확인했어야 했다고 적었다.

   사례 보기
3. IL-0343 digitaloceanspaces.com 도메인의 DNS 해석이 멈춰 DigitalOcean 의 Spaces, 컨테이너 레지스트리, App Platform, 로드 밸런서가 실패했다

   DigitalOcean2024

   증상

   2024년 11월 28일 22:38 UTC 부터 DigitalOcean 의 Cloud Control Panel 이 열리지 않았고, 고객은 가입하거나 로그인하지 못했다. 모니터링과 고객 신고로 장애가 선언됐고, 22:44 에 내부 알림이 문제를 잡았다.

   DNS 조회 실패오류율 상승이미지 풀 실패

   촉발

   도메인 등록 대행자 Network Solutions 가 11월 28일 22:38 UTC 에 digitaloceanspaces.com 도메인에 Extensible Provisioning Protocol, 곧 EPP 의 clientHold 상태 코드를 잘못 걸었다. 이 코드는 고객이 Network Solutions 에 연락해 풀기 전까지 DNS 해석을 막는다.

   원인

   의존성 장애

   구성 요소

   도메인 등록 대행자와 레지스트리오브젝트 스토리지컨테이너 레지스트리와 자격 증명

   기여 요인

   캐시로 가려진 장애모니터링 사각지대

   감지

   22:38 UTC 에 Cloud Control Panel 이 열리지 않는다는 모니터링과 고객 신고로 장애가 선언됐다. 22:44 에 내부 알림이 문제를 잡았고, 22:57 에 Cloud Control Panel 영향을 알리는 첫 고객 연락이 들어왔다.

   조치

   • Cloud Control Panel 을 다시 살리는 조치를 배포해 01:42 UTC 에 기능을 되살렸다. 사용자에게는 페이지를 몇 번 새로 고쳐 캐시를 비우라고 안내했다.
   • 01:08 UTC 에 Network Solutions 에 연락해 clientHold 를 풀어 달라고 요청했다.
   • 02:44 부터 04:03 UTC 까지 Verisign 임원진에게 여러 차례 에스컬레이션했고, 04:03 에 도메인의 clientHold 가 풀렸다.

   후속 조치

   • Network Solutions 와 함께 그쪽에서 무슨 일이 있었기에 도메인에 clientHold 가 잘못 걸렸는지 알아낸다.
   • DigitalOcean 도메인을 옮길 곳으로 다른 도메인 등록 대행자들을 검토한다.
   • 등록 대행자가 건 변경과 DNS 해석 문제로 생기는 장애를 더 빨리 알아채도록 모니터링과 알림을 검토한다.

   사례 보기
4. IL-0381 Newark 의 Linode Object Storage 가 두 번 느려지고 일부 요청이 504 gateway timeout 으로 실패했다

   Linode2022

   증상

   10월 10일부터 16일까지 한 주 동안 Newark 의 Linode Object Storage 에서 성능과 가용성이 떨어지는 장애가 두 번 났다. 일부 경우에는 프런트엔드 게이트웨이가 고객에게 504 gateway timeout 으로 응답했다.

   간헐적 타임아웃처리량 저하

   촉발

   백엔드 Object Storage 노드 하나에 하드웨어 문제가 생겼다. 완전한 고장이 아니어서 그 백엔드 인프라가 올라왔다 내려가기를 반복했다.

   원인

   하드웨어 고장

   구성 요소

   오브젝트 스토리지

   기여 요인

   모니터링 사각지대자동화 증폭

   조치

   • 10월 16일 10:31 UTC 에 완전히 고장 난 백엔드 Object Storage 인프라를 클러스터에서 뺐다. 그 뒤 클러스터가 회복하고 프런트엔드 게이트웨이가 정상으로 요청을 처리했다.

   후속 조치

   • 고장 나고 있거나 이상하게 동작하는 하드웨어의 미묘한 문제를 클러스터 전체에 번지기 전에 빨리 찾아 분류하도록 탐지 방법을 개선한다.
   • Ceph 관련 이벤트를 당직 관리자에게 더 정확히 설명하도록 모니터링을 바꿨다. 관리자가 문제를 더 빨리 좁힐 수 있게 알림도 더 분명히 정의했다.

   교훈

   Linode 는 이 장애로 내부 모니터링 시스템의 빈틈이 드러났다고 적었다. 완전히 고장 나지 않고 이상하게 동작하는 하드웨어의 미묘한 문제는 클러스터 전체에 번지기 전에 찾아내야 한다고 봤다.

   사례 보기

원인별4