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. 문제점 및 설계 고민어떤 부분을 개선할지 생각해보면, 스와이프 시 좋아요 카운트는 어느 시점에 해야..

Part 1. 문제 상황현재 Products(상품) 테이블에는 180만개의 데이터가 적재되어있다. 180만개였던 이유는 무신사의 경우 1만개 브랜드가 입점해있었고 '바로'에서는 그의 5분의 1 수준인 2000개 브랜드 기준으로 브랜드당 3개의 카테고리, 카테고리 당 300개의 상품을 둔다고 가정한 수치이다. 기능 개발을 마치고 API들을 테스트해보던 중 인기상품조회 API의 응답시간이 느리다는 것을 파악하게 되어 개선을 시작했다 현재 기능에 대해 좀 더 자세히 설명하자면 상품을 좋아요 개수 순서대로 보여주는 인기상품조회 기능이다. Cursor를 활용한 무한스크롤 방식으로 구현하였고, CurosrId로는 likeCount(좋아요 수), productId(상품 ID)를 복합적으로 사용하고 있다. 일단 먼저 ..