Email Receivers 리팩토링

[ekgns33]

AS

• 우선 기능이 잘 작동하고 있습니다.
• 현재 Task에 대해 N명의 수신자가 존재하는데, 이는 @ElementCollection. 즉, 값 컬렉션을 사용중입니다.
• 개발 당시 모든 task는 all or nothing으로 하나라도 실패하면 fail로 간주하기 때문에 각 Receivers에 대해 상태를 추적하지 않았습니다.

제안

• 코드를 다시 살펴보던 도중, 사용자 경험을 떠올렸는데요.

현재 로직에서는 어떤 사용자는 메일을 수신받고 나머지 1명이 실패하면 N명 전체를 다시 보내야합니다. 운영진 입장에서는 편하지만 수신자입장에서는
중복 메일이 두번 날라오게됩니다.

• 따라서 각 수신자에 대한 발송여부를 상태로 갖게하는 엔티티로 승격시키는 것을 제안합니다.

EmailTask -< EmailReceiver
- id
- task_id
- is_sent
- email

고려할점

• DB 스키마의 변경이 있는 작업이라 매우 고민이 됩니다.
  • 변경한다면 기존의 Task 테이블은 변경없이 EmailReceivers 테이블만 수정될 것 같습니다.
• 프로젝트 초기에 너무 단정지었다고 생각합니다 ㅠ 더 데이터가 쌓이기전에 바꾼다면 빠르게 바꾸는게 어떨까 생각이듭니당

[ekgns33]

@goldentrash 한번 확인해주세요~

[goldentrash]

좋은 생각입니다! 다만, 몇 가지 궁금한 점이 있습니다.

1. 현재의 테이블 구조를 변경하지 않고, 전송 완료된 수신자에 대해 기록해둔다면 동일한 처리가 가능하지 않을까요?
   • 이벤트 기반의 failsafe 시스템 구축도 가능할 것 같습니다. 흔한 지수법처럼요?
2. 현재와 같은 구조를 생각하게 된 계기는, 이메일 전송 작업 중간에 프로그램의 얘기치 못한 다운을 의식하였기 때문인 것으로 이해했습니다. 그러한 경우에서 제안하신 구조를 도입하더라도, EmailReceiver 정보를 갱신하지 못하면 결국 동일한 문제가 발생하지 않을까요?
   • 물론, 이메일 전송 중 외부 API에 오류 발생한 경우에 경우에는 확실히 개선된 사용자 경험을 제공할 수 있을 것이라고 기대합니다!

[ekgns33]

현재의 테이블 구조를 변경하지 않고, 전송 완료된 수신자에 대해 기록해둔다면 동일한 처리가 가능하지 않을까요?

새로운 테이블을 추가하는 방법을 말씀하시는걸까요? 이미 Receivers테이블이 존재하기에 바꾸려했어요. JPA와 다르게 테이블은 컬럼하나만 추가하게 될것같아서요.

현재와 같은 구조를 생각하게 된 계기는, 이메일 전송 작업 중간에 프로그램의 얘기치 못한 다운을 의식하였기 때문인 것으로 이해했습니다. 그러한 경우에서 제안하신 구조를 도입하더라도, EmailReceiver 정보를 갱신하지 못하면 결국 동일한 문제가 발생하지 않을까요?
물론, 이메일 전송 중 외부 API에 오류 발생한 경우에 경우에는 확실히 개선된 사용자 경험을 제공할 수 있을 것이라고 기대합니다!

1. 현재 구조는 전체 이메일을 보내고 트랜잭션이 해제됩니다. << 트랜잭션 시간이 엄청 길죠.. 저희 트래픽에서는 문제가 아니지만 그래도 좋은 방향은 아니라고 생각합니다. 이를 해결하는게 1순위 목표이구요

2. 말씀해주신 동일한 문제는 트랜잭션을 쪼개서 매우짧게 가져가고 Graceful Shutdown도 넣어서 대비하려합니다. JVM이 죽는경우는 거의 없으니까요. 서버 자체가 죽는다면 그건 크나큰 아픔이지만.. 1번이 해결되면 트랜잭션이 외부 API 와 쪼개지기에 대비하기 편할것같습니다. 또한 상태를 3가지로 나누면 처리하기 쉬울 것 같아요.

PRESEND, SENDING, SENT 로 3가지 상태를 두고, SMTP를 쏘기전에 SENDING으로 짧은 트랜잭션을 치고 request가 성공적이면 SENT로 2번째 트랜잭션으로 업데이트를 하는거죠. 해당 방안에서는 request를 쏘는동안 죽으면 SENDING으로 UPDATE된 시간이 10분이상이라면 비정상으로 판단해 재 전송하는 로직을 작성할 수 있을 것 같아요. 보상 트랜잭션으로 다시 취소할 수도 있구요.

등록 -> PRESEND -> 전송시작 -> SENDING -> 외부 SMTP -> 성공 -> SENT

• 구현 할 것

상태 추적, 데이터베이스 폴링(DEAD Letter감지 및 메모리에 로드), Graceful Shutdown

[goldentrash]

해당 방안에서는 request를 쏘는동안 죽으면 SENDING으로 UPDATE된 시간이 10분이상이라면 비정상으로 판단해 재 전송하는 로직을 작성할 수 있을 것 같아요.

이거 흥미롭네요. 일종의 SAGA를 생각하시는걸까요?

새로운 테이블을 추가하는 방법을 말씀하시는걸까요?

아 저는 이제 In-memory로 바로 retry하는걸 생각했어요. 중간에 서버가 죽는 경우에는 말씀하신것처럼 DB까지 영속한 후 상태를 불러와야하겠지만, 그렇게 하기보다는 그냥 이벤트를 발행하고 성공할때까지 다시 쏘면 되지 않을까 싶었네요. 그런데 위 로직(SENDING)이 너무 흥미로워 보여서 찬성입니다 ㅋㅅㅋ

[ekgns33]

넵 설계해보고 올려보겠습니다