그래프
사례2건
2건 중 1~2번째
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 를 한꺼번에 올리지 않고 인스턴스마다 차례로 올렸다면 전체에 퍼지기 전에 버전별 성능 문제를 찾았을 것이라고도 했다.
- 증상
2023-02-07 9:47 AM 동부 시간에 평소 부하에서 데이터베이스 성능 문제 알림이 울렸다. 알림 내용은 주말에 업그레이드한 데이터베이스의 락 경합이 높다는 것이었고, 이 때문에 통화 서버인 SFU 가 문제를 겪었다.
- 촉발
Daily 는 주말에 데이터베이스 서버를 업그레이드했고, 이 작업으로 데이터베이스가 MySQL 포인트 릴리스의 저수준 동작 변경이 들어간 버전으로 올라갔다. 월요일까지 정상이던 데이터베이스가 2월 7일 평소 부하에서 대량의 교착을 일으켰다.
- 원인
- 구성 요소
- 기여 요인
- 감지
9:47 AM 동부 시간에 평소 부하에서 데이터베이스 성능 문제 알림이 울렸고, 알림은 새로 업그레이드한 데이터베이스의 높은 락 경합을 가리켰다.
- 조치
- 10:13 에 옛 데이터베이스를 최신으로 맞추던 MySQL binlog 복제를 끄고 데이터베이스를 재시작해 부하를 줄였다. 나아졌지만 SFU 가 교착을 일으키던 쿼리를 재시도해 문제가 이어졌다.
- 10:47 에 데이터베이스가 갑자기 스스로 재시작했다. 이 재시작 덕분에 SFU 는 재시작하지 않고 오래된 meeting 업데이트를 버릴 수 있었고, 플랫폼이 정상으로 돌아왔다.
- 예방 조치로 방을 만드는 REST API 엔드포인트에 요청 제한을 걸었다. POST /rooms 의 한도를 DELETE /rooms/:name 과 같은 초당 약 2회, 30초에 50회로 맞췄다.
- MySQL 동작 변경을 피하려고 영향받은 테이블 하나의 인덱스를 고쳤다. 그 주 동안 계획을 만들어 시험했고 토요일 저녁에 사용자 영향 없이 운영 데이터베이스에 적용했다.
- 후속 조치
- 운영 환경의 Aurora MySQL 2.11.0 에서 본 교착 문제를 문서로 남기고 원인을 밝혀 다음 릴리스에서 고치도록 AWS 와 계속 협력한다.
- 시험 부하에 API 요청 패턴을 더했다.
- 더 세밀한 데이터베이스 지표를 보는 운영 모니터링 알람을 더했다.
- 교훈
Daily 는 모든 인프라 변경을 운영과 비슷한 부하로 시험하려 하지만, 이번에는 이 교착을 일으킬 만한 형태의 합성 부하로 시험하지 못했다. MySQL 5.7 에서 교착 처리가 더 보수적으로 바뀐 것은 알려진 변경이었어도, 실제로 겪은 교착의 심각도는 Daily 와 AWS Aurora 팀 모두에게 뜻밖이었다.
이 2건에서 가장 많이 나오는 구성 요소: 데이터베이스, 데이터베이스 프록시와 커넥션 풀러. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.