사례4건
4건 중 1~4번째
- 증상
새로 만든 VM 이 네트워크 연결 없이 올라와 아무 연결도 맺지 못했고, 마이그레이션되거나 재시작된 VM 은 연결을 잃었다. 방화벽이나 네트워크 로드 밸런서 같은 가상 네트워크 설정을 바꿀 수 없었다. GKE 노드와 노드 풀 생성이 실패했다.
- 촉발
한 Google Cloud 존에서 쓰지 않는 VPC 컨트롤러 하나를 끄려던 정기 유지보수 자동화가 존 매개변수를 무시하고, 아직 쓰이던 모든 존의 VPC 컨트롤러를 껐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
엔지니어들은 미국 태평양 시간 15:41 에 내부 모니터링 알림으로 장애를 알았다.
- 조치
- 재발을 막으려고 유지보수 작업을 곧바로 멈췄다.
- 유지보수 작업을 멈추는 동시에 영향을 받은 VPC 컨트롤러를 다시 서비스 상태로 되돌렸다. 대부분 존은 미국 태평양 시간 17:30 에, 모든 VPC 컨트롤러는 18:09 에 돌아왔다.
- 이 변경을 일으킨 자동화를 찾아냈고, 알맞은 안전장치가 생길 때까지 그 자동화를 중단시켰다.
- Apigee Edge 에서 일부만 배포된 프록시는 손으로 처리해 2024-05-17 미국 태평양 시간 01:00 까지 복구했다.
- 클러스터 삭제 작업이 실패해 완전히 지워지지 않은 Dataproc VM 을 찾아냈고, 장애가 완화된 뒤 정리했다.
- 후속 조치
- 유지보수 작업에 존 정보가 알맞은 범위로 들어 있는지 검증하는 안전장치를 더한다.
- 하위 도구가 존을 지정하지 않은 유지보수 작업을 거부하게 해 심층 방어를 넓힌다.
- 필요할 때만 권한을 주는 접근 제어를 늘려, 유지보수 작업 한 번이 여러 존에 걸쳐 동작하지 못하게 한다.
- 유지보수 작업에 필요한 안전 점검, 테스트, 검증 절차를 갖춘다. 회귀를 막도록 위의 세 안전장치마다 통과해야 할 경우와 막아야 할 경우의 테스트를 넣는다.
IL-0530us-central1 의 가상 네트워크 라우터 컨트롤러가 메모리 부족으로 재시작을 되풀이해 새 VM 과 마이그레이션된 VM 의 네트워크가 오래 끊겼다Google Cloud2023- 증상
us-central1 에서 새로 만든 VM 은 네트워크가 동작하기까지 오래 기다려야 했고, 라이브 마이그레이션된 VM 은 마이그레이션 뒤 오래 연결을 잃었다. us-central1 을 오가는 리전 간 트래픽에서 패킷 손실이 났다. 기존 VM 중 마이그레이션되지 않고 상태도 바뀌지 않은 VM 은 직접 영향을 받지 않았다.
- 촉발
관리 플레인의 동작 변경이 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 변경 때문에 리전 전체의 메모리가 한꺼번에 바닥나는 일이 줄도록 배포 구성을 바꾼다.
- 트래픽 라우터와 컨트롤러의 메모리를 최적화해 불필요한 부담을 없앤다.
IL-0532Azure 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 로 배포하는 동안 더 철저한 종단 간 모니터링이 필요하다는 것이 확인됐다.
- 증상
2014년 9월 27일 토요일 18:50 UTC 에 Mailgun 은 모든 데이터베이스 복제와 모든 리전의 환경 사이 내부 트래픽이 끊기고 타임아웃이 보고되는 것을 알아챘다. 그때 Mailgun 은 Rackspace 의 ORD 재부팅을 앞두고 트래픽을 다른 환경으로 옮길 준비를 하고 있었다.
- 촉발
Rackspace 가 시카고 데이터 센터 ORD 의 클라우드 인스턴스를 재부팅한 유지 보수가 Mailgun 의 F5 서버에 오류 상태를 일으켰다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
9월 27일 18:50 UTC 에 ORD 트래픽 전환을 준비하던 Mailgun 이 모든 데이터베이스 복제와 환경 사이 내부 트래픽이 끊기고 타임아웃이 보고되는 것을 발견했다.
- 조치
- Rackspace 네트워크 팀이 Mailgun 의 F5 와 일부 Rackspace 전용 고객의 F5 에서 캐시를 지웠다.
- Rackspace 네트워크 팀이 Mailgun 서비스용 새 virtual IP 를 만들었다.
- Mailgun 이 DNS 설정을 바꿔 원격 F5 의 캐시가 강제로 비워지게 했다.
- 후속 조치
- Rackspace 와 함께 F5 문제의 근본 원인을 계속 조사한다.
- 근본 원인 분석을 마치면 클라우드 인프라 유지 보수가 Mailgun 고객에게 영향을 주지 않도록 조치한다.
이 4건에서 가장 많이 나오는 구성 요소: 클라우드 로드 밸런서, 네트워크 컨트롤 플레인. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.