사례21건

21건 중 4~8번째

1. IL-0487 Postgres 테이블 두 개의 콜레이션을 바꾼 뒤 데이터베이스 CPU가 치솟아 Autumn API 요청의 약 10%가 실패했다

   Autumn2026

   증상

   2026-03-15 15:00 GMT 무렵 운영 데이터베이스의 두 테이블에 콜레이션 변경을 적용하자 데이터베이스 CPU가 치솟고 질의가 실패하기 시작했다. 16:15 GMT까지 Autumn API 요청의 약 10%가 실패했다.

   데이터베이스 과부하오류율 상승잠금 경합과 교착

   촉발

   가장 자주 도는 질의를 최적화하던 중 관련 테이블 네 개의 콜레이션을 맞추기로 하고, 운영 데이터베이스에서 customer_entitlements와 customer_products의 콜레이션을 바꿨다.

   원인

   설정 변경

   구성 요소

   데이터베이스

   기여 요인

   롤백 무효

   조치

   • 15:48에 PlanetScale 지원팀의 도움을 받아 모든 애플리케이션 연결을 끊었다.
   • 콜레이션 변경을 되돌렸다.
   • ANALYZE로 플래너 통계를 다시 만든 뒤 재시작했다. 질의가 바로 정상으로 돌아왔고 CPU도 안정됐다.

   후속 조치

   • 앞으로 열과 스키마 마이그레이션은 모두 복제, 이중 쓰기, 전환 순서로 한다. 열을 제자리에서 바꾸지 않고 원하는 타입의 새 열을 만들어 두 열에 함께 쓰고, 기존 행을 작은 묶음으로 채우고, 인덱스를 동시 생성한 뒤 전환한다.
   • 문제가 생겼을 때 상황을 투명하게 알리려고 상태 페이지를 만든다.
   • 장애가 나도 유료 고객이 영향을 받지 않도록 check와 track SDK가 기본으로 fail-open 하게 바꾸는 방안을 검토한다.

   사례 보기
2. IL-0318 Google Cloud SQL 데이터베이스의 디스크 지연이 치솟아 Clerk API 가 429 를 내며 전체 장애가 났다

   Clerk2026

   증상

   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 승격에 기대는 편이 더 안전하다고 보았다.

   사례 보기
3. IL-0369 데이터베이스 마이그레이션이 잠금에 막히는 동안 Railway 백엔드 복제본이 헬스 체크에 실패해 대시보드와 API 가 멈췄다

   Railway2025

   증상

   Railway 백엔드 API 가 트래픽을 받지 못해 대시보드 접속, CLI 작업, GitHub 기반 배포 처리, 로그인, API 가 멈췄다. 이미 돌고 있던 배포는 계속 온라인이었고, 이 시스템들을 쓰지 않은 사용자는 영향을 받지 않았다.

   프로브 실패잠금 경합과 교착데이터베이스 과부하서비스 중단

   촉발

   엔지니어들이 15:03 UTC 에 데이터 마이그레이션이 들어간 데이터베이스 스키마 변경을 머지했다. 이 마이그레이션은 약 10억 행이 있고 많이 쓰는 테이블에 nullable 열을 더하는 것이었다.

   원인

   배포 결함

   구성 요소

   데이터베이스데이터베이스 프록시와 커넥션 풀러스키마 마이그레이션라이브니스·레디니스 프로브

   기여 요인

   의존성에 묶인 헬스 체크

   후속 조치

   • 데이터베이스 연결 수를 늘리고, PgBouncer 가 그 한도 안에서 동작하도록 다시 설정한다.
   • 오래 도는 쿼리를 고쳐 행 잠금 문제가 다시 나지 않게 한다.

   사례 보기
4. IL-0315 약 10억 행 테이블에 인덱스를 만드는 스키마 변경이 테이블 전체를 잠가 Railway 의 백엔드 API 가 멈췄다

   Railway2025

   증상

   2025-10-28 18:36 UTC 에 내부 모니터링 알림이 울려 엔지니어링 팀이 호출됐다. 대시보드가 열리지 않았고, railway up 처럼 API 를 쓰는 CLI 작업이 실패했으며, Public API 작업이 모두 멈췄다.

   서비스 중단잠금 경합과 교착데이터베이스 과부하

   촉발

   일상적인 Postgres 데이터베이스 변경으로 약 10억 행 테이블에 새 컬럼과 인덱스가 더해졌다. 인덱스 생성에 CONCURRENTLY 옵션을 쓰지 않아 테이블 전체에 배타적 잠금이 걸렸다.

   원인

   배포 결함

   구성 요소

   데이터베이스데이터베이스 프록시와 커넥션 풀러

   기여 요인

   설정 테스트 부재디버그 접근 제한

   감지

   변경이 운영에 반영되고 2분 뒤인 18:36 UTC 에 내부 모니터링 알림이 울려 엔지니어링 팀이 호출됐다.

   조치

   • 인덱스를 만드는 마이그레이션이 약 30분 만에 끝나 테이블 잠금이 스스로 풀렸고, 줄을 선 작업이 처리되며 커넥션 풀이 정상으로 돌아왔다.

   후속 조치

   • CI 에서 모든 인덱스 생성에 CONCURRENTLY 사용을 강제하고, 지키지 않은 풀 리퀘스트는 머지 전에 막는다.
   • PgBouncer 커넥션 풀 한도를 조정해 뒤에 있는 Postgres 인스턴스의 용량을 넘지 않게 한다.
   • 데이터베이스 사용자별 커넥션 한도를 설정해 장애 중에도 관리용 접속을 보장하고, 어떤 상황에서도 유지 보수 작업을 할 수 있게 한다.

   사례 보기
5. IL-0436 Aurora MySQL 에서 INSERT 가 supremum 락에 막혀 커넥션이 고갈되고 freee 웹 서비스 전체가 다운되었다

   freee2025

   증상

   Aurora MySQL 에 접속 실패가 잦아지다가 결국 웹 페이지를 열 수 없게 되어 서비스 전체가 다운되었다. 웹 애플리케이션은 DB 가 응답하지 않아 타임아웃이 잇따랐고 새 DB 접속을 맺지 못했다.

   잠금 경합과 교착서비스 중단

   촉발

   롱 트랜잭션 안에서 SAVEPOINT 를 만들고 대상 테이블에 INSERT 한 뒤 ROLLBACK TO SAVEPOINT 를 실행했고, 이 롤백이 그 테이블의 supremum 에 배타 락을 남겼다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스

   기여 요인

   미검증 가정기본 설정 방치

   후속 조치

   • 원칙적으로 SAVEPOINT 를 쓰지 않는다. 부분 롤백이 필요하면 트랜잭션 자체를 나누고, 꼭 트랜잭션을 중첩해야 하면 애플리케이션 쪽에 타임아웃을 둔다.
   • 트랜잭션 격리 수준은 세션 단위로도 정할 수 있다. 그래서 팬텀 행을 허용할 수 있는 경우에는 갭 락을 잡지 않는 READ COMMITTED 를 쓰는 것도 고려하도록 개발자를 교육하고 안내한다.
   • 롱 트랜잭션을 감시하고, 회사 전체에서 롱 트랜잭션을 없애는 자발적인 활동을 이어 간다.

   교훈

   supremum 락 하나로는 문제가 되지 않지만 롱 트랜잭션과 겹치면 서비스 정지로 이어진다. ORM 프레임워크는 중첩 트랜잭션을 만들려고 내부에서 SAVEPOINT 를 쓰는 일이 많아 개발자가 모르고 쓰게 된다. 롱 트랜잭션이 잡은 락은 영향 범위가 좁아 막히는 작업이 적으면 지나치기 쉽지만, 이번 일로 그 잠재 위험이 드러났다.

   사례 보기

원인별8