Today I Learned 날짜 2024년 12월 16일 월요일 내용 네이버는 왜 주지 않는가 아임리포트 자동 업데이트 떄, 생성한 보고서 조회 요청에 자꾸 빈 값이 들어온다. 무작위로 중구난방하게 발생하고 있어 원인을 도저히 파악할 수 없다. 특히나, 매일 아침 실행되는 실서버 정기 업데이트에서만 발생하기 때문에 버그를 재현할 수 없다는게 가장 큰 문제… 일단 구체적으로 어느 날짜의 보고서 조회가 빈값을 반환하는지 확인할 수 있도록 로그문을 추가해놨다. 실제로 없어서 안주는 건지, 뭐가 잘못된건지 내일이면 알 수있지 않을까! ...
Today I Learned 날짜 2024년 12월 13일 금요일 내용 pre-signed url이 작동하지 않는 이유 현재 티켓페이지에서 사용자가 추가한 이미지와 파일을 저장하는 방식은 그다지 좋지 않다. 서버에게 티켓의 이미지와 파일을 S3에 저장해달라고 요청을 보냄 서버는 저장 후 그 링크를 반환함 반환받은 링크를 티켓 데이터에 추가하여 티켓 데이터 생성 요청을 보냄 이 방식이다. 만약 클라이언트가 S3에 저장할 수 있다면 굳이 서버에게 파일을 보내지 않아도 된다. 이를 위해 pre-signed-url을 보내도록만 요청을 변경해야 한다. 이 URL은 설정한 시간만큼만 유효한 URL이다. 서버에게 어떤 버킷 내 어떤 키에 생성해야 할지 알려주고 url을 받아왔으나 생성이 되지 않는다. 클라이언트의 요청에 0 Unknown Error만 나와 정확한 원인도 모른다… 구글링을 한참 해보니 pre-signed url을 생성하기 위해 boto3 클라이언트를 초기화할 때 리전을 입력해보라고 한다. ...
Today I Learned 날짜 2024년 12월 12일 목요일 내용 선택적으로 path parameter 받기 쇼핑몰 상세 페이지에서 오른쪽 네비게이션 바를 통해 티켓을 볼 수 있다. 이 티켓을 클릭하면 티켓 페이지를 새창으로 띄워줘야 하고 상세보기에는 해당 티켓이 나타나야 한다. 티켓페이지에선 상세보기도 하위 컴포넌트로 구현되어 있어서 어떤 티켓을 눌러도 중앙 쪽에 있는 돔에만 변화가 생길뿐 나머지는 그대로다. 즉, 티켓 페이지의 최상위 컴포넌트에는 정해져있는 로직에 따라 최초로 상세보기에 띄울 티켓을 선택할 뿐이고 그 외는 없어서 구현해야 했다. ...
Today I Learned 날짜 2024년 12월 11일 수요일 내용 리마인더 알람기능 이것저것 아주 간단한 기능들을 고치거나 만드는 중. 기본 코드가 워낙 보기 쉽게 잘 짜여져있고 로직도 단순해서 큰 어려움은 전혀 없었다. 다만, 리마인더 기능은 조금 고민이 들었다. 티켓에는 리마인더 기능이 있는데, 노션에서 처럼 일정 기간 후 유저에게 알려줘야 한다. 물론 유저가 티켓 페이지에 접속했을 떄만.. 그래서 유저가 티켓 페이지에 들어왔을 때 리마인더를 조회하도록 했다. 설정된 리마인더 시간이 가장 빠른 것부터 보여준다(다시 말하면 알람이 울린지 가장 오래되었다는 뜻). ...
Today I Learned 날짜 2024년 12월 10일 화요일 내용 코어 작업에 투입되었다. 아는 구조, 로직, 코드가 하나도 없어서 작은 태스크부터 맡기로 했는데 우선 티켓 관리 페이지 QA부터 처리하기로 했다. 프론트까지! 딱 작년 이맘때에 첫 태스크를 맡았을 때의 느낌이 난다. 1년동안 열심히는 살았는지, 로직 파악이나 코드 파악 등도 훨씬 빨라졌고 로컬 세팅도 알아서 잘 했다. 첫 시작으로 아주 좋은 태스크를 맡은 듯 하다. 회고 정말 오랜만에 다른 사람의 코드를 보는 거라 뭔가 설렌다. ...
Today I Learned 날짜 2024년 12월 9일 월요일 내용 빠르게 대기열을 처리하자 아임리포트가 진행하는 매일 아침 정기업데이트가 심각하게 오래 걸린다. 이대로는 유저가 사용할 리가 없으니 최대한 줄이는 작업이 필요하다. 현재는 대기열 시스템을 만들었으나 약간의 로직상 구멍이 있다. 로우데이터 처리 로직이 끝나야만 대기열을 추적한다는 것.. 대기열 시스템이 존재하는 것은 네이버 API 사용 제한으로 인한 것이니 전체 로직중 가장 처음인 네이버 처리만 끝나면 대기열에 있는 로우데이터를 꺼내와 동시에 처리해도 무방하다. 이 부분을 처리할 방법이 떠올랐는데.. ...
Today I Learned 날짜 2024년 12월 6일 금요일 내용 ECS Task의 IP 고정하기 네이버 커머스 솔루션에서 앱을 등록할 때, IP를 등록해야 한다. 네이버 쪽 API를 사용할때는 등록된 API만 사용해야 한다. 네이버쪽에서 허용되지 않은 IP로 요청이 왔었고, 이게 지속되면 막아버린다고 한다. 곰곰히 생각해봤을 때, 네이버 API에 접근하는 곳은 3가지이다. 서버, 크론 작업이 돌아가는 ECS Task, 서버의 데이터베이스 마이그레이션이나 커맨드를 돌릴 떄 사용하는 EC2다. 서버는 진작에 등록해줬기 떄문에 문제가 없고, EC2는 이참에 등록해줬다. 그런데 네이버쪽에서 보내준 IP는 EC2 것과는 달랐다. 인스턴스를 바꾸거나 한 일이 없으니 IP도 바뀌지 않았기 떄문에.. 아마 ECS Task의 IP였나보다. 그렇다면 크론작업이 돌아갈 때만 생성되는 Task의 IP가 무엇일 줄 알고 미리 네이버에 등록할 수 있을까.. ...
Today I Learned 날짜 2024년 12월 5일 목요일 내용 버그 대폭발 아임리포트의 버그가 대폭발했다. 데이터 업데이트가 미친듯이 오래걸리기 시작해서, 제한시간인 6시간이 넘어가며 실패처리 되는 걸로 파악했다. 네이버에서 안준다고 못박아버리는 바람에, 우선은 “-”로 저장하도록 로직을 바꿔줬다. 이제 삭제된 키워드가 많더라도 하루만 고생하면 그 이후에는 요청이 오래 걸릴 일이 없다. 슈퍼어드민에서 유저를 불러올 때 일부 데이터가 안불러와진다.. 아마 온갖 데이터를 다 조인하는 과정에서 연관데이터가 없는 경우 누락된 듯하다. 쿼리를 수정해줬다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 # 기존 쿼리 stmt = ( select(models.User) .outerjoin(models.User.company) .options(joinedload(models.User.billing_plan)) .options(joinedload(models.User.google_login_account)) .options(joinedload(models.User.super_admin_memo)) ) db.execute(stmt).scalars().all() # 수정 쿼리 stmt = ( select(models.User) .outerjoin(models.User.company) .options(contains_eager(models.User.company)) .options(joinedload(models.User.billing_plan)) .options(joinedload(models.User.google_login_account)) .options(joinedload(models.User.super_admin_memo)) ) db.execute(stmt).unique().scalars().all() 회고 버그야 제발 ...
Today I Learned 날짜 2024년 12월 4일 수요일 내용 오오오랜만에 프론트엔드 아임리포트의 실서버 유저데이터를 보고 관리할 수 있는 슈퍼어드민을 만들어야한다. 급한대로 어제 서버 기능은 후딱 다 만들었기 때문에, 프론트엔드 쪽만 만들면 된다. 기능들은 뭐 다 돌아가게 만들었는데… 내가 생각해도 코드나 구조가 참.. 코드에 대한 이해없이 기존 코드를 가져다 붙여 작동만 하게 만들었다. 장고, 프론트 공부할 꺼 투성이다. 회고 백엔드만 할줄 아니까 일단 50% 맞음
Today I Learned 날짜 2024년 12월 3일 화요일 내용 결제 내역 아임리포트의 슈퍼어드민을 만들어야 한다. 유저의 결제 상태에 따라 서비스 사용 상태를 바꿔줄 계획인데, 우선 결제는 나중에 하더라도 관련 테이블과 구조는 짜놓을 계획이다. 이 과정에서 고민이 참 많았는데, 최상위 테이블로 company를 만들고 난 후 결제 테이블이 어디에 엮여야 될 지가 관건이었다. 이 서비스의 특성상 같은 회사 내에 여러 사람이 쓸 가능성이 높다고 생각했다. 그렇다면 이 사람들의 사용에 대한 결제가 회사차원에서 이뤄질게 당연하다. 회사가 일괄적으로 결제할 것이라면, 모든 유저는 각자가 속해있는 company 데이터에 엮인 billing 을 체크하도록 구현하는게 좋다고 생각했다. ...