Log

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일차의 데이터는 빼도록 바꿔져서 해결했다. ...

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) 왠 처음보는 에러가 자꾸 뜬다. 메시지가 참 심상치 않은데, 주로 뜨는 곳이 웹훅을 처리하는 부분이다. 마침 쇼피파이에서 앱 상태를 확인해보는데, 웹훅 처리율이 너무 낮아 사태가 꽤 심각하다고 느꼈다. 관련 메시지를 찾아보니, 데이터베이스에 연결하는 클라이언트가 동시에 너무 많아서 발생한 문제라고 한다. ...

Today I Learned 날짜 2024년 11월 26일 화요일 내용 HTML 검사 네이버 배너 이미지의 실 사용 상태를 스프레드시트에 업데이트 해준다. 거의 대부분(80~90%)가 미연동상태로 표시된다. 미연동 상태라 함은 우리 어드민에 접속해 배너이미지 삭제하기 버튼을 누르진 않았지만, 유저 본인이 네이버 상품 수정 페이지에서 우리 이미지를 삭제했다는 뜻이다. 우리 서비스를 이렇게 안 쓸리 없다는 희망을 품고 실제 미연동상태인 데이터들을 확인했다. 역시 실제로는 쓰는데, 미연동 상태로 표시되는 것들이 대부분이었다. 배너 이미지는 매 주 자동 업데이트 및 업로드 되는데 미연동상태로 처리되어 업데이트조차 되지 않았다. 뭔가 로직에 이상이 생겼다. ...

Today I Learned 날짜 2024년 11월 25일 월요일 내용 코드 정리하기 아름다운 사람은 머문 자리도 아름답다 카더라. 국내에서 개발을 어느정도 마치고 마무리하고 있다. 나중에 기능을 완전하게 활성화 할 때, 내 코드를 보는 사람이 누구더라도 알아 볼 수 있도록 했다. 엔드포인트 정리하기: 사실 이제와서 바꾸면 프론트 입장에서 화딱지가 나겠지만, 그렇다고 더러운 엔드포인트 이름은 두고 볼 수 없다. 처음부터 제대로 했으면 된다고? 생각이 안나는걸 어떡함? 함수 쪼개기: 코드가 기~인 함수는 보면 함수부터 나온다. 기능에 따라 최대한 나누어줬다. 인스타그램에서 데이터를 받아온다고 가정하면 받아오기 ⇒ 있는지 조회하기 ⇒ 저장하기 쯤으로 나눌 수 있겠다. 각주 적기: 클린 코드의 저자는 각주를 적을 필요가 없을 만큼 깔끔한 코드를 작성할 생각을 하라고 하셨다. 난 어느덧 그럴 수 없으니 각주를 적는다. 클래스 다시 확인하기: 코드를 쓰면서 종종 피어나는 클린 코드 독자로서의 자부심은 열심히 클래스를 정의하도록 만들었다. 정신차리고 보면 클래스에 온갖 잡다한게 다 들어간 강아지 장난감 보관함같다. 기능 별로, 작동하는 테이블명 별로 잘 나눠주자. 회고 PR 올리고 도망가려다가 코드리뷰에 붙잡혔다. 오랜만이라 무섭다. ...