사례3건
3건 중 1~3번째
- 증상
2026-03-10 15:57 UTC 에 알림 시스템이 Clerk API 전반의 지연 증가와 5xx 오류 증가를 알렸다. 모니터링에는 그보다 1분쯤 앞서 시작된 데이터베이스 락 경합 증가가 보였다.
- 촉발
Google Cloud SQL 이 Clerk 데이터베이스를 호스팅하는 가상 머신을 일상적으로 라이브 마이그레이션하다 실패했다. Clerk 는 라이브 마이그레이션 시점을 미리 통보받지 않는다.
- 원인
- 구성 요소
- 기여 요인
- 감지
15:57 UTC 에 알림 시스템이 API 전반의 지연 증가와 5xx 오류 증가를 알렸고, 이때 내부에서 사고를 선언했다.
- 조치
- 16:10 UTC 에 Origin Outage Mode 를 켜 세션 관리가 계속 돌아가게 했다.
- 읽기의 IO wait 만 오르는 것을 보고 인프라 문제를 의심해 GCP 에 티켓을 열었다.
- 16:23 UTC 에 문제가 스스로 풀리고 시스템이 안정된 것을 확인한 뒤 곧 Origin Outage Mode 를 껐다.
- 후속 조치
- 추가 라이브 마이그레이션을 막도록 Google 에 데이터베이스를 다시 고정해 달라고 요청했다. 글을 쓸 때까지 요청은 받아들여지지 않았다.
- 앞으로 모든 Postgres 데이터베이스 유지 보수는 기존 방식의 replica 승격으로 한다. Clerk 는 이미 안전하고 빠른 replica 승격 자동화를 갖고 있고, 2026-01-17 Postgres 메이저 버전 업그레이드에 문제없이 썼다.
- Google 이 라이브 마이그레이션을 영구히 끌 방법을 주지 않으면 다른 데이터베이스 제공업체로 옮기거나 Postgres 를 직접 운영한다. 지금 선택지를 조사하고 있다.
- 내부 서비스의 429 가 그대로 전달되지 않고 500 으로 바뀌게 고쳐, 애플리케이션이 오류 코드로 Clerk 시스템의 상태를 정확히 판단하게 한다.
- 엔지니어링 팀 대부분을 안정성 중심 프로젝트로 옮겼고, 당분간 시스템 안정성 회복을 가장 앞에 둔다.
- 교훈
2025년 9월 장애에서 Clerk 는 라이브 마이그레이션이 실패하면 작업이 끝날 때까지 서비스가 멈추고, 마이그레이션 도중 replica 장애 조치를 하는 것도 안전하지 않다는 것을 배웠다. 몇 달에 걸친 Google 과의 작업 뒤에도 이번 장애로 라이브 마이그레이션이 여전히 안전하지 않다는 것이 드러났다. 라이브 마이그레이션은 잘 되면 무중단이지만 안을 들여다볼 수 없어 Google 의 말을 믿는 수밖에 없다. 그래서 Clerk 는 준비가 더 들더라도 기존 방식의 replica 승격에 기대는 편이 더 안전하다고 보았다.
- 증상
data100 클러스터의 쿠버네티스 API 서버에 닿지 않아 새 자원을 만드는 요청이 실패했다. 허브 파드가 멈춘 뒤 새 파드가 만들어지지 않아 사용자들은 프록시 오류 메시지를 보았다.
- 원인
- 구성 요소
- 기여 요인
- 감지
11:34 에 인프라 담당자가 Slack 으로 알림을 받았다. API 서버가 멈춘 시각인 11:21 은 장애가 끝난 뒤 클라우드 사업자의 모니터링 지표로 확인했다.
- 조치
- 13:00 에 새 클러스터를 만들고, 그 클러스터의 리소스 그룹에 새 nfs 서버를 요청했다.
- 데이터 볼륨을 옛 nfs 서버에서 떼어 옛 클러스터의 리소스 그룹에서 새 클러스터의 리소스 그룹으로 옮겼다.
- ZFS 풀을 새 nfs 서버로 가져왔다.
- helm 으로 staging 허브를 띄우고 DNS 를 바꿨다.
- helm 으로 prod 허브를 띄우고 DNS 를 바꿨다.
- 후속 조치
- API 서버 엔드포인트를 외부에서 감시하고, 응답하지 않으면 알림을 보낸다.
- 증상
2017년 11월 17일 PST 11시 52분에 엔지니어들이 서비스 영향을 알아채고 사고 채팅방에 올렸다. 이어서 sessions 클러스터의 다른 노드들에서 메모리 부족 알림이 차례로 울렸다.
- 촉발
Google 이 Google Cloud Platform 네트워크 스택에 내보낸 업그레이드가 Discord VM 의 네트워크 연결을 짧게 여러 번 끊었다. 네트워크를 많이 쓰는 sessions 클러스터 노드에서만 16번 일어났다.
- 원인
- 구성 요소
- 기여 요인
- 감지
17일 11시 52분에 엔지니어들이 서비스 영향을 알아채고 사고 채팅방에 올렸다. 그 뒤로는 sessions 노드의 메모리 부족 알림으로 당번 엔지니어가 호출됐다. 18일에는 11시 38분 네트워크 문제로 당번 엔지니어가 호출됐고, 11시 40분에 고객 경험 팀이 지원 채널의 신고를 올렸다.
- 조치
- 12시 14분 sessions-1-9 를 안전하게 빼는 절차가 실패하자 노드를 강제로 종료했다. 같은 증상이 난 다른 sessions 노드도 강제로 종료했다.
- 12시 42분 Google 지원 티켓을 가장 높은 등급인 P1 로 올리고 기술 담당 매니저에게 알렸다.
- 14시 21분 Discord 의 핵심 서비스 여러 개를 재시작했다. 이 작업으로 연결된 클라이언트 수백만 대가 약 20분에 걸쳐 다시 연결됐다.
- 17일 밤 강제 종료하고 재부팅한 노드가 다시 망가지지 않는 것을 보고 sessions 클러스터 전체를 종료하고 재부팅하기 시작했다.
- 18일 12시 4분 서비스 복구를 도우려고 전 세계에서 메시지 전송을 껐다.
- 18일 12시 4분 sessions 클러스터의 모든 멤버를 재시작했다.
- 18일 12시 31분 첫 정상화를 알리고 메시지 전송을 다시 켰다.
- Google 이 금요일에 네트워크 스택에 넣은 소프트웨어 변경을 18일 13시 30분 무렵부터 롤백했고, 15시 30분쯤 롤백이 끝났다.
- 후속 조치
- Discord 를 재부팅해야 했던 이전 장애에서 Erlang 클러스터가 노드 장애를 다루는 방식의 문제를 찾았다. 그 문제를 고치는 프로젝트를 이어 간다.
- 그 개선을 안전하게 내보낼 수 있도록 이 서비스들의 업그레이드 부하 테스트 방식을 넓힌다.
- Elixir 와 Erlang 서비스에서 쓰는 HTTP 라이브러리를 바꾼다.
- Erlang 의 net_kernel 구성 요소에서 본 불안정을 재현했고 수정을 넣었다.
- 장애 동안 성능이 떨어진 서비스 디스커버리 구성 요소의 일부를 더 성능이 좋은 구현으로 바꾼다.
- 이번 장애를 Google 과 같이 처리하며 겪은 문제들을 Google 과 함께 고쳐 나간다.
- P1 문제의 진행 상황을 제대로 추적하도록 Google 과 소통하는 내부 절차를 넓혔다.
- 교훈
Discord 는 두 번의 큰 장애가 그만큼 커진 데에는 Discord 시스템의 성능과 안정성 문제가 크게 작용했다고 봤다. 이런 형태의 네트워크 장애가 서비스의 연쇄 장애를 일으킬 수 있었기 때문이다. 일부 사용자에게만 머물렀어야 할 문제가 시스템 전체 장애 두 번으로 번진 데에는 여러 문제가 있었고, Discord 는 후속 조치로 그 문제 대부분을 풀 수 있다고 봤다.
이 3건에서 가장 많이 나오는 구성 요소: AKS 컨트롤 플레인, 데이터베이스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.