사례3건

3건 중 1~3번째

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-0461 메트릭 질의 서비스를 롤아웃할 때마다 DNS 오류가 나며 질의가 실패했다

   Datadog2022

   증상

   2021년 9월부터 메트릭 질의 서비스의 업데이트를 롤아웃할 때마다 오류가 늘었다. 서비스 로그에는 DNS 오류 때문에 메트릭 데이터 저장소에 연결하지 못했다는 내용이 찍혔다. 클라이언트가 실패한 질의를 자동으로 재시도해 사용자에게 보이는 오류는 적었지만, 재시도 때문에 대시보드와 모니터의 지연이 늘었다.

   오류율 상승DNS 조회 실패지연 시간 증가OOMKilled패킷 손실오래된 엔드포인트 라우팅

   촉발

   2021년 8월 메트릭 질의 클라이언트의 업데이트를 롤아웃하면서 새 기본값인 gRPC round_robin 부하 분산 정책이 처음 적용됐다. round_robin 은 끊긴 채널을 자동으로 다시 연결하는데, 오래전에 넣어 둔 매우 공격적인 gRPC 재연결 타임아웃과 겹쳐 서비스 롤아웃 때마다 사라진 파드 IP 로 SYN 이 쏟아졌다.

   원인

   설정 변경

   구성 요소

   conntrack 테이블Cilium리눅스 커널CoreDNS클라이언트 쪽 DNS 리졸버와 캐시external-dnsHTTP·RPC 클라이언트 라이브러리

   기여 요인

   늦게 드러난 변경재시도 폭주한계 미인지모니터링 사각지대

   감지

   2021년 9월부터 메트릭 질의 서비스 롤아웃 때 오류가 늘어나는 것을 보았고, 서비스 로그에서 DNS 오류가 데이터 저장소 연결을 막는 것을 확인했다.

   조치

   • node-local-dns 파드의 메모리를 64 MB 에서 256 MB 로 올렸다. OOM 오류는 멈췄지만 DNS 오류는 계속됐다.
   • AWS 가 더 많은 연결을 추적할 수 있다고 한 더 큰 인스턴스 유형으로 서비스 인프라를 올려 보았고, 그것만으로 문제가 사라지는 것을 확인했다.
   • SYN 폭주를 일으킨 사용자 지정 gRPC 재연결 파라미터를 지우고 기본값으로 되돌리는 PR 을 만들었다. 다음 롤아웃에서는 오류가 나지 않았다.

   후속 조치

   • Cilium 프로젝트에 PR 을 기여한다. 이 PR 은 옛 파드 IP 에 unreachable 경로를 더해, 지워진 파드로 가는 요청이 martian 패킷이 되지 않게 한다. 그러면 역경로 필터가 SYN 을 버리지 않고, 클라이언트는 분명한 ICMP 오류를 받는다.

   교훈

   gRPC, 쿠버네티스, AWS 같은 강력한 추상화도 엣지 케이스에서는 평소에 숨어 있던 복잡함이 오류로 드러난다. 몇 달을 조사한 끝에, 이번 장애의 뿌리가 팀이 직접 한 변경에 있다는 것을 찾았다. 의존성의 버그를 피해 가려던 변경, 이전 장애를 고치려던 변경, 기본 재연결 파라미터를 덮어쓴 변경이었다. 이 변경들은 당시에는 안전해 보였지만 한참 뒤에 상관관계를 찾기 어려운 때에 뜻밖의 결과를 냈다. DNS 문제처럼 보여도 DNS 문제가 아닐 때가 있다. AWS ENA 지표와 VPC Flow Logs 는 연결 추적을 들여다보는 데 중요하다. DNS 전파 시간은 여러 요인에 좌우된다.

   사례 보기
3. IL-0336 도쿄 리전으로 가는 Direct Connect 트래픽에 패킷 손실과 간헐적인 연결 끊김이 6시간 넘게 이어졌다

   Amazon Web Services2021

   증상

   일본 시간 2021년 9월 2일 오전 7시 30분부터 Direct Connect 로 도쿄 리전에 접속하는 고객의 트래픽에 간헐적인 연결 문제와 패킷 손실 증가가 나타났다. 같은 시각 AWS 엔지니어는 패킷 손실 증가를 알리는 내부 알람을 받았다.

   패킷 손실간헐적 연결 실패

   촉발

   네트워크 장비 운영체제에 결함이 있었고, 이 결함은 아주 특정한 패킷 속성과 내용이 맞아야만 드러났다. 고객 트래픽이 그 조건에 맞는 패킷을 꾸준히 만들어 내 결함을 건드렸다. AWS 는 악의를 의심할 이유가 없다고 밝혔다.

   원인

   소프트웨어 결함

   구성 요소

   트랜짓 게이트웨이와 네트워크 연결 장비

   기여 요인

   늦게 드러난 변경스테이징 불일치

   감지

   오전 7시 30분, 도쿄 리전에 접속하는 Direct Connect 고객의 패킷 손실 증가를 알리는 내부 알람이 AWS 엔지니어에게 울렸다. 고장 난 장비를 감시하는 자동화도 고장 장비의 비율이 평소보다 높다는 것을 알아채고 엔지니어에게 조사와 조치를 요청했다.

   조치

   • 이 계층에 이중화가 충분하다고 보고 영향받은 장비를 서비스에서 빼, 정상 장비가 트래픽을 처리하게 했다. 잠시 나아졌지만 다른 장비들이 같은 고장을 일으켰다.
   • 고장 난 장비를 리셋하고 천천히 서비스에 되돌려 봤지만 고장은 이어졌다.
   • 한 가용 영역에서 먼저 새 프로토콜을 끄고 회복이 유지되는지 지켜보면서 도쿄 리전 전체에 적용할 변경을 준비했다. 그 뒤 도쿄 리전에서 새 프로토콜을 껐다.

   후속 조치

   • 고객 영향이 나기 전에 이 결함을 찾아 고치는 개선된 방법을 갖추고, 나머지 모든 AWS 리전에 이 변경을 조심스럽게 적용한다.

   사례 보기

원인별2