사례10건

10건 중 1~5번째

1. IL-0354 Fly.io 일부 머신의 사설 네트워크 6PN 이 끊겼고 다음 날 잠깐 다시 끊겼다

   Fly.io2026

   증상

   9월 23일 일부 머신의 사설 네트워크인 6PN 이 끊겼다. 다음 날에도 같은 문제가 잠깐 다시 일어났다.

   네트워크 도달 불가요청 오라우팅

   촉발

   에지가 static 이 아닌 피어의 게이트웨이 역할도 하도록 바꾸면서, 모든 에지에 게이트웨이처럼 netid 마다 /80 접두사 전체를 그 호스트로 보내는 라우팅 규칙이 들어갔다.

   원인

   배포 결함

   구성 요소

   호스트 라우팅 규칙네트워크 컨트롤 플레인

   기여 요인

   미검증 가정자동 테스트 공백

   조치

   • 영향을 받은 모든 호스트의 라우팅 테이블에서 잘못된 /80 경로를 지웠다.
   • 6PN 경로를 관리하는 데몬 s6pnforwarderd 의 변경을 롤백했다.
   • interactive 피어를 /128 로만 넣도록 고쳐 배포했다. 이 수정은 근본 원인을 고치지 못해 다음 날 잠깐 같은 문제가 다시 났다.
   • 호스트가 워커로 알려져 있는지와 상관없이 그 호스트의 ID 를 가진 머신이 있는지부터 찾도록 고쳐 근본 원인을 일단 막았다.

   후속 조치

   • 6PN 문제를 시험하고 알림을 내는 데 쓰는 머신에 당분간 로컬이 아닌 6PN 주소를 배정한다.
   • 중장기적으로 6PN 주소의 host ID 가 경로 결정에 아무 역할도 하지 않게 한다. 머신은 지금도 대체로 그렇지만 게이트웨이 피어는 아직 그렇지 않다.
   • 기존 게이트웨이 피어를 살리려고 둔 지금의 임시 방식을 끝내고, 새 피어와 머신 전체를 더 나은 모델로 옮긴다.

   교훈

   Fly.io 는 워커의 host ID 가 워커가 아닌 호스트에 다시 쓰일 수 있다는 점이 문서로 잘 남아 있지 않아 처음에 모두가 떠올린 것은 아니었다고 봤다. 게이트웨이를 오래 손대지 않았기 때문에 에지를 게이트웨이로 쓰기 전까지 문제가 드러나지 않았다. 더 깊은 문제는 6PN 라우팅의 알림과 자동 테스트였다. 기존 점검은 모두 원래 호스트에 있는 머신을 써서 host ID 재사용으로 생기는 충돌이나 고정 6PN 주소 구현과 얽힌 문제를 잡을 수 없었다. Fly.io 는 알림이나 큰 장애로 이어지지 않은 문제가 더 있었을 수 있다고 했다. 6PN 주소의 host ID 가 경로 결정에 아무 역할도 하지 않아야 이런 장애가 되풀이되지 않는다고 결론지었다.

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

   사례 보기
3. IL-0563 Linode 의 모든 리전에서 서버에 연결할 수 없게 됐고 Amsterdam 데이터센터는 거의 전부 멈췄다

   Linode2025

   증상

   2025년 3월 17일 16:38 UTC 쯤 여러 데이터센터에서 서버들에 오랫동안 연결할 수 없다는 내부 알림이 한꺼번에 울렸다. 같은 때 고객들도 여러 제품에서 문제를 신고하기 시작했다.

   네트워크 도달 불가서비스 중단

   촉발

   Akamai Compute 의 내부 백엔드 API 구성 요소를 릴리스하는 중이었다. 롤아웃이 이어지는 동안 이 API 의 응답이 서로 일치하지 않았다.

   원인

   배포 결함

   구성 요소

   BGP 라우팅네트워크 컨트롤 플레인

   기여 요인

   부분 배포

   감지

   16:38 UTC 쯤 여러 데이터센터에서 서버들에 오랫동안 연결할 수 없다는 내부 알림이 대거 울렸다. 같은 때 고객들도 여러 제품의 문제를 신고하기 시작했다.

   조치

   • 18:30 UTC 쯤부터 모든 데이터센터의 라우트 서버를 영향이 가장 큰 리전부터 단계적으로 재시작했고, 21:34 UTC 쯤 마쳤다.

   후속 조치

   • 라우트 서버가 받는 경로 데이터가 끊김 없이 이어지게 할 더 나은 방법을 마련할 때까지 백엔드 API 릴리스를 멈춘다.

   사례 보기
4. IL-0233 eu-west1 에서 Managed Kubernetes 의 거의 모든 파드가 네트워크 연결을 잃었고 롤백으로도 돌아오지 않았다

   Nebius2025

   증상

   2025-03-13 eu-west1 리전에서 Managed Services for Kubernetes 고객의 파드가 거의 모두 13:36 에서 18:11 UTC 사이에 적어도 한동안 네트워크 연결을 잃었다. Nebius 팀은 15:13 UTC 에 문제를 알아챘다. eu-north1 리전은 영향을 받지 않았다.

   네트워크 도달 불가

   촉발

   eu-west1 에 배포한 VPC 컨트롤 플레인 구성 요소의 릴리스가 새 기능에 필요한 route distinguisher 값을 바꿨다. 이 변경으로 오래전부터 코드에 있던 버그가 실제로 드러났다.

   원인

   소프트웨어 결함

   구성 요소

   네트워크 컨트롤 플레인BGP 라우팅

   기여 요인

   롤백 무효자동 테스트 공백모니터링 사각지대

   조치

   • 문제가 난 노드에서 구성 요소를 재시작하면 그 노드가 풀린다는 것을 찾고, 영향을 받은 모든 노드에서 구성 요소를 한 번에 한 노드씩 재시작하기 시작했다.
   • 17:57 UTC 에 구성 요소 재시작만으로 고쳐진다고 확신하고 병렬 재시작을 시작했다. 18:11 UTC 에 영향이 완전히 해소되었다.

   후속 조치

   • 버그 자체를 바로잡는다.
   • 경로 수가 어긋나면 울리는 알림을 더한다.
   • 데이터 플레인의 패킷 drop 수를 보는 알림을 더한다.
   • 호스트 VPC 구성 요소를 재시작하지 않고도 엔드포인트를 초기화하는 방법을 만든다.
   • VPC 의 상시 e2e 테스트 가상 머신을 카나리 호스트로 옮긴다.
   • Managed Services for Kubernetes 용 상시 e2e 테스트를 더한다.
   • e2e 테스트를 더 자주 돌린다.
   • 중요하지 않은 내부 서비스가 가장 먼저 업데이트를 받는 배포 단계를 새로 둔다.

   교훈

   문제를 재현하려면 두 조건이 함께 맞아야 해서 테스트 환경과 카나리의 e2e 테스트로는 잡지 못했다. 기술 지표가 평소 값에서 벗어날 때 울리는 알림이 모자라 대응이 늦어졌다. 이번 경우에는 경로 수와 패킷 drop 수가 민감하게 반응한 지표였다.

   사례 보기
5. 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 이다.
   • 버그 하나가 여러 경로 반사기를 한꺼번에 멈추지 않도록 경로 반사기의 소프트웨어 버전을 서로 다르게 둔다.
   • 경로 반사기를 멈춘 상태에 빠뜨린 소프트웨어 문제를 깊이 조사한다.

   사례 보기

원인별4