사례4건
4건 중 1~4번째
- 증상
2025-03-10 16:23 UTC 무렵 FR-PAR 리전의 모든 제품에서 공용 인터넷 연결이 크게 흔들렸다. 인터넷 트래픽 대부분이 사실상 버려졌고, FR-PAR-2 가용 영역과 나머지 PAR 리전 사이의 공용 인터넷 연결이 심하게 끊겼다.
- 촉발
Scaleway 네트워크 팀이 FR-PAR 리전 백본에 새 데이터 센터를 붙이던 중 라우터 구성을 잘못 넣었다. 이 실수로 OpCore DC3 와 DC5 사이의 1Tbps 넘는 트래픽이 100Gbps 링크 하나로 돌아갔다.
- 원인
- 구성 요소
- 기여 요인
- 감지
라우터 구성 실수는 빨리 발견되어 4분 안에 롤백됐다.
- 조치
- 잘못 넣은 라우터 구성을 4분 안에 롤백해 16:27 UTC 에 올바른 구성을 되돌렸다.
- 후속 조치
- 변경 관리를 고쳐 동료 검토와 운영 공지 절차를 강화한다.
- 백본 수준의 네트워크 구성을 적용하기 전에 안전장치와 시험을 더 거치도록 운영 절차를 고친다.
- Object Storage 동기화 소프트웨어의 문제를 찾아 수정을 만들고 시험했으며, 이 수정을 배포하고 있다.
- 증상
2024-07-30 PDT 오후 2:45 부터 US-EAST-1 리전의 여러 AWS 서비스에서 지연과 오류율이 올랐다. CloudWatch Logs, Amazon Data Firehose, Amazon S3 이벤트를 게시하는 이벤트 프레임워크, Amazon ECS, AWS Lambda, Amazon Redshift, AWS Glue 가 영향을 받았다. 같은 리전의 다른 Kinesis Data Streams 셀로 가는 요청은 정상이었다.
- 촉발
2024-07-30 PDT 오전 9:09 에 내부 Kinesis 셀 하나의 가용 영역 한 곳에서 정기 배포가 시작됐다. 이 셀에는 처리량이 아주 낮은 샤드가 아주 많았다. 배포가 호스트를 서비스에서 뺐다가 다시 넣자 셀 관리 시스템이 잘못 동작했다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- PDT 오후 4:25 에 덜 급한 내부 워크로드의 유입 스트림을 줄여 부하를 덜어 내는 변경을 배포했다. 셀 관리 시스템이 처리할 데이터가 줄어 오후 5:39 에 오류율과 지연이 나아지기 시작했다.
- 보안 연결을 만드는 하위 시스템에 용량을 더해 셀 관리 시스템의 상태를 되살렸다. 오후 5:55 에 셀 관리 시스템이 Kinesis 요청 처리에 쓰는 보안 연결을 제대로 맺었다.
- 오후 6:32 에 연결 프로비저닝을 더 나아지게 하려고 용량을 더 늘렸고, 오류율이 더 내려갔다.
- 후속 조치
- 장애 중에 한 변경을 US-EAST-1 에 그대로 남긴다. 데이터 플레인 연결을 만드는 용량을 늘리고, 부하를 덜어 내는 도구를 운영에 넣고, 연결 한도를 바꾼 것이 여기에 든다.
- 새 Kinesis Data Streams 아키텍처의 셀이 있는 다른 모든 AWS 리전에도 같은 변경을 이미 적용했다.
- 이번 장애를 일으킨 워크로드를 더 잘 다루도록 셀 관리 시스템을 더 고친다.
- 증상
10월 10일부터 16일까지 한 주 동안 Newark 의 Linode Object Storage 에서 성능과 가용성이 떨어지는 장애가 두 번 났다. 일부 경우에는 프런트엔드 게이트웨이가 고객에게 504 gateway timeout 으로 응답했다.
- 촉발
백엔드 Object Storage 노드 하나에 하드웨어 문제가 생겼다. 완전한 고장이 아니어서 그 백엔드 인프라가 올라왔다 내려가기를 반복했다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 10월 16일 10:31 UTC 에 완전히 고장 난 백엔드 Object Storage 인프라를 클러스터에서 뺐다. 그 뒤 클러스터가 회복하고 프런트엔드 게이트웨이가 정상으로 요청을 처리했다.
- 후속 조치
- 고장 나고 있거나 이상하게 동작하는 하드웨어의 미묘한 문제를 클러스터 전체에 번지기 전에 빨리 찾아 분류하도록 탐지 방법을 개선한다.
- Ceph 관련 이벤트를 당직 관리자에게 더 정확히 설명하도록 모니터링을 바꿨다. 관리자가 문제를 더 빨리 좁힐 수 있게 알림도 더 분명히 정의했다.
- 교훈
Linode 는 이 장애로 내부 모니터링 시스템의 빈틈이 드러났다고 적었다. 완전히 고장 나지 않고 이상하게 동작하는 하드웨어의 미묘한 문제는 클러스터 전체에 번지기 전에 찾아내야 한다고 봤다.
IL-0229손상된 SmartEdge 데이터 파일을 받은 bunny.net 의 전 세계 DNS 서버가 크래시를 되풀이해 플랫폼 대부분이 2시간 넘게 멈췄다.bunny.net2021- 증상
2021-06-22 UTC 8:25 에 업데이트를 내보내고 몇 분 만에 전 세계에 있는 100대 가까운 bunny.net DNS 서버가 거의 모두 죽었다. bunny.net 은 트래픽의 60% 넘게 잃었고, 수백 Gbit 의 처리량이 사라졌으며, 750,000개가 넘는 웹사이트가 영향을 받았다.
- 촉발
2021-06-22 UTC 8:25 에 최적화 데이터베이스의 다운로드 크기를 줄이려는 업데이트가 손상된 파일을 Edge Storage 에 올렸다. DNS 서버가 이 파일을 읽자 BinaryPack 직렬화 라이브러리가 stack overflow 예외를 일으켰고, 예외 처리를 건너뛴 채 DNS 프로세스가 종료됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
팀은 무슨 일인지 알아채는 데 시간이 걸렸다. 업데이트 10분 뒤에야 DNS 서버가 다시 시작했다가 죽기를 되풀이하고 있고, 이 상태로는 되살릴 방법이 없다는 것을 알았다.
- 조치
- UTC 8:45 에 SmartEdge 시스템을 끄는 업데이트를 DNS 노드에 손으로 배포했다. 하지만 손상된 GeoDNS 데이터베이스 때문에 요청이 Madrid 로 몰렸다.
- 9:40 무렵 임시 조치로 모든 요청을 가장 큰 리전인 Frankfurt 로 보내는 라우팅 업데이트를 준비해 DNS 서버 몇 대에 손으로 배포했다. 트래픽의 상당 부분이 돌아왔다.
- 자체 시스템을 쓰지 않으려고 배포 시스템과 파일을 모두 외부 클라우드 스토리지 서비스로 옮겼다.
- 10:15 에 배포 시스템과 DNS 소프트웨어를 새 스토리지에 연결하도록 바꾸고 배포했다. 10:30 에 트래픽이 돌아왔지만 잘못된 GeoDNS 데이터베이스 버전 때문에 요청은 여전히 Madrid 로 갔다.
- 10:45 에 외부 서비스를 거쳐 데이터베이스를 동기화하고 최신 파일 세트를 배포해 서비스를 되살렸다. 11:00 에 상황이 안정되기 시작했다.
- 후속 조치
- 긴급 수정으로 BinaryPack 라이브러리를 단계적으로 걷어 낸다.
- 앞으로 쓰는 외부 라이브러리를 더 폭넓게 시험한다.
- 내부 API 를 외부의 독립 서비스로 완전히 옮긴다. 그 서비스가 내려가면 업데이트를 못 하지만, bunny.net 시스템이 내려가도 무너지는 인프라에 갇히지 않고 빠르게 대응할 수 있다.
- 중요하지 않다고 본 소프트웨어 하나가 여러 클러스터에 걸친 단일 장애 지점이 되지 않게 하는 방법을 조사한다.
- DNS 시스템이 모든 백업 데이터의 로컬 사본을 갖추고 장애를 자동으로 감지하게 해, 시스템끼리 최대한 독립시키고 장애가 연쇄로 번지지 않게 한다.
- 교훈
bunny.net 은 내부 인프라의 핵심 부분까지 모든 시스템이 서로 기대도록 설계했다. 그 때문에 손상된 파일 하나가 여러 겹의 이중화를 무너뜨리고 복구할 길까지 막았다. 자체 인프라를 자기 생태계 안에 지으면 한 곳의 장애가 연쇄로 번질 수 있다. 업데이트는 카나리 방식으로 잘게 배포하려 했지만, 중요하지 않다고 본 소프트웨어 하나가 여러 클러스터에 동시에 걸친 단일 장애 지점이 됐다. 급하게 고치는 동안 오타와 실수가 늘었고, 결국 침착하게 모든 것을 다시 확인한 뒤의 마지막 배포로 복구했다.
이 4건에서 가장 많이 나오는 구성 요소: 오브젝트 스토리지, DNS 서버와 레코드. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.