사례4건

4건 중 1~4번째

1. IL-0529 모든 Google Cloud 존에서 VPC 컨트롤러가 꺼져 새로 만든 VM 과 여러 제품의 새 인스턴스가 네트워크 없이 올라왔다

   Google Cloud2024

   증상

   새로 만든 VM 이 네트워크 연결 없이 올라와 아무 연결도 맺지 못했고, 마이그레이션되거나 재시작된 VM 은 연결을 잃었다. 방화벽이나 네트워크 로드 밸런서 같은 가상 네트워크 설정을 바꿀 수 없었다. GKE 노드와 노드 풀 생성이 실패했다.

   네트워크 도달 불가패킷 손실클러스터·노드 생성 정체노드 증설 실패오류율 상승

   촉발

   한 Google Cloud 존에서 쓰지 않는 VPC 컨트롤러 하나를 끄려던 정기 유지보수 자동화가 존 매개변수를 무시하고, 아직 쓰이던 모든 존의 VPC 컨트롤러를 껐다.

   원인

   소프트웨어 결함

   구성 요소

   네트워크 컨트롤 플레인클라우드 로드 밸런서NAT 게이트웨이

   기여 요인

   늦게 드러난 변경초기 신호 무시파괴적 변경 보호 장치 부재과도한 영향 범위

   감지

   엔지니어들은 미국 태평양 시간 15:41 에 내부 모니터링 알림으로 장애를 알았다.

   조치

   • 재발을 막으려고 유지보수 작업을 곧바로 멈췄다.
   • 유지보수 작업을 멈추는 동시에 영향을 받은 VPC 컨트롤러를 다시 서비스 상태로 되돌렸다. 대부분 존은 미국 태평양 시간 17:30 에, 모든 VPC 컨트롤러는 18:09 에 돌아왔다.
   • 이 변경을 일으킨 자동화를 찾아냈고, 알맞은 안전장치가 생길 때까지 그 자동화를 중단시켰다.
   • Apigee Edge 에서 일부만 배포된 프록시는 손으로 처리해 2024-05-17 미국 태평양 시간 01:00 까지 복구했다.
   • 클러스터 삭제 작업이 실패해 완전히 지워지지 않은 Dataproc VM 을 찾아냈고, 장애가 완화된 뒤 정리했다.

   후속 조치

   • 유지보수 작업에 존 정보가 알맞은 범위로 들어 있는지 검증하는 안전장치를 더한다.
   • 하위 도구가 존을 지정하지 않은 유지보수 작업을 거부하게 해 심층 방어를 넓힌다.
   • 필요할 때만 권한을 주는 접근 제어를 늘려, 유지보수 작업 한 번이 여러 존에 걸쳐 동작하지 못하게 한다.
   • 유지보수 작업에 필요한 안전 점검, 테스트, 검증 절차를 갖춘다. 회귀를 막도록 위의 세 안전장치마다 통과해야 할 경우와 막아야 할 경우의 테스트를 넣는다.

   사례 보기
2. IL-0530 us-central1 의 가상 네트워크 라우터 컨트롤러가 메모리 부족으로 재시작을 되풀이해 새 VM 과 마이그레이션된 VM 의 네트워크가 오래 끊겼다

   Google Cloud2023

   증상

   us-central1 에서 새로 만든 VM 은 네트워크가 동작하기까지 오래 기다려야 했고, 라이브 마이그레이션된 VM 은 마이그레이션 뒤 오래 연결을 잃었다. us-central1 을 오가는 리전 간 트래픽에서 패킷 손실이 났다. 기존 VM 중 마이그레이션되지 않고 상태도 바뀌지 않은 VM 은 직접 영향을 받지 않았다.

   패킷 손실네트워크 도달 불가OOMKilled오래된 엔드포인트 라우팅클러스터·노드 생성 정체

   촉발

   관리 플레인의 동작 변경이 us-central1 에 배포됐다. 이 변경은 로드 밸런서 백엔드로 쓰는 GCP Instance Group 과 Network Endpoint Group 의 API 업데이트 처리를 더 잘 분리하려는 것이었다. 이 리전의 큰 워크로드 규모 때문에 가상 네트워크 라우터 컨트롤 플레인의 메모리가 예상 밖으로 늘었다.

   원인

   배포 결함

   구성 요소

   네트워크 컨트롤 플레인클라우드 로드 밸런서

   기여 요인

   과도한 영향 범위한계 경보 부재

   감지

   엔지니어들은 10월 4일 미국 태평양 시간 21:45 에 us-central1 가상 네트워크 컨트롤 플레인이 느리다는 알림을 받았고, 10월 5일 02:11 에 가상 네트워크 라우터 컨트롤러가 메모리를 다 써서 실패한다는 알림을 받았다. 03:08 부터는 네트워크 텔레메트리가 us-central1 을 오가는 리전 간 패킷 손실을 보여 주었다.

   조치

   • 컨트롤러에 메모리를 더 할당하는 변경을 배포했고, 이 변경은 미국 태평양 시간 05:27 부터 운영 환경에 닿았다. 08:15 에 리전 안 패킷 손실이 가라앉았다.
   • 08:52 에 관리 플레인 변경의 롤백을 시작해 09:35 에 us-central1 에서 마쳤고, 이때 메모리 부족이 모두 멈췄다.
   • 업데이트를 받지 않던 라우터 몇 대를 손으로 재시작했다. 이 재시작으로 패킷 손실이 더 생기지는 않았다.

   후속 조치

   • 메모리 위험과 예상 밖의 메모리 증가를 미리 알리는 알림을 만든다.
   • 엔지니어가 메모리를 훨씬 빨리 다시 할당할 수 있도록 배포 설정을 다시 짠다.
   • API 조정 작업의 기존 관행과 안전장치를 다시 평가하고 새 관행과 안전장치를 만든다.
   • 관리 플레인 변경을 여러 팀이 더 잘 볼 수 있게 해 장애와 더 빨리 연결 짓게 한다.
   • 리전 단위 API 변경 때문에 리전 전체의 메모리가 한꺼번에 바닥나는 일이 줄도록 배포 구성을 바꾼다.
   • 트래픽 라우터와 컨트롤러의 메모리를 최적화해 불필요한 부담을 없앤다.

   사례 보기
3. IL-0532 Azure Software Load Balancer 뒤의 백엔드가 15개를 넘는 로드 밸런서에서 연결이 간헐적으로 끊기고 패킷이 사라졌다

   Microsoft Azure2022

   증상

   고객 일부가 Software Load Balancer 뒤의 리소스에 연결할 때 네트워크 실패와 패킷 손실이 간헐적으로 났다. 장애는 2022-06-28 05:26 UTC 부터 2022-07-01 04:00 UTC 까지 이어졌다.

   간헐적 연결 실패패킷 손실요청 오라우팅

   촉발

   Software Load Balancer 에 배포한 최신 코드의 변경 하나 때문에, 백엔드 풀에 목적지 IP 가 15개를 넘는 로드 밸런서에서 일부 MUX 인스턴스가 목적지 IP 를 다른 순서로 저장했다.

   원인

   배포 결함

   구성 요소

   클라우드 로드 밸런서

   기여 요인

   초기 신호 무시

   감지

   텔레메트리에서 오류가 조금 늘었고 고객 지원 요청도 여러 건 들어왔지만, 실패가 간헐적이어서 헬스 체크가 이 신호를 최근 배포와 연결하지 못했다. 고객 영향을 이 배포와 연결했을 때 코드는 이미 14개 리전에 퍼져 있었다.

   조치

   • 원인을 파악하는 동안 먼저 영향을 받은 것으로 확인된 고객의 VIP 를 골라 손으로 완화했다.
   • 고객 트래픽에 더 영향을 주지 않고 적용할 수 있는 핫픽스를 만들어 테스트했고, Safe Deployment Practices 에 따라 단계적으로 배포했다.
   • 핫픽스가 퍼지는 동안 5분마다 모든 VIP 를 검사해 상태가 어긋난 VIP 를 완화하는 자동화를 만들어, 오래 유지할 완화책이 다 배포될 때까지 돌렸다.
   • 백엔드 인스턴스의 순서를 장애 전처럼 일관되게 되돌렸다.

   후속 조치

   • Azure Firewall 에서 한 흐름의 오가는 패킷이 같은 목적지 IP 에 닿지 않는 경우를 잡는 모니터링을 더한다.
   • IPv6 흐름 식별자가 연결이 이어지는 동안 바뀌지 않도록 고쳐서 한 연결의 모든 패킷이 MUX 하나에 닿게 한다.
   • Azure Firewall 에 방화벽 전용 패킷 캡처 지원을 더해 이런 문제를 더 빨리 찾고 완화하게 한다.
   • Azure Firewall 의 TCP 흐름 로그를 늘려 잘못된 패킷과 RST, FIN, FIN-ACK 패킷을 기록해 문제를 더 잘 좁히게 한다.
   • Safe Deployment Practices 로 배포하는 동안 종단 간 모니터링을 늘리려고 더 많은 Azure 서비스가 내부 AIOps 도구인 Gandalf 를 쓰도록 서두른다.

   교훈

   이번 장애로 Safe Deployment Practices 로 배포하는 동안 더 철저한 종단 간 모니터링이 필요하다는 것이 확인됐다.

   사례 보기
4. IL-0590 Rackspace ORD 재부팅 뒤 Mailgun 연결이 간헐적으로 실패하고 이벤트 유실과 이메일 중복 발송이 났다

   Mailgun2014

   증상

   2014년 9월 27일 토요일 18:50 UTC 에 Mailgun 은 모든 데이터베이스 복제와 모든 리전의 환경 사이 내부 트래픽이 끊기고 타임아웃이 보고되는 것을 알아챘다. 그때 Mailgun 은 Rackspace 의 ORD 재부팅을 앞두고 트래픽을 다른 환경으로 옮길 준비를 하고 있었다.

   간헐적 연결 실패간헐적 타임아웃패킷 손실

   촉발

   Rackspace 가 시카고 데이터 센터 ORD 의 클라우드 인스턴스를 재부팅한 유지 보수가 Mailgun 의 F5 서버에 오류 상태를 일으켰다.

   원인

   DNS·네트워크 장애

   구성 요소

   클라우드 로드 밸런서데이터베이스 복제

   기여 요인

   –

   감지

   9월 27일 18:50 UTC 에 ORD 트래픽 전환을 준비하던 Mailgun 이 모든 데이터베이스 복제와 환경 사이 내부 트래픽이 끊기고 타임아웃이 보고되는 것을 발견했다.

   조치

   • Rackspace 네트워크 팀이 Mailgun 의 F5 와 일부 Rackspace 전용 고객의 F5 에서 캐시를 지웠다.
   • Rackspace 네트워크 팀이 Mailgun 서비스용 새 virtual IP 를 만들었다.
   • Mailgun 이 DNS 설정을 바꿔 원격 F5 의 캐시가 강제로 비워지게 했다.

   후속 조치

   • Rackspace 와 함께 F5 문제의 근본 원인을 계속 조사한다.
   • 근본 원인 분석을 마치면 클라우드 인프라 유지 보수가 Mailgun 고객에게 영향을 주지 않도록 조치한다.

   사례 보기

원인별3