{"id":"IL-0395","org":"Google Cloud","date":"2017-04-05","docs":[],"title":{"en":"Google Cloud HTTP(S) Load Balancer gave 502s on 25% of requests for 22 minutes after reverting to a stale configuration","ko":"Google Cloud HTTP(S) Load Balancer 가 한참 오래된 구성으로 되돌아가 요청의 25%가 22분 동안 502 오류로 실패했다"},"domain":["gcp","networking"],"impact":{"scope":"Google Cloud HTTP(S) Load Balancer: 25% of requests failed with 502 for 22 minutes, 100% on some recently modified load balancers; App Engine Flexible deployments failed during the 3 hours 41 minutes configuration pause","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.cloud.google.com/incident/compute/17007","kind":"official-status","archived":"https://web.archive.org/web/20261103100409/https://status.cloud.google.com/incident/compute/17007"}],"summary":{"en":"A master server controls the process that pushes configuration to the Google Cloud HTTP(S) Load Balancers. When mastership changes, the new master starts its next push by testing the configuration on a subset of load balancers; if the test passes the configuration goes to all load balancers globally, and if it fails the master reverts all load balancers to the last \"known good\" configuration. On 5 April 2017 one master replica lost access to Google's distributed file system, could not read recent configuration files, and then took over mastership. Its test of the latest configuration failed, so it reverted every HTTP(S) Load Balancer to the newest configuration it could read, which was far out of date. Google describes this as a bug in the configuration update process.\n\nThe stale configuration deleted many configurations on the Google Frontend servers, which started garbage collection to free their memory. The garbage collection took so much CPU that the servers failed health checks and were restarted, and requests served by those servers got 502 errors. Engineers were paged at 01:22 PDT and at 01:34 switched the configuration update process to a different master server, which ended the errors for most services within one minute. Configuration updates to the HTTP(S) Load Balancer then stayed paused until 05:16 while the root cause was confirmed, which made App Engine Flexible deployments fail in that window.","ko":"HTTP(S) Load Balancer 의 구성 갱신은 master 서버가 맡는다. master 역할이 다른 서버로 넘어가면 새 master 는 평소처럼 다음 구성을 일부 로드 밸런서에서 먼저 시험한다. 시험이 통과하면 전 세계 모든 로드 밸런서에 배포하고, 시험이 실패하면 모든 로드 밸런서를 마지막으로 정상이 확인된 \"known good\" 구성으로 되돌린다. 2017년 4월 5일 master 복제본 하나가 Google 분산 파일 시스템에 접근하지 못해 최근 구성 파일을 읽지 못했는데, master 역할이 바로 그 서버로 넘어갔다. 새 master 의 첫 시험이 실패했고, 구성 갱신 과정의 버그 때문에 로드 밸런서는 master 가 읽을 수 있던 가장 최근 구성으로 되돌아갔다. 그 구성은 한참 오래된 것이었다.\n\n오래된 구성이 들어가자 Google Frontend 서버에서 삭제된 구성의 메모리를 비우는 가비지 컬렉션이 돌았다. 삭제된 구성이 많아 서버는 CPU 의 상당 부분을 가비지 컬렉션에 썼고, 헬스 체크에 실패해 재시작됐다. 재시작 중인 서버가 받은 요청은 502 오류로 끝났고, 01:13 부터 01:35 PDT 까지 22분 동안 요청의 25%가 실패했다.\n\n엔지니어는 01:22 에 호출을 받았고 01:34 에 구성 갱신 과정이 다른 master 서버를 쓰도록 바꿨다. 대부분의 서비스는 1분 안에 회복했다. 근본 원인을 확인하는 동안 05:16 까지 구성 갱신을 멈췄고, 그동안 App Engine Flexible 앱 배포가 실패했다."},"trigger":{"en":"One replica of the master servers that control the HTTP(S) Load Balancer configuration update process lost access to Google's distributed file system and could not read recent configuration files, and mastership then passed to that replica.","ko":"구성 갱신을 맡은 master 서버의 복제본 하나가 Google 분산 파일 시스템에 접근하지 못해 최근 구성 파일을 읽지 못한 채 master 역할을 넘겨받았다. 새 master 의 첫 구성 시험이 실패하자 모든 로드 밸런서가 그 master 가 읽을 수 있던 한참 오래된 구성으로 되돌아갔다."},"severity":"unknown","symptoms":["high-error-rate","readiness-probe-failures"],"timeline":{"detected_after":"9m","resolved_after":"22m"},"date_kind":"incident","detection":{"en":"Google engineers were paged at 01:22 PDT, nine minutes after the errors began.","ko":"01:22 PDT 에 Google 엔지니어가 호출을 받았다."},"components":["cloud-load-balancer"],"root_cause":"software-bug","remediation":[{"text":{"en":"Switched the configuration update process to a different master server at 01:34 PDT","ko":"01:34 에 구성 갱신 과정이 다른 master 서버를 쓰도록 바꿨고, 대부분의 서비스가 1분 안에 회복했다."}},{"text":{"en":"Paused configuration updates to the HTTP(S) Load Balancer until 05:16 while the root cause was confirmed","ko":"근본 원인을 확인하는 동안 05:16 까지 HTTP(S) Load Balancer 구성 갱신을 멈췄다."}}],"action_items":[{"text":{"en":"Configure master servers never to push HTTP(S) Load Balancer configurations more than a few hours old","ko":"master 서버가 몇 시간 넘게 지난 HTTP(S) Load Balancer 구성은 절대 배포하지 않도록 설정한다."}},{"text":{"en":"Make Google Frontend servers reject loading a configuration file more than a few hours old","ko":"Google Frontend 서버가 몇 시간 넘게 지난 구성 파일을 읽어 들이지 않고 거부하게 한다."}},{"text":{"en":"Improve testing of new HTTP(S) Load Balancer configurations so out-of-date configurations are flagged before reaching production","ko":"새 HTTP(S) Load Balancer 구성을 시험하는 과정을 개선해, 오래된 구성이 운영에 배포되기 전에 잡아낸다."}},{"text":{"en":"Fix the issue that made the master server fail to read files from Google's distributed file system","ko":"master 서버가 Google 분산 파일 시스템에서 파일을 읽다가 실패한 문제를 고친다."}},{"text":{"en":"Fix the issue that made Google Frontends fail health checks during heavy garbage collection","ko":"가비지 컬렉션이 많을 때 Google Frontend 의 헬스 체크가 실패하는 문제를 고친다."}}],"contributing":["automation-amplified"],"recurrence_of":null,"symptoms_text":{"en":"On 5 April 2017 from 01:13 to 01:35 PDT, 25% of requests to the Google Cloud HTTP(S) Load Balancer failed, and clients received 502 errors for the failed requests. Some HTTP(S) Load Balancers that had been modified recently failed 100% of their requests.\n\nThe errors came from Google Frontend servers that were restarting. After loading a configuration from which many configurations had been deleted, the Google Frontend servers spent a large share of their CPU on garbage collection to free the memory of the deleted configurations, failed their health checks and were restarted. Every client request served by a restarting server got a 502.\n\nAfter the errors ended, Google paused all configuration changes to the HTTP(S) Load Balancer for three hours and 41 minutes while engineers confirmed the root cause. During that pause, deployments of App Engine Flexible apps failed.","ko":"2017년 4월 5일 01:13 부터 01:35 PDT 까지 22분 동안 Google Cloud HTTP(S) Load Balancer 로 들어온 요청의 25%가 실패했고, 클라이언트는 실패한 요청에 502 오류를 받았다. 최근에 구성을 바꾼 일부 로드 밸런서는 오류율이 100%였다.\n\n502 오류는 재시작 중인 Google Frontend 서버가 받은 요청에서 났다. Google Frontend 서버는 삭제된 구성이 쓰던 메모리를 비우는 가비지 컬렉션에 CPU 를 많이 썼다. 그러다 헬스 체크에 실패했고, 결국 재시작됐다.\n\n장애가 끝난 뒤에도 근본 원인을 파악할 때까지 3시간 41분 동안 HTTP(S) Load Balancer 구성 변경을 멈췄다. 그동안 App Engine Flexible 앱 배포가 실패했다."},"updated_at":"2026-11-14T12:34:04.630401Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0395","org_slug":"google-cloud"}