Today I Learned 날짜 2024년 8월 5일 월요일 내용 ECS 태스크 호출하기 아무리 생각해도 서버 외부에서 호출해야 했다. 람다는 15분 제한 시간에 넘치고, 서버에서 돌리기엔 처음 네이버에 호출하는 순간 CPU 사용률이 80%에 달한다! 다행히 boto3로 ECS Task를 호출하는 방법이 있어 적용했다. 태스크를 직접 요청시에 적용할 수 도 있지만, 미리 정의해놓고 호출해서 원하는 로직만 처리하도록 구현했다. 다만, 일부 파라미터들은 일시적인 환경변수로 지정해줘야 했다. 기존에 lambda_function.py에 있는 lambda_handler 를 자동으로 호출되었는데, ECS에선 내가 실행할 스크립트를 추가해줘야 했다. ...
Today I Learned 날짜 2024년 8월 2일 금요일 내용 실사용 환경 테스트 아임리포트의 개발이 끝났다. 실서버 구축도 완료했고.. 마지막으로 일부 고객들을 대상으로 한 베타테스트 전에 열심히 테스트를 돌려봤다. 네이버 API로 가져오는 데이터 양이 많은 것은 당연히 알고 있었으나, 생각치도 못한 부분에서 문제가 발생했다. AWS Lambda는 지속시간이 15분이 넘을 수 없는데 일부 테스트때 로직 수행 시간이 15분이 넘어갔다.. “검색어 성과”에 관한 데이터를 가져올떄는 가져오는 데이터가 많은데, 특히 데이터가 많은 브랜드로 테스트 해보니 15분이 훌쩍 넘어가서 기능이 제대로 문제가 됐다. 다른 브랜드들은 괜찮았는데 하… ...
Today I Learned 날짜 2024년 8월 1일 목요일 내용 또슈처리 오늘도 이슈가 발생했다. 어떤 샵에서 CSV 파일로 4천개 정도의 리뷰를 가져왔는데, 그 샵의 위젯에 나타나지 않는다. 아예 안나타나는 것도 아니고 딱 96개만 나타난다. 해당 스토어의 어드민 페이지로 접근해보니 문제가 된 리뷰들은 고유 넘버도 없다. 리뷰 임포트 부분은 히스토리를 잘 몰라서 당황하긴 했는데… 일단 원인부터 들여다 봤다. 난 당연히 리뷰 테이블에서 갯수를 센 결과가 위젯에 표시될거라고 생각했는데 아니었다. ProductJudge 라는 테이블의 필드를 조회한다. 이 테이블은 그룹 리뷰를 위한 거라고 써있는데… 왜 뜬금없이 애를 참조하는 건가? 그룹 리뷰라 하면 다른 상품의 리뷰까지 포함해서 보여주는 기능이다. 그럼 그룹 리뷰로 설정되지 않으면 그냥 자신의 리뷰만 보여주면 되는거 아닌가? 싶었는데 그런 코드는 없다. 흠… ...
Today I Learned 날짜 2024년 7월 31일 수요일 내용 실서버 운영을 위한 EC2 구축하기 실서버 배포를 위한 환경을 구축했다. VPC를 만들고, ECR, ECS 클러스터 이것 저것 다 만들고 CI CD도 구축했다. 이제 나름 몇번 해봤다고 할 줄 알게 됨.. 물론 실서버에서 이슈처리를 위해 X-Ray를 구축할 예정인데, 이 부분은 아직 건드리지 못헀다는 게 첫번쨰 문제고 두번째는 서비스를 운영할 기반을 만드는 거였다. 실서버에서 마이그레이션을 하거나, 커맨드를 돌리기 위해 사용할 EC2를 만들어주려고 한다. 기존 글로벌 프로덕트 리뷰가 그렇게 되있다. ECS에서 돌아가는 컨테이너가 실서버는 항상 2개길래 “아 하나가 사용하는 서버고, 나머지 하나가 EC2를 위한 거구나” 라고 생각했다. ECS는 도커 이미지로 서버를 돌리는데 사용량에 따라 자동으로 스케일이 조정되는 Fargate 방식과, 생성해둔 EC2 인스턴스에서 구동하는 방식이 있기 떄문에 그런줄 알았다. 설정을 들어가보니 전혀 아니었지만… ...
Today I Learned 날짜 2024년 7월 30일 화요일 내용 사소한 듯 한 에러처리 어제 나는 분명 기능을 완성하고 갔다. 분명. 그런데 오늘 2차 QA를 시작하자마자 안 만들어진다. 하… 헛고생 했다는 생각에 1차 분노, QA 하는 분들의 시간을 낭비했다는 생각에 2차 분노했다. 화를 삭히고 열심히 원인을 찾았다. 네이버 API 호출 제한 네이버 검색광고에서 데이터를 불러올 때, 호출 횟수의 제한이 있다. 초당 2030회가 넘어가면 429 코드가 반환되면서 “Too many requests” 라는 메시지를 뱉는다. 담당자의 답변에 의하면 1초 후 다시 시도하란다. 데이터를 불러올 떄, 이런 일이 발생하면 1초 후 로직을 다시 시작하도록은 구현해 놨다. 우선 테스트를 위해 요청 횟수를 적게 해놔서 발생할 일은 없을 거라고 예상했는데.. 오늘 QA 과정에서 문제가 됐다. 여러 명이 동시에 진행하는 QA에서 모두가 같은 네이버 계정을 사용했기 떄문이다. 100일치만 불러오느라 괜찮을 줄 알았는데 동시에 23 명이 요청을 보내니 에러가 떴고 내가 짠 코드가 제대로 작동 안하는게 확인됐다. 400일치가 제대로 돌아가는지 꼭 재차 확인해야겄다. ...
Today I Learned 날짜 2024년 7월 29일 월요일 내용 오류 뜯어고치기 QA를 계속 진행중. 자잘한 오류를 뜯어 고치는 중이다. 데이터베이스상으론 등록된 스프레드시트가 존재하지만, 실제로 구글 드라이브에는 존재하지 않을 떄에 대한 처리가 없었다. 스프레드시트는 존재하지만 이름이 바뀌었을 경우, 정해진 로우데이터 이름대로 변경하는 코드가 없었다. 템플릿 데이터가 int로 들어오는데, 올바른 스키마 형태로 처리하지 못했다. 로직이 실패했을 때 올바른(?) 이유가 저장되거나 실패처리가 되지 않았다. 등등… 뭔가 큰 틀에서는 이상이 없는데 온갖 자잘한 곳에서 자꾸 삐그덕거린다.. 뒤늦게 이 코드 저 코드 추가하니 모양새가 영 보기 좋지 않다. ...
Today I Learned 날짜 2024년 7월 26일 금요일 내용 또 이슈.. 또 이슈가 터졌다. 우리 프로덕트 리뷰 기능에는 구글 검색에 나타나는 제품 스니펫을 추가해주는 기능이 있다. 제대로 들어갔는지는 링크에서 확인해보면 되는데, aggregateRating과 리뷰가 없다고 결과가 나온다. 스니펫이 없다거나, 스니펫에 들어갈 데이터가 상품 메타필드에 없거나 하는 문제가 있을까 싶어 열심히 찾아봤는데 다 있다. 그럼 도대체 어디가 문제인가… 비정상을 찾는 최고의 방법은 정상과 비교해보는 법. 우리 서비스를 이용하는 다른 샵들의 대시보드로 들어가서 구글 스니펫을 사용하는 샵들도 테스트를 돌려봤다. 근데 다 똑같은 오류가 뜬다..? 그럼 둘 중 하나다. 저게 뜨는게 정상적인 상태였거나, 애초에 기능 자체가 고장나버린 상태거나.. 월요일에 도움을 받아 다시 봐야 겠다. 혹시나해서 구글에 검색해봤는데 역시나 리뷰 갯수나 평점 등의 스니펫은 안뜨긴 한다. 아마 고장났나보다… ...
Today I Learned 날짜 2024년 7월 25일 목요일 내용 람다의 재요청 방지 데이터 임포트를 요청하면 boto3로 AWS Lambda를 호출하도록 구현했다. 맨 처음에는 RequestResponse로 보냈었다. 그런데 디버깅 과정에서 요청이 실패할때마다 1분 간격으로 재시도가 발생해서, 데이터가 꼬이고 쓸데없는 로그가 많이 남아 힘들었다. 그래서 비동기 호출인 Event로 바꾸었다. 근데 비동기 함수라 로직이 원하는대로 실행되지 않았다.. 알아보니 RequestResponse 호출을 했을 때 요청이 실패하면 AWS에서 자동으로 3회 정도 재시도를 한다고 한다. Lambda 클라이언트를 설정할 때 config를 설정해서 이를 방지 할 수 있었다. ...
Today I Learned 날짜 2024년 7월 24일 수요일 내용 리뷰 요청 메일 리뷰를 요청하는 메일은 중요한 기능이기 떄문에 매일매일 확인하고 있다. 발송 자체는 올바르게 되나 한가지 문제점을 발견했다. 발송 여부에 관한 데이터를 메시징 로그라 하는데, 이 데이터가 조회가 안된다. 메뉴에서 collect 메뉴에 들어가면 유저는 메시징 로그가 생성된 메일들 목록을 볼 수 있다. 특정 날짜에 발송되었거나, 취소되었거나, 발송할 예정인 메일들과 그 메일의 기점이 된 주문 데이터를 볼 수 있다. 주문데이터를 볼떄는 필터링을 추가할 수 있는데 주문시점, 배송완료 시점, 요청 메일 발송 시점 3가지다. ...
Today I Learned 날짜 2024년 7월 23일 화요일 내용 자주 추가될 템플릿. 네트워크 문제를 해결하니 무사히 람다함수가 완성됐다. 그동안 임시로 멀티스레드로 처리하도록 구현해놓은거를 다 바꿔주었다. 그런데 변경사항이 발생했다. 템플릿이 여러 스프레드시트에 나눠져서 만들어질 것이고 자주 추가될 듯하다. 매번 코드를 엎거나 수정하기엔 번거로울 듯하여 새로운 방안을 모색했다. 각 템플릿의 정보를 담은 테이블을 사용하려고 한다. 그동안은 유저에 의해 생성되는 데이터들만을 위해 데이터베이스를 사용했지만, 이번엔 기능에 추가되는 템플릿들을 저장하는 테이블을 생성하려고 한다. 1 2 3 4 5 6 7 8 9 template : { "id" : 데이터베이스 내 고유 id, "number" : 각각에게 부여되는 고유 숫자, "name" : 템플릿 이름(ex. NSA_GTD 항목별 캠페인 유형, "description": 템플릿에 관한 설명, "spreadsheet_id": 템플릿 원본이 존재하는 스프레드시트의 아이디, "sheetfile_id": 템플릿 원본이 존재하는 시트파일의 아이디, "raw_data_foramt_type": 템플릿이 참조하는 로우데이터의 형식 } 쯤으로 만들면 되지 않을까! 앞으로 추가, 삭제, 변경도 쉬워지도록… ...