Abiding by Amazon SES's "14 emails per second" maximum send rate에서 이어지는 토론입니다:
10만 건당 20달러인 관대한 Emailit 요금제로 SMTP 릴레이를 전환하는 것을 고려해 왔습니다. 하지만 최근 초당 2통의 속도 제한을 설정했습니다.
다이제스트와 이메일의 속도 제한/스로틀링에 대해 질문하는 주제들을 살펴보니, 이용 가능한 설정은 DISCOURSE_MAX_DIGESTS_ENQUEUED_PER_30_MINS_PER_SITE인 것 같습니다.
해당 값이 초당 X통의 속도로 정확히 분배된다고 가정해야 하는지 모르겠습니다.
그리고 다이제스트에만 해당됩니다. 첫 게시물 시청 시 발송되는 대량 이메일과 같은 다른 급증 상황도 고려해야 합니다.
현재 가지고 있는 정보로는 속도 제한이 있는 SMTP 서비스를 사용하는 것이 현실적이지 않다고 느껴집니다. 제가 놓친 안심할 수 있는 부분이 있을까요?
테드, 이 주제에 대해 관심을 보이는 사람이 없었다니 안타깝네요. 혹시 해결하셨나요?
Discourse가 속도 제한(rate limit)에 도달했을 때 어떻게 처리하는지에 대한 정보가 부족하여, Emailit으로의 전환을 보류하고 있습니다. 하지만 Don의 Emailit 전환 결과가 어떻게 될지 알고 싶습니다.
답은 아닙니다.
다이제스트를 큐에 추가하는 작업은 30분마다 실행되며, 이 설정은 단순히 큐에 max_digests_enqueued_per_30_mins_per_site라는 최대 수를 넣는 역할만 합니다. 큐가 처리되는 속도를 제어하지는 않습니다.
참고로 최근 emailit에 대한 부정적인 리뷰가 trustpilot과 appsumo 모두에서 꽤 많이 보입니다.
정보 주셔서 감사합니다, 리처드! 초당 제한이 있는 릴레이는 피하는 게 좋겠네요.
(이곳에서 성공 사례를 보고한 사람들이 있으니, 10,000통당 2.50달러인 조호의 Zeptomail을 살펴볼 수도 있겠어요.)
제가 이 상황을 다뤄야 한다면, 메일을 큐에 담아 두는 로컬 postfix 인스턴스로 전달하여 복잡성을 처리할 것입니다.
이 인스턴스는 메일을 직접 전달하거나(직접 전달을 먼저 시도하고 실패 시 폴백하도록 설정할 것입니다) 하나 이상의 유료 아웃바운드 서비스를 통해 전달할 수 있습니다.
아웃바운드 전송 속도도 관리할 수 있습니다: Postfix Configuration Parameters
이 방식은 서버의 부담을 줄여 줍니다. 상대적으로 비용이 많이 드는 이메일 생성 작업이 반복적으로(레이트 리미팅이 발생하는 경우) 수행되지 않고 한 번만 수행되기 때문입니다.