사례7건

7건 중 4~7번째

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-0312 max_connections 를 올리려고 재시작한 주 PostgreSQL 데이터베이스가 다시 올라오지 않아 Gadget 의 모든 앱 요청이 멈췄다

   Gadget2024

   증상

   2024-12-13 11:25 AM EST 에 Gadget 은 커넥션 한도를 올리려고 주 Postgres 데이터베이스를 그 자리에서 재시작했는데, 서버가 내려간 뒤 다시 올라오지 않았다. 그동안 Gadget 앱으로 오는 모든 요청이 실패했다.

   서비스 중단지연 시간 증가

   촉발

   Gadget 은 플랫폼이 커지며 Postgres 의 max_connections 한도에 닿아 생기던 짧은 장애를 끝내려고, 이 값을 올리는 긴급 설정 변경을 결정했다. max_connections 는 서버를 재시작해야만 바뀌므로 11:25 AM EST 에 데이터베이스를 그 자리에서 재시작했다.

   원인

   용량 한계

   구성 요소

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

   기여 요인

   미검증 가정스테이징 불일치자동화 증폭과도한 영향 범위

   감지

   Gadget 은 11:25 AM EST 에 재시작한 데이터베이스가 기대대로 다시 올라오지 않는 것을 11:26 AM 에 확인했다.

   조치

   • 데이터베이스 서버를 하드웨어 리셋해 메모리 조각화를 없앴고, 11:50 AM EST 에 데이터베이스가 다시 올라왔다.
   • 데이터베이스가 멈춘 동안 오토스케일러가 줄인 컴퓨트를 당시의 거의 4배로 다시 띄웠고, 이 확장은 성공했지만 서비스 저하가 20분 더 이어졌다.

   후속 조치

   • 이번처럼 중단을 일으키는 데이터베이스 작업은 앞으로 replica 를 만들어 장애 조치하는 방법으로만 한다. 새 replica 를 먼저 띄우면 넘어가기 전에 운영 인프라 안에서 동작을 확인할 수 있다.
   • Black Friday 와 Cyber Monday 전의 용량 계획을 훨씬 공격적으로 세워 부하 6배 증가에 대비하고, 충분한 시간을 두고 종합 부하 시험을 해서 준비가 됐는지 확인한다.
   • 계획된 중단은 상태 페이지와 커뮤니티 Discord 로 미리 알리고, 계획된 점검과 서비스 장애의 차이를 분명히 알리도록 표준 운영 절차를 다듬는다.
   • 계획해 온 데이터베이스 샤딩 프로젝트를 끝내 Gadget 앱마다 다른 데이터베이스를 쓰게 한다. 그러면 데이터베이스 설정 변경에 카나리 배포와 블루/그린 구성을 써서 고객 앱에 닿기 전에 충분히 시험하고, 장애 범위도 좁힐 수 있다.
   • 이미 진행 중인 무중단 데이터베이스 장애 조치 시스템을 완성해 어떤 앱도 멈추지 않고 데이터베이스 크기와 설정을 바꿀 수 있게 한다.
   • 오토스케일러의 최소 규모를 크게 높였다. 앞으로 장애가 나도 컴퓨트가 훨씬 덜 줄어 복구가 빨라진다.

   교훈

   Gadget 은 그 자리에서 재시작하는 방법을 고른 것을 판단 착오로 보았다. 확신할 수 없고 겪어 본 적 없는 상태로 시스템을 몰아넣은 위험한 선택이었다는 것이다. Gadget 은 모든 실패 상태를 미리 알 수는 없어도 처음 보는 실패 상태로 들어가는 일은 대개 피할 수 있다고 했다. Black Friday 와 Cyber Monday 의 용량 계획이 두 배로 잡혀 거의 5배의 부하를 감당하지 못했다. 제대로 계획했다면 점검 시간을 미리 잡고 스테이징에서 연습할 수 있었다. 새 데이터베이스 설정을 사용자에게 영향 없이 운영과 비슷한 환경에서 시험할 방법도 없었다. 통합 테스트는 합성 Postgres 데이터베이스와 쿠버네티스 인프라에서 돌기 때문에, 몇 달 동안의 운영 부하가 만드는 메모리 조각화나 메모리 사용 문제를 재현하지 못한다.

   사례 보기
4. IL-0308 RevenueCat 이 Aurora PostgreSQL 10 에서 14 새 클러스터로 넘어간 직후 쿼리가 극도로 느려져 대시보드와 SDK 엔드포인트가 세 시간 넘게 실패했다

   RevenueCat2022

   증상

   2022년 11월 23일 9:39 UTC 에 트래픽 전부가 새 Aurora PostgreSQL 14.x 클러스터로 넘어갔고, 지연이 나빠져 인프라 팀이 조사를 시작했다. 9:54 UTC 에는 쿼리가 평소보다 훨씬 오래 걸리면서 데이터베이스 연결을 모두 차지하고 있었다.

   데이터베이스 과부하지연 시간 증가서비스 중단커넥션 풀 고갈

   촉발

   복제를 이용해 Aurora PostgreSQL 10.x 클러스터에서 새 14.x 클러스터로 트래픽을 넘겼다. 그런데 가장 큰 테이블 하나의 vacuum 이 전환 전에 끝나지 않아, 새 클러스터의 가장 큰 테이블들에 ANALYZE 가 돌지 않은 상태였다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   데이터베이스PostgreSQL vacuum데이터베이스 복제데이터베이스 프록시와 커넥션 풀러쿼리 플래너와 테이블 통계

   기여 요인

   스테이징 불일치미검증 가정자동화 증폭모니터링 사각지대

   감지

   9:39 UTC 에 트래픽 전부가 새 클러스터로 넘어갔을 때 지연이 나빠 보였고, 인프라 팀이 바로 조사를 시작했다.

   조치

   • 9:54 UTC 에 쿼리가 데이터베이스 연결을 너무 오래 잡지 않도록 데이터베이스 사용자에 statement timeout 을 걸었다.
   • 9:58 UTC 에 로드 밸런서에서 트래픽의 90% 에 503 을 보내 부하를 덜고 시스템이 회복할 여유를 만들었다.
   • 10:00 UTC 무렵부터 오래 걸리는 쿼리에 EXPLAIN 을 돌려 보고, 해만 끼치고 필요 없는 인덱스를 지우기 시작했다.
   • 트래픽을 100% 로 되돌리는 동안 Apple 웹훅을 잠시 받지 않았다.
   • New Relic 이 느린 쿼리마다 돌리는 EXPLAIN 쿼리를 없애려고 New Relic 을 끈 새 릴리스를 냈다.
   • 12:00 UTC 무렵부터 가장 큰 테이블들에 손으로 ANALYZE 를 돌렸다.
   • 미리 준비해 둔 스크립트로 영향받은 시퀀스 값을 자동으로 올려 기본 키 중복을 풀었다.
   • 전환 몇 분 뒤 통합 이벤트 발송 작업이 이벤트 테이블을 갱신하지 못하는 것을 잡고 발송 작업을 손으로 멈췄다.
   • 발송되었지만 데이터베이스에 기록되지 않은 웹훅을 만일에 대비해 다시 보냈다.
   • 13:33 UTC 에 통합 이벤트 발송, ETL, 웹 서버 밖의 작업을 모두 되살렸다.

   후속 조치

   • 사업에 중요한 시기에는 변경 동결을 두는 것을 검토한다.
   • 백엔드 장애 때 SDK 가 얼마나 믿을 만하게 동작하는지 더 잘 알린다.
   • 개발자 대시보드와 기술 담당자에게 보내는 직접 이메일을 써서 유지보수와 장애를 고객에게 더 잘 알린다.
   • 사전 연습에서 트래픽 일부를 재생해 전환 당일과 더 비슷한 조건을 만든다. 이번 연습은 쓰기 트래픽을 재생하지 않았다.
   • API 를 빠르고 안정적으로 유지하려고 비용이 큰 작업을 최대한 비동기로 옮기는 데 더 투자한다.
   • 테이블 인덱스를 다시 검토한다. 쓰이지 않는 인덱스가 있고, 데이터베이스가 쿼리에 그 인덱스를 고르면 성능이 떨어질 수 있다.
   • 데이터베이스 대시보드에서 엔드포인트와 시스템별 부하를 더 잘 보여 줘 부하가 어디서 오는지 빨리 찾게 한다. 이번에는 Apple 웹훅 부하가 복구를 막는다는 것을 아는 데 너무 오래 걸렸다.
   • 장애 중에 고객 지원과 고객 커뮤니케이션 담당을 불러 소통을 맡긴다.

   교훈

   RevenueCat 은 처음부터 롤백했으면 더 나았다고 돌아봤다. 사전 연습에서는 데이터 일관성과 쿼리 성능만 보고 쓰기 트래픽을 재생하지 않았다. 쓰기는 인덱스가 얽히지 않아 읽기보다 단순하다고 여겼기 때문이다. 복제를 멈추고 평소처럼 쓰기를 해 봤다면 문제를 찾을 수 있었다. 시퀀스 상태가 복제되지 않는다는 한계를 놓치고 상태도 함께 복제된다고 가정했다. 사전 연습 때는 새 클러스터가 오래 떠 있어 vacuum 과 통계가 이미 끝나 있었기 때문에 ANALYZE 가 없는 문제를 보지 못했다. 시기로는 추수감사절과 블랙 프라이데이 전에 끝내려 했지만, 미국 지원팀 일부가 이미 휴가 중인 민감한 때였으므로 그다음 주로 미뤘어야 했다고 밝혔다.

   사례 보기

원인별5