Incident Library

IL-0387 Mailgun · 2017-01-12database

Mailgun 한 리전의 MongoDB 서버가 연결 증가로 과부하돼 트래킹, API, SMTP, 웹사이트에서 간헐적 타임아웃과 오류가 났다

2017년 1월 12일 14:09 UTC 에 Mailgun 엔지니어들은 한 운영 리전의 클릭·오픈 트래킹 서비스와 주 MongoDB 클러스터에서 울린 알림에 대응하기 시작했다. 10분 안에 대부분의 읽기를 맡는 MongoDB secondary 서버가 높은 부하 때문에 요청을 제때 처리하지 못한다는 것을 확인했고, 트래킹 서비스의 오류도 여기서 왔다. 지표에서 이 서버들로 가는 연결이 서서히 늘고 있었다. 이 증가가 전날 낸 MongoDB 설정 변경 몇 건과 거의 겹쳐, 15:15 UTC 부터 새 pull request 여러 개로 그 변경을 롤백했다.

롤백 과정에서 사람의 실수로 API 와 SMTP 서비스가 secondary 대신 primary 를 쓰게 하는 새 변경이 함께 들어갔다. MongoDB primary 서버는 요청량을 따라가지 못해 불안정해졌고, 15:55 UTC 부터 API, SMTP, 웹사이트의 오류율이 올라갔다. 16:00 부터 19:00 UTC 사이에 MongoDB 서버 크기를 키우고 서버 단의 연결 한도를 넣어, 이 리전 API 가 평소 처리량의 약 75% 를 처리하게 했다. 20:28 UTC 부터 서비스가 primary 에 열 수 있는 연결 수의 한도와 읽기에 secondary 를 우선하는 설정을 다시 배포했고, 20:35 UTC 에 이 리전 서비스가 정상으로 돌아왔다.

사고 뒤 MongoDB 클러스터 로그를 살폈지만 클러스터 전반의 성능 저하만 보였고, 성능 저하나 연결 증가를 일으킨 쿼리는 찾지 못했다. Mailgun 은 이 데이터베이스를 쓰는 서비스마다 둔 연결 한도가 같은 문제를 막을 것이라고 봤다.

심각도
–
영향 범위
Click and open tracking services, then the API, SMTP and website in one production region; the API served about 75% of typical throughput between 16:00 and 19:00 UTC
영향 사용자
–
지역
–
감지까지
–
복구까지
6h 26m

증상

2017년 1월 12일 14:09 UTC 에 한 운영 리전의 클릭·오픈 트래킹 서비스와 주 MongoDB 클러스터에서 알림이 울렸다. 대부분의 읽기를 맡는 MongoDB secondary 서버가 높은 부하 때문에 요청을 제때 처리하지 못했고, 트래킹 서비스의 오류도 여기서 왔다.

지표에서는 secondary 서버로 들어오는 연결 수가 서서히 늘고 있었다. 엔지니어들은 이 연결 증가를 성능 저하의 원인으로 판단했다. 연결이 늘기 시작한 때는 전날 낸 MongoDB 설정 변경 몇 건과 거의 겹쳤다.

15:55 UTC 부터는 API, SMTP, 웹사이트의 오류율이 올라갔다. 롤백 과정에서 API 와 SMTP 서비스가 secondary 대신 primary 를 쓰게 됐고, MongoDB primary 서버가 요청량을 따라가지 못해 불안정해졌다.

상태 페이지에는 08:11 PST 에 Control Panel, API, SMTP, 트래킹 링크의 간헐적 타임아웃을 조사한다는 공지가 올라왔다.

처음에는 전날의 설정 변경을 의심해 15:15 UTC 부터 롤백했다. 그 뒤 MongoDB 서버 크기를 키우고 서버 단의 연결 한도를 넣었지만, 이 리전 API 는 평소 처리량의 약 75% 만 처리했다.

증상 데이터베이스 과부하간헐적 타임아웃오류율 상승

원인

원인 unknown

구성 요소 데이터베이스
기여 요인 수동 조치 악화단일 장애점
촉발
전날 낸 MongoDB 설정 변경 몇 건과 거의 같은 때부터 MongoDB secondary 서버로 들어오는 연결이 서서히 늘었다. 이 변경을 롤백하는 과정에서 사람의 실수로 API 와 SMTP 서비스가 읽기를 primary 로 보내게 됐다.

감지

14:09 UTC 에 클릭·오픈 트래킹 서비스와 주 MongoDB 클러스터의 알림이 울려 엔지니어들이 대응을 시작했다.

조치

후속 조치

교훈

–

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.