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만 사용해서 이메일을 보내고 있었다. 사이드 프로젝트에서도 여러 번 써봐서 충분..

배경현재 프로젝트로 개발중인 snappy라는 서비스에서는 여러 사용자가 촬영한 사진을 다음과 같이 보여주게된다. 현재 각각의 사진들은 사용자가 촬영한 원본 사진 그대로 홈화면에서 사용중이다. 서비스의 특성상 사진을 확인하는 사용자가 많을텐데 이렇게 원본 사진을 그대로 사용자에게 보여주는 것은 네트워크 지연뿐만아니라 네트워크 트래픽도 많아져 aws에 지불해야할 요금이 서비스가 커지면 커질수록 높아질 것이다. 또한 사진뿐만아니라 모임의 logo 이미지 등 원본 이미지의 크기가 필요없는곳에 불필요하게 원본 이미지 크기만큼 다운받고 있어 이또한 문제가 된다.   잘 생각해보면, UI에 맞는 크기의 이미지를 불러오면 원본 이미지를 불러오는 것에 비해 속도도 더 빠르고 네트워크 트래픽도 더 낮아질 것이다.그럼 어떻..

도입저번시간에 작성한 성능 테스트 자동화 환경 구축기(1)에 대한 내용을 정리해 보면, 성능 테스트를 위해 여러 가지 요소들이 필요했다. 우선, 성능 테스트를 위한 대량의 요청을 생성해주는 nGrinder, 서버 상태를 모니터링할 수 있는 PinPoint, 그리고 성능 테스트 대상이 되는 API 서버를 AWS 상에 구축해야 했다. 이를 위해 우리는 Terraform을 활용하여 AWS 자원(EC2, VPC, RDS 등)을 코드로 관리할 수 있도록 설정하였다. 하지만 단순히 AWS 자원을 콘솔이 아닌 코드로 관리할 수 있게 되었다고 해서 성능 테스트 자동화 환경을 구축했다고 말할 수는 없다. 그렇다면, 진정한 의미에서 성능 테스트 자동화 환경을 구축했다고 말하려면 무엇이 더 필요할까?자동화의 필요성성능 테스..

배경서비스를 실제로 사용자에게 공개하기 전에 해야 할 중요한 작업 중 하나는, 내가 만든 서버가 어느 정도의 사용자 유입을 감당할 수 있는지를 파악하는 것이다. 이를 알아낸다면 예상되는 사용자 수를 기준으로 서버를 개선하고, 안정적인 서비스를 제공할 수 있다.나 역시 DND 프로젝트에서 snappy라는 서비스를 개발하면서, 사용자에게 서비스를 공개하기 전에 서버가 어디까지 버틸 수 있는지 확인하고 싶었다. 그래서 성능 테스트를 도입해보았고, 이번 테스트 과정에서 어떤 문제들이 있었는지, 그리고 그 문제들을 어떻게 해결해 나갔는지에 대해 작성해보려 한다.성능 테스트성능 테스트를 하려면 무엇이 필요할까? 우선 가장 먼저 생각나는 것은 내가 만든 서버이다. 서버는 이미 만들어 놓았기 때문에 이 부분은 문제없다..

DND라는 IT 동아리에서 프로젝트를 기획할때 우리가 중요하게 생각한 한가지는 바로 로그인 없이 사용자가 접근할 수 있게 하는거였다. 로그인이 있다면 귀차니즘이 강한 사용자는 바로 나갈게 뻔하다. 나또한 로그인이 있어야 사용할 수 있는 서비스를 보다보면 그냥 나가기 일쑤였다. 하지만 로그인없이 사용자가 했던 행동들을 다 어떻게 기억할 수 있단 말인가? 우리가 개발하기로 한 프로젝트에서는 로그인은 없지만 사용자가 촬영한 사진, 사용자가 참여하고 있는 모임, 사용자가 모임에서 사용하고 있는 닉네임 등을 알고 있어야 했다. 로그인의 주 역할은 해당 요청을 보낸 사용자가 누구인지 알려주는 역할을 한다. HTTP는 상태를 유지하지 않는 프로토콜이라는 것은 네트워크를 배우다 보면 누구나 접하는 개념이다. 그렇기 때..