Today I Learned
날짜
2024년 1월 16일 화요일
내용
다행히 Task들이 얼추 마무리 되었다. 얼추인 이유는 실서버에서도 잘 되나 확인해야 하니까..
DKIM이 없는 이유
DMARC 설정을 위해 SPF와 DKIM을 적용했었다. 이메일을 받으면 원본에서 header를 확인할 수 있다.
이것처럼 DKIM은 흔적도 없다. DMARC는 둘 중 하나만 통과하면 되기 때문에 기능에 이상은 없으나 분명 설정한게 나타나지 않으니 찝찝해서 그냥 지나칠 수 없었다.
고민의 흐름은 다음과 같았다.
- 이 인증의 핵심은 alph.kr 이라는 도메인에서 온 메일은 안전하다는 증거다.
- alph.kr은 AWS의 Route53에서 라우팅한다.
- 나는 테스트를 위해 info@alph.kr의 daum 메일로 보내고 있다. 목적지는 gmail
- 이 DMARC는 누가 어떻게 확인하는가?
우선 이 고민에 대한 답을 얻었다
- DAUM에서 Gmail로 메일을 보내면 검증은 Gmail에서 처리한다.
- Gmail은 도메인의 DNS 레코드에서 SPF 정보를 조회하고 거기에 Daum이 있는지 확인한다.
- 있다면 SPF는 검증된 것
- Gamil은 이메일 헤더에 DKIM-Signature 가 있는지 확인한다.
- 애초에 이건 Daum에서 담아 보냈어야 했다.
AWS SES에서 설정했으니 DKIM은 SES에서만 보낼 수 있는 것 아닌가 싶어 SES로 테스트해봤다.
이제 DKIM 걱정은 없겠다.
ECS Task와 구글 스프레드시트
cron에 구글스프레드 시트에 데이터를 전송하는 Task를 등록했다. shop과 review쪽 서버 둘다에. review쪽만 이상하게 환경변수를 못 찾고 있었다.
여러가지로 종합된 문제가 있었는데
- 스크립트를 실행하는 명령문에 오타가 있었다.
- Task를 예약할 떄 사용한 VPC가 다른 것이었다.
두 가지를 해결하니 잘 작동했다. 날짜가 들어가야할 데이터가 숫자로 표시되는 문제가 있었지만, 구글 스프레드 시트에서 서식을 날짜로 바꿔주니 해결됐다.
아직도 어떤 Task가 가끔 환경변수를 못찾아 종료되긴 하지만 전체적으로 기능에는 이상이 없다. 도대체 왜저럴까 싶어 Cloudwatch에서 CPU랑 메모리 사용률도 보고 다 뒤져봤지만 로그 상 이상은 없는데..
UTC
Universal Time Coordinate. 협정 세계시다. 지역마다 시차가 있으니 전 세계에서 기준으로 삼는 표준 시간. 기준은 런던이다. 그리니치 천문대가 있어서 그런가.. 어쩄든.
전세계에 있는 고객들이 매주 월요일 아침 8시 30분에서 9시 30분 사이에 메일을 받길 원했다. 따라서 cron을 매주 월요일 0시부터 24시 까지 1시간 간격으로 설정해주었다. 문득, 이게 맞나 싶어 확인해봤더니 역시 잘못됐다.
우리나라는 UTC보다 9시간 빠르다. 한국 표준시는 KST고 바꿔말하면 UTC+9 라고 표기한다. 각 지역별로 표준시가 있지만, UTC로 표현할 수 있다. 여기서 내가 간과한건, UTC보다 빠른 곳도 있지만 느린 곳도 있다! 가장 느린 곳(태평양 오세아니아에 있는 미국의 베이커 섬)은 UTC-12고, 가장 빠른 곳(키리바시 공화국)은 UTC+14다. 날짜 변경선이 태평양에 있다보니 둘의 위치는 가깝지만 시간차이는 하루가 넘게 나버린다.
UTC를 기준으로 월요일 오전 0시에 첫 메일을 발송하게 되면, 베이커 섬의 손님은 일요일 점심시간이다. 물론 무인도긴 하지만… 반면 키리바시 공화국의 고객님은 월요일 오후 2시가 된다. 내가 작성한 스크립트는 현지 시간이 오전 8시 30분~ 오전 9시 30분일 때만 작성하도록 해놨으므로 키리바시 공화국에 계신 손님은 메일을 받을 수 없다. 이분께 보내려면 Task는 UTC 기준 일요일 오후 6시 30분에 실행되야 한다. 전세계에서 가장 늦게 메일을 받으실 분은 베이커섬의 사장님인데, UTC 기준 오후 8시 30분에 Task가 실행되야 한다.
더 빨리 알았으면 좋았겠지만, 실서버에 배포되기 전에 알아서 다행이다.
회고
드디어 실서버에 배포됐다. 이렇게 고생했는데 문제좀 터지지 말아다오..
