사례13건

13건 중 6~10번째

1. 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 인스턴스의 용량을 넘지 않게 한다.
   • 데이터베이스 사용자별 커넥션 한도를 설정해 장애 중에도 관리용 접속을 보장하고, 어떤 상황에서도 유지 보수 작업을 할 수 있게 한다.

   사례 보기
2. IL-0368 AWS us-east-1 장애 동안 PlanetScale 컨트롤 플레인이 멈추고, 이어 일부 데이터베이스 브랜치가 네트워크 분할로 쿼리에 실패했다

   PlanetScale2025

   증상

   7:13 UTC 에 프로덕션에서 계속 도는 PlanetScale 테스트가 실패하기 시작했다. 테스트는 새 데이터베이스 브랜치를 만들지 못하고 있었다. 데이터베이스 브랜치를 만들고 크기를 바꾸고 설정하는 서비스가 응답하지 않았다.

   서비스 중단노드 증설 실패네트워크 도달 불가오류율 상승복제 지연DNS 조회 실패

   촉발

   PlanetScale 의 서비스 제공자 한 곳에서 DNS 설정 오류가 났고, 이어서 AWS us-east-1 에 몇 시간 동안 용량 제약과 네트워크 불안정이 이어졌다.

   원인

   클라우드 제공자 장애

   구성 요소

   데이터베이스데이터베이스 복제데이터베이스 프록시와 커넥션 풀러오브젝트 스토리지

   기여 요인

   –

   감지

   첫 단계는 7:13 UTC 에 프로덕션에서 계속 도는 테스트가 실패하면서 엔지니어들에게 알림이 갔다. 둘째 단계는 10:05 UTC 에 한 고객 환경의 Kubernetes operator 가 쓸 수 있는 자원을 모두 쓰고 있다는 알림으로 알았다.

   조치

   • us-east-1 에 새 데이터베이스를 만드는 것을 잠시 막고, 새 데이터베이스의 기본 리전을 AWS us-east-2 로 바꿨다.
   • 추가 백업 예약을 미루고, EC2 인스턴스를 띄우려고 기다리던 백업을 취소했다. PlanetScale 의 표준 백업은 백업 동안 데이터베이스의 용량과 장애 내성이 줄지 않도록 복제본을 하나 더 띄워 이전 백업을 복원하고 복제를 따라잡은 뒤 새 백업을 뜬다.
   • vtgate 자동 확장을 쓰는 PlanetScale Managed 고객에게 큐 처리를 미루거나 ETL 작업을 멈추는 식으로 줄일 수 있는 부하를 줄이라고 권했다.
   • 30일이 넘은 EC2 인스턴스를 비우고 종료하던 상시 작업을 멈췄다.
   • 비게 된 EC2 인스턴스를 종료하지 않고 다시 쓰려고 남겨 뒀다.
   • 자동 확장을 설정한 고객의 vtgate 프로세스를 평소보다 빽빽하게 배치해 CPU 용량에 더 가깝게 돌리면서, 미국 업무 시간 동안 쓸 용량을 넉넉히 확보했다.
   • 가능한 곳에서는 손으로 reparent 요청을 보내 프라이머리 데이터베이스를 더 건강하다고 알려진 가용 영역이나 고객 애플리케이션과 같은 영역으로 옮겼다.
   • 네트워크 분할이 풀린 뒤 스스로 복구하지 못한 엣지 로드 밸런서와 vtgate 프로세스를 재시작해 서비스를 되살렸다.

   후속 조치

   • CI/CD, SSO, 웹 애플리케이션 호스팅, 장애 공지에 쓰는 SaaS 의 장애 양상을 더 잘 이해하고, 그 장애에 버틸 수 있게 한다.
   • 런타임에 내부 서비스와 AWS 서비스에 기대는 정도를 더 크게 줄이는 방법을 조사한다.
   • AWS us-east-1 에 있는 가용 영역 여섯 개를 모두 더 잘 써서, 영역 장애와 영역 사이의 네트워크 분할에 더 잘 버티는 방법을 살핀다.

   교훈

   PlanetScale 은 컨트롤 플레인과 데이터 플레인을 확실히 나눠 둔 덕분에 컨트롤 플레인 장애가 고객 데이터베이스에 번지지 않았다고 봤다. 중복 구성과 자동 장애 조치로 프라이머리 데이터베이스 서버가 네트워크 분할의 다수 쪽으로 옮겨 갔고, 영역을 고려한 트래픽 라우팅이 분할의 영향을 최대한 줄였다. 네트워크 분할은 장애 양상 가운데 따져 보기도, 시험하기도, 견디기도 가장 어려운 편이다. 가용 영역 세 개를 쓰면 하나가 망가져도 버틸 수 있지만, 나머지 두 영역 사이의 네트워크 연결이 믿을 만할 때만 그렇다.

   사례 보기
3. IL-0316 밀린 배포가 한꺼번에 몰린 Control Plane 에서 새 버전 PgBouncer 가 CPU 와 메모리를 비정상적으로 많이 써 데이터베이스 연결이 타임아웃됐다

   Railway2025

   증상

   2025-09-22 11:05 UTC 에 Railway 프로젝트 캔버스가 열리지 않는다는 첫 신고가 들어왔다. 캔버스는 실제 오류를 보여 주지 않고 끝없이 로딩 상태에 머물렀다.

   지연 시간 증가간헐적 타임아웃배포 실패

   촉발

   코드 정리 중 쓰지 않는 컬럼을 지우는 스키마 변경을 했는데, 뒤이은 코드 변경이 그 일부를 의도치 않게 되돌려 프런트엔드가 쓰는 핵심 API 가 실패했다. 이 문제를 고친 뒤 밀린 배포가 한꺼번에 시작되면서, 몇 버전 올라간 PgBouncer 를 쓰던 Control Plane 이 부하를 이기지 못했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

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

   기여 요인

   버전 미고정단계적 배포 부재모니터링 사각지대기본 설정 방치

   감지

   11:05 UTC 에 사용자들이 Railway 프로젝트 캔버스가 열리지 않는다고 신고했다. 두 번째 문제는 11:48 UTC 에 Control Plane 의 자원 사용이 비정상으로 늘고 API 지연이 높아지면서 드러났다.

   조치

   • 사고를 선언하고 15분 안에 수정을 배포해 프로젝트 캔버스 문제를 풀었다.
   • 먼저 Free, Trial, Hobby 등급 사용자의 배포를 멈춰 Pro 사용자는 평소대로 배포하게 하고 배포 대기열이 차츰 줄게 했다.
   • 가장 불안정할 때는 Pro 를 포함한 모든 새 배포를 최대 20분 멈춰 대기열을 더 줄였다.
   • Control Plane 데이터베이스의 CPU 와 메모리를 늘리고, 커넥션 한도를 조정하고, IOPS 용량을 늘렸다.
   • 설정을 손보는 대신 안정적이던 이전 PgBouncer 버전으로 곧바로 롤백했고, 성능이 100배 좋아지며 모든 지표가 정상으로 돌아왔다.
   • 롤백 뒤 Pro 가 아닌 사용자 모두의 배포를 다시 열었다.
   • 21:27 UTC 에 사설 네트워크와 그 엔드포인트가 대시보드에 보이지 않던 드문 경우를 뒤늦게 고쳤다.

   후속 조치

   • Control Plane 저장 계층의 큰 부분을 Postgres 밖으로 옮기는 재설계를 계속한다. 이 작업은 3분기 초에 시작했고, 한 리전의 Control Plane 장애가 플랫폼 전체에 번지는 것을 막고 지금의 Postgres 보다 몇 자릿수 높은 IOPS 를 낼 것을 목표로 한다.
   • CI 파이프라인 검증을 강화해 중단을 일으키는 스키마 변경이 운영에 닿지 못하게 하고, 백엔드 배포 전에 스키마 호환성을 자동으로 검사한다.
   • PgBouncer 노드의 CPU, 메모리, 커넥션 풀 사용률을 모니터링하고 알림을 건다.
   • PgBouncer 업그레이드는 한꺼번에 하지 않고 인스턴스마다 단계적으로 적용한다.

   교훈

   Railway 는 호환되지 않는 스키마 변경이 운영에 닿지 않았다면 이번 연쇄 장애가 없었을 것으로 보았다. PgBouncer 의 성능 저하를 미리 알았다면 훨씬 빨리 복구할 수 있었다고 했다. PgBouncer 를 한꺼번에 올리지 않고 인스턴스마다 차례로 올렸다면 전체에 퍼지기 전에 버전별 성능 문제를 찾았을 것이라고도 했다.

   사례 보기
4. IL-0498 Postgres 데이터베이스 부하가 15분마다 치솟아 나흘 동안 요청 실패와 지연 급증이 간헐적으로 이어졌다

   Clerk2025

   증상

   2025년 9월 15일 13:08 UTC에 내부 모니터링이 요청 실패가 크게 늘고 지연이 늘었다고 알렸다. 그 뒤 9월 18일까지 고객 트래픽에서 요청 실패와 지연 급증이 간헐적으로 이어졌다.

   오류율 상승지연 시간 증가데이터베이스 과부하커넥션 풀 고갈

   촉발

   2025년 9월 14일 클라우드 사업자가 Clerk 의 Postgres 데이터베이스를 마이너 버전으로 자동 업그레이드했다. 이 업그레이드에는 Postgres 가 연결 잠금을 다루는 방식의 큰 내부 변경이 들어 있었다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

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

   기여 요인

   버전 미고정재시도 폭주모니터링 사각지대장애 중첩수동 조치 악화

   감지

   9월 14일 업그레이드 직후 내부 모니터링이 데이터베이스 부하 증가를 잡았지만 견딜 만한 수준이었고 지연에는 영향이 없었다. 9월 15일 13:08 UTC에 내부 모니터링이 요청 실패가 크게 늘고 지연이 늘었다고 알렸다.

   조치

   • 비용이 큰 쿼리 여러 개를 최적화해 데이터베이스의 기본 부하를 영구히 줄였다. 주요 인덱스를 다듬고 전체 재색인을 해 데이터베이스 오버헤드도 줄였다.
   • 안정성을 지키려고 남용 트래픽 차단을 잠시 강화했다. 효과는 있었지만 정상 요청 일부가 HTTP 429 로 거부됐을 수 있다.
   • 9월 17일 07:15 UTC부터 08:10 UTC까지 수동 마이너 버전 업그레이드를 하고 데이터베이스 용량을 늘렸다. 데이터베이스 상태가 눈에 띄게 나아졌고 지연 급증이 다시 사라진 듯했다.
   • 연결 재생성 시각이 서로 맞춰지지 않도록 연결 풀링 전략에 지터를 넣었다. 배포 직후 데이터베이스 부하가 장애 전보다 낮아졌고 지연 급증이 사라졌다.

   후속 조치

   • 업그레이드와 다운그레이드를 더 통제할 수 있고 지금 사업자보다 성능이 나은 데이터베이스 솔루션을 검토한다.
   • 가입과 로그인 인프라를 시스템의 다른 부분에서 떼어 내는 식으로 서비스 격리를 넓힌다.
   • 비용이 큰 쿼리 목록을 계속 따라가며 데이터베이스 성능을 더 끌어올린다.
   • 애플리케이션 하나를 다른 애플리케이션과 격리하는 테넌트 격리 방법을 검토한다. 이 작업은 샤딩과 멀티테넌트 인프라의 최신 방식을 살펴보는 일이라 다른 개선보다 오래 걸릴 가능성이 크다.

   교훈

   Clerk 는 돌아보면 원인이 단순해 보이지만 여러 요인이 겹쳐 찾기 어려웠다고 밝혔다. 첫째, 연결 지표를 60초 간격으로 수집해 15분마다 몇 초 안에 일어나는 재생성 주기가 대시보드에 드문드문한 급증으로만 보였다. 둘째, 같은 시기의 사기 가입 공격이 약 10분 주기로 부하를 만들어 원인을 그쪽으로 의심하게 했다. 셋째, 10분, 15분, 30분 간격의 정기 작업과 예약 쿼리가 급증 시각과 맞아떨어져 조사를 흩뜨렸다. 넷째, 같은 연결 풀링 로직을 쓰는 Backend API 에는 급증이 잘 보이지 않았는데, Clerk 는 Backend API 가 관리하는 연결 수가 훨씬 적어 재생성이 맞춰져도 데이터베이스가 감당했기 때문으로 봤다. 다섯째, 장애 중에 건 배포 동결은 평소 배포가 연결 생성 시각을 흩어 주던 효과를 없애 문제를 키웠다. 이 관계가 직관적이지 않아 연결 동기화를 가리키는 가장 분명한 신호가 가려졌다.

   사례 보기
5. IL-0307 Supabase us-east-1 에서 Supavisor 2.0 업그레이드 뒤 Postgres 연결 풀러가 테넌트 약 80% 의 연결을 끊었다

   Supabase2025

   증상

   2025년 1월 29일 16:05 UTC 에 us-east-1 의 Supavisor 클라이언트 대다수가 연결이 끊겼고 다시 연결하는 데 자꾸 실패했다. Supavisor 는 Postgres 연결을 관리하는 연결 풀러다. Supabase Storage 연결도 함께 문제를 겪었다.

   연결 리셋간헐적 연결 실패

   촉발

   us-east-1 에 Supavisor 2.0 으로 올리는 메이저 업그레이드를 배포한 뒤, :ets.select_delete 작업이 실패해 ETS 테이블이 손상되었다.

   원인

   배포 결함

   구성 요소

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

   기여 요인

   –

   조치

   • 16:11 UTC 에 이전 Supavisor 버전으로 롤백을 시작했고, 16:53 UTC 에 롤백이 끝나 이전 안정 버전으로 정상 동작이 돌아왔다.

   후속 조치

   • 롤백 시간을 40분에서 90초 안으로 줄인다.
   • 클라이언트 연결이 끊기는 것을 2분 안에 잡도록 알림을 고친다.

   교훈

   Supabase 는 이 장애로 롤백이 느리고, 부하가 걸린 상태에서 예상하지 못한 장애를 견디는 힘이 약하다는 점이 드러났다고 밝혔다. 앞으로 비슷한 배포 실패의 영향을 줄이려고 롤백 효율을 높이는 데 집중한다고 썼다.

   사례 보기

원인별6