사례3건

3건 중 1~3번째

1. IL-0350 TXL 클러스터 한 곳의 호스트 네트워크가 끊기고 프로비저닝 대기열이 밀려 여러 서비스가 오래 나빠졌다

   IONOS Cloud2026

   증상

   2026-03-03 11:36 UTC 에 상태 페이지가 TXL 의 모니터링 알림을 조사하고 있다고 알렸다. 정비 중이던 클러스터 한 곳의 호스트가 연결을 잃었고, 고객은 간헐적인 네트워크 서비스 저하나 중단을 겪었다.

   네트워크 도달 불가링크 플래핑서비스 중단

   촉발

   TXL 데이터 센터 클러스터의 고장 난 스위치를 바꾸는 정비로 두 토폴로지 가운데 Topology 2 를 계획대로 껐다. 그동안 남은 Topology 1 에서 스위치 하나의 링크 흔들림이 패브릭 resweep 을 일으켰다.

   원인

   용량 한계

   구성 요소

   InfiniBand 패브릭네트워크 컨트롤 플레인BGP 라우팅NIC·케이블·스위치 포트 링크모델 허브데이터베이스

   기여 요인

   자동화 증폭과도한 영향 범위

   감지

   IONOS Cloud 는 TXL 에서 울린 모니터링 알림으로 장애를 알아챘고, 11:36 UTC 에 상태 페이지에 이 알림을 조사하고 있다고 올렸다.

   조치

   • 문제가 난 컨트롤 플레인을 대기 장비로 전환했다.
   • 멈춘 게이트웨이를 재부팅했다.
   • 예정된 정비 상태에서 Topology 1 을 복구했다.
   • 작업이 밀린 클러스터의 프로비저닝을 잠시 멈췄다. 실행 중인 서비스는 영향이 없었지만 기존 자원의 변경은 다시 켤 때까지 처리되지 않았다.
   • 네트워크 연결이 나아지자 프로비저닝을 다시 켜고 작업 실행을 지켜봤다.
   • DCD 를 받치는 시스템들의 연결을 다시 세워 DCD 서비스를 되살렸다.

   후속 조치

   • 컨트롤 플레인 구성에서 failover 타이머를 덜 민감하게 바꾸고 무거운 sweep 작업을 줄여 전달 테이블의 부하를 낮췄다.
   • 멀티캐스트 그룹 가입 수를 줄여 전달 테이블의 부담을 더 덜었다.
   • 전달 테이블 사용률과 컨트롤 플레인 메모리를 계속 감시해 용량 한도에 닿기 전에 알림이 오게 했다.
   • 네트워크 관리와 데이터 플레인 트래픽이 자원을 다투지 않도록 컨트롤 플레인을 전용 고성능 서버로 옮긴다. 2025년 4분기에 시작했고 2026년 2분기 완료가 목표다.
   • IPv6 구성과 IPoIB 드라이버 설정을 깊이 감사한다. 2026년 2분기 완료가 목표다.
   • 스위치, 게이트웨이, 드라이버를 포함한 인터커넥트 패브릭을 현대화해 복원력과 성능을 높인다. 2026년 3분기 완료가 목표다.
   • 주요 Cloud API 를 잠시 쓸 수 없어도 핵심 신원 서비스가 동작하도록 IAM 정비 절차를 강화했다.
   • IAM 을 전용 플랫폼으로 옮기는 작업을 앞당겨 IAM 이 일반 Managed Kubernetes 클러스터에 기대지 않게 한다. 목표 시점은 2026년 3분기다.
   • DBaaS 와 Managed Kubernetes 에 전용 프로비저닝 공급자를 두어 자가 치유 같은 변경 중에 서비스가 끊기는 일을 줄인다. 목표 시점은 2026년 3분기다.
   • 자가 치유 서비스 때문에 과부하가 나거나 대기열이 끝없이 쌓이지 않도록 프로비저닝 엔진에 자동 서킷 브레이커를 넣는다. 목표 시점은 2026년 1분기다.
   • 프로비저닝 대기열에서 작업 실행과 우선순위를 더 잘 보고 다룰 수 있도록 QoS 를 개선한다.
   • 서비스 사이의 파급을 줄이도록 프로비저닝 대기열의 결합을 푸는 구조 변경을 한다.

   교훈

   IONOS Cloud 는 서비스들이 프로비저닝 대기열로 서로 얽혀 있던 점이 서비스 저하를 길게 만든 핵심 요인이었다고 봤다. 앞으로는 서비스마다 견고하게 만드는 것과 함께 프로비저닝 대기열의 결합을 풀어 이번과 같은 파급을 줄이겠다고 했다. 서비스 사이의 의존도 찾아 풀어서 앞으로의 장애가 미치는 범위를 줄이겠다고 했다.

   사례 보기
2. IL-0347 FR-PAR-1 가용 영역에서 하이퍼바이저 약 25% 의 VPC 연결이 11분 동안 끊겼다

   Scaleway2024

   증상

   FR-PAR-1 가용 영역의 하이퍼바이저 약 25% 가 리전의 나머지와 VPC 로 통신하지 못했다. 7:50 부터 8:01 UTC 까지 Managed Database, Redis, Serverless, Kubernetes Kapsule 처럼 VPC 에 기대는 제품이 함께 영향을 받았다.

   네트워크 도달 불가패킷 손실노드 NotReady

   촉발

   6:20 UTC 에 랙 하나의 ToR 스위치 소프트웨어가 충돌했다. 이 불안정이 같은 랙의 하이퍼바이저에서 돌던 VPC 용 BGP 경로 반사기를 비정상 상태에 빠뜨렸다.

   원인

   소프트웨어 결함

   구성 요소

   네트워크 컨트롤 플레인BGP 라우팅네트워크 스위치데이터베이스관리형 쿠버네티스 컨트롤 플레인과 제공자 API

   기여 요인

   과도한 영향 범위자동화 증폭

   감지

   Scaleway 의 Customer Excellence 팀과 SRE 팀이 영향을 알아채고 사고를 열었다. RR 의 헬스 체크 모니터링도 이상을 잡았지만 자동 재시작은 실패했다.

   조치

   • 멈춘 VPC 경로 반사기 두 대를 손으로 고쳤다.

   후속 조치

   • 멈춘 상태의 경로 반사기를 고치지 못한 자동 복구 장치를 고쳤다. 수정 내용은 https://github.com/FRRouting/frr/pull/17163 이다.
   • 버그 하나가 여러 경로 반사기를 한꺼번에 멈추지 않도록 경로 반사기의 소프트웨어 버전을 서로 다르게 둔다.
   • 경로 반사기를 멈춘 상태에 빠뜨린 소프트웨어 문제를 깊이 조사한다.

   사례 보기
3. IL-0337 US East 리전 한 가용 영역에서 네트워크 변경으로 EBS 노드가 복제본과 끊겨 EBS 볼륨이 멈췄다

   Amazon Web Services2011

   증상

   2011년 4월 21일 오전 12시 47분 PDT, US East 리전의 한 가용 영역에서 EBS 볼륨 일부가 읽기와 쓰기를 처리하지 못하게 됐고, 그 볼륨을 쓰던 EC2 인스턴스도 읽거나 쓰려다 함께 멈췄다. 리전 전체에서 EBS API 의 오류율과 지연도 높아졌다.

   스토리지 연결 끊김네트워크 도달 불가컨트롤 플레인 지연오류율 상승장애 조치 실패데이터 유실

   촉발

   US East 리전의 한 가용 영역에서 주 EBS 네트워크의 용량을 올리는 작업 중, 이중화된 라우터 하나에서 트래픽을 빼는 단계를 잘못 실행했다. 트래픽은 주 네트워크의 다른 라우터가 아니라 용량이 작은 보조 EBS 네트워크로 갔다.

   원인

   운영 실수

   구성 요소

   클라우드 블록 스토리지데이터베이스

   기여 요인

   자동화 증폭재시도 폭주여유 용량 부재과도한 영향 범위잡음에 묻힌 신호

   조치

   • 잘못된 트래픽 전환을 되돌려 네트워크 연결을 살렸다. 연결이 돌아오자 노드들이 한꺼번에 재미러링할 공간을 찾기 시작했다.
   • 4월 21일 오전 2시 40분 PDT, 영향받은 가용 영역의 새 Create Volume 요청을 모두 막는 변경을 배포했다. 2시 50분에 다른 EBS API 의 지연과 오류율이 회복했다.
   • 오전 8시 20분부터 망가진 EBS 클러스터와 EBS 컨트롤 플레인 사이의 통신을 모두 끊었다. 그 가용 영역의 EBS API 는 전부 막혔지만 리전의 나머지 EBS API 는 정상으로 돌아왔다.
   • 오전 11시 30분, 클러스터 노드 사이에 꼭 필요한 통신은 그대로 두고, 망가진 클러스터의 EBS 서버가 빈 공간도 없는 다른 서버에 헛되이 연락하지 못하게 막았다. 이 변경 뒤 클러스터는 더 나빠지지 않았다.
   • 오전 11시 30분, EBS 컨트롤 플레인을 바꿔 다른 가용 영역에서 EBS 기반 EC2 인스턴스를 새로 띄울 때의 오류와 지연을 없앴다. 정오에 거의 정상으로 돌아왔다.
   • 실패한 노드는 다시 쓰지 않고, US East 리전 곳곳의 여유 서버를 물리적으로 옮겨 망가진 EBS 클러스터에 설치했다.
   • 새로 들인 서버와는 협상이 일어나되 기존 서버에 처리하지 못할 요청이 다시 몰리지 않도록 협상 스로틀을 조심스럽게 바꿨다.
   • 리전의 다른 가용 영역에 영향이 가지 않도록 영향받은 가용 영역에만 쓰는 EBS 컨트롤 플레인을 따로 세우고 더 세밀한 스로틀을 만든 뒤, 밀린 상태 변경을 처리했다.
   • 장애 초반에 데이터 손실에 대비해 남은 2.2% 의 볼륨을 S3 백업에 스냅샷으로 떠 두었다. 그 스냅샷에서 볼륨을 복구하는 코드를 만들고 시험한 뒤 밤새 묶음으로 처리했다.
   • 기계 고장을 겪어 스냅샷도 뜨지 못한 나머지 볼륨을 포렌식으로 조사했고, 4월 24일 오후 3시부터 복구했다.
   • 자동 장애 전환을 하지 못하고 고립된 RDS multi-AZ 인스턴스의 primary 복제본은 데이터 손실 위험 때문에 사람이 직접 개입해 처리했다.

   후속 조치

   • 변경 절차를 감사하고 자동화를 늘려 이번 같은 실수가 다시 나지 않게 한다.
   • 큰 장애 복구에 필요한 안전 여유 용량을 늘 갖도록 용량 계획과 알람을 바꾼다. 용량 여유분은 이미 크게 늘렸고, 필요한 새 용량은 몇 주 안에 갖춘다.
   • EBS 서버 노드의 재시도 로직을 바꿔, 큰 중단이 나면 더 적극적으로 백오프하고 새 노드를 헛되이 찾기보다 이전 복제본과 연결을 되살리는 데 집중하게 한다.
   • EBS 노드를 죽인 경쟁 조건의 원인을 찾았고, 고친 코드를 시험해 몇 주 안에 클러스터에 배포한다.
   • RDS multi-AZ 인스턴스가 자동 장애 전환을 하지 못하게 만든 버그를 고치고 있다.
   • 한 가용 영역의 클러스터가 요청을 너무 오래 처리할 때 스레드가 고갈되지 않도록 타임아웃 로직을 바로 고친다.
   • EBS 컨트롤 플레인이 가용 영역을 더 잘 구분하고, 용량을 넘었을 때 부하를 골라서 덜어 내게 한다.
   • EBS 컨트롤 플레인의 기능을 더 많이 떼어 내, 지원하는 EBS 클러스터와 같은 가용 영역에서 도는 클러스터별 서비스로 옮긴다.
   • 로드맵을 조정해 지금은 가용 영역 하나만 쓸 수 있는 VPC 고객이 되도록 빨리 여러 가용 영역을 쓰게 한다.
   • 가용 영역 하나를 통째로 잃어도 애플리케이션 가용성이 유지되는 multi-AZ 애플리케이션을 만들 수 있도록 더 나은 도구를 고객에게 준다.
   • 클라우드 설계 모범 사례를 다루는 무료 웨비나를 5월 2일 월요일부터 열고, 모범 사례 백서와 함께 AWS 웹사이트의 새 Architecture Center 에 둔다.
   • 팀이 클러스터를 복구할 때 쓴 세밀한 제어와 스로틀을 EBS 노드 안에 바로 넣고, 여러 종류의 볼륨 복구에 쓴 방식을 자동화한다.
   • 클러스터가 나빠진 동안에도 볼륨 기능을 지키는 방법을 찾고, stuck 볼륨의 스냅샷을 뜨는 기능을 넣는 것을 검토한다.
   • 장애 도중부터 늘린 업데이트 빈도를 앞으로도 같은 수준으로 이어 간다. 또 이런 장애 때 개발자 지원 팀 인력을 더 넓게 배치하고, 짐작은 피하면서 이르고 쓸모 있는 정보를 내도록 조직하는 방법을 준비하고 있다.
   • 고객이 API 로 자기 인스턴스가 손상됐는지 볼 수 있는 도구를 만들고 있다.

   교훈

   AWS 는 이 사고를 촉발한 것은 네트워크 설정 변경이었지만, 앞으로의 일은 비슷한 실패가 나도 EBS 가 견디게 만드는 데 둔다고 했다. 여유 용량이 더 있었다면 망가진 클러스터가 재미러링 요청을 빨리 흡수해 폭주를 피했을 것이라고 봤다. 가용 영역들을 완전히 독립된 것처럼 만들려면 더 투자해야 한다는 것을 이 사고로 배웠다고 했다. 장애 중에 고객이 영향받은 자원을 다른 정상 가용 영역에서 바꾸기 어려웠던 일이 다시 일어나지 않게 하는 것을 최우선으로 꼽았다. 여러 가용 영역에 걸친 배포를 쉽게 설계하고 운영하도록 고객을 돕는 일도 더 잘해야 한다고 했다. 여러 종류의 볼륨 복구에 쓴 방식을 자동화해 두었다면 복구 시간을 크게 줄였을 것이라고 했다. 장애 중 고객 소통은 더 자주, 더 많은 정보를 담아야 한다고 봤다.

   사례 보기

원인별3