사례6건

6건 중 1~5번째

1. IL-0287 Atlas 와 Cloud Manager 의 모니터링을 받치는 내부 데이터베이스 클러스터의 샤드 하나가 과부하되어 지표 수집과 클러스터 작업이 늦어졌다

   MongoDB2025

   증상

   MongoDB Atlas 와 Cloud Manager 에서 지표 수집 파이프라인이 늦어졌고, Atlas 대시보드의 지표가 늦거나 빠졌다. Host Down 알림이 울리지 않았고, 프로비저닝과 크기 조정 같은 Atlas 클러스터 관리 작업이 늦어졌다.

   모니터링 중단데이터베이스 과부하부하 불균형

   촉발

   새 내부 소프트웨어 버전을 롤아웃하는 동안 자원 사용량이 일시적으로 치솟아, 이미 부하가 몰려 있던 샤드의 부하가 예상한 한도를 넘었다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   비효율적인 쿼리여유 용량 부재

   조치

   • 원인을 찾아 바로잡는 조치를 하고 그 효과를 지켜봤다. 그동안 Host Down 알림, 지표, 일부 Atlas 클러스터 작업은 계속 늦거나 빠질 수 있었다.
   • 수정을 적용하고 결과를 지켜봤으며, 이후 장애가 해결됐다.

   후속 조치

   • 부하가 몰리는 컬렉션을 샤딩해 트래픽을 여러 노드에 고르게 나누고 샤드 하나에 몰리는 부하를 던다.
   • 비효율적인 쿼리를 최적화해 자원 사용을 개선하고 평소 작업의 지연을 줄인다.
   • 늘어난 트래픽을 감당하도록 인프라 용량을 더 확보했다.
   • 앞으로의 부하 급증을 미리 내다보도록 용량 계획 절차를 다듬는다.
   • 롤아웃 중 예상할 수 있는 자원 수요 증가를 감안하도록 새 소프트웨어 버전 배포 절차를 다시 설계한다.
   • 엔지니어링 팀이 샤딩 전략과 쿼리 최적화의 성능을 계속 지켜보며 핫스팟이 제대로 풀렸는지 확인한다.
   • 높은 부하 상태를 감지하는 피드백 장치를 넓혀 이상을 더 빨리 찾고 대응한다.

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

   Atlassian2025

   증상

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

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

   촉발

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

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

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

   감지

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

   조치

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

   후속 조치

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

   사례 보기
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-0302 GitHub 의 공용 MySQL 클러스터 mysql1 이 최대 부하 시간대에 연결이 바닥나 쓰기 작업이 네 번 멈췄다

   GitHub2022

   증상

   2022년 3월 16일 14:09 UTC, 최대 부하 시간대에 mysql1 데이터베이스의 부하가 늘면서 데이터베이스 프록시가 최대 연결 수에 닿았다. GitHub 의 모든 쓰기 작업이 동작하지 않았다.

   쓰기 거부데이터베이스 과부하오류율 상승장애 조치 실패

   촉발

   최대 부하 시간대에 공용 MySQL 클러스터 mysql1 의 부하가 늘어 데이터베이스 프록시가 최대 연결 수에 닿았다.

   원인

   용량 한계

   구성 요소

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

   기여 요인

   비효율적인 쿼리피크 시간 변경수동 조치 악화과도한 영향 범위

   조치

   • 정상인 복제본으로 페일오버해 3월 16일 장애에서 복구했다.
   • 3월 17일 미리 한 페일오버 뒤 새 주 노드에 생긴 연결 문제를 풀려고 연결을 재설정했다.
   • 3월 17일 장애 중에 부하 패턴을 찾아 인덱스를 추가해 주된 성능 문제를 고쳤다.
   • 3월 22일 클라이언트 연결이 실패하자 다시 주 노드를 페일오버해 복구했다.
   • 3월 23일 같은 부하 특성으로 클라이언트 연결이 실패하자 다시 주 노드를 페일오버해 복구했다.
   • 3월 23일 부하를 줄이려고 웹훅 트래픽을 제한했다.

   후속 조치

   • 다른 대책을 더 찾는 동안 최대 부하 시간대에 웹훅 트래픽 제한을 계속 써서 같은 장애가 다시 나지 않게 한다.
   • 최대 부하 시간대의 mysql1 부하 패턴을 점검하고, 그 결과에 따라 성능 수정을 차례로 한다.
   • 부하를 줄이고 페일오버 시간을 줄이려고 mysql1 의 트래픽을 다른 데이터베이스로 옮긴다.
   • 변경 관리 절차를 검토한다. 특히 운영 환경에 부하가 높을 때의 모니터링과 변경을 살핀다.
   • 플랫폼 성장에 맞춰 데이터베이스 샤딩과 하드웨어 확장을 비롯한 인프라 확장을 이어 간다.

   사례 보기
5. IL-0212 캐시 적중률이 떨어지며 채널 멤버십 Vitess 키스페이스가 과부하에 빠져 많은 사용자가 Slack 에 접속하지 못했다

   Slack2022

   증상

   2022년 2월 22일 태평양 시간 오전 6시 직후 Slack 에 접속하지 못한다는 사용자 티켓과 내부 사용자의 문제 보고가 들어왔고, 여러 엔지니어링 팀에 호출과 알림이 거의 동시에 왔다. 많은 사용자가 Slack 에 접속하지 못했다. 클라이언트는 부팅 과정에서 채널 목록, 설정, 최근 대화를 서버에서 가져오는데, 부팅하지 못하면 Slack 은 오류 페이지를 보였다.

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

   촉발

   2월 22일 Consul 에이전트 업그레이드를 비율 단위로 롤아웃하는 단계에서 전체 에이전트의 25% 를 차례로 재시작했다. memcached 노드의 에이전트가 재시작될 때마다 캐시 제어 계층인 Mcrib 가 그 노드를 비어 있는 예비 노드로 바꾸거나 다시 들어온 노드를 비웠고, 하루 중 트래픽이 가장 많은 시간에 캐시 적중률이 떨어졌다.

   원인

   용량 한계

   구성 요소

   데이터베이스인메모리 캐시서비스 디스커버리

   기여 요인

   데워진 캐시에 기댄 구조비효율적인 쿼리자동화 증폭재시도 폭주피크 시간 변경

   감지

   태평양 시간 오전 6시 직후 Slack 에 접속하지 못한다는 사용자 티켓, 내부 사용자의 문제 제기, 여러 엔지니어링 팀의 호출과 알림이 거의 동시에 들어왔다.

   조치

   • 대응 초기에 장애를 촉발한 Consul 에이전트 재시작 작업을 멈췄다. 그때는 재시작이 장애와 관련 있다고 의심하지 않았다.
   • 느린 부팅 요청이 데이터베이스 자원을 바닥내 이미 부팅한 사용자의 요청까지 막자 클라이언트 부팅 요청에 엄격한 속도 제한을 걸었다.
   • 처음 제한을 너무 많이 풀어 데이터베이스 부하와 실패한 요청이 다시 늘자 부팅 속도 제한을 다시 낮췄고, 그 뒤로는 작은 폭으로 올렸다.
   • 캐시 미스마다 모든 샤드를 읽던 쿼리를 memcached 에 없는 데이터만 Vitess 에서 읽도록 바꿨다.
   • 그룹 DM 데이터는 바뀌지 않아 조금 오래된 값을 써도 되므로 쿼리가 Vitess 프라이머리뿐 아니라 복제본에서도 읽도록 바꿨다.
   • 캐시가 다시 차고 적중률이 오르자 데이터베이스 처리량을 최대로 유지하면서 클라이언트 부팅 속도 제한을 천천히 정상 트래픽 수준까지 올렸다.

   후속 조치

   • Consul 롤아웃 절차를 바꿔 업그레이드 중에 같은 장애가 다시 촉발되지 않게 했다.
   • 캐시 노드에 짧은 네트워크 단절이 생겨도 같은 연쇄 장애가 나지 않도록 Mcrib 제어 루프의 해당 부분을 바꿔 배포한다.
   • 문제가 된 scatter query 를 채널 기준으로 샤딩한 테이블에서 읽도록 바꿨다.
   • 캐시 계층 뒤에 있는 다른 데이터베이스 쿼리를 분석해 비슷한 위험이 있는 대량 scatter query 가 있는지 찾는다.
   • 장기 프로젝트로 캐시 계층의 복원력을 높이는 다른 방법을 찾는다.

   교훈

   Slack 은 성능 병목, 연쇄 장애, 데워진 캐시에 기대는 구조, 촉발 요인이 된 변경이 장애에서 자주 보이는 패턴이라고 봤다. 이번 장애는 여러 시스템의 경계를 넘는 상호작용이었고 그중 일부 시스템은 최근에 바뀌었다. 큰 소프트웨어 시스템에서 복잡성과 변경은 피할 수 없고, 그만큼 시스템이 예측하지 못한 방식으로 움직일 위험도 커진다. Mcrib 는 틀리거나 비효율적이어서가 아니라 오히려 빠르고 효율적이어서 장애를 키웠다. 빠진 memcached 인스턴스를 더 빨리 찾아 설정을 고치면서 캐시 계층의 교체가 늘었고, 더 나은 구성 요소가 전체 시스템을 덜 안전하게 만들었다. 캐시 노드에 짧은 네트워크 단절이 생겨도 같은 연쇄 장애가 날 수 있다는 위험도 드러났다. 연쇄 장애에 빠진 시스템은 부하를 크게 줄이거나 용량을 늘리는 외부 개입 없이는 안정 상태로 돌아오지 않는다.

   사례 보기

원인별1