사례21건

21건 중 1~5번째

1. IL-0570 안 쓰는 테이블을 지우는 마이그레이션 직후 MySQL 쿼리가 막혀 crowdworks.jp에 1분쯤 접속하기 어려웠다

   CrowdWorks2026

   증상

   drop_table 마이그레이션을 실행한 직후부터 데이터베이스 쿼리가 막히기 시작했고, crowdworks.jp에는 1분쯤 접속이 잘 되지 않았다. 마이그레이션은 끝내 타임아웃으로 실패했고 서비스는 저절로 복구됐다.

   잠금 경합과 교착간헐적 연결 실패

   촉발

   이미 쓰지 않는 테이블을 지우려고 drop_table 마이그레이션을 실행했다. 이 테이블에는 트래픽이 매우 많은 테이블을 가리키는 외래 키 제약이 걸려 있었다.

   원인

   배포 결함

   구성 요소

   데이터베이스스키마 마이그레이션

   기여 요인

   –

   후속 조치

   • 대상 마이그레이션은 execute 'SET SESSION lock_wait_timeout = 3' 으로 MDL 대기 상한을 줄여, 대기가 길어지기 전에 실패하게 한다. 3초는 운영하면서 조정할 임시 값이다.
   • execute는 change에서 되돌릴 수 없어 롤백 때 ActiveRecord::IrreversibleMigration 이 나므로, def change 대신 def up 과 def down 으로 쓴다. 롤백 쪽 DDL도 같은 MDL을 잡으므로 up과 down 모두 대상 DDL 앞에 설정을 둔다.
   • 중간에 실패해 일부만 적용되는 일을 피하려고 마이그레이션 하나에 대상 DDL은 하나만 둔다.
   • 실패할 때 다른 마이그레이션까지 휩쓸리지 않도록 대상 DDL을 담은 마이그레이션은 따로 릴리스한다.
   • 대상 마이그레이션은 트래픽이 적은 시간대에 실행한다.
   • 대상 조건과 대응 방법의 자세한 내용은 db/migrate/README.md 에 둔다.
   • AGENTS.md 의 참조 표에 db/migrate/ → db/migrate/README.md 한 줄을 더해 Copilot과 AI 에이전트가 리뷰할 때 이 규칙을 보게 한다.
   • db/migrate/** 를 바꾼 PR에 자동으로 달리는 기존 코멘트의 체크리스트에 이번 확인 항목을 더한다.

   사례 보기
2. IL-0322 GitLab.com 의 모든 주요 서비스에서 HTTP 503 오류가 두 차례 쏟아졌다가 저절로 멎었다

   GitLab2026sev1

   증상

   2026-06-11 06:16 UTC 에 Pingdom 알림이 https://gitlab.com 의 HTTP 503 오류를 알렸다. 웹, 프런트엔드, API, git, 웹소켓, web-pages, CI 러너가 06:16~06:22 UTC 와 07:03~07:12 UTC 두 차례 503 을 냈다. 오류는 여러 서비스에 걸쳐 끊겼다 이어지기를 반복했고, 매번 5~10분 안에 저절로 회복했다.

   서비스 중단간헐적 타임아웃커넥션 풀 고갈잠금 경합과 교착복제 지연

   촉발

   us-east1-b 존의 GCP 스토리지 장애로 주 데이터베이스 노드가 쓰는 디스크의 스토리지 IO 성능이 떨어졌다.

   원인

   클라우드 제공자 장애

   구성 요소

   데이터베이스클라우드 블록 스토리지

   기여 요인

   단일 장애점한계 경보 부재런북 부재

   감지

   06:16:12 UTC 에 Pingdom 알림이 장애를 알렸다. 영향은 06:12 에 시작됐으므로 감지까지 약 4분이 걸렸다. 사용자에게 보이는 503 은 알림이 잡았지만, 먼저 나타난 신호인 디스크 IO 포화, pgBouncer 풀 포화, LWLock 경합에는 알림이 없었다.

   조치

   • 두 번째 구간이 데이터베이스와 연결 계층을 가리키자 07:11 UTC 에 데이터베이스 운영 tier2 로 장애를 에스컬레이션했다. 데이터베이스 전문가가 LWLock 경합, pg_wait_sampling_buffer_mapping 급증, 복제 지연을 깊이 진단했다.
   • 배포를 멈췄다.
   • 08:13 UTC 에 GCP TAM 에 연락하고 08:56 에 GCP 지원 케이스를 열었다. 클라우드 제공자가 스토리지 장애를 확인해 줬다.
   • 다시 나빠지면 바로 실행할 수 있게 us-east1-d 의 04 노드로 Patroni 주 노드 전환을 준비했다. 쓰기 처리량에 줄 영향도 따져 두었지만 실행하지는 않았다.
   • GCP 쪽 문제가 가라앉은 것으로 보이자 15:19 UTC 에 장애를 멈춰 두고 3시간 동안 지켜봤고, 재발이 없음을 확인한 뒤 해결로 처리했다.

   후속 조치

   • Patroni 주 데이터베이스 노드에 디스크 IO 포화와 큐 깊이 알림을 넣는다.
   • 명시적인 실행 기준을 담은 Patroni 주 노드 전환 런북을 쓴다.
   • 끊겼다 저절로 회복하는 장애에서 장애 상태를 언제 바꿀지 지침을 분명히 한다.
   • 디스크 IO 가 떨어지는 동안 자동으로 장애 조치했어야 했는지 검토한다.
   • Cells 는 장기적으로 영향 범위를 줄이도록 설계됐다. 그와 별도로 디스크 하나가 GitLab.com 전체를 멈추지 않도록 단기 완화책을 마련한다.
   • 주 노드가 응답하지 않을 때 애플리케이션의 데이터베이스 부하 분산이 요청을 덜어 내거나 다른 곳으로 보내, 요청이 60초 Rack 타임아웃까지 쌓이지 않고 빨리 실패하게 한다.
   • pgBouncer 풀 포화와 LWLock 경합이 전면 장애보다 먼저 튀었으므로, 이 둘을 먼저 나타나는 신호로 보고 알림을 걸지 검토한다.

   교훈

   디스크 하나가 나빠진 것만으로 GitLab.com 전체가 멈췄다. 데이터베이스 부하 분산이 빨리 실패하지 않아 요청이 60초 Rack 타임아웃까지 쌓였다. 빨리 실패하지 않는 문제는 이전 장애 #18269 에서 얻은 교훈과 겹쳤다. 장애 조치 기준이 미리 정해져 있지 않아 문제가 다시 날지 몰라 지켜보고 기다리는 데 많은 시간을 썼다. 클라우드 제공자 장애가 넓게 퍼진 상황이라 어느 존이 정상인지 미리 확인할 수도 없었다. 끊겼다 저절로 회복하는 장애에서는 장애 상태를 언제 Fixing 이나 Monitoring 으로 옮길지 정하기 어려웠다.

   사례 보기
3. IL-0510 MIT Learn 운영 RDS PostgreSQL 의 저장 공간이 임시 파일로 가득 차 learn.mit.edu 가 세 시간 동안 503 과 504 를 냈다

   MIT Open Learning2026

   증상

   learn.mit.edu 가 멈췄다는 보고가 Sentry 이슈 링크와 함께 올라왔다. MIT Learn 의 운영 데이터베이스인 RDS PostgreSQL 인스턴스가 쓸 수 있는 저장 공간을 모두 써 버린 상태였고, 사이트는 503 과 504 오류를 냈다.

   서비스 중단노드 디스크 가득 참데이터베이스 과부하잠금 경합과 교착

   촉발

   정기 릴리스 절차로 배포한 변경이 페이지 응답의 메인 쿼리 안에 집계를 넣었다. DRF 는 페이지 응답의 count 칸을 SELECT COUNT * ($QUERY) 로 계산하므로, 운영의 데이터 규모에서 이 쿼리가 임시 파일을 대량으로 만들었다.

   원인

   배포 결함

   구성 요소

   데이터베이스

   기여 요인

   비효율적인 쿼리스테이징 불일치수동 조치 악화

   감지

   엔지니어가 장애를 보고하며 Sentry 이슈를 연결했다. 이어 다른 엔지니어가 운영 데이터베이스의 저장 공간이 바닥난 것을 확인했고, FreeStorageSpace 지표와 Sentry 에 쌓인 504 도 같은 상황을 보여 줬다.

   조치

   • 쿼리 패턴 변경을 쓴 엔지니어가 그 변경이 원인임을 확인하고 릴리스를 롤백했다.
   • 데이터베이스가 버퍼에 쌓인 WAL 파일을 따라잡아 비울 여유를 주려고 읽기 복제본을 삭제했다.
   • AWS 지원의 도움을 받아 백업이 끝난 뒤 오래 돌던 쿼리를 안전하게 종료했다. pg_stat_activity 에서 state = 'active' 이고 시작한 지 10분이 넘은 쿼리를 pg_terminate_backend(pid) 로 끝내자 저장 공간과 처리 여유가 돌아왔다.

   후속 조치

   • 운영 learn 데이터베이스에 enhanced analytics 를 켜는 방안을 검토한다.
   • 플랫폼 엔지니어링 문서 사이트에 롤백 절차를 적는다.
   • 장기적으로는 새로 만드는 릴리스 관리 체계에서 롤백을 쉽게 할 수 있게 한다.
   • 운영 데이터베이스의 DiskQueueDepth 에 알림을 걸되 너무 자주 울리지 않게 한다.
   • API 와 사이트의 응답 시간이 평소보다 30% 넘게 높아지면 알림을 보낸다.
   • 운영 데이터베이스 장애를 예제로 삼아 게임데이 훈련을 한다.
   • 장애 관리 도구 Rootly 를 써서 장애 때 소통을 한 채널에 자동으로 모으고 장애 기록을 자동으로 남긴다.
   • 장애 대응 런북을 가볍게 만든다. 장애가 나면 Zoom 통화를 열고, 당번 엔지니어가 지표가 평소 수준으로 돌아오는지 지켜보며, 소통 담당을 따로 두어 이해관계자의 문의가 핵심 대응자를 방해하지 않게 한다.
   • 오래 도는 쿼리를 종료하는 SQL 과, 이 SQL 을 고쳐 아주 오래 도는 쿼리만 골라 종료하는 SQL 을 운영 Postgres 런북에 넣는다.
   • Learn Resource View Event 모델이 지금은 건수를 세는 데만 쓰이므로 다시 설계해야 한다는 이슈를 쓴다.
   • 익명화한 운영 데이터 생성 도구로 RC 환경의 데이터 양을 운영 수준까지 늘린다. 운영 데이터를 익명화해 담은 운영 규모의 부하 시험 환경을 만들고, 이해관계자도 시험에 쓰는 RC 에 영향이 없도록 인프라를 분리한다.
   • 조회 수를 미리 계산해 둔 열에서 읽도록 고쳐 배포했다. 영향을 받던 API 의 운영 응답 시간이 약 13~15초에서 150~200ms 로 줄었다.

   교훈

   이 변경은 가장 시니어인 엔지니어 두 명이 꼼꼼히 리뷰했지만 로컬과 RC 환경에서는 아무 문제도 드러나지 않았다. 운영의 데이터 규모와 시스템 부하가 크게 달랐고, 효율적이라고 여긴 COUNT 집계가 디스크 사용량을 폭증시킬 것이라는 점은 당시 시스템 상태만 보고는 알기 어려웠다. 그래서 운영과 같은 규모의 데이터로 부하를 시험할 환경이 필요하다고 팀은 결론지었다. AWS 지원은 ORM 쿼리 변경을 운영 수준의 데이터를 담은 스테이징에서 시험하고, EXPLAIN ANALYZE 로 실행 계획과 예상 자원 사용을 보며, 시험 중 log_temp_files 로 임시 파일 생성을 지켜보라고 권했다. 폭주하는 쿼리를 막도록 temp_file_limit 를 설정하고, 실행 계획에 따라 work_mem 이나 shared_buffers 를 조정하되 메모리를 너무 쓰면 out of memory 로 장애 조치가 일어날 수 있다는 점도 짚었다. 임시 파일을 많이 쓰는 작업에는 임시 파일을 EBS 대신 로컬 NVMe 에 두는 RDS Optimized Reads 를 고려하라고 했다.

   사례 보기
4. 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 하게 바꾸는 방안을 검토한다.

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

   사례 보기

원인별8