사례11건

11건 중 1~5번째

1. 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 를 고려하라고 했다.

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

   Railway2025

   증상

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

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

   촉발

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

   원인

   배포 결함

   구성 요소

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

   기여 요인

   의존성에 묶인 헬스 체크

   후속 조치

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

   사례 보기
3. IL-0547 Buildkite 의 Agent API, REST API, GraphQL 이 annotations 테이블 쿼리 타임아웃으로 4시간 가까이 저하됐다

   Buildkite2025

   증상

   2025년 11월 10일 04:48 UTC 부터 Buildkite 의 Agent API 가 대부분의 고객에게 심하게 저하됐고, REST API, GraphQL, Web UI 도 오류율이 오르고 느려졌다.

   간헐적 타임아웃데이터베이스 과부하오류율 상승지연 시간 증가

   촉발

   2025년 11월 10일 04:48 UTC 에 Pipelines 제품의 annotations 를 저장하는 테이블에서 인덱스 하나를 지우는 데이터베이스 마이그레이션이 적용됐다. 대신할 인덱스가 이미 있었지만 트래픽이 많은 일부 쿼리가 새 인덱스를 타지 않았다.

   원인

   배포 결함

   구성 요소

   데이터베이스

   기여 요인

   리뷰 누락단계적 배포 부재

   감지

   04:53 UTC 에 annotations 테이블 쿼리의 타임아웃으로 인덱스 삭제의 영향이 감지됐다.

   조치

   • 바로 지운 인덱스를 다시 만들기 시작해 05:30 UTC 까지 데이터베이스 샤드의 절반쯤에서 끝냈고, 서비스 일부가 돌아왔다.
   • 나머지 샤드의 부하를 줄이려고 애플리케이션 사용자의 annotations 테이블 읽기·쓰기 권한을 잠시 뺐다.
   • Postgres 의 max_parallel_maintenance_workers 를 늘려 인덱스 생성 속도를 크게 올렸다.
   • 07:50 UTC 부터 08:43 UTC 까지 읽기·쓰기 권한을 뺀 상태에서 나머지 샤드의 인덱스를 다시 만들었고, Agent API, REST API, GraphQL 의 지연과 오류율이 평소 수준으로 돌아왔다.
   • 일관되지 않은 상태로 남은 에이전트를 풀어 주고 잡 상태를 정리했다. 스스로 회복하지 못한 경우는 손으로 처리했고 11:56 UTC 에 끝났다.

   후속 조치

   • 코드 리뷰 때 위험한 마이그레이션을 짚어 주는 내부 도구가 인덱스 삭제도 다루도록 넓혔다. 이 도구는 인덱스를 지우는 마이그레이션을 배포하기 전에 그 인덱스가 더는 필요 없는지 엔지니어가 확인하게 한다.
   • 지금은 데이터베이스 마이그레이션이 모든 샤드에 동시에 적용된다. 위험도가 높은 마이그레이션은 단계적으로 적용해 영향 범위를 좁히고, 문제가 생기면 더 빨리 복구할 수 있게 한다.
   • 인덱스를 만들거나 지울 때의 분석을 개선하려고 HypoPG 같은 도구를 검토한다.
   • pganalyze 의 인덱스 사용 데이터를 개발 흐름에서 더 잘 보이게 해, 엔지니어가 그 데이터를 보고 인덱스 변경을 결정하게 한다.
   • 일부 에이전트의 일관되지 않은 상태를 풀 때 쓴 수작업 정리를 자동화해, 비슷한 문제에서 시스템이 스스로 회복하게 한다.

   교훈

   Buildkite 는 이 장애가 주로 데이터베이스 마이그레이션 하나에서 비롯됐고, 그 마이그레이션이 검토 과정의 빈틈을 드러냈다고 밝혔다.

   사례 보기
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-0327 워크플로 데이터베이스를 blue/green 으로 업그레이드한 뒤 워크플로 시작과 취소가 지연되고 실패했다

   CircleCI2025

   증상

   blue/green 전환은 22:08 UTC 에 끝났다. 22:17 에 워크플로 서비스의 지연이 커졌고, 10분 재시도를 다 쓴 작업이 버려지며 오류가 났다. 고객은 워크플로와 작업을 시작하거나 취소할 때 지연과 실패를 겪었고 UI 에서 워크플로를 보기 어려웠다.

   지연 시간 증가오류율 상승데이터베이스 과부하

   촉발

   22:00 UTC 무렵 워크플로를 맡는 서비스의 데이터베이스를 blue/green 배포로 업그레이드했고, 22:08 에 전환이 끝났다.

   원인

   배포 결함

   구성 요소

   데이터베이스쿼리 플래너와 테이블 통계

   기여 요인

   –

   감지

   22:17 UTC 에 워크플로 서비스의 지연이 커지고 10분 재시도를 다 쓴 작업이 버려지며 오류가 나는 것을 확인했다.

   조치

   • 22:30 UTC 에 모든 워크플로 파드가 올바른 데이터베이스에 연결하도록 파드를 재시작했다.
   • 22:41 에 새 데이터베이스의 모든 쿼리가 디스크에서 읽히는 것을 보고 곧바로 데이터베이스 크기를 키우고 업무에 꼭 필요하지 않은 데이터베이스 작업을 껐다.
   • 23:00 에 통계 테이블을 다시 만드는 동안 데이터베이스가 회복할 여유를 주려고 워크플로 서비스를 파드 하나로 줄였다.
   • 23:19 에 옛 데이터베이스의 쓰기를 다시 켜고 옛 데이터베이스를 다시 주 데이터베이스로 되돌리기로 했다. 이 작업은 23:29 에 끝났다.

   후속 조치

   • blue/green 데이터베이스 배포 절차에서 메이저 버전이 바뀔 때마다 analyze 절차를 돌리도록 바꿨다.
   • 부하가 걸린 데이터베이스에서 analyze 명령을 돌려도 성능이 더 나빠지지 않는다는 것을 시험으로 확인했다. 앞으로 복구할 때 참고하도록 이 결과를 적어 둔다.
   • 다음 마이그레이션 전에 자동 테스트와 수동 확인 지점을 절차 곳곳에 더해 blue/green 전환 전에 문제를 찾아 해결한다.

   사례 보기

원인별1