목록TIL (68)
개발지식 먹는 하마 님의 블로그
문제 발견!스터디에서 CS25 서비스 기반으로 CS 공부를 하는 도중 오류를 발견하였다!서술형 문제 풀이 과정에서 분명히 정답이라는 결과가 나왔으나,해당 문제가 틀린 문제 다시 보기 페이지에서 보인 것이다.맞았는데 왜 틀린 문제에서 조회되는 거지?원인 파악AI가 정답을 채점할 때 우리는 분명 "정답"으로 시작해라고 프롬프트에 확실히 명시하였다.그에 따라 AI가 사용자의 답안을 정답으로 판단했는지에 대한 여부를 아래의 코드처럼 확인한 것이다.boolean isCorrect = feedback.startsWith("정답"); 그런데 일부 피드백이 "- 정답 : " 형태로 구성되는 것을 확인하였다.앞에 "-"와 공백이 붙으니 위의 코드를 기반으로 정답 여부를 판별할 때,정답으로 시작하지 않으니 오답으로 판별한..

내일부터 프로젝트 고도화 작업을 시작하고자 한다.가장 먼저 수정할 부분으로 이메일 발송 방식을 디자인 패턴 기반으로 쉽게 변경할 수 있도록 바꾼 부분을 선정하고자 하였다.그 당시에도 튜터님들의 의견이 서로 다르셔서 약간 애매했던 부분이 있는데 바로,해당 구조를 전략 패턴과 팩토리 메서드 패턴 중 무엇으로 불러야 할 지에 대한 것이었다.메일 발송 방식 변경 구조메일 발송 방식을 변경하는 구조는 다음과 같다.메일 발송 시, 사용하는 서버가 달라지더라도 공통으로 실행되어야 하는 행위들이 있다.메일 내용 구성 + 메일 발송 요청 -> sendQuizMailRateLimiter 적용먼저, 위와 같은 공통된 기능을 상위 객체 인터페이스로 추상화하였다. = MailSenderStrategy그 후, MailSender..

트러블 슈팅 - 일부 메일 발송 실패100개의 메일 발송에 대해 비동기로 테스트 했을 때,100개 중 일부인 5개의 메일에 대해서 발송이 실패하는 현상이 발생하였다.(이럴 때 쓰라고 있는게 메일 로그지!)실패 원인을 파악하기 위해 저장된 메일 로그를 확인하였다. 아니 AccessKey랑 SecretKey도 잘 입력되어있고, 그래서 다른 95개의 메일은 잘 발송되었는데어째서 저 5개만 Authentication failed라는 예외가 발생한단 말인가?!Authentication failed 예외 발생 원인원인은 사용 중인 외부 메일 서버의 스로틀(Throttle) 정책에 의해 발생한 것이었다.💡 Throttle이란?이벤트 핸들러가 너무 자주 실행되지 않도록 조절하는 기법이다.서버에 과도한 요청이 몰리는 ..

MVP 개발로 인해 구조 개선이 필요했던 부분에 대한 리팩토링을 마쳤으니이제 이전에 측정했던 성능 테스트 결과를 기반으로 개선을 해야 했다.이전 테스트에서 이메일 발송 요청에서 병목 현상이 발생하였다.https://devhippo.tistory.com/126 [내일배움캠프 76일차] 문제 풀이 링크 발송 테스트MVP 방식 기반 1차 개발 완료MVP 기반으로 진행되는 프로젝트 개발 일정에 따라,이메일 발송 기능에 대한 초기 구현을 마쳤다.이제는 여러 부분을 테스트해 본 후, 성능 개선을 목적으로 2차 개발devhippo.tistory.com 따라서, 이메일 발송 처리에 단계에서 비동기를 적용하는 작업이 필요하였다.💡비동기 처리 도입ThreadPoolExecutor 설정 및 적용ThreadPoolExecu..

프로젝트 중 맡은 부분을 비롯해서 연관된 흐름을 한 번 점검하면서개선이 필요한 점을 찾아 리팩토링 하였다. 1. JOB 분리하기역할 분리추후 확장성배포 시, 유연한 실행기존에는 1개의 Job에서 producer, consumer를 모두 수행하고 있었다.위와 같은 부분을 고려하여 mailProducerJob, mailConsumerJob, mailRetryJob 이렇게 3개의 Job으로 분리하였다. 2. 데이터 정합성 보장큐에 들어간 데이터에 대해서, 큐에서 빼서 쓸 때 해당 발송이 여전히 유효한지에 대한데이터 정합성을 보장하기 위한 로직을 추가해주어야 했다.발송이 유효하지 않게 되는 상황큐에 들어간 데이터가 꺼내져서 실제 발송되기 전에유저가 받고 싶은 문제의 카테고리가 변경되는 경우메일 발송 요일이 변경..

MVP 방식 기반 1차 개발 완료MVP 기반으로 진행되는 프로젝트 개발 일정에 따라,이메일 발송 기능에 대한 초기 구현을 마쳤다.이제는 여러 부분을 테스트해 본 후, 성능 개선을 목적으로 2차 개발을 진행해야 하였다.실제 개선에 앞서 현재 어디서 병목 현상이 발생하고, 원인은 무엇이며 어떻게 개선하면 좋을지 확인하기 위해 테스트를 진행하였다. 💡 잘 동작하는가? 문제 출제부터 이메일 발송까지 프로젝트의 일부 흐름을 테스트하기 위해부분 통합 테스트로 테스트 코드를 작성하였다.@TestConfigurationpublic class TestMailConfig { @Bean public JavaMailSender mailSender() { JavaMailSender mockSender..

MessageQueue란?메시지 지향 미들웨어로 임시로 데이터를 저장하는 큐 형태의 버퍼 역할을 한다.프로세스 또는 프로그램 간에 데이터를 교환할 때 사용하는 통신 방법이다.Queue에 데이터를 입력하는 주체를 Producer, 소비하는 주체를 Consumer라고 한다. 메일 발송에 MessageQueue를 도입해야 하는 이유지난 글에서 잠시 언급했던 것에 이어서 좀 더 설명을 보충하고자 한다.💡프로젝트에 적합하다.Message Queue는 바로 처리되지 않더라도 언젠가 처리되어야 할 작업들에 적용할 수 있다.문제풀이 링크 메일 발송은 정해진 시간에 딱 맞춰 빠르게 보내지는 것보다는 몇 분 늦더라도 정확하게 도착하는 것이 중요하기 때문에 적합하다고 판단하였다. 💡신뢰도 보완현재까지 구현된 알고리즘은 ..

인증코드 발송 구현을 마쳤으니 이제 프로젝트 구독자에게 발송할 문제풀이 링크를 구현해야 했다.프로젝트 기획 기반 문제풀이 링크 설정CS25 프로젝트와 다른 프로젝트의 차별점은 회원가입을 좋아하지 않는 유저들의 접근성을 위해로그인을 하지 않아도 문제를 풀 수 있도록 했다는 것이다.대신 로그인한 유저에게는 마이페이지 기반 취약점 분석 등의 부가 기능을 제공한다.따라서, 사용자 정보는 비로그인 유저와 로그인 유저 모두를 관리하는 Subscription과로그인 유저를 관리하는 User 두 개의 테이블로 관리한다.비로그인 유저 식별하기위와 같은 기획대로 로그인하지 않은 유저가 메일로 받은 문제풀이 링크를 통해문제풀이 페이지에 접근하여 문제를 푼 기록을 남길 때, 어떤 사람이 풀었는지를 어떻게 식별할 것인가?를 구..

Spring에서 이메일 발송하기이메일 발송을 구현하기에 앞서 관련된 원리를 먼저 알아보았다. 📨이메일 프로토콜 이메일과 관련된 프로토콜에는 3가지가 있다.그중 POP3와 IMAP 메일 수신용이고 SMTP는 발신용 프로토콜이다. ✅ SMTP 프로토콜 기반 메일 시스템Mail User Agent (MUA) : 이메일을 작성하거나 열람하는 클라이언트 Mail Transfer Agent (MTA) : MUA로부터 메일을 전달받아서 외부로 전달, 받은 메일을 MDA로 메일을 전달 Mail Delivery Agent (MDA) : 사용자의 메일함에 메일을 저장이메일이 발송되는 과정은 다음과 같다.MUA에서 메일을 작성하고 발송 요청을 보내면 이를 MTA가 실제로 발송한다.발송된 메일은 메일을 받는 사람이 사용하는..
인증 코드를 어떤 DB에서 관리할 것인가이메일로 인증 코드를 발급하는 기능을 구현하기 전, 인증 코드를 어떤 DB에서 관리할 것인가에 대한 설계 과정이 필요하였다.인증 코드는 휘발되어도 괜찮은 데이터인가?개인적으로 인증 코드가 너무 자주 휘발되는 것은 당연히 프로그램의 신뢰성을 떨어뜨릴 것이다.그러나, 인증코드는 어차피 짧은 시간 동안만 유효하고혹여 서버 오류로 발급된 코드가 누락되더라도 다시 발급받으면 되는 데이터라고 생각했다.따라서, 인증코드를 휘발되어도 괜찮은 데이터라고 판단하였다.로컬 캐시 Vs 글로벌 캐시인증코드가 휘발되어도 괜찮다는 판단을 내린 후 무엇으로 이를 관리할지 고민을 했을 때, Redis를 생각하였다.인메모리 기반으로 인증코드를 빠르게 조회할 수 있다.TTL 기능으로 만료 키 삭제에..