{"id":"IL-0338","org":"Google Cloud","date":"2018-07-17","docs":[],"title":{"en":"Google Cloud HTTP(S) and TCP/SSL Proxy load balancers returned 502s or reset connections on 33% to 87% of requests","ko":"Google Cloud 의 HTTP(S) 로드 밸런서와 TCP/SSL Proxy 로드 밸런서가 32분 동안 요청의 33~87% 에 502 나 연결 재설정을 냈다"},"domain":["gcp","networking"],"impact":{"scope":"Google Cloud HTTP(S) Load Balancer, TCP/SSL Proxy Load Balancer and the services behind them, including App Engine serving, Cloud Functions, the Stackdriver web UI, Dialogflow, the Cloud Support Portal and API, GKE Ingress and Cloud Storage traffic through Cloud Load Balancers; Cloud CDN cache hits dropped 70%","users":"customers using Google Cloud App Engine, HTTP(S) Load Balancer or TCP/SSL Proxy Load Balancers","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.cloud.google.com/incident/cloud-networking/18012","kind":"official-status","archived":"https://web.archive.org/web/20261021131904/https://status.cloud.google.com/incident/cloud-networking/18012"}],"summary":{"en":"Google's Global Load Balancers are built on two tiers of Google Front Ends (GFE). The first tier answers requests as close to the user as possible and forwards them over Google's network to a second tier of GFEs placed close to the backend service. The GFE team was adding security and performance features to the second-tier GFE code; the features were in the code base but not yet in service, and one of them contained a bug that made the GFE restart. Neither testing nor the initial rollout had caught the bug.\n\nAt 12:17 PDT on 17 July 2018 a configuration change in production began to set off the bug intermittently, and the affected second-tier GFEs restarted again and again. Restarts take time, so second-tier capacity shrank: some requests were answered, others were cut off, which showed as connection resets, or refused for lack of capacity while GFEs came back. Engineers were alerted within 3 minutes, found the root cause at 12:44 and reverted the configuration change, after which the GFEs stopped restarting and traffic returned to normal by 12:55.","ko":"Google 의 글로벌 로드 밸런서는 두 계층의 Google Front End, 곧 GFE 로 이루어진다. 첫 계층 GFE 는 사용자와 가장 가까운 곳에서 요청을 받아, 요청이 쓰는 서비스 가까이에 있는 두 번째 계층 GFE 로 보낸다. GFE 개발 팀은 보안과 성능을 높이는 기능을 GFE 에 넣는 중이었고, 이 기능들은 두 번째 계층 GFE 코드에 들어갔지만 아직 쓰이지 않았다. 그중 한 기능에 GFE 를 재시작시키는 버그가 있었고, 테스트에서도 첫 배포에서도 드러나지 않았다.\n\n2018년 7월 17일 12시 17분 PDT, 운영 환경의 설정 변경이 이 버그를 간헐적으로 건드려 영향받은 GFE 들이 거듭 재시작했다. 재시작에는 시간이 걸리므로 두 번째 계층 GFE 의 가용 용량이 줄었다. 일부 요청은 제대로 응답을 받았지만, 다른 요청은 중간에 끊겨 연결이 재설정되거나 용량이 모자라 거부됐다. 엔지니어는 12시 19분에 자동 모니터링의 알림을 받았고, 12시 44분에 원인을 찾아 설정 변경을 되돌렸다. GFE 들은 재시작을 멈췄고, 12시 49분에 502 비율이 평소로 돌아왔으며, 서빙은 12시 55분에 완전히 회복했다."},"trigger":{"en":"A configuration change in the production environment intermittently set off a bug in a new feature of the second-layer Google Front Ends.","ko":"두 번째 계층 GFE 코드에는 아직 쓰지 않던 새 기능이 들어가 있었고, 이 기능에 버그가 있었다. 운영 환경의 설정 변경이 이 버그를 간헐적으로 건드렸고, 버그는 GFE 를 재시작시켰다."},"severity":"unknown","symptoms":["high-error-rate","connection-resets","high-latency"],"timeline":{"detected_after":"2m","resolved_after":"38m"},"date_kind":"incident","detection":{"en":"Automated monitoring alerted Google's engineering team at 12:19 PDT, two minutes after the 502s began.","ko":"12시 19분에 자동 모니터링이 Google 엔지니어링 팀에 알림을 보냈다. 엔지니어는 장애가 시작되고 3분 안에 알림을 받고 바로 조사를 시작했다."},"components":["cloud-load-balancer","cdn"],"root_cause":"software-bug","remediation":[{"text":{"en":"Reverted the configuration change at 12:44 PDT, which stopped the GFE restarts","ko":"12시 44분 PDT 에 원인을 찾고 문제의 설정 변경을 곧바로 되돌렸다. 영향받은 GFE 들이 재시작을 멈추고 모두 서비스에 돌아오자 트래픽이 평소 수준과 동작을 되찾았다."}}],"action_items":[{"text":{"en":"Add safeguards that disable features not yet in service","ko":"아직 쓰지 않는 기능을 꺼 두는 안전장치를 더한다."}},{"text":{"en":"Harden the GFE testing stack against latent bugs in production binaries that make a task restart","ko":"작업을 재시작시킬 수 있는 잠재 버그가 운영 바이너리에 남을 위험을 줄이도록 GFE 테스트 스택을 더 단단하게 만든다."}},{"text":{"en":"Isolate the shards of GFE pools further from each other to reduce the scope of failures","ko":"장애가 미치는 범위를 줄이도록 GFE 풀의 샤드끼리 더 격리한다."}},{"text":{"en":"Build a consolidated dashboard of all configuration changes for GFE pools","ko":"진단을 빠르게 하도록 GFE 풀의 모든 설정 변경을 한곳에 모은 대시보드를 만들어, 엔지니어가 문제를 일으킨 변경을 쉽게 보고 대조해 찾아내게 한다."}}],"contributing":["test-coverage-gap","blast-radius-too-wide"],"recurrence_of":null,"symptoms_text":{"en":"From 12:17 to 12:49 PDT on 17 July 2018, Google Cloud HTTP(S) Load Balancers answered a share of requests with 502 return codes, and connections to TCP/SSL Proxy Load Balancers were reset. The share of failed requests moved between 33% and 87% during those 32 minutes, and automated monitoring alerted Google engineers at 12:19.\n\nGoogle services that serve through Cloud HTTP Load Balancing were affected for the whole period, including App Engine application serving, Cloud Functions, the Stackdriver web UI, Dialogflow and the Cloud Support Portal and API. Services on Google Kubernetes Engine that use the Ingress resource returned 502s, and Cloud Storage traffic served through Cloud Load Balancers was hit as well. Cloud CDN cache hits fell by 70%, because fewer Cloud CDN URLs were referenced by the services behind the load balancers and Cloud CDN could not validate stale entries or add new content on cache misses. Applications that used direct VM access or Network Load Balancing were not affected.\n\nAfter the fix took effect at 12:49 the 502 rate fell back to normal quickly, but latency stayed degraded for several more minutes while traffic returned and caches warmed. Serving was fully recovered at 12:55.","ko":"2018년 7월 17일 12시 17분 PDT 부터 Google Cloud App Engine, HTTP(S) 로드 밸런서, TCP/SSL Proxy 로드 밸런서를 쓰는 고객의 요청이 502 응답 코드나 연결 재설정으로 실패했다. 오류 비율은 32분 동안 33% 에서 87% 사이를 오갔다.\n\nHTTP(S) 로드 밸런서는 받은 요청 일부에 502 를 냈고, TCP/SSL Proxy 로드 밸런서로 들어온 연결은 백엔드 연결이 실패한 뒤 재설정됐다. Google Kubernetes Engine 에서 Ingress 리소스를 쓰는 서비스도 502 를 냈다.\n\nHTTP 로드 밸런싱에 기대는 Google 서비스들도 장애 내내 영향을 받았다. App Engine 애플리케이션 서빙, Google Cloud Functions, Stackdriver 웹 UI, Dialogflow, Cloud Support Portal 과 API, Cloud Load Balancer 를 거치는 Google Cloud Storage 트래픽이 여기에 포함됐다. 상태 페이지의 첫 공지는 12시 34분에 올라왔다.\n\nCloud CDN 의 캐시 적중은 70% 줄었다. 로드 밸런서 뒤 서비스들이 Cloud CDN URL 을 덜 참조했고, CDN 은 오래된 캐시 항목을 검증하지도, 캐시 미스 때 새 콘텐츠를 넣지도 못했기 때문이다.\n\n12시 49분에 수정이 효과를 내자 502 비율은 빠르게 평소 수준으로 돌아왔다. 트래픽이 돌아오고 캐시가 다시 데워지는 몇 분 동안은 지연이 더 이어졌고, 서빙은 12시 55분에 완전히 회복했다.\n\nVM 에 직접 접속하는 애플리케이션과 서비스, Network Load Balancing 을 쓰는 서비스는 영향을 받지 않았다."},"updated_at":"2026-11-14T12:33:59.344023Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0338","org_slug":"google-cloud"}