사례3건

3건 중 1~3번째

1. IL-0574 운영 환경의 DB 접속 경로를 Amazon RDS Proxy로 바꾼 지 몇 분 만에 Aurora MySQL writer CPU가 100%에 이르고 에러가 났다

   Safie2026

   증상

   운영 환경의 엔드포인트를 RDS Proxy로 바꾸고 몇 분 뒤 사내 알림 모니터링 시스템에서 에러 알림이 울렸다. Aurora writer의 CPU 사용률은 거의 100%에서 내려오지 않았다.

   데이터베이스 과부하오류율 상승

   촉발

   운영 환경의 Aurora MySQL 접속 엔드포인트를 RDS Proxy로 바꿨다. Proxy는 MaxConnectionsPercent 21%로 Aurora에 커넥션을 약 3,360개만 열 수 있었고, ConnectionBorrowTimeout은 애플리케이션 소켓 타임아웃과 같은 7초였다.

   원인

   설정 변경

   구성 요소

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

   기여 요인

   재시도 폭주스테이징 불일치단계적 배포 부재

   감지

   운영 환경의 엔드포인트를 RDS Proxy로 바꾸고 몇 분 뒤 사내 알림 모니터링 시스템이 에러 알림을 냈다.

   조치

   • 그 자리에서 되돌리기로 하고, RDS Proxy를 보는 애플리케이션 서버인 ECS Fargate 태스크를 이전 버전으로 되돌렸다.

   후속 조치

   • 검증 환경에서 설정 값만으로 장애가 재현되고 해소되는 것을 확인한 뒤 MaxConnectionsPercent를 62%로, MaxIdleConnectionsPercent를 31%로 바꿨다.
   • 애플리케이션 안에서 피처 플래그를 평가해 Aurora 직결과 Proxy 경유 중 어디로 접속할지 요청마다 정하게 했다. 플래그는 ECS 태스크 ID의 해시로 태스크 단위로 나눠 한 태스크 안에서 접속 대상이 섞이지 않게 했다.
   • 트랜잭션 중간에 커넥션이 끊길 때 영향이 큰 쓰기 요청은 뒤로 미루고, 조회용 GET 요청부터 옮긴다.
   • 옮기는 비율은 1%, 10%, 25%, 50%, 75%, 100%로 단계적으로 올린다. 단계마다 Proxy의 대기 시간과 새 백엔드 커넥션 수, Aurora의 커넥션 수와 CPU와 지연, 애플리케이션 에러 수를 보고 다음 단계로 간다.

   교훈

   이번 장애와 이후의 문제는 RDS Proxy의 버그가 아니었고, Proxy를 끼우면서 애플리케이션 커넥션 풀의 구현과 설정에 있던 문제가 드러난 것이었다. Proxy를 끼우면 백엔드 커넥션을 여러 클라이언트가 나눠 쓰므로, 세션 상태가 같은지, 트랜잭션이 닫혔는지, 커넥션이 DB 쪽 수명 안에 있는지가 모두 재사용 조건이 된다. 도입 전에는 Proxy 설정 값보다 애플리케이션 커넥션 풀이 커넥션을 반납할 때 무엇을 실행하는지, 커넥션 수명을 어떻게 정하는지, 접속할 때 무엇을 보내는지를 확인했어야 했다. 타임아웃과 상한은 애플리케이션, Proxy, 데이터베이스 순으로 아래 계층일수록 같거나 길게 맞춘다. 엔드포인트만 바꾸는 한 번의 전환은 실패하면 모든 서비스에 한꺼번에 번지므로 단계적으로 옮겨야 한다.

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

   사례 보기
3. IL-0292 App Engine Memcache 가 글로벌 설정을 읽지 못해 모든 리전에서 1시간 50분 동안 멈췄다

   Google Cloud2017

   증상

   2017-11-06 12:33 US/Pacific 부터 App Engine Memcache 를 모든 리전의 애플리케이션에서 쓸 수 없었다. Google 은 12:34 에 자동 알림을 받았고, 상태 페이지는 Memcache 를 쓰는 모든 프로젝트가 영향을 받는다고 알렸다.

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

   촉발

   설정 업데이트 뒤 애플리케이션과 데이터센터의 매핑 설정을 담은 글로벌 데이터베이스의 엔티티를 읽을 수도 쓸 수도 없게 됐다.

   원인

   설정 변경

   구성 요소

   인메모리 캐시데이터베이스

   기여 요인

   롤백 무효과도한 영향 범위

   감지

   Google 은 장애가 시작된 1분 뒤인 12:34 US/Pacific 에 자동 알림을 받았다.

   조치

   • 14:21 에 데드라인을 충분히 길게 준 업데이트 요청으로 설정을 고쳤다. 데이터베이스의 모든 복제본이 동기화되고 클라이언트가 매핑 설정을 다시 읽을 수 있게 됐다.
   • Memcache 로 보내는 트래픽을 천천히 다시 늘렸고 오류율이 줄어들었다.

   후속 조치

   • 임시 완화로 글로벌 설정을 읽는 쪽의 수를 줄여 쓰기 때 경합이 생기지 않게 한다.
   • 이 설정을 리전 단위로 나눠 비슷한 실패가 번지는 범위를 줄인다.

   사례 보기

원인별1