사례7건

7건 중 4~7번째

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-0225 라우터 명령 하나가 Microsoft WAN 의 모든 라우터에 토폴로지를 다시 계산하게 해 전 세계 Azure 네트워크 연결이 불안정해졌다.

   Microsoft Azure2023

   증상

   2023-01-25 07:08 UTC 부터 Azure 리전의 리소스와 Microsoft 365, Power Platform 같은 Microsoft 서비스에 연결할 때 네트워크 지연이 길어지거나 타임아웃이 났다. 모니터링은 07:11 UTC 부터 DNS 와 WAN 문제를 잡았고, 명령을 실행하고 5분 안에 당직 엔지니어에게 알림이 갔다.

   지연 시간 증가간헐적 타임아웃간헐적 연결 실패패킷 손실네트워크 도달 불가

   촉발

   07:08 UTC 에 마드리드에서 전 세계 WAN 에 용량을 더하던 엔지니어가, 다시 검증하지 않은 표준 운영 절차대로 IGP 데이터베이스를 비우는 명령을 실행했다. 이 명령은 한 제조사의 라우터에서는 로컬 라우터에 그치지 않고 IGP 로 이어진 모든 라우터에 IGP 토폴로지 데이터베이스를 다시 계산하라고 지시했다.

   원인

   설정 변경

   구성 요소

   백본망내부 라우팅BGP 라우팅

   기여 요인

   설정 테스트 부재미검증 가정과도한 영향 범위수동 조치 악화

   감지

   모니터링이 07:11 UTC 부터 DNS 와 WAN 문제를 잡았고, 명령을 실행하고 5분 안에 당직 엔지니어에게 알림이 갔다. 변경하던 엔지니어는 바뀐 절차 때문에 이 알림을 전달받지 못했다. 팀은 최근 변경을 모두 살펴 08:20 UTC 에 문제의 명령을 찾았다.

   조치

   • WAN 라우팅이 수렴한 뒤에도 남은 패킷 손실을 없애려고, 사고 중 멈춰 있던 비정상 장비 제거 시스템과 트래픽 엔지니어링 시스템을 손으로 다시 시작했다. 12:43 UTC 에 복구를 마쳤다.

   후속 조치

   • 세 제조사 전부와 모든 WAN 라우터 역할을 대상으로, 넓은 영향을 줄 수 있는 비슷한 명령을 감사하고 막는다. 2023년 2월에 끝낼 예정이다.
   • 승인된 자동화와 승인된 비상 접근인 break glass 작업, 승인되지 않은 장비 작업을 실시간으로 보여 줘, 당직 엔지니어가 누가 네트워크 장비에서 무엇을 바꾸는지 볼 수 있게 한다. 2023년 2월에 끝낼 예정이다.
   • 정기적인 필수 운영 교육과 모든 표준 운영 절차를 지키겠다는 확인 절차를 도입해 절차를 계속 개선한다. 2023년 2월에 끝낼 예정이다.
   • 아직 검증을 기다리는 표준 운영 절차를 모두 감사하고, 엔지니어 의견을 받아 30일 안에 Change Advisory Board 검토를 우선 받게 한다. 2023년 4월에 끝낼 예정이다.

   사례 보기
4. IL-0222 유지보수 자동화가 여러 위치의 네트워크 제어 평면 작업을 한꺼번에 내려 미국 Google Cloud 리전의 네트워크가 심하게 혼잡해졌다.

   Google Cloud2019

   증상

   2019-06-02 US/Pacific 11:47~11:49 부터 미국 여러 리전의 Google Cloud 프로젝트에서 패킷 손실이 늘고, 지연이 커지고, 간헐적 오류와 인스턴스 연결 끊김이 나타났다. us-west1 과 유럽, 아시아 리전에는 리전 네트워크 혼잡이 없었다. Google 엔지니어는 장애가 시작되고 2분 뒤 알림을 받았다.

   패킷 손실네트워크 도달 불가지연 시간 증가오류율 상승모니터링 중단

   촉발

   US/Pacific 11:45 에 비교적 드문 유형의 데이터 센터 유지보수 이벤트가 물리 위치 한 곳에서 시작됐다. 자동화 소프트웨어가 내릴 작업 목록에 네트워크 제어 작업을 돌리는 논리 클러스터를 넣었다. 이 클러스터에는 다른 물리 위치의 네트워크 제어 작업도 들어 있어, 여러 위치의 네트워크 제어 평면과 지원 인프라가 한꺼번에 내려갔다.

   원인

   소프트웨어 결함

   구성 요소

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

   기여 요인

   과도한 영향 범위순환 의존디버그 접근 제한롤백 무효

   감지

   Google 엔지니어는 장애가 시작되고 2분 뒤 알림을 받았고, 가장 심각한 운영 사고에 쓰는 사고 관리 절차를 곧바로 시작했다. 고객용 상태 페이지에는 US/Pacific 12:53 에 첫 공지가 올라왔다.

   조치

   • 혼잡을 줄이려고 덜 중요한 네트워크 트래픽 등급의 우선순위를 낮췄다.
   • US/Pacific 13:01 에 근본 원인을 찾고, 유지보수 이벤트를 일으킨 자동화 소프트웨어를 멈췄다.
   • 네트워크 제어 평면과 지원 인프라를 위치마다 다시 스케줄해 켰다.
   • 제어 평면 인스턴스가 모두 내려가면서 사라진 설정 데이터를 여러 위치에 다시 만들어 배포했다. 새 설정은 14:03 부터 나가기 시작했다.
   • Google 안의 여러 팀이 서비스별 완화 조치로 트래픽을 피해 리전 밖으로 돌려 다른 곳에서 계속 서비스했다.
   • us-west2, northamerica-northeast1, southamerica-east1 에서 장애 때문에 fail-safe 상태에 들어간 VPN 제어 평면을 손으로 빼냈다. 이 리전의 VPN 게이트웨이는 16:30 에 회복됐다.

   후속 조치

   • 유지보수 때 작업을 내리는 데이터 센터 자동화 소프트웨어를 즉시 멈췄고, 여러 물리 위치에서 동시에 작업을 내리지 않게 하는 안전장치를 갖춘 뒤에만 다시 켠다.
   • 클러스터 관리 소프트웨어가 요청의 출처와 상관없이 여러 물리 위치의 작업을 한꺼번에 내리는 요청을 거부하도록 강화한다.
   • 네트워크 제어 평면 소프트웨어와 지원 인프라가 이번 사고에 얽힌 유형의 유지보수 요청을 거부하도록 다시 설정한다.
   • 위치마다 네트워크 제어 평면이 설정을 영구 저장하게 바꿔, 모든 작업이 내려가도 설정을 다시 만들고 배포할 필요가 없게 한다. 이렇게 하면 복구 시간이 열 배쯤 줄어든다.
   • 제어 평면을 잃었을 때 네트워크가 fail static 모드로 더 오래 버티게 해, 사용자 영향 없이 복구할 시간을 충분히 둔다.
   • 고객 소통 도구를 포함한 비상 대응 도구와 절차를 검토하고 고치고 시험해, 이번과 같은 네트워크 장애에도 견디게 한다.
   • 상시 재해 복구 시험의 범위를 넓혀 이번 장애와 이와 비슷한 수준의 큰 장애를 넣는다.

   사례 보기

원인별4