사례1건

1건 중 1~1번째

1. IL-0305 Intercom 의 PlanetScale 샤드 하나에서 복제본이 CPU 100% 로 주 데이터베이스를 따라가지 못해 받은편지함에 최대 2.2시간 전의 데이터가 보였다

   Intercom2026

   증상

   2026년 1월 27일 17:25 UTC 에 메시지 백로그가 지나치게 쌓였다는 워커 알람이 울려 장애가 자동으로 선언되었다. 일부 고객의 받은편지함에서 지연이 들쭉날쭉했고 오래된 데이터가 보였다.

   복제 지연데이터베이스 과부하지연 시간 증가

   촉발

   내부 앱 삭제 작업과 ETL 파이프라인이 한 샤드에 겹쳤다. 앱 삭제 작업은 속도 제한 없이 평소보다 많은 삭제 단계를 동시에 돌렸고, ETL 파이프라인은 분석과 보고에 쓸 데이터를 같은 샤드에서 읽고 있었다.

   원인

   용량 한계

   구성 요소

   데이터베이스데이터베이스 복제

   기여 요인

   여유 용량 부재

   감지

   17:25 UTC 에 워커에서 메시지 백로그가 지나치게 쌓였다는 알람이 울렸고, 이 알람으로 장애가 자동으로 선언되었다.

   조치

   • 18:25 UTC 에 영향받은 샤드의 부하를 줄이려고 ETL 처리를 껐다.
   • 21:33 UTC 에 앱 삭제 워커를 0 으로 줄였다.
   • 모니터링에서 지표가 안정된 것을 확인한 뒤 ETL 을 조심스럽게 다시 켰다.

   후속 조치

   • 예상하지 못한 부하 급증에 대비할 여유를 두려고 샤드 용량을 미리 늘렸다.
   • 앱 삭제 작업에 속도 제한과 자원 통제를 넣어 데이터베이스 인프라를 짓누르지 못하게 했다. 이제 워커는 용량 한도를 지키고, 데이터베이스 부하가 높으면 처리 속도를 늦춘다.
   • ETL 과 유지보수 작업 같은 백그라운드 작업이 운영 데이터베이스 용량과 어떻게 얽히는지 검토한다. 이런 작업이 고객이 쓰는 기능과 핵심 자원을 다투지 못하게 하는 것이 목표다.
   • 복제 지연을 더 일찍 잡고 특정 작업과 연결해 볼 수 있도록 알림을 보강한다.
   • 영향 범위가 좁은 장애에서도 영향받은 고객에게 먼저 연락하도록 절차를 고친다. 상태 페이지 전체에 올릴 일이 아니어도 영향받은 고객은 제때 소식을 받게 한다.

   교훈

   Intercom 은 이 장애가 샤딩한 데이터베이스 구조의 가치를 보여 줬다고 밝혔다. 데이터를 서로 독립된 여러 샤드에 나눠 두었기 때문에, 플랫폼 전체의 성능 저하가 될 수 있었던 일이 고객 1% 미만에 그쳤다.

   사례 보기

원인별1