사례3건

3건 중 1~3번째

1. IL-0543 Twingate 의 인증과 관리 서비스 전반이 29분 동안 오류를 내며 멈췄다

   Twingate2025

   증상

   2025년 5월 28일 20:45 UTC 부터 Twingate 의 여러 핵심 서비스에서 API 요청이 넓게 실패하고 오류율이 올라갔다. 장애는 3분 뒤인 20:48 UTC 에 감지됐다.

   요청 오라우팅부하 불균형오류율 상승

   촉발

   글로벌 로드 밸런서의 라우팅 규칙을 바꾸는 롤아웃에서 새 라우팅 규칙이 의도치 않게 높은 우선순위를 받았다.

   원인

   설정 변경

   구성 요소

   클라우드 로드 밸런서

   기여 요인

   스테이징 불일치순환 의존

   감지

   장애가 시작되고 3분 뒤인 20:48 UTC 에 감지됐고, 엔지니어들이 원인 파악과 초기 대응을 시작했다.

   조치

   • 20:52 UTC 에 라우팅 변경의 롤백을 시작했지만, 복구에 쓰는 인프라가 영향을 받은 구성 요소에 기대고 있어서 21:05 UTC 에 자동 롤백 과정이 지연됐다.
   • 21:09 UTC 에 엔지니어들이 로컬 도구로 직접 고쳤고, 21:14 UTC 에 서비스가 모두 복구됐다.

   후속 조치

   • 라우팅 규칙을 바로잡았다.
   • 하위 환경에서 백엔드 트래픽 이상을 감지하는 알림을 더했다.
   • 리소스 스케일링 임계값을 조정했다.
   • 복구 수단을 더 빨리 쓸 수 있도록 인프라 도구가 서비스에 기대지 않게 떼어 낸다.
   • 백엔드 샤딩을 도입해 고객 워크로드를 서로 격리하고 장애의 영향을 줄인다.

   사례 보기
2. IL-0542 Twingate 의 인증과 인가 요청 일부에서 약 30분 동안 오류율이 올라갔다

   Twingate2025

   증상

   Twingate 서비스로 가는 인증과 인가 요청 일부에서 오류율이 올라갔다. 처음에는 여러 GKE 클러스터 가운데 하나에서 이상 동작이 보였다.

   오류율 상승

   촉발

   GKE 클러스터 하나에서 이상 동작이 보이자 시스템 전체를 지키려고 그 클러스터의 디플로이먼트를 미리 줄였고, 트래픽이 평소 부하가 가벼운 다른 클러스터로 옮겨 갔다.

   원인

   클라우드 제공자 장애

   구성 요소

   클라우드 로드 밸런서GKE 컨트롤 플레인수평 파드 오토스케일러클러스터 오토스케일러

   기여 요인

   재시도 폭주여유 용량 부재장애 중첩수동 조치 악화

   감지

   사고 초기에 엔지니어들이 GKE 클러스터 하나에서 이상 동작을 관찰했다.

   조치

   • 앞서 디플로이먼트를 줄였던 클러스터에 용량을 다시 넣어 리전 사이의 트래픽을 다시 나눴고, 오류율과 재시도가 가라앉았다.

   후속 조치

   • 예상하지 못한 타임아웃과 클러스터 업데이트의 영향이 왜 생겼는지 클라우드 사업자와 계속 함께 조사한다.
   • HPA 설정을 고쳐 모든 리전의 디플로이먼트 레플리카 수를 같게 맞췄다.
   • 클러스터 노드 오토스케일러의 최대 노드 수를 늘려 확장할 여유를 키웠다.
   • HPA 가 더 빨리 확장하도록 설정했다.

   사례 보기
3. IL-0541 Twingate 의 us-east4 와 europe-west6 Relay 클러스터에 Client 와 Connector 가 접속하지 못했다

   Twingate2023

   증상

   Terraform 변경을 전 세계 Relay 클러스터에 적용하던 중 01:40 UTC 에 us-east4 와 europe-west6 두 클러스터의 연결 수가 줄어드는 것이 보였다. Client 와 Connector 는 두 클러스터를 찾을 수는 있었지만 접속할 수는 없어 교착 상태에 빠졌다.

   네트워크 도달 불가

   촉발

   2023년 2월 14일 01:00 UTC 에 Relay 클러스터 인프라에 스팟 인스턴스 스케일링을 넣는 Terraform 변경을 전 세계 모든 Relay 클러스터에 적용하기 시작했다. 적용에는 약 45분이 걸렸다.

   원인

   설정 변경

   구성 요소

   TerraformVPC 라우팅 테이블과 방화벽 규칙

   기여 요인

   스테이징 불일치단계적 배포 부재

   감지

   01:40 UTC 에 엔지니어들이 us-east4 와 europe-west6 두 클러스터의 연결 수가 줄어든 것을 보고 조사를 시작했다.

   조치

   • 02:04 UTC 에 영향을 받은 두 클러스터의 파드를 꺼서 Client 와 Connector 가 다음으로 가까운 Relay 클러스터로 다시 붙게 했다.
   • 03:30 UTC 에 Terraform 설정 오류를 고치고 영향을 받은 클러스터를 다시 배포했다.

   후속 조치

   • 스테이징 환경에 Relay 클러스터의 크기 차이와 설정 차이를 정확히 반영한다.
   • 기능 개발 브랜치에서 운영의 모든 설정 변형을 포함해 모든 환경의 Terraform plan 을 자동으로 만든다.
   • 필요한 네트워크 방화벽 태그가 없으면 Connector 와 Client 가 그 클러스터를 발견하지 못하도록 Relay 헬스 체크를 강화한다.
   • Relay 클러스터 인프라에 Terraform 으로 단계적 롤아웃을 하는 방법을 조사하고 도입한다.
   • 중기 계획으로 Connector 가 여러 클러스터에 연결할 수 있게 해 리전 단위의 Relay 클러스터 문제를 자동으로 처리한다.

   사례 보기

원인별2