사례11건

11건 중 4~8번째

1. IL-0551 Bitbucket Cloud 주 데이터베이스가 과부하로 장애 조치된 뒤 하루 가까이 지연과 간헐 오류가 이어졌다

   Atlassian2025

   증상

   2025년 5월 8일 15시 26분 UTC부터 Bitbucket Cloud 웹사이트와 API의 응답이 느려졌다. 주 데이터베이스가 과부하에 걸려 있었다.

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

   촉발

   Atlassian 내부 서비스가 돌린 대규모 백필 작업이 일부 API 엔드포인트에 과도한 부하를 걸었고, 그 엔드포인트들이 비용이 큰 쿼리를 주 데이터베이스에 대량으로 보냈다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   비효율적인 쿼리재시도 폭주

   감지

   실시간 모니터링이 장애를 바로 감지했다. 상태 페이지에는 15시 41분 UTC에 조사 중이라는 공지가 올라왔다.

   조치

   • 부하가 큰 백필 작업을 멈췄다.
   • 주 데이터베이스가 자동으로 장애 조치됐고, Bitbucket 서비스가 15분 만에 회복했다.
   • 장애 조치 뒤 엔지니어링 팀이 데이터베이스 부하를 더 덜어 내는 여러 방법을 적용해 자원 압박을 줄이고 성능을 끌어올렸다.

   후속 조치

   • 데이터베이스 요청 라우팅을 고쳐, 읽기 요청을 쓰기용 주 데이터베이스 대신 읽기 복제본으로 더 많이 보낸다.
   • 자원을 많이 쓰는 데이터베이스 작업을 하는 내부 API 엔드포인트의 속도 제한을 조정한다.
   • 데이터베이스 쿼리가 더 효율적으로 돌도록 최적화한다.
   • 하위 서비스들의 재시도 정책을 조정한다.

   사례 보기
2. IL-0571 STORES 予約의 스마트리스트 검색 쿼리가 특정 테넌트에서 20분 넘게 DB 프로세스를 붙잡아 504 에러가 급증했다

   STORES2024

   증상

   스마트리스트 프리셋 데이터를 고쳐 쓰는 배치를 20분쯤 돌린 시점에 504 Gateway Timeout 에러가 갑자기 늘었다는 알림이 왔다. 작업은 03:00 UTC 조금 넘어 시작했다.

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

   촉발

   검색 사양 변경에 맞춰 스마트리스트 프리셋 데이터인 初回予約の顧客 와 要フォロー顧客 의 검색 조건을 새 조건으로 고쳐 쓰는 배치를 실행했다. 프리셋 이름은 그대로였지만 검색 파라미터가 달라져 새 검색 쿼리를 타게 됐다.

   원인

   배포 결함

   구성 요소

   데이터베이스

   기여 요인

   비효율적인 쿼리늦게 드러난 변경스테이징 불일치모니터링 사각지대미검증 가정

   감지

   고쳐 쓰기 배치를 시작하고 20분쯤 지나 504 에러가 늘었다는 알림으로 알았다. 작업 중 보던 라이터 인스턴스 지표에는 변화가 없었다.

   후속 조치

   • DB 설계부터 다시 봤고, 이번 글의 인라인 뷰 검색 로직은 더 이상 쓰지 않는다.
   • 이 API의 EXPLAIN을 확인해 훑는 행 수가 예상보다 많지 않은지 검사하는 테스트를 더했다.
   • 해당 로직의 실제 실행 시간을 재기 쉬운 환경을 갖췄다.

   교훈

   실행 계획을 보고 실제 데이터로 동작을 확인해도, 멀티테넌트 환경에서는 테넌트 인덱스만으로 크게 좁혀지는 것처럼 보여 실제로 훑는 양을 놓칠 수 있다. 검증은 양극단만이 아니라 일부만 느린 경우까지 봐야 한다. 작업 중 모니터링하는 대상이 실제 부하가 걸리는 곳인지도 확인해야 한다. 일정을 너무 서두르면 이런 부분이 빠지기 쉽고, 결국 일정이 늦어지고 사용자에게 피해를 준다.

   사례 보기
3. IL-0447 RDS MySQL 인스턴스의 EBS BurstBalance 가 바닥나 IOPS 가 기준 성능으로 묶이고 데이터베이스 성능이 크게 떨어졌다

   every2024

   증상

   RDS 인스턴스의 BurstBalance 가 갑자기 빠르게 줄기 시작해 끝내 바닥났고, 데이터베이스 성능이 크게 떨어졌다. 인스턴스는 MySQL 5.7.44, db.t3.medium, 범용 SSD gp2 30GiB 였다.

   데이터베이스 과부하처리량 저하

   촉발

   복잡한 SELECT 문이 어느 시점부터 갑자기 임시 테이블에 대량으로 쓰기 시작해 WriteIOPS 가 늘었다. 그렇게 바뀐 이유는 아직 조사 중이다.

   원인

   용량 한계

   구성 요소

   데이터베이스클라우드 블록 스토리지

   기여 요인

   비효율적인 쿼리

   후속 조치

   • 문제 쿼리를 튜닝하는 것을 검토한다. 인덱스를 다시 보거나, 서브쿼리를 없애고 JOIN 을 최적화하는 식으로 쿼리를 다시 쓰는 방안이다.
   • gp2 볼륨을 성능 특성을 더 예측하기 쉬운 gp3 로 옮기거나, 스토리지를 늘려 기준 IOPS 를 높이는 것을 검토한다.
   • 임시 테이블의 크기 한도를 정하는 tmp_table_size 와 max_heap_table_size 파라미터를 조정하는 것을 검토한다.
   • 더 성능이 높은 인스턴스 타입으로 옮기는 것을 검토한다.
   • CloudWatch 알림 같은 수단으로 BurstBalance 를 감시하고, Pingdom 같은 외부 모니터링을 두는 것을 검토한다.

   교훈

   RDS 에서 BurstBalance 가 바닥나면 예상하지 못한 성능 저하가 올 수 있다. 복잡한 쿼리는 I/O 에 큰 영향을 주므로, 데이터베이스 설계와 쿼리 최적화를 계속 고쳐 나가고 성능을 정기적으로 감시해야 한다.

   사례 보기
4. IL-0567 쿠키런: 오븐브레이크의 패키지 매출 랭킹 기능을 배포한 뒤 Aurora MySQL CPU가 100%에 이르러 유저가 게임에 접속하지 못했다

   Devsisters2023

   증상

   패키지 매출 랭킹 기능을 배포한 뒤 버그 픽스를 몇 차례 더 배포하고 유저를 재접속시키자 Database 알람이 울렸고, Database CPU 그래프가 100%에서 내려오지 않았다. Database 접속에 문제가 생기면서 유저들이 게임에 정상적으로 접속하거나 플레이할 수 없었다.

   데이터베이스 과부하서비스 중단

   촉발

   새 패키지 매출 랭킹 기능의 집계 쿼리가 들어간 배포 뒤 버그 픽스를 추가로 배포하고 유저를 재접속시키면서, 캐시가 빈 서버들이 이 쿼리를 한꺼번에 실행했다.

   원인

   배포 결함

   구성 요소

   데이터베이스

   기여 요인

   비효율적인 쿼리데워진 캐시에 기댄 구조스테이징 불일치

   감지

   버그 픽스를 추가로 배포하고 유저를 재접속시킨 뒤 Database 알람이 울려 CPU 그래프를 보고 알았다.

   조치

   • 서버 점검을 걸었다.
   • 문제가 된 패키지 매출 랭킹 기능을 켜고 끌 수 있는 설정을 빠르게 추가해 꺼 둔 뒤 서비스를 정상화했다.
   • 판매 시작 시간을 공유하는 상품들의 product_id 조건을 하나로 묶고, 의미가 없는 현재 시각 조건을 지운 쿼리로 바꿔 바로 적용했다.
   • 모든 서버가 함께 쓰는 캐시를 스케줄러 서버에 따로 두었다. 각 서버는 Database 대신 원격 저장소의 결과를 읽고, 요청은 큐에 넣는다. 스케줄러 서버는 주기적으로 마지막 요청으로 쿼리해 결과를 원격 저장소에 캐싱한다. 이렇게 해서 쿼리 실행 횟수를 줄였다.
   • 쿼리 최적화와 캐시 사용 방식 개선을 적용한 뒤 패키지 매출 랭킹 기능을 다시 켰고, CPU가 문제 없이 유지되는 것을 확인했다.

   교훈

   무거운 쿼리와 분산 서버의 캐시 구조가 겹치면 예상하지 못한 문제가 생기므로, 문제가 될 만한 지점을 미리 파악해야 한다. 장애가 나면 원인 파악보다 서비스 정상화가 먼저다. 문제가 되는 기능을 끄고 켤 수 있는 안전장치를 미리 만들어 두면 서비스를 더 안정적으로 운영하는 데 도움이 된다. Production 환경의 online alter에는 Percona Toolkit 같은 유용한 툴을 잘 활용하는 것이 중요하다.

   사례 보기
5. IL-0326 MailPace 의 관리형 Postgres 데이터베이스 디스크가 가득 차 데이터베이스가 두 시간 넘게 내려갔다

   MailPace2023

   증상

   2023-08-11 13:36 BST 에 여러 서비스에서 모든 데이터베이스 트랜잭션이 실패한다는 알림이 들어왔다. 데이터베이스를 다시 시작하려 했지만 공간이 없다며 올라오지 않았다. 메일도 나가지 않았다.

   노드 디스크 가득 참서비스 중단쓰기 거부

   촉발

   13:15 BST 에 cron 인스턴스 메모리를 1gb 에서 8gb 로 늘려 밀려 있던 보존 기간 정리 작업을 돌렸다. destroy_all 이 연결된 레코드까지 한꺼번에 많이 지우면서 데이터베이스 디스크가 빠르게 찼다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   비효율적인 쿼리모니터링 사각지대여유 용량 부재

   감지

   13:00 BST 정기 점검에서 데이터베이스가 평소보다 큰 것을 먼저 봤다. 13:36 에는 여러 서비스에서 모든 데이터베이스 트랜잭션이 실패한다는 알림이 곧바로 들어왔다. 상태 페이지 두 개는 장애를 잡지 못했다. 업스트림 제공자는 저장 공간이 99% 찼을 때 자동으로 알림을 받았다.

   조치

   • Postgres 가 관리형 서비스였으므로 13:37 BST 에 곧바로 업스트림 제공자 지원팀에 연락했다.
   • 13:40 에 Twitter 와 Mastodon 으로 사용자에게 장애를 알렸다. 상태 페이지가 자동으로 바뀔 것으로 생각했지만 바뀌지 않았다.
   • 제공자의 답을 기다리는 동안 13:45 에 전체 장애 복원 절차를 시작해 6시간 전 오프사이트 백업을 새 데이터베이스 인스턴스에 준비했다.
   • 15:50 에 제공자의 이전이 끝나 더 큰 데이터베이스 인스턴스로 옮겨졌고 메일이 다시 나갔다.
   • 백업에서 시험해 고친 쿼리로 운영의 오래된 데이터를 하루 단위로 직접 지웠다. 그동안 메모리, 데이터베이스 크기, 지표를 가까이 지켜봤다.

   후속 조치

   • 매일 도는 정리 작업을 in_batches(of: 50) 로 바꿔 한 번에 50건씩만 지우게 했다. ruby 메모리 요구량과 postgres 부하가 줄었다.
   • 정리 작업을 하루 한 번이 아니라 네 번 돌게 바꿔 한 번 실행의 영향을 줄였다.
   • 성장 여유가 훨씬 많은 더 큰 데이터베이스 인스턴스로 옮겼다.
   • 모든 cron 작업에 cron 모니터링을 적용했다.
   • 상태 페이지가 헬스 체크 엔드포인트 /health 를 보게 바꿨다. 이 엔드포인트는 데이터베이스 접근을 포함해 여러 가지를 확인하고 하나라도 실패하면 500 오류로 응답한다.
   • 자동 장애 조치를 위한 핫 레플리카 데이터베이스를 검토한다.

   교훈

   장애는 여러 원인이 겹쳐 났다. 오래된 데이터를 지우는 cron 작업이 조용히 실패해 데이터가 쌓였다. 이 작업은 평소 하루치 양이었다면 문제없었겠지만 지나치게 단순하게 짜여 있었다. 데이터베이스 요금제는 처음부터 성장 여유가 부족했다. 상태 페이지는 장애를 잡지 못했다. MailPace 는 중요한 서비스마다 제공자를 여럿 두라고 권했다. 또 장애를 감지해 메일을 예비 제공자로 보내는 오픈 소스 아웃바운드 SMTP 프록시 Outgoer 를 만들고 있다고 밝혔다.

   사례 보기

원인별3