현재 개발하고 있는 프로젝트에서 인증을 메일로 처리하는 부분이 있어
JavaMailSender가 아닌 AWS의 SES를 적용해본 일지를 기록한다.
Amazon SES
Amazon Simple Email Service의 줄임말이다.
말 그대로 간단하게 이메일을 전송할 수 있는 서비스이다.
SandBox
처음 SES를 파게 되면 샌드박스 모드로 SES를 시작하며 제한이 걸려있다.
- 24시간 동안 최대 200개의 메세지를 보낼 수 있다.
- 초당 최대 1개의 메세지를 보낼 수 있다.
- 자격 증명이 된 이메일로만 메세지를 보낼 수 있다.
마지막의 자격증명이 된 이메일로만 메일을 전송할 수 있는 점이 굉장히 크리티컬하게 다가왔다.
우리가 메일을 보내려는 목적은 우리 서비스의 인증(Verification)을 위함이었다.
인증 코드를 메일로 보내서 메일을 통해 처리를 하려고 했다.
이럴 경우 지정한 사용자에게 메일을 보내야하는데 AWS에서 자격증명을 우리가 미리 해둘 수는 없는 노릇이다.
누군지도 모르는 사용자의 메일을 전부 증명을 해둘 수가 없다.
고로 이러한 제한조건들을 해제하기 위해 SandBox 모드를 해제해야한다.
영문을 통해 샌드박스 해제 요청을 신청했고 하루만에 승낙이 되어서 샌드박스를 해제하고 사용하고 있다.
SpringBoot - Aws SES 적용
implementation 'com.amazonaws:aws-java-sdk-ses:1.12.429'다음과 같은 의존성을 부여한다.
aws:
ses:
access-key: accesskey
secret-key: secretkey
region: us-west-1
from:
email: example@example.comapplication.yml 파일에 다음과 같이 작성한다.
액세스 키와 시크릿 키는 aws에서 본인에게 부여된 값을 사용하며 region 또한 그렇다.
from은 메일을 보낼 때 사용할 이메일 주소를 사용한다.
내부의 Service 코드로직은 생략한다.
AWS SES 요청 시간 비교
- 동기적으로 요청 시 평균적으로 2초에서 3초가 걸린다.
@Async비동기 요청 시 평균적으로 800ms부터 시작해서 요청할 수록 빨라진다.(할수록 빨라지는 이유는 ses내의 캐싱 처리 효과이지 않을까 예측)- @Async를 걸었을 때 기준 시간 - 약 91.00% 감소
@Async를 걸어주는 이유
Aws SES 로직의 경우 메일을 전송하는 부분은 AWS 내에서 처리되는 부분이다.
AWS 내에서 SES를 처리하도록 우리는 요청만 보낸다.
진행 상황은 AWS에서 처리하기 때문에 저 처리과정동안을 동기적으로 우리가 기다릴 필요는 없다.
고로 우리는 요청을 보내놓고 다음 처리해야할 일을 하면 되기 때문에 비동기를 적용한다.
@Configuration
@EnableAsync
public class AsyncConfig {
@Bean(name = "threadPoolTaskExecutor")
public Executor threadPoolTaskExecutor(){
ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
taskExecutor.setCorePoolSize(50);
taskExecutor.setMaxPoolSize(200);
taskExecutor.setQueueCapacity(100);
return taskExecutor;
}
}- taskExecutor.setCorePoolSize(50);
- 기본적으로 대기중인 Thread 개수: 50개
- taskExecutor.setMaxPoolSize(200);
- 동시에 동작하는 최대 Thread의 개수: 200개
- taskExecutor.setQueueCapacity(100);
- CorePool의 크기(위에서 설정한 50)을 넘어가면 큐에 저장하게 되는데 그 큐의 최대 용량
