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)를 복합적으로 사용하고 있다. 일단 먼저 ..

Part 1. 문제 상황https://chobo-backend.tistory.com/56 [바로] 일괄 주문 기능 개선 #1 (Ft. Lua Script, 비동기)https://chobo-backend.tistory.com/54 [바로] 단일 주문 성능 개선 삽질기 (Ft. 목표 TPS 1666 vs 현실 187.4)상품을 주문하는 행위는 E-Commerce 도메인에서 가장 중요한 기능 중 하나이다. 먼저 재고 관리 측면에서chobo-backend.tistory.com 바로 전 포스팅에서 일괄 주문을 개선하면서 Redis로 가져온 재고 데이터가 부하테스트 이후 불일치하다는 것을 체크했다 당황스러웠다.. DB에서 주문 수와 물품 수량은 데이터 불일치가 없었는데, Redis에서만 불일치하다는 것이 이해가 ..

https://chobo-backend.tistory.com/54 [바로] 단일 주문 성능 개선 삽질기 (Ft. 목표 TPS 1666 vs 현실 187.4)상품을 주문하는 행위는 E-Commerce 도메인에서 가장 중요한 기능 중 하나이다. 먼저 재고 관리 측면에서 예를 들면, 남은 재고는 10개였으나 12개의 주문이 발생할 수 있다. 이로 인해 사용자는 결chobo-backend.tistory.com 지난 포스팅에서 다음과 같은 고민들을 남기며 마쳤었다 1. DB Connection Pool을 늘린다면 개선 될까2. 서버나 DB를 Scale-up 한다면 개선 될까3. 비즈니스 로직이 훨씬 더 복잡해진다면 UPDATE로 원자적 주문이 가능할까4. Redis를 도입하면 개선 될까 먼저 여러가지 방법들을 생..

Part 1. DeadLock 현상 발생단일 품목 주문 API 부하테스트를 진행하면서 아래와 같이 응답이 실패함을 확인할 수 있었다 실패의 원인을 찾는데는 APM 툴로 Pinpoint를 사용하고 있었기에 크게 어렵지 않았다. 모니터링한 결과, DeadLock이 빈번하게 발생하고 있음을 확인했다. 위의 사진에서 보다시피 CannotAcquireLockException이 반복적으로 나타나고 있으며, 특히 HikariCP 데이터베이스 연결 풀에서 2,443ms 동안 대기하는 것을 볼 수 있다. 지금부터 DeadLock이 왜 발생했는지 찾아보자! Part 2. 문제 원인 분석현재 주문 처리의 핵심 플로우는 다음과 같다. Orders와 Order_items 테이블에 순차적으로 INSERT를 수행한..

상품을 주문하는 행위는 E-Commerce 도메인에서 가장 중요한 기능 중 하나이다. 먼저 재고 관리 측면에서 예를 들면, 남은 재고는 10개였으나 12개의 주문이 발생할 수 있다. 이로 인해 사용자는 결제까지 모두 완료한 이후에 결제가 취소되는 상황을 겪거나 브랜드 측에서 추가 발주를 진행해야하는 상황이 발생할 수 있다. 전자는 사용자에게 서비스가 불쾌한 경험으로 남을 수 있고, 후자는 브랜드 측에서 서비스에 불신을 가질 수 있으며 추가 발주라는 예상치 못한 상황으로 인해 리소스가 발생할 수 있다 블랙프라이데이나 한정판 의류 같은 경우 매우 높은 트래픽이 발생 가능한 상황을 고려해야 하며, 동시성 문제로 인한 데이터 정합성 문제가 발생하면 안된다. 즉, 이를 해결하지 못한다면 서비스의 가치를 떨어뜨리고..

세션저장소 기반 로그인을 구현하면서 이후에 만들 API에 공통적으로 사용할 '인증(Authentication) 및 인가(Authorization)' 처리에 대해 고민하고 구현한 내용을 작성해 보려고 한다. ‘바로’에서 JWT가 아닌 세션저장소 방식을 선택한 이유에는 아래에서 확인할 수 있다https://chobo-backend.tistory.com/50 [바로] JWT는 정말 괜찮은 방법일까? (Ft.세션 선택의 이유)클라우드 네이티브와 마이크로서비스 아키텍처(MSA) 시대에 'Stateless(무상태)'하다는 것은 꽤 중요한 특징이 되었다. 그리고 인증 과정에서 무상태를 위한 방법으로 JWT(JSON Web Token)가 자리 잡고 있chobo-backend.tistory.com Part1. 문제..