회사 서비스중 이메일 전송하는 기능이 작동하지 않는다는 연락을 받았다.
(모니터링 시스템 고도화가 아직 진행중이라 일일히 확인해야하는 부분이 많다.)
AWS SES에 메일을 보내려고 했으나 메일이 전송되지 않는다는 연락이었다.
Error executing "SendRawEmail" on "https://email.us-west-2.amazonaws.com"; AWS HTTP error: Client error: `POST https://email.us-west-2.amazonaws.com` resulted in a `400 Bad Request` response:
얼른 AWS 콘솔에 들어가 확인해보니, SES 서비스가 pause되어 있었다. 반송률(Bounce rate)가 30%가 넘었고 해당 서비스 계정은 pause라고 빨갛게 표시가 되어 있었다.
먼저, pause된 이유를 찾아보았다. 당연히 반송률이 기준치이상 발생한 게 문제였다.
여기서 장애조치를 위해 해야 할 일을 목록화 했다.
1. 근본원인은 무엇인가(root cause)
2. pause를 해결하는 방법은 무엇인가?
3. pause를 해결할 수 없다면 대체할 수단은 무엇인가?
4. 장애가 재발생하지 않게 하기 위한 방법은 무엇인가?
(해당 내용은 단순히 시간 순서대로 기술하였고, 작업 우선순위가 잘못된 부분도 있을 수 있습니다.)
가장 먼저 한 작업은 pause를 해결하는 방법을 찾아보았고 support case를 올리는 방법이었다.
support case에는 이미 생성되어 있었다?
반송률은 이미 12월 10일에 문제가 발생했고, 70일 이상 방치가 된 상태였다. (사실 여태까지 문제가 없었던 게 신기할정도)
주변에 수소문해보니 SES pause는 거의 풀어주지 않거나 3-4주 정도 걸릴 수 있다는 경험을 들었다.
2월 19일에는 (장애가 최초로 발생한 지점) SES 서비스에 대한 문제를 해결하라는 메일이 추가로 왔다.
이때 발견했다면 장애가 더 크게 전파되지 않았을텐데 아쉬움이 있다.
어쨋든 ses 서비스가 pause된 이유를 알았고, 당장 해결하기 어렵다는 생각에 네이버 클라우드 서비스 중 하나인 cloud outbound mailer를 사용해 1시간 만에 대체할 email 서비스를 테스트완료했다.
이후 메일 전송은 다른 서비스로 대체했지만 문제는 기존 SES에 맞는 코드와 로직이 상당할텐데 어떤 다른 이슈가 발생할지 몰라 SES 서비스를 정상화 하기위해 노력했다.
1. SES 서비스에 대한 장애조치 및 호소문 작성
ses pause를 풀기 위해 SES 팀에서 요청한 내용은 다음과 같았다.
-- What did you determine was the root cause of your high bounce rate?
-- What changes have you made to your systems or processes?
Only include information about changes you have already implemented, not those that you plan to implement in the future.
-- How will these changes prevent similar issues from occurring in the future?
정말 단어 하나하나 조심스럽게 작성해서 회신을 했더니 모두의 예상과 다르게 24시간이 채 지나지 않아 SES 서비스의 pause가 해지되었다. (내용은 미포함)
2. 반송이 발생했던 근본 원인 찾기
- 반송이 발생했던 근본원인은 백엔드 로직에서 퇴사자들에 대해 ses로 메일을 전송했던게 발견되었다. 이후 백엔드 로직에서 해당 메일 전송 로직을 제거하였다.
- 메일 발송시 발송 응답을 모두 기록하고, 반송시 반송 코드를 확인하고 dynamoDB 테이블에 기록한다. 메일 발송시 dynamoDB 테이블에서 등록된 사용자인지 먼저 확인하는 로직을 추가했다.
3. 알람을 받지 못했던 이유
- 해당 aws 루트 계정에 오는 메일을 확인할 수 없었다.
하지만, aws 콘솔에서 alternative contact 를 사용하여 루트 계정이 아니더라도 연락 이메일을 등록할 수 있는 수단을 활용해서 엔지니어 팀의 그룹 계정을 등록하여 support 관련 메일을 언제든지 받을 수 있도록 설정하였다.
후기
회사에서 쓰는 aws는 모두 점검해보고 비용, 사용량, 메트릭이 정상적인지 혹은 주기적으로 알림을 체크해야하는지 다시 한 번 알게 되었다.
'AWS' 카테고리의 다른 글
Provisioned Concurrency에 대한 고찰 (0) | 2024.08.31 |
---|---|
JIRA에서 IAM 권한 요청 관리하기 (0) | 2024.02.12 |
IAM 서비스 알고 쓰자 - 1 (0) | 2023.09.28 |
EC2에서 로그 확인 (0) | 2023.08.31 |
AWS CodeWhisperer를 활용하기 (0) | 2023.04.18 |