{"id":"IL-0387","org":"Mailgun","date":"2017-01-12","docs":[],"title":{"en":"Mailgun MongoDB secondaries were overloaded by rising connections, and a rollback then moved reads onto the primary too","ko":"Mailgun 한 리전의 MongoDB 서버가 연결 증가로 과부하돼 트래킹, API, SMTP, 웹사이트에서 간헐적 타임아웃과 오류가 났다"},"domain":["database"],"impact":{"scope":"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","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.mailgun.com/incidents/p9nxxql8g9rh","kind":"official-status","archived":"https://web.archive.org/web/20260125084143/https://status.mailgun.com/incidents/p9nxxql8g9rh"}],"summary":{"en":"The MongoDB secondary servers that handle most of Mailgun's reads in one production region became overloaded as connections to them rose gradually, which also caused the elevated errors in the click and open tracking services. Because the rise coincided with MongoDB configuration changes made the previous day, the team started rolling those changes back at 15:15 UTC through several new pull requests. Through human error, the rollback also moved the API and SMTP services from reading on the secondaries to the primary, and the MongoDB primary could not handle the load, so from 15:55 UTC the API, SMTP and website returned more errors.\n\nBetween 16:00 and 19:00 UTC the team resized the MongoDB servers and added server-level connection limits, which brought the API back to about 75% of normal throughput. At 20:28 UTC the team began deploying limits on how many connections each service could open to the primary, together with a redeploy of the configuration that prefers secondaries for reads, and services returned to normal at 20:35 UTC. The MongoDB logs reviewed afterwards showed a broad loss of cluster performance but no set of queries that explained the rise in connections. The tracking services had run from a single region until then.","ko":"2017년 1월 12일 14:09 UTC 에 Mailgun 엔지니어들은 한 운영 리전의 클릭·오픈 트래킹 서비스와 주 MongoDB 클러스터에서 울린 알림에 대응하기 시작했다. 10분 안에 대부분의 읽기를 맡는 MongoDB secondary 서버가 높은 부하 때문에 요청을 제때 처리하지 못한다는 것을 확인했고, 트래킹 서비스의 오류도 여기서 왔다. 지표에서 이 서버들로 가는 연결이 서서히 늘고 있었다. 이 증가가 전날 낸 MongoDB 설정 변경 몇 건과 거의 겹쳐, 15:15 UTC 부터 새 pull request 여러 개로 그 변경을 롤백했다.\n\n롤백 과정에서 사람의 실수로 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 에 이 리전 서비스가 정상으로 돌아왔다.\n\n사고 뒤 MongoDB 클러스터 로그를 살폈지만 클러스터 전반의 성능 저하만 보였고, 성능 저하나 연결 증가를 일으킨 쿼리는 찾지 못했다. Mailgun 은 이 데이터베이스를 쓰는 서비스마다 둔 연결 한도가 같은 문제를 막을 것이라고 봤다."},"trigger":{"en":"A gradual increase in connections to the MongoDB secondary servers, which coincided with several MongoDB configuration changes made the day before. A rollback of those changes then also introduced, by mistake, a change that moved the API and SMTP services from the secondaries to the primary.","ko":"전날 낸 MongoDB 설정 변경 몇 건과 거의 같은 때부터 MongoDB secondary 서버로 들어오는 연결이 서서히 늘었다. 이 변경을 롤백하는 과정에서 사람의 실수로 API 와 SMTP 서비스가 읽기를 primary 로 보내게 됐다."},"severity":"unknown","symptoms":["database-overloaded","intermittent-timeouts","high-error-rate"],"timeline":{"detected_after":null,"resolved_after":"6h 26m"},"date_kind":"incident","detection":{"en":"Alerts for the click and open tracking services and the primary MongoDB clusters at 14:09 UTC.","ko":"14:09 UTC 에 클릭·오픈 트래킹 서비스와 주 MongoDB 클러스터의 알림이 울려 엔지니어들이 대응을 시작했다."},"components":["database"],"root_cause":"unknown","remediation":[{"text":{"en":"Rolled back the previous day's MongoDB configuration changes through several pull requests from 15:15 UTC","ko":"전날 낸 MongoDB 설정 변경을 15:15 UTC 부터 새 pull request 여러 개로 롤백했다. 이 과정에서 사람의 실수로 API 와 SMTP 서비스의 읽기를 primary 로 옮기는 변경이 함께 들어갔다."}},{"text":{"en":"Resized the MongoDB servers to handle more connections","ko":"더 많은 연결을 감당하도록 MongoDB 서버 크기를 키웠다."}},{"text":{"en":"Deployed connection limits at the MongoDB server level","ko":"근본 원인을 찾는 동안 서버를 안정시키려고 서버 단에 연결 한도를 넣었다. 서버 크기 조정과 함께 이 조치로 이 리전 API 가 평소 처리량의 약 75% 를 처리했다."}},{"text":{"en":"Limited the number of connections the services could open to the MongoDB primary","ko":"20:28 UTC 부터 서비스가 MongoDB primary 서버에 열 수 있는 연결 수에 한도를 두는 변경을 배포했다."}},{"text":{"en":"Redeployed the configuration that makes services prefer secondary servers for reads","ko":"읽기에 secondary 서버를 우선하는 설정을 다시 배포했다. 20:35 UTC 에 이 리전 서비스가 정상으로 돌아왔다."}}],"action_items":[{"text":{"en":"Run the tracking infrastructure across two independent regions","ko":"그동안 한 리전에서만 돌던 트래킹 인프라를 독립된 두 리전에서 운영한다."}},{"text":{"en":"Limit the number of connections every service can open to the database","ko":"이 데이터베이스를 쓰는 모든 서비스에 열 수 있는 연결 수의 한도를 둬서, 서비스 하나가 다른 서비스에 주는 피해를 줄인다."}},{"text":{"en":"Permanently increase the size of the primary Mongo cluster and roll the change out to the other data centers","ko":"주 MongoDB 클러스터 크기를 영구히 키우고, 같은 변경을 다른 데이터센터에도 적용한다."}},{"text":{"en":"Let click redirection keep working when downstream services fail","ko":"하위 서비스가 실패해도 클릭 리디렉션은 제대로 동작하도록 트래킹 서비스를 고친다."}}],"contributing":["manual-action-worsened","single-point-of-failure"],"recurrence_of":null,"symptoms_text":{"en":"On 12 January 2017 at 14:09 UTC, Mailgun engineers began responding to alerts for the click and open tracking services and the primary MongoDB clusters in one production region. Within ten minutes the engineers found that the MongoDB secondary servers, which serve most reads, were under heavy load and slow to answer, which also caused the tracking errors. The status page reported intermittent timeouts on the Control Panel, API, SMTP and tracking links.\n\nMetrics showed a gradual rise in connections to the secondary servers. From 15:55 UTC, after a rollback, the API, SMTP and website had elevated error rates because the MongoDB primary could not keep up with the requests and became unstable. Between 16:00 and 19:00 UTC the API in this region served about 75% of its typical request throughput.","ko":"2017년 1월 12일 14:09 UTC 에 한 운영 리전의 클릭·오픈 트래킹 서비스와 주 MongoDB 클러스터에서 알림이 울렸다. 대부분의 읽기를 맡는 MongoDB secondary 서버가 높은 부하 때문에 요청을 제때 처리하지 못했고, 트래킹 서비스의 오류도 여기서 왔다.\n\n지표에서는 secondary 서버로 들어오는 연결 수가 서서히 늘고 있었다. 엔지니어들은 이 연결 증가를 성능 저하의 원인으로 판단했다. 연결이 늘기 시작한 때는 전날 낸 MongoDB 설정 변경 몇 건과 거의 겹쳤다.\n\n15:55 UTC 부터는 API, SMTP, 웹사이트의 오류율이 올라갔다. 롤백 과정에서 API 와 SMTP 서비스가 secondary 대신 primary 를 쓰게 됐고, MongoDB primary 서버가 요청량을 따라가지 못해 불안정해졌다.\n\n상태 페이지에는 08:11 PST 에 Control Panel, API, SMTP, 트래킹 링크의 간헐적 타임아웃을 조사한다는 공지가 올라왔다.\n\n처음에는 전날의 설정 변경을 의심해 15:15 UTC 부터 롤백했다. 그 뒤 MongoDB 서버 크기를 키우고 서버 단의 연결 한도를 넣었지만, 이 리전 API 는 평소 처리량의 약 75% 만 처리했다."},"updated_at":"2026-11-14T12:34:03.831666Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0387","org_slug":"mailgun"}