Incident Library

IL-0318 Clerk · 2026-03-10databasegcp

Google Cloud SQL 데이터베이스의 디스크 지연이 치솟아 Clerk API 가 429 를 내며 전체 장애가 났다

Clerk 는 2021년부터 고가용성 구성의 Google Cloud SQL Enterprise Plus 를 데이터베이스로 쓴다. Google Cloud SQL 은 데이터베이스 가상 머신을 일상적으로 라이브 마이그레이션한다. 이 작업은 Cloud SQL 문서에는 없지만 Google Compute Engine 의 라이브 마이그레이션과 비슷하다. 정상으로 끝나면 가용성이나 부하에 영향이 없다. Clerk 는 라이브 마이그레이션이 언제 일어나는지 미리 통보받지 않는다. 2025년 9월에는 다른 라이브 마이그레이션이 큰 장애를 일으켰다. 그때 Google 은 티켓을 P0 로 올리고 데이터베이스를 데이터센터에 고정해 추가 라이브 마이그레이션을 막았다. 두 회사는 몇 달 동안 함께 일한 끝에 1월에 고정을 풀었다. 고정을 푼 뒤 첫 라이브 마이그레이션은 문제없이 끝났다.

2026-03-10 에 라이브 마이그레이션이 다시 실패했다. 데이터베이스의 디스크 지연이 크게 늘었고, 이것이 락 경합을 키워 결국 전체 서비스 장애로 이어졌다. 15:57 UTC 에 알림이 API 의 지연과 5xx 증가를 알렸고 내부에서 사고를 선언했다. 쿼리와 트랜잭션이 오래 걸려 컴퓨트가 포화되자 요청이 429 를 받았고, 자동으로 작동한 세션 장애 대비 기능도 대부분 429 를 냈다. 모든 읽기를 replica 로 돌려 봤지만 소용없었다. 16:10 UTC 에 Origin Outage Mode 를 켜자 세션 관리가 다시 돌아갔다. 팀은 읽기의 IO wait 만 오르는 것을 보고 인프라 문제를 의심해 GCP 에 티켓을 열었다. 16:23 UTC 에 마이그레이션이 끝나며 문제가 스스로 풀렸고, 시스템이 안정된 것을 확인한 뒤 Origin Outage Mode 를 껐다. GCP 가 나중에 근본 원인을 알려 주었다.

심각도
–
영향 범위
Clerk's APIs: increased latency, 5xx errors and then 429 responses, and a complete service outage; session management kept working from 16:10 UTC through Origin Outage Mode
영향 사용자
Clerk customers and the users of their applications
지역
–
감지까지
1m
복구까지
27m

증상

2026-03-10 15:57 UTC 에 알림 시스템이 Clerk API 전반의 지연 증가와 5xx 오류 증가를 알렸다. 모니터링에는 그보다 1분쯤 앞서 시작된 데이터베이스 락 경합 증가가 보였다.

데이터베이스 CPU 사용률은 정상 범위였고 데이터베이스 자체도 돌아가고 있었다. 그러나 쿼리와 트랜잭션이 훨씬 오래 걸려 컴퓨트 자원이 포화됐고, 컴퓨트가 바닥나자 들어오는 요청이 429 를 받았다.

세션 장애 대비 기능이 origin 에서 자동으로 작동해 세션 토큰 요청을 계속 받았다. 그러나 컴퓨트가 이미 포화돼 처리가 너무 오래 걸렸고, 세션 토큰 요청도 대부분 429 를 받았다. 이 429 는 내부 서비스가 낸 응답이 500 으로 바뀌지 않고 그대로 전달된 것이었다.

조사 중 읽기의 IO wait 가 올랐는데 쓰기는 그만큼 늘지 않은 특이한 모습이 보였다. 팀은 이때 인프라 문제를 의심해 GCP 에 티켓을 열었다.

팀은 원인을 찾아 나섰지만 뚜렷한 단서가 없었다. 완화책으로 모든 읽기를 replica 로 돌려 primary 데이터베이스의 부담을 덜려 했지만 소용없었다.

증상 지연 시간 증가오류율 상승잠금 경합과 교착서비스 중단

원인

원인 클라우드 제공자 장애

구성 요소 데이터베이스
기여 요인 디버그 접근 제한
촉발
Google Cloud SQL 이 Clerk 데이터베이스를 호스팅하는 가상 머신을 일상적으로 라이브 마이그레이션하다 실패했다. Clerk 는 라이브 마이그레이션 시점을 미리 통보받지 않는다.

감지

15:57 UTC 에 알림 시스템이 API 전반의 지연 증가와 5xx 오류 증가를 알렸고, 이때 내부에서 사고를 선언했다.

조치

후속 조치

교훈

2025년 9월 장애에서 Clerk 는 라이브 마이그레이션이 실패하면 작업이 끝날 때까지 서비스가 멈추고, 마이그레이션 도중 replica 장애 조치를 하는 것도 안전하지 않다는 것을 배웠다. 몇 달에 걸친 Google 과의 작업 뒤에도 이번 장애로 라이브 마이그레이션이 여전히 안전하지 않다는 것이 드러났다. 라이브 마이그레이션은 잘 되면 무중단이지만 안을 들여다볼 수 없어 Google 의 말을 믿는 수밖에 없다. 그래서 Clerk 는 준비가 더 들더라도 기존 방식의 replica 승격에 기대는 편이 더 안전하다고 보았다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.