{"id":"IL-0542","org":"Twingate","date":"2025-03-21","docs":[],"title":{"en":"Twingate authentication and authorization requests failed at higher rates after traffic moved onto a smaller GKE cluster","ko":"Twingate 의 인증과 인가 요청 일부에서 약 30분 동안 오류율이 올라갔다"},"domain":["kubernetes","gcp","networking"],"impact":{"scope":"A subset of authentication and authorization requests to Twingate services; the status page lists Authentication (Enterprise and Social), MFA, Authorization, Connector Heartbeat and management services","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.twingate.com/incidents/mhs89xs5rhb8","kind":"official-status","archived":null}],"summary":{"en":"Twingate runs its services active-active on several Google Kubernetes Engine (GKE) clusters, with a Global Load Balancer (GLB) spreading traffic between them. When one cluster showed anomalies, Twingate scaled down its deployments, and the traffic moved mainly to a cluster that usually handles a lighter load and was sized for it. That cluster autoscaled, but the extra traffic raised error rates, retry mechanisms across services increased the load further, and a cloud provider-initiated update on the same cluster restarted pods and reduced capacity.\n\nTwingate attributed the incident to behaviour on the cloud provider's side, namely unexpected request timeouts at the load balancer and instability during the cluster update, which together started a cascade of retry traffic. The incident ended when Twingate brought capacity back in the first cluster, so traffic was balanced across regions again and the errors and retries died down. Twingate said it was still investigating the timeout configuration and the cluster's behaviour during the update together with the provider.","ko":"Twingate 는 여러 GKE 클러스터를 Global Load Balancer 로 묶어 액티브-액티브로 운영한다. 2025년 3월 21일 한 클러스터에서 이상 동작이 보이자 엔지니어들은 시스템 전체를 지키려고 그 클러스터의 디플로이먼트를 미리 줄였다. 트래픽은 다른 클러스터로 옮겨 갔고, 주로 평소 부하가 가벼워 규모도 그만큼만 잡아 둔 클러스터가 받았다.\n\n이 클러스터는 오토스케일링을 시작했지만 늘어난 트래픽에 오류율이 올라갔다. 서비스들의 재시도는 많은 요청을 성공시켰지만 전체 부하도 키웠다. 같은 때 이 클러스터에서는 클라우드 사업자가 시작한 업데이트 작업으로 파드가 재시작되고 용량이 줄었다. Twingate 는 클라우드 사업자 쪽의 이상 동작이 원인이었다고 밝혔다. 로드 밸런서 단에서 예상하지 못한 요청 타임아웃이 났고, 클러스터 업데이트 중에 클러스터가 불안정했다. 이 때문에 재시도 트래픽이 연쇄적으로 불어나 시스템 일부가 잠시 감당하지 못했다. Twingate 는 예상하지 못한 타임아웃 설정과 업데이트 중의 클러스터 동작을 클라우드 사업자와 함께 조사하고 있다고 적었다.\n\n엔지니어들은 앞서 줄였던 클러스터에 용량을 다시 넣어 리전 사이의 트래픽을 다시 나눴고, 그 뒤 오류율과 재시도가 가라앉았다. 포스트모템은 영향 시간을 21:10 UTC 부터 21:41 UTC 까지로 적었다. 상태 페이지에는 20:10 UTC 에 조사를 시작한다는 글, 20:41 UTC 에 조치를 적용하고 지켜본다는 글, 21:13 UTC 에 해결됐다는 글이 차례로 올라왔다."},"trigger":{"en":"Twingate saw anomalies in one of its GKE clusters and scaled down the deployments in that cluster to protect the rest of the system, which moved its traffic to the other clusters.","ko":"GKE 클러스터 하나에서 이상 동작이 보이자 시스템 전체를 지키려고 그 클러스터의 디플로이먼트를 미리 줄였고, 트래픽이 평소 부하가 가벼운 다른 클러스터로 옮겨 갔다."},"severity":"unknown","symptoms":["high-error-rate"],"timeline":{"detected_after":null,"resolved_after":"31m"},"date_kind":"incident","detection":{"en":"Twingate observed anomalies in one of its GKE clusters at the start of the incident.","ko":"사고 초기에 엔지니어들이 GKE 클러스터 하나에서 이상 동작을 관찰했다."},"components":["cloud-load-balancer","gke-control-plane","hpa","cluster-autoscaler"],"root_cause":"cloud-provider","remediation":[{"text":{"en":"Reintroduced capacity in the cluster that had been scaled down, so traffic was rebalanced across regions","ko":"앞서 디플로이먼트를 줄였던 클러스터에 용량을 다시 넣어 리전 사이의 트래픽을 다시 나눴고, 오류율과 재시도가 가라앉았다."}}],"action_items":[{"text":{"en":"Keep working with the cloud provider to find the cause of the unexpected timeouts and of the cluster update's impact","ko":"예상하지 못한 타임아웃과 클러스터 업데이트의 영향이 왜 생겼는지 클라우드 사업자와 계속 함께 조사한다."}},{"text":{"en":"Run deployments in all regions with the same number of replicas in the HPA configuration","ko":"HPA 설정을 고쳐 모든 리전의 디플로이먼트 레플리카 수를 같게 맞췄다."}},{"text":{"en":"Raise the maximum node counts of the cluster node autoscalers to leave more room to scale up","ko":"클러스터 노드 오토스케일러의 최대 노드 수를 늘려 확장할 여유를 키웠다."}},{"text":{"en":"Configure the HPA to scale up faster","ko":"HPA 가 더 빨리 확장하도록 설정했다."}}],"contributing":["retry-storm","no-spare-capacity","overlapping-failures","manual-action-worsened"],"recurrence_of":null,"symptoms_text":{"en":"On 21 March 2025, between 21:10 and 21:41 UTC, part of the authentication and authorization requests to Twingate services failed with elevated error rates.\n\nThe errors appeared on a GKE cluster that normally carries a lighter share of traffic, after deployments in another cluster were scaled down and the Global Load Balancer moved that cluster's traffic onto it. The receiving cluster started autoscaling, but the errors made services across Twingate retry their requests. Many retried requests then succeeded, but the retries also added to the total load. During the same period the cloud provider ran an update operation on that cluster, which restarted pods and took away capacity, and Twingate also saw unexpected request timeouts at the load balancer.","ko":"Twingate 서비스로 가는 인증과 인가 요청 일부에서 오류율이 올라갔다. 처음에는 여러 GKE 클러스터 가운데 하나에서 이상 동작이 보였다.\n\n그 클러스터의 디플로이먼트를 줄이자 트래픽이 다른 클러스터로 옮겨 갔고, 주로 평소 부하가 가벼워 규모도 그만큼만 잡아 둔 클러스터가 받았다. 이 클러스터는 예상대로 오토스케일링을 시작했지만 늘어난 트래픽 때문에 오류율이 올라갔고, 서비스들의 재시도가 전체 부하를 더 키웠다.\n\n같은 때 이 클러스터에서는 클라우드 사업자가 시작한 업데이트 작업이 돌아 파드가 재시작되고 용량이 줄었다. 로드 밸런서 단에서는 예상하지 못한 요청 타임아웃이 났다.\n\n상태 페이지는 영향 범위로 컨트롤 플레인의 Authentication - Enterprise, Authentication - Social, MFA, Authorization, Connector Heartbeat 와 관리 영역의 Identity Providers Sync, Public API, Admin Console, Realtime Updates, Client Log Upload, 3rd Party Integrations, Network Dashboards, DNS Filtering Dashboards 를 적었다."},"updated_at":"2026-11-14T12:34:18.766566Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0542","org_slug":"twingate"}