기본 감시 설정이 대량의 이메일을 유발했습니다 - default_watch_categories

3.1.0.beta5 - [09feb03056]


default_watch_categories가 기본값(기억이 맞다면 아무것도 없는 상태)에서 단일 카테고리로 설정된 것으로 보입니다. 아마도 처음 있는 일이었을 것입니다.

이로 인해 대량의 이메일이 발생했으며, 3일 동안 거의 40만 건의 이메일 재시도가 처리되었을 수 있으며, 그중 09% 이상이 실패했습니다. 초기 단계에서 이는 SMTP 제공업체 측의 속도 제한(rate limiting)을 유발했습니다(이것이 예상치 못한 막대한 이메일 비용을 막아주었습니다!).

default_watch_categories 설정은 실수로 설정된 것이므로 기본값으로 재설정되었습니다.

그러나 SMTP 제공업체의 속도 제한이 여전히 적용되고 있었기 때문에, 시스템은 계속 시도하고 실패하면서 sidekiq에 여전히 대량의 이메일 재시도가 표시되었습니다.

자세히 살펴본 결과, default_watch_categories가 기본값으로 재설정되었음에도 불구하고, 하나의 게시물이 계속해서 동일한 이메일을 수백 번, 그리고 수천 번 재시도하며 트리거하는 것으로 보였습니다. 무슨 일이 일어나고 있는 걸까요?

해당 게시물과 그 아래에 있는 다른 게시물들을 일반적 조정(reasons)으로 인해 자체 “새” 주제로 분리하자, 이메일 트리거와 재시도가 완전히 중단되었습니다. 재시도가 더 이상 발생하지 않았습니다.

SMTP 제공업체의 속도 제한 덕분에 정말 다행입니다!

추가 인사이트로, 이 문제는 SMTP 제공업체의 제한 조치로 인해 실패했을 때야말로 감지되었습니다. 대시보드에서 지난 7일, 24시간, 1시간의 이메일 발송 활동을 더 명확하게 보여주고, 이상 징후에 대한 경고를 제공하는 기능이 있으면 좋겠습니다.

이런 문제는 금전적으로 큰 문제를 일으킬 수 있습니다.

제공업체에 속도 제한이 없었다면, 며칠 만에 수년간의 호스팅 비용을 소진했을 수도 있습니다! :crazy_face:

Hey @agemo

인스턴스에서 이 사이트 설정을 확인해 주실 수 있나요?

이것은 사용자를 위한 기본 설정입니다. 사용자는 프로필에서 이 설정을 덮어쓸 수 있습니다:

제가 생각하기에 무슨 일이 일어났을지 추측해 보면:

  1. 기본 설정이 always(항상) 또는 only when away(부재 중에만)로 되어 있었을 것입니다;
  2. 주제가 관찰(watched) 카테고리에서 생성되었습니다. 시스템은 모든 사용자 또는 부재 중 사용자에게만 알림을 보내려 했을 것입니다;
  3. 레이트 리밋(rate limits)으로 인해 충돌한 Sidekiq 작업이 대량으로 큐에 쌓였을 것입니다;
  4. 기본 관찰 카테고리가 삭제되었지만, 이미 큐에 들어간 Sidekiq 작업은 제거되지 않았을 것입니다;
  5. Sidekiq는 실패한 작업을 다시 시도(retry)합니다;
  6. 게시글이 새로운 주제로 이동했을 때, 이전에 잘못 생성된 알림들이 삭제되었을 것입니다;
  7. 알림이 삭제되었을 때, 재시도 중이던 작업들은 이메일을 보내지 않고 성공적으로 완료되었을 것입니다.
3개의 좋아요

default_email_level : 부재 중에만

deafult_email_message_level : 절대

1개의 좋아요