ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 2023년 3월 회고
    🤔 개인 회고 2023. 4. 14.

    날씨가 아직은 추워서 아직도 겨울인것 같은데 벌써 3월이 지나갔다니 이제 계절에도 둔감해지는 기분이 든다.


    fastAPI  + GraphQL 환경에서 테스트 코드 작성하기

    fastAPI  + GraphQL 환경에서 e2e 테스트와 일부 계산 로직이 포함된 함수에 유닛 테스트를 작성했다. e2e 테스트 코드의 경우 테스트용 DB에 붙어서 수행되기 때문에 신경써야 할 부분들이 많은 것 같다.(테스트 DB 마이그레이션, 테스트용 더미 데이터 생성, 테스트 수행 속도 저하 등) 그래서 e2e테스트 코드는 각 API에 대해서만 작성을 하고, graphQL의 resolver 들에 대한 부분은 유닛테스트 코드를 작성하려고 했다. 그런데 현재는 graphQL의 각 resolver 함수에 대한 유닛테스트 코드를 작성하지 못했는데, db session 객체를 resolver에서 바로 import 해서 사용하는 방식으로 코드가 의존적으로 작성되어있기 때문이였다. 유닛테스트를 위해 이 부분을 어떻게 분리 할 수 있을지 고민 중이다.

     

    SSR 환경이 아닌 상황에서 동적 open graph 적용

    회사 상품을 소개하는 웹사이트에서 상품의 디테일 페이지에서는 링크를 공유했을때 대표 이미지가 아닌 그 상품의 미리보기 이미지가 나왔으면 좋겠다는 이슈가 있었다.  프론트의 경우 Next.js와 같이 SSR을 적용할수있는 형태가 아니였다. 하지만 Vue 개발되어 빌드된 프론트 페이지가 백엔드 쪽에서 django webpack loader 를 통해 서비스 되고있는 상황이였기 때문에 Django 에서 상품 조회 URL로 라우팅 되었을때, 해당 template을 내려 줄 때에 view에서 DB에서 상품에 대한 정보를 조회 한 후 동적으로 템플릿에 open graph meta 태그 삽입해 내려주었다.

     

    이 이슈를 처리하면서 ngrok이라는 로컬환경을 외부에서 테스트 할 수 있게 해주는 툴을 처음 경험해 보았는데, 해당 과정을 정리하고있다.

     

    구체화된 뷰 테이블을 활용한, snowflake 데이터 추출 업무

    회사에서 출시한 앱의 로그 분석 업무를 진행하면서 snowflake의 구체화된 뷰(materalized view, mview)를 사용해보았다. 원본 로그 테이블의 크기가 너무 컷기 때문에(30분 소요 / 109.67GB 스캔) 쿼리를 수행하는데 너무 많은 시간이 소요되었는데, 구체화된 뷰를 구성하여 쿼리를 수행하니까 19초 만에 쿼리가 완료되었다. 이 작업을 진행하면서 snowflake에서 구체화된 뷰 테이블 갱신은 언제 일어나는지, 유지비용은 어느정도 드는지, 파티션 프루닝이란 무엇이고 왜 중요한지에 대해 알게 되었는데 알게된 내용을 블로그에 정리해야겠다.

     

    redis 메모리 이슈

    로그 처리를 하는 과정에서 1분동안 발생한 로그를 잠시 캐싱해두는 용도로 redis를사용하는데, 해당 redis의 메모리가 계속 증가하고 있는 것을 발견했다. 

    3월에 갑자기 redis 메모리 사용율이 증가했는데, 그 원인은 2월과 3월에 한번씩 처리에 실패한 로그를 redis에 잠시 담아두도록 로그 처리 서버를 업데이트 했기 때문이였다. 그리고 redis 메모리 사용량도 너무 적게 설정 되어있었다.(300MB 수준) 일단은 redis 메모리 사용량을 올리고, 처리에 실패한 로그를 굳이 리소스를 잡아먹어가며 인메모리에 담아둘 필요는 없을 것 같아서 이부분도 S3와 같은 파일형태로 따로 저장하도록 로그 파이프라인을 수정했다.


    express JS -> Nest.js TS 로 리펙토링

    올해 초 원티드 프리온보딩 Node.js 과정을 수강하면서 새로 알게된 Port and Adaptor 아키텍쳐를 적용하면 좋을 프로젝트가 떠올라 기존 express JS 로 만들어진 프로젝트를 Nest.js로 바꾸고 있다. 프로젝트를 진행하면서 고민 했던 내용들을 정리하고있다.

     

    Real MySQL 8.0 스터디 진행

    RealMySQL 1권을 거의 마무리 하게 되었다. 개인적으로 스터디를 진행하면서 두가지 문제에 대해 봉착을 했는데 


    1. 비슷한 경험치의 구성원들만 모여 스터디를 하게 될 경우, 새로운 관점이나 경험에서 우러나온 지식을 얻기 힘들다.

    2. 내용과 흐름이 한눈에 안들어오는 경우 어떻게 정리를 할것인가?

     

    하는 문제였다. 1번 문제의 경우 지인을 통해 저자분이 운영하시는 오픈채팅방을 알게 되어 그 책의 저자분에게 질문을 바로 할 수 있게 되었다. 보통 스터디의 경우 "교수님"이라 불리우는 능력자 분이 있는 경우, 그 교수님의 도움을 받을 수 있는데, 만약 그런 상황이 아니라면 커뮤니티를 활용하는것도 많은 도움이 될 수 있다는 것을 느꼈다.

     

    Real MySQL 8.0 책의 경우, 뒤에 나올 내용이 갑자기 앞에 미리 나오기도 하고, 앞에 살짝 나왔던 내용이 뒤에 추가되어 나오기도 했다. 그러다보니 읽으면서 내용들이 한눈에 안들어오는 문제가 생겼는데 마인드맵을 그려보니 전체적인 흐름을 정리하는데 개인적으로 많은 도움이 되었던것같다.

    스터디를 하면서 다른 분이 자신이 쿼리 최적화 한 내용을 예시로 보여주셨는데, 마인드맵을 같이 보면서 아 이래서 임시테이블이 생성된것이였구나! 한눈에 파악 할 수 있었다.

     

     

    토스 스터디 클럽 지원

    https://toss.im/career/toss-study-club?studyId=82236225003 

     

    토스 스터디 클럽

    혼자 고민은 그만, 함께 이야기 나누며 해결해요

    toss.im

    토스 스터디 클럽 Node.js 분야에 지원했다.

    백엔드 관련 아키텍쳐나 클린코드 글들을 보면 대부분 Java로 쓰여져있는 부분들이 많았고, 나 또한 Java에 대한 경험이 없었기 때문에 원리를 이해해도 이걸 어떻게 JS에 적용할 수 있을까? 하는 2차적인 고민들이 어려웠다. 그런데 Node.js를 사용하는 백엔드 개발자 분들이 모여서 TS로 서로의 경험을 나눌수있는 자리라니!! 만약 스터디에 붙는다면 정말 너무 좋은 경험이 될것 같다.

    댓글

GitHub: https://github.com/Yesung-Han