Today I Learned
날짜
2024년 1월 10일 수요일
내용
빨리 빨리 처리를 못하니 업무가 쌓인다. 똑띠 한번에 처리하자.
리뷰 처리
오늘 또 실수를 했다. 리뷰가 작성되면, 유저는 이름, 성 , 이메일 등을 입력해야 한다. 이때 입력한 이메일로 DB에서 고객정보를 탐색해 이름과 성을 덮어쓰고 저장했다. 어제 이 부분을, 덮어쓰지 않고 저장하도록 코드를 변경했다. 확인해보니 이름이 저장되지 않고 비어있었다.
작성된 리뷰를 저장할 때 사용하는 클래스는 여러가지가 있다. 기본 클래스를 바탕으로, 스토어 리뷰와 주문한 고객의 리뷰(검증된 리뷰), 주문하지 않은 고객의 리뷰(검증되지 않은 리뷰), 관리자의 리뷰가 모두 대동소이하다. 각 클래스는 비슷한 메서드를 필요에 맞게 각각 정의하고 있다.
기존 로직에 대해 더 자세히 설명해보자면, 미검증리뷰가 작성될 때 입력받은 이메일로 DB에서 정보를 찾는다. 없으면 받은 정보를 DB에 저장한다. 그리고 반환한다. 고객정보가 있다면 DB의 값이 반환될 것이고 없다면 지금 입력받은 값이 반환될 것이다. 이떄 반환한 데이터로 리뷰에 저장할 정보를 설정하게 된다. 이 부분을 반환받은 데이터를 사용하지 않고 맨 처음 프론트에서 받은 데이터로 지정해주도록 바꾸어서 해결했다.
문득 회고를 적다보니, 처음 팀에 들어왔을 때 여러 디자인구조에 관해 공부했고 그떄 템플릿 메서드, 팩토리 메서드에 대해 공부했던 기억이 스쳤다. 과거를 뒤져봤다.
둘의 차이는 부모 클래스를 상속받아 약간 바꾸는 것(템플릿)과 부모 클래스는 기본만 만들어 놓고 이후는 자식 클래스에서 결정되는 것(팩토리)이라고 생각했다. 아마 여긴 템플릿인 것 같은데..
Weekly Review Report Email
슬프게도, 오늘도 이메일이 발송되지 않았다. 가정을 두 가지로 나눴다.
- 내가 작성한 스크립트가 잘못되어 발송되지 않았다. AWS ECS에서 Task가 실행되긴 했다.
- AWS ECS에서 Task가 실행되지 않았다. 스크립트가 올바른지는 별개의 문제다.
어제 테스트 서버의 도커 컴포즈 파일을 구동하는 것을 알게 됐기 때문에, 이 방법을 이용했다. 테스트 서버 DB에는 메일 발송 조건을 충족하도록 리뷰가 작성되어 있었다. 따라서 로직으로 인해 발송되지 않을 이유는 없다. 테스트 서버의 컨테이너에서 해당 스크립트를 실행했는데 발송 됐다. 따라서 2번이라고 판단했다.
ECS 클러스터의 로그를 열심히 뒤져봤는데, 중지된 Task가 10개 이상으로 상당히 많았다. Task가 중지되면 1시간 동안 로그가 저장되니 내가 보는 로그들은 1시간 동안 발생한 것들이었다. 여기에서 내가 설정한 예약 태스크가 중지되었던 것을 보게 됐는데, 다른 태스크들과 동일한 오류였다.
ResourceInitializationError: failed to download env files: file download command: non empty error stream: service call has been retried 5 time(s): RequestCanceled: request context canceled caused by: context deadline exceeded
S3 버킷에서 환경변수를 받아오지 못했고, 재요청 횟수가 초과해 취소됐다. 내 Task만 오류가 나는게 아니다 보니 도움을 요청했다. 이 ECS 클러스터의 지역은 서울이고 환경변수를 받아와야 하는 S3의 지역은 미국이다. 물리적인 거리가 멀다보니 통신 속도가 증가하였고, Timeout 시간을 초과해서 실패로 처리되었을 수 있다는 조언을 들었다. 잠깐 찾아보았는데, Timeout 시간을 조금 늘려서 먼 지역이더라도 충분히 받아올 수 있는 시간을 확보해주거나 S3 다중 리전 액세스 포인트에 대해 알아보고 이용해볼 예정.
회고
AWS는 잘 알면 정말 편할 것 같은데.. 잘 모르다보니 건들기 무섭다. 올해 계획에 AWS 공부 하는 것도 추가해야겠다.
