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 을 체크하도록 구현하는게 좋다고 생각했다. ...

Today I Learned 날짜 2024년 12월 2일 월요일 내용 제공되지 않는 키워드 데이터 아임리포트에서 지속적으로 특정 계정의 데이터 업데이트 속도가 상당히 지연되는 문제를 겪고 있다. 그동안 확인해본 바에 의하면, 보고서에서 찾은 키워드 데이터가 우리 데이터베이스에 없어서 네이버에서 새로 불러오는 과정이 추가되었기 떄문이다. 그런데 왜 이 계정의 데이터만 유독 많이 불러와야 하며, 매일 매일 불러와야 할 정도로 키워드 데이터가 많이 추가되는지가 의문이었다. 이 부분을 확인하기 위해 로깅문을 찍어봤는데 원인을 알아냈다. 키워드 데이터가 없어서 네이버에 키워드 요청을 보냈지만 받는 응답이 비어있다. 다른 경우에는 작동하고 있기 떄문에 코드 자체의 오류도 아닐 뿐더러 요청에 대한 status_code 는 200인 것으로 보아 요청 자체가 문제가 있는 것은 아닌 듯 하다. 이리저리 찾아본 바에 의하면, 현재 시점에선 삭제된 키워드일 경우 보고서에는 나타나지만 해당 키워드의 상세 데이터는 조회할 수 없는 것으로 추측된다. 더 명확히 하기 위해 네이버 검색광고 github repository에 남겼으니 답을 기다릴 수 밖에 없겠다. ...

Today I Learned 날짜 2024년 11월 29일 금요일 내용 무한증식 커넥션 그저께, 커넥션 풀 문제가 생겨 한도를 늘려줘서 해결했다. 그런데 갑작스레 오늘 점심 쯤에 같은 오류가 발생했다. 그렇게 유저가 바글바글하지도 않은데 뭐지 싶어 RDS에서 커넥션 풀 그래프를 찾아봤다. 처음 50정도로 늘렸을 때 였다가 그저께 올리자마자 급격히 상승해서 유지됐다. 항상 연결이 많은걸로 보이는데, 피크타임도 없이 그렇다는게 뭔가 납득이 안됐다. RDS에서 어떤 경고(?)가 떠서 확인해보니 유휴 상태로 쓰이지 않는 트랜잭션이 너무 많이 유지되고 있다는 에러다. 유휴 상태는 데이터베이스에 접속해서 현재 유휴 상태인 트랜잭션을 확인했다. ...

Today I Learned 날짜 2024년 11월 28일 목요일 내용 중복 잘 되는 줄 알았는데… 중복 데이터가 나타난다는 테스터의 제보를 받았다. 딱 데이터 생성시점을 기준으로 30일 전 ~ 40일 전이 문제가 되었다. 아임리포트에서 데이터를 업데이트할 때는, 최근 30일 데이터만 가져오고 나머지는 S3에서 가져온다. 이걸 40일로 수정했는데 혹시나 S3에 누락된 데이터가 발생할 수 있기 때문이다. 그래서 40일치를 가져오고, 그중 30~40일 사이 데이터를 S3에 저장해서 혹시나 빈 것이 있더라도 잘 채워지도록 해놨다. 이 코드가 문제가 되었는데 (네이버 에서 가져온 140일차 데이터) + (S3에서 가져온 31365일차 데이터)가 합쳐지면서 3140일 차가 데이터가 두번 들어가게 되었던 것.. S3에서 가져올 때, 3041일차의 데이터는 빼도록 바꿔져서 해결했다. ...

8장 프로파일 현재까지 공부한 API 설계의 규칙 프로토콜 의미 체계의 문제 해결법 내 문제에 맞는 도메인 특화표준이 있다? ⇒ 사용 애플리케이션 특화 확장은 문서화 내 문제에 맞는 컬렉션 패턴이 있다? ⇒ 사용 애플리케이션 특화 용어를 정의하고 문서화 둘 다 해당되지 않으면? ⇒ 일반적인 하이퍼미디어 유형 사용 애플리케이션을 상태 전이로 나누고 문서화 애플리케이션 의미 체계의 문제 해결법 내 문제에 맞는 마이크로데이터 아이템이나 마이크로포맷이 있다? ⇒ 사용 문서화 없으면 애플리케이션 특화 용어를 정의 문서화 결국 문서화는 필요하다. ...

Today I Learned 날짜 2024년 11월 27일 수요일 내용 DB Connection Pool QueuePool limit of size 25 overflow 5 reached, connection timed out, timeout 30.00 (Background on this error at: https://sqlalche.me/e/20/3o7r) 왠 처음보는 에러가 자꾸 뜬다. 메시지가 참 심상치 않은데, 주로 뜨는 곳이 웹훅을 처리하는 부분이다. 마침 쇼피파이에서 앱 상태를 확인해보는데, 웹훅 처리율이 너무 낮아 사태가 꽤 심각하다고 느꼈다. 관련 메시지를 찾아보니, 데이터베이스에 연결하는 클라이언트가 동시에 너무 많아서 발생한 문제라고 한다. ...