IL-0542 Twingate · 2025-03-21kubernetesgcpnetworking
Twingate 의 인증과 인가 요청 일부에서 약 30분 동안 오류율이 올라갔다
Twingate 는 여러 GKE 클러스터를 Global Load Balancer 로 묶어 액티브-액티브로 운영한다. 2025년 3월 21일 한 클러스터에서 이상 동작이 보이자 엔지니어들은 시스템 전체를 지키려고 그 클러스터의 디플로이먼트를 미리 줄였다. 트래픽은 다른 클러스터로 옮겨 갔고, 주로 평소 부하가 가벼워 규모도 그만큼만 잡아 둔 클러스터가 받았다.
이 클러스터는 오토스케일링을 시작했지만 늘어난 트래픽에 오류율이 올라갔다. 서비스들의 재시도는 많은 요청을 성공시켰지만 전체 부하도 키웠다. 같은 때 이 클러스터에서는 클라우드 사업자가 시작한 업데이트 작업으로 파드가 재시작되고 용량이 줄었다. Twingate 는 클라우드 사업자 쪽의 이상 동작이 원인이었다고 밝혔다. 로드 밸런서 단에서 예상하지 못한 요청 타임아웃이 났고, 클러스터 업데이트 중에 클러스터가 불안정했다. 이 때문에 재시도 트래픽이 연쇄적으로 불어나 시스템 일부가 잠시 감당하지 못했다. Twingate 는 예상하지 못한 타임아웃 설정과 업데이트 중의 클러스터 동작을 클라우드 사업자와 함께 조사하고 있다고 적었다.
엔지니어들은 앞서 줄였던 클러스터에 용량을 다시 넣어 리전 사이의 트래픽을 다시 나눴고, 그 뒤 오류율과 재시도가 가라앉았다. 포스트모템은 영향 시간을 21:10 UTC 부터 21:41 UTC 까지로 적었다. 상태 페이지에는 20:10 UTC 에 조사를 시작한다는 글, 20:41 UTC 에 조치를 적용하고 지켜본다는 글, 21:13 UTC 에 해결됐다는 글이 차례로 올라왔다.
- 심각도
- –
- 영향 범위
- 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
- 영향 사용자
- –
- 지역
- –
- 감지까지
- –
- 복구까지
- 31m
증상
Twingate 서비스로 가는 인증과 인가 요청 일부에서 오류율이 올라갔다. 처음에는 여러 GKE 클러스터 가운데 하나에서 이상 동작이 보였다.
그 클러스터의 디플로이먼트를 줄이자 트래픽이 다른 클러스터로 옮겨 갔고, 주로 평소 부하가 가벼워 규모도 그만큼만 잡아 둔 클러스터가 받았다. 이 클러스터는 예상대로 오토스케일링을 시작했지만 늘어난 트래픽 때문에 오류율이 올라갔고, 서비스들의 재시도가 전체 부하를 더 키웠다.
같은 때 이 클러스터에서는 클라우드 사업자가 시작한 업데이트 작업이 돌아 파드가 재시작되고 용량이 줄었다. 로드 밸런서 단에서는 예상하지 못한 요청 타임아웃이 났다.
상태 페이지는 영향 범위로 컨트롤 플레인의 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 를 적었다.
증상 오류율 상승
원인
- 촉발
- GKE 클러스터 하나에서 이상 동작이 보이자 시스템 전체를 지키려고 그 클러스터의 디플로이먼트를 미리 줄였고, 트래픽이 평소 부하가 가벼운 다른 클러스터로 옮겨 갔다.
감지
사고 초기에 엔지니어들이 GKE 클러스터 하나에서 이상 동작을 관찰했다.
조치
- 앞서 디플로이먼트를 줄였던 클러스터에 용량을 다시 넣어 리전 사이의 트래픽을 다시 나눴고, 오류율과 재시도가 가라앉았다.
후속 조치
- 예상하지 못한 타임아웃과 클러스터 업데이트의 영향이 왜 생겼는지 클라우드 사업자와 계속 함께 조사한다.
- HPA 설정을 고쳐 모든 리전의 디플로이먼트 레플리카 수를 같게 맞췄다.
- 클러스터 노드 오토스케일러의 최대 노드 수를 늘려 확장할 여유를 키웠다.
- HPA 가 더 빨리 확장하도록 설정했다.
교훈
–
출처
- https://status.twingate.com/incidents/mhs89xs5rhb8 · official-status
관련 사례
같은 원인 · 공통 GKE 컨트롤 플레인, 수평 파드 오토스케일러, 클러스터 오토스케일러
IL-0463Harness Secure Connect 의 내부 로드 밸런서에 닿을 수 없게 되어 Secure Connect 를 쓰는 git 커넥터 검사와 CI 파이프라인이 실패했다Harness · 2026같은 원인 · 공통 클라우드 로드 밸런서, GKE 컨트롤 플레인
같은 원인 · 공통 클라우드 로드 밸런서
IL-0096GCP europe-west2-b 존의 자원이 바닥나 이 존 하나에 묶인 GKE 노드 풀이 늘어나지 못했고, LIS 허브의 사용자 서버가 6시간 30분 동안 뜨지 않았다.2i2c · 2022같은 원인 · 공통 클러스터 오토스케일러
같은 원인 · 공통 클라우드 로드 밸런서
IL-0205Google Cloud us-east1 의 SSD 영구 디스크 재고가 바닥나 GKE 클러스터 오토스케일러가 프로덕션 노드를 늘리지 못했고, API 디플로이먼트가 파드를 띄울 용량을 얻지 못했다.GitLab · 2021같은 원인 · 공통 클러스터 오토스케일러
같은 원인 · 공통 클라우드 로드 밸런서
같은 원인 · 공통 GKE 컨트롤 플레인
같은 원인 · 공통 클라우드 로드 밸런서
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0542
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0542/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.