[Refactor] #267 - 유저 회원가입 이벤트 발행 비동기 처리 #268
Conversation
|
흥미롭네요 .. |
| executor.setMaxPoolSize(4); | ||
| executor.setQueueCapacity(4); | ||
| executor.setKeepAliveSeconds(60); | ||
| executor.setRejectedExecutionHandler(new ThreadPoolExecutor.DiscardPolicy()); |
There was a problem hiding this comment.
q;
여기 부분이 PR에 작성하신 "대기 큐 오버플로우가 발생하면 이벤트를 받지 않고 폐기하도록 정책을 설정하였습니다." 부분인 것 같은데 다른 정책들도 있는데 이 정책을 사용하신 이유가 궁금합니다 !
There was a problem hiding this comment.
@0lynny
a;
ThreadPoolExecutor.AbortPolicy
ThreadPoolExecutor.CallerRunsPolicy
ThreadPoolExecutor.DiscardPolicy
ThreadPoolExecutor.DiscardOldestPolicy
정책에는 4가지가 존재합니다. AbortPolicy가 기본 정책으로 Reject 된 task가 RejectedExecutionException을 던집니다. 이는 예외를 잡아 처리해줘야 하지만, 로그인 알림 자체가 예외를 잡아 처리할 상황은 아니라고 판단하였습니다.
CallerRunsPolicy는 호출한 Thread에서 Reject한 task를 대신 실행합니다. 따라서 이 정책은 비동기로 알림을 보내려고 했던 의도가 사라지고 유저의 회원가입 시간이 증가하게 됩니다.
DiscardPolicy는 Reject된 Task를 버립니다. 하지만 DiscardOldestPolicy는 가장 오래 처리되지 않은 Task를 Reject하기 때문에 순차처리에 문제가 있을수 있어 차라리 늦게 회원가입이 된 유저의 알림이 처리되지 않도록 하는 것이 맞다고 판단하였습니다.
🚀PullRequest🚀
📟 관련 이슈
💻 작업 내용
유저 회원가입 이벤트 발행 로직을 비동기로 처리하도록 변경하였습니다.
비동기는 기본적으로 해당 요청의 반환 결과를 기다리지 않고 다음 실행을 이어나가는 방법을 말합니다. 로그인 특성상 회원가입 이벤트를 Discord에 로깅하는데 로깅하는 데까지 유저가 기다리는 시간이 많을 뿐더러, 이는 유저에게 불필요한 대기시간이므로 비동기로 분리하였습니다.
비동기로 분리했을 떄의 API 수행 시간 차이는 다음과 같이 테스트하였습니다.
[기존 로직을 통해 이벤트를 발행한 경우]
[비동기로 변경된 로직으로 이벤트를 발행한 경우]
위 테스트 결과를 보시면 거의 이벤트의 I/O 시간만큼 유저의 회원가입 시간이 오래 걸린다는 것을 확인할 수 있습니다. 이를 통해 비동기 처리의 효과를 확인할 수 있습니다.
그리고 비동기 처리를 위한 쓰레드 풀을 설정하였는데요.
저희는 EC2 프리티어를 사용하고 있어서 싱글 코어입니다.
싱글 코어인데 쓰레드 풀의 크기를 크게 설정하면 정상적인 처리가 되지 않을 뿐더러, 회원가입 이벤트가 동시다발적으로 많이 발생하지 않을 것입니다. 그래서 쓰레드 풀의 크기를 4로 설정하고 keep-alive 시간도 60초로 설정하여 정상적으로 처리되도록 하였습니다.
또한, 대기 큐 오버플로우가 발생하면 이벤트를 받지 않고 폐기하도록 정책을 설정하였습니다.
잘못된 점 있으면 지적해주시기 바랍니다 감사합니다.
첨언 : 궁금해하실거 같아서 덧붙히자면, @async 어노테이션은 AOP로 동작하기 떄문에 self-invocation(자가 호출) 즉, 같은 클래스 내에서 호출을 못합니다. 따라서 SignUpService로 클래스를 분리하고 빈을 주입받아 호출하도록 하였습니다.
📝 리뷰 노트