Part 0. 25년을 마친 소감 25년이 정말 너무나도 빠르게 지나가버렸다..왜 이렇게 빠르게 지났는지 생각해보면 거의 매일 반복되는 일상에 적응해버려서 지나가는 시간들을 잘 못느꼈던 것 같다 올해는 매일매일이 다음 중 하나였다 1. 부캠 + 나머지 공부 + 잠2. DH 합숙(플젝 + 개인 공부) + 잠3. 카페 + 잠 어디 놀러간 적도 없이 쉰다고 한다면 혼자 유튜브보거나 넷플정도..쉼없이 달려왔지만 사실 크게 힘든 건 못 느꼈다. 아무래도 개발이 천직이지 않을까ㅎㅎ 취준 과정에서 계속되는 탈락이 조금 힘들었던 것 같긴한데 그래도 내가 열심히하면 안되는 건 없다고 믿는 편이라 최대한 긍정적으로 생각했었다결과적으로 올해 목표였던 취뽀는 성공 + 내가 원해왔던 회사 기준에 맞는 곳으로길었던 취준의 마무리..

Part 0. 개선 할 기능 룩 상세 조회 기능은 룩 이미지와 해당 룩에 착용된 상품 리스트를 모두 조회하는 기능이다. 이 기능은 내부적으로 5개의 테이블에서 데이터를 조회하고 있고, 생성된 룩은 생성자만 수정할 수 있어 데이터 변경 빈도가 낮다는 특성을 가지고 있다. Part 1. 문제 상황 💻 테스트 환경단일 WAS(SpringBoot) : AWS EC2 t4g.xlarge(4 vCPU, 16GiB Memory)단일 DB(MySQL) : AWS EC2 t4g.medium(2 vCPU, 4GiB Memory)단일 Redis : AWS EC2 t4g.medium(2 vCPU, 4GiB Memory)부하테스트 툴 : LocustAPM 툴 : PinpointMetric 수집 및 시각화 툴 : P..

Part 1. 기능 개요 평소 인터넷을 통해 옷을 구매하는 경우 정말 나와 어울리는지 입어볼 수 없다는 것이 문제였다. 따라서 최근 구글에서 출시한 나노 바나나 모델을 통해 사용자의 사진과 쇼핑몰의 옷 사진을 합성해 보여줄 수 있다면 빠르게 가상으로 피팅하고 구매 결정을 빠르게 할 수 있게 도와 구매 전환율을 높일 수 있을 것이라 생각했다.(위 사진처럼 - 저는 톰브라운 가디건 없어요) 하지만 구글의 나노 바나나 API는 비용이 들어가는 유료 API 였기에 무제한적으로 사용되는 것을 막기 위한 사용량 제한 로직이 필요했다. 그리고 그전에 사용자의 사진을 업로드 할 수 있는 기능도 필요했다 Part 2. 사진 업로드 기능 구현(Presigned URL)먼저 사용자의 사진을 업로드 할 수 있는 기능이 ..

Part 0. 개선할 기능https://chobo-backend.tistory.com/56 [바로] 일괄 주문 기능 개선 Vol.1 (Ft. Eventual Consistency)https://chobo-backend.tistory.com/54 [바로] 단일 주문 성능 개선 삽질기 (Ft. 목표 TPS 1666 vs 현실 187.4)상품을 주문하는 행위는 E-Commerce 도메인에서 가장 중요한 기능 중 하나이다. 먼저 재고 관리 측면에서chobo-backend.tistory.com 지난 포스팅에서 일괄 주문을 개선하고 목표 성능에 도달하지 못했고 확장성을 고려해 개선을 더 진행해보려고 한다. 기능에 대해서 간단히 설명하면 사용자가 장바구니에 담은 여러 물품들을 한번에 주문하는 기능이다. Part..

Part 0. 개선할 기능시작하기 전 이해를 위해 용어를 정의하겠다. 룩(Look) : 유저의 전반적인 스타일을 볼 수 있는 사진스와이프(API) : 룩에 좋아요 혹은 싫어요 반응을 남기는 기능으로 API를 뜻한다 위 사진처럼 룩이 보이면 유저는 왼쪽(싫어요) 오른쪽(좋아요) 스와이프를 통해 반응을 남길 수 있다. '바로'서비스의 핵심 기능으로 많은 사용자가 지연없이 해당 기능을 이용할 수 있어야한다. 따라서 성능 개선이 필요했다 핵심 요구사항 정리동시 사용자 수 500명의 트래픽을 견뎌낼 수 있어야 한다부하 상황에서 스와이프 및 룩 조회는 평균응답시간이 200ms 내로 들어와야 한다 Part 1. 문제점 및 설계 고민어떤 부분을 개선할지 생각해보면, 스와이프 시 좋아요 카운트는 어느 시점에 해야..