사례2건

2건 중 1~2번째

1. IL-0084 베어메탈 업체 vSwitch 의 패킷 드롭으로 Namespace 의 fra3 리전이 빠져 전 세계 용량이 모자랐고, 다음 날에는 컨트롤 플레인 노드의 느린 NVMe 쓰기로 쿠버네티스 API 서버 CPU 가 치솟아 zrh1 이 멈췄다.

   Namespace2024

   증상

   10월 17일부터 fra3 리전에서 패킷이 드문드문 버려지기 시작했다. 처음 이틀은 TCP 와 QUIC 의 재전송이나 컨트롤 플레인의 재시도로 대부분 넘어갔지만, 시스템이 조금씩 불안정했다. 이런 실패는 비결정적이라 겉으로 잘 드러나지 않았다.

   간헐적 연결 실패지연 시간 증가컨트롤 플레인 지연서비스 중단

   촉발

   fra3 에서 베어메탈 업체의 vSwitch 를 지나는 패킷이 무작위로 드문드문 버려지기 시작했다. 두 번째 장애는 컨트롤 플레인 노드 하나의 느린 NVMe 가 쿠버네티스의 변경 속도를 더는 따라가지 못하면서 일어났다.

   원인

   클라우드 제공자 장애

   구성 요소

   쿠버네티스 API 서버

   기여 요인

   용량 계획 부재여유 용량 부재장애 중첩

   감지

   패킷 드롭은 비결정적이라 바로 보이지 않았다. 주요 상호작용에 잡아 둔 백분위 지연 SLO 의 에러 버짓이 줄어드는 것을 보고 영향을 알아챘다.

   조치

   • fra3 의 고객 트래픽을 모두 다른 리전으로 돌렸다.
   • vSwitch 대신 Wireguard 로 업체의 물리 머신 하나하나를 zrh1 클러스터에 연결했다.
   • 각 머신을 새 신원, 새 인증서, 새 저장 데이터 암호화 키로 다시 깔았고, 복구를 앞당기려고 캐시를 버렸다.
   • 팀 일부가 데이터셋을 더 분산된 방식으로 복제해 머신을 다시 까는 작업을 앞당겼다.
   • 준비된 머신을 묶음으로 새 리전에 넣고, 충분히 모이자 리전을 컴퓨트 풀에 다시 넣었다.
   • 두 번째 장애에서 워크로드를 zrh1 밖으로 돌렸다.
   • 실패하던 컨트롤 플레인 노드의 핵심 상태를 더 큰 노드로 복제하고, 새 노드가 같은 IP 주소로 옛 노드의 역할을 넘겨받게 했다.

   후속 조치

   • 장애 동안 실행된 모든 인스턴스의 요금을 고객에게 크레딧으로 환급했다.
   • 비슷한 상황이 다시 와도 고객에게 영향을 주지 않도록 백업 리전과 대안을 만든다.

   교훈

   비결정적인 네트워크 드롭은 재시도에 가려져서 SLO 기반 모니터링으로 긴 시간을 봐야 영향이 드러난다. 핵심 인프라의 문제를 직접 고칠 수단을 갖고 있어야 한다. 큰 장애 직후에는 같은 종류의 원인에 매이기 쉽다. 이번 두 번째 장애는 전혀 다른 종류였다. 미리 해 둔 모의 위기 훈련 덕분에 대응을 바로 체계적으로 시작할 수 있었다.

   사례 보기
2. IL-0154 SFO3 코어 라우터의 라인 카드가 하드웨어 오류로 한꺼번에 재부팅된 뒤 게스트 네트워킹이 돌아오지 않은 DOKS 노드가 비정상으로 남아, 일부 클러스터의 연결과 컨트롤 플레인 접속이 01:40 UTC까지 불안정했다.

   DigitalOcean2024

   증상

   2024년 9월 25일 22:25 UTC부터 SFO3 리전의 DigitalOcean 서비스 전반에서 네트워크 연결 문제가 생겼다. 리전 전체 서비스는 22:50에 회복됐지만 일부 Managed Kubernetes 클러스터는 그 뒤에도 연결이 불안정했다.

   노드 NotReady컨트롤 플레인 무응답간헐적 연결 실패

   촉발

   SFO3 코어 라우터 한 대에서 하드웨어 오류로 라인 카드 대부분이 동시에 재부팅됐다.

   원인

   DNS·네트워크 장애

   구성 요소

   쿠버네티스 API 서버kubelet

   기여 요인

   –

   조치

   • 죽었던 라인 카드가 모두 빠르게 다시 올라와 네트워크 트래픽이 다시 흐르고 코어 라우터가 정상으로 돌아왔다.
   • SFO3 리전 DOKS 전체에서 영향받은 노드를 손으로 모두 재생성했다.

   후속 조치

   • 장비 벤더 지원팀과 함께 라인 카드가 죽은 근본 원인을 찾는다.
   • SFO3 리전 코어 라우터의 소프트웨어를 업그레이드한다.
   • 자동 복구 조치의 임계값을 높여 사람이 손으로 노드를 복구해야 하는 일을 줄인다.

   교훈

   네트워크가 몇 분 만에 돌아와도 게스트 네트워킹이 회복되지 않은 노드는 사람이 재생성할 때까지 비정상으로 남았다. 리전 전체 서비스는 25분 만에 돌아왔지만 DOKS 는 01:40까지 영향을 받았다. 자동 복구 조치가 이 경우를 처리하지 못해 SFO3 DOKS 전체에서 수동 작업이 필요했다.

   사례 보기

원인별2