사례2건

2건 중 1~2번째

1. IL-0395 Google Cloud HTTP(S) Load Balancer 가 한참 오래된 구성으로 되돌아가 요청의 25%가 22분 동안 502 오류로 실패했다

   Google Cloud2017

   증상

   2017년 4월 5일 01:13 부터 01:35 PDT 까지 22분 동안 Google Cloud HTTP(S) Load Balancer 로 들어온 요청의 25%가 실패했고, 클라이언트는 실패한 요청에 502 오류를 받았다. 최근에 구성을 바꾼 일부 로드 밸런서는 오류율이 100%였다.

   오류율 상승프로브 실패

   촉발

   구성 갱신을 맡은 master 서버의 복제본 하나가 Google 분산 파일 시스템에 접근하지 못해 최근 구성 파일을 읽지 못한 채 master 역할을 넘겨받았다. 새 master 의 첫 구성 시험이 실패하자 모든 로드 밸런서가 그 master 가 읽을 수 있던 한참 오래된 구성으로 되돌아갔다.

   원인

   소프트웨어 결함

   구성 요소

   클라우드 로드 밸런서

   기여 요인

   자동화 증폭

   감지

   01:22 PDT 에 Google 엔지니어가 호출을 받았다.

   조치

   • 01:34 에 구성 갱신 과정이 다른 master 서버를 쓰도록 바꿨고, 대부분의 서비스가 1분 안에 회복했다.
   • 근본 원인을 확인하는 동안 05:16 까지 HTTP(S) Load Balancer 구성 갱신을 멈췄다.

   후속 조치

   • master 서버가 몇 시간 넘게 지난 HTTP(S) Load Balancer 구성은 절대 배포하지 않도록 설정한다.
   • Google Frontend 서버가 몇 시간 넘게 지난 구성 파일을 읽어 들이지 않고 거부하게 한다.
   • 새 HTTP(S) Load Balancer 구성을 시험하는 과정을 개선해, 오래된 구성이 운영에 배포되기 전에 잡아낸다.
   • master 서버가 Google 분산 파일 시스템에서 파일을 읽다가 실패한 문제를 고친다.
   • 가비지 컬렉션이 많을 때 Google Frontend 의 헬스 체크가 실패하는 문제를 고친다.

   사례 보기
2. IL-0396 새로 만들거나 라이브 마이그레이션한 GCE 인스턴스, Cloud VPN 터널, 네트워크 로드 밸런서가 2시간 8분 동안 공인 IP 주소로 연결되지 않았다

   Google Cloud2017

   증상

   2017년 1월 30일 새로 만든 GCE 인스턴스에 네트워크 연결이 되지 않았다. 라이브 마이그레이션 중인 인스턴스, 새로 만든 Cloud VPN 터널과 GCE 네트워크 로드 밸런서도 공인 IP 주소로 닿을 수 없었다. 이미 만들어져 있고 라이브 마이그레이션을 겪지 않은 인스턴스, 로드 밸런서, VPN 터널은 영향이 없었다.

   네트워크 도달 불가프로브 실패

   촉발

   드물게 쓰는 로드 밸런싱 구성에 대량의 변경이 들어갔다. 이 변경이 비효율적인 코드 경로를 타면서 canary 배포가 타임아웃됐다.

   원인

   소프트웨어 결함

   구성 요소

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

   기여 요인

   과도한 영향 범위자동 테스트 공백

   조치

   • 네트워크 로드 밸런서에 변경을 반영하는 작업을 재시작했다. 재시작 뒤 문제의 변경이 한 묶음으로 처리되면서 비효율적인 코드 경로를 타지 않았고, 변경이 다시 처리됐다.
   • 이 조치를 11:36 부터 12:42 까지 존마다 차례로 적용했다.

   후속 조치

   • canary 타임아웃을 늘려, 비효율적인 코드 경로를 타는 변경이 네트워크 변경을 완전히 멈추지 않고 늦추기만 하게 한다.
   • 비효율적인 코드 경로를 개선한다.
   • 더 넓은 범위의 구성에서 동작을 확인하는 테스트를 새로 쓴다.
   • 주소 구성을 전 세계로 퍼뜨리는 방식을 분산 라우팅으로 바꾸는 작업을 앞당겨, 이 계층의 문제가 전 세계에 영향을 주지 않게 한다.
   • 이런 문제를 더 빨리 알아보고 더 빨리 해결할 수 있도록 지표와 알림을 더 만든다.

   사례 보기

원인별1