perseverance

들어가며1편에서는 Gmail SMTP의 하루 발송량 제한인 500건을 넘지 않기 위해 BCC를 도입하여 발송량 자체를 줄였다. 2편에서는 서킷브레이커 패턴을 활용해 Gmail SMTP의 하루 발송량을 초과하더라도 정상적으로 이메일을 발송할 수 있는 시스템을 구현하였다. 3편에서는 Transactional Outbox 패턴을 적용하여 네트워크 장애, 비동기 스레드 풀 포화, 애플리케이션 종료 상황에서도 최소 1회 이메일 전송을 보장하였다. 이번 편에서는 어떻게 AWS SES의 초당 14건 전송 제한에 맞춰 초당 전송량 초과 예외 없이 이메일을 전송했는지에 관해 작성할 예정이다. 배경서비스 운영 중 다음과 같은 에러가 발생했다.org.springframework.mail.MailSendException: F..

배경 1편에서는 Gmail SMTP의 하루 발송량 제한인 500건을 넘지 않기 위해 BCC를 도입하여 발송량 자체를 줄였다. 2편에서는 서킷브레이커 패턴을 활용해 Gmail SMTP의 하루 발송량을 초과하더라도 정상적으로 이메일을 발송할 수 있는 시스템을 구현하였다. 이번 편에서는 이메일을 최소 한번 보내도록 보장하기 위해 어떻게 구현했는지에 관해 작성할 예정이다. 현재 시스템의 문제점 현재 이메일을 보낼때 JavaMailSender를 통해 비동기로 보내고 있다. 이 구조에서는 이메일이 보내지지 않을 수 있는데 이는 다음 이유때문이다. 이메일을 보낼때 SMTP 서버에게 데이터를 보내야 한다. 이때 네트워크를 타기 때문에 패킷이 유실되거나, 네트워크 지연, 네트워크 다운등의 이유로 데이터를 보내지 못할..

배경 저번 글에서는 Gmail SMTP의 하루 발송량 제한인 500건을 넘지 않기 위해 BCC를 도입하여 발송량 자체를 줄였다. 하지만 BCC 방식은 어디까지나 임시방편일 뿐이다. BCC로 발송량을 조금 줄일 수는 있지만, 500건 제한을 근본적으로 해결하는 방법은 아니기 때문이다. 그래서 실제로 500건을 넘어가는 상황이 발생했을 때 어떻게 처리할지도 함께 고민해야 했다. 이번 글에서는 하루 발송량이 500건을 넘었을 때 어떻게 대처했는지 공유한다.500건이 넘는다면? 하루 발송량이 500건을 초과해 Gmail SMTP 서버로부터 실패 응답을 받게 되면 어떻게 처리해야 할까? 다른 SMTP 서버로 전환해야 할까? 아니면 애초에 하루 발송량 제한이 높은 다른 서비스로 완전히 옮겨야 할까? 결론부터 말하자..

배경 우아한테크코스에서 진행 중인 팀 프로젝트에서는 사용자가 속한 조직에서 이벤트가 주최되면, 알림을 설정한 사용자들에게 이메일을 보내고 있다. 추가로 이벤트 신청 마감 30분 전, 이벤트 시작 하루 전에도 리마인더 이메일을 보내고 있다. 여기서 중요한 점은 이메일을 ‘확실하게’ 보내야 한다는 것이다. 이벤트 리마인더 성격의 서비스다 보니, 이벤트가 열렸다는 이메일을 제때 전달하지 못하면 특히 선착순 이벤트에서는 사용자가 참여하고 싶어도 참여하지 못할 수 있다. 그래서 이 글에서는 어떻게 하면 이메일을 신뢰성 있게 보낼 수 있을지에 대해 정리해보려고 한다. Gmail SMTP 하루 발송량 초과 우리는 처음에 Gmail SMTP만 사용해서 이메일을 보내고 있었다. 사이드 프로젝트에서도 여러 번 써봐서 충분..