개발 사이클에 맞춰 성능을 개선한 이커머스 프로젝트, Sellect

📽️ 시연영상

https://www.youtube.com/watch?v=gmP8cwH3PW0

🔖 프로젝트 개요

• 주제 : 국내 이커머스 서비스를 벤치마킹하여, 상품 검색부터 주문·결제까지 핵심 기능을 구현하고 성능을 개선한 프로젝트
• 개발 프로세스 : 기획 및 MVP 구축 → 단위/통합/부하 테스트 기반 로직 정합성 점검 및 성능 개선 반복

📚 기술 스택

🌏 서버 아키텍쳐

🔗 담당 핵심 기능 (대표 기능 중심)

1️⃣ 상품 검색

• 키워드 기반 검색 : 상품명, 브랜드명, 카테고리명을 기준으로 키워드를 검색할 수 있습니다.
• 필터 기능 지원 : 브랜드, 카테고리, 최소/최대 가격 조건을 활용해 검색 결과를 필터링할 수 있습니다.
• 정렬 기능 제공 : 최신순, 높은/낮은 가격순 정렬 옵션을 통해 사용자 맞춤 검색이 가능합니다.
• 회원/비회원 구분 로그 기록 : 검색 시 사용자(회원/비회원)를 구분하여 검색 로그를 기록하고,
  해당 로그를 통해 인기 검색어를 추출하고 자동완성 기능에 활용됩니다.

2️⃣ 주문 및 결제 시스템

• 단일 또는 여러 상품을 동시에 주문 가능 : 사용자는 단일 주문 혹은 장바구니에 담은 여러 상품들을 한 번에 주문도 가능합니다.
• 상품 수량 선택 기능 제공 : 각 상품별로 원하는 수량을 자유롭게 설정할 수 있습니다.
• 카카오페이 결제 지원 : 간편결제 서비스인 카카오페이를 통해 손쉽게 결제를 진행할 수 있습니다.
• 결제 프로세스 흐름 : 주문 생성 → 결제 준비 → 결제 승인으로 이어지는 단계적 결제 흐름을 따릅니다.
• 실시간 재고 확인 및 반영 : 결제 승인 시점에 상품의 재고를 확인하여 품절이나 초과 주문을 방지합니다.

🚀 개선 사항

1️⃣ 결제 시스템 1차 성능 개선 - 애플리케이션 구조 개선

문제 상황

• 결제 승인 과정이 모두 하나의 동기 트랜잭션 내에서 처리됨
  • 재고 차감, 주문 상태 변경, 카카오페이 결제 승인 요청이 순차적으로 동기 실행됨
  • 외부 API 호출 지연 시 전체 응답 흐름이 지연되어, 사용자가 결제 완료 후 결과 화면까지 오랜 대기 시간을 겪게 됨
• 재고 차감 시 Pessimistic Read 락 사용으로 잦은 데드락 발생
  • 다수 사용자가 동시에 동일 상품을 주문하는 상황에서, Pessimistic_Read락으로 조회한 후 UPDATE 시 배타적 락(X Lock) 요청이 발생
  • 다른 트랜잭션이 동일 레코드에 대해 공유 락(S Lock)을 보유 중인 경우, X 락을 획득하지 못하고 순환 대기로 인해 데드락 발생

해결 방법

• 트랜잭션 범위 분리 및 이벤트 기반 비동기 처리 도입
  • 내부 처리 로직(재고 차감, 주문 상태 변경)은 트랜잭션 내에서 우선 수행
  • 외부 API 호출(카카오페이 결제 승인)은 커밋 이후 이벤트 리스너를 통해 비동기 처리, 병목 완화 및 응답 속도 개선
• Pessimistic Write 락으로 변경
  • 재고 조회 시점에 명시적으로 배타적 락(X Lock)을 걸어, 이후 UPDATE 시점의 락 전환 충돌 없이 처리
  • 락 획득 충돌로 인한 데드락 발생 가능성 제거
• PlatformTransactionManager를 활용한 수동 트랜잭션 제어
  • 트랜잭션 커밋 이후에만 외부 API 호출 이벤트를 발행함으로써, 트랜잭션 정합성과 외부 시스템과의 안정성 확보
• 보상 트랜잭션 구조 도입
  • 외부 API 호출 실패 시, 주문 상태 복구 및 재고 복원 등 정합성 유지 로직을 별도 보상 흐름으로 처리

결과

개선 전

개선 후

개선 전/후 비교

2️⃣ 결제 시스템 에러 응답 개선 - DB 데드락 해결

문제 상황

• 재고 차감 시 발생하는 빈번한 데드락 문제
  • 다건 주문 상황에서 여러 트랜잭션이 서로 다른 상품에 대해 락을 획득 후 교차 접근하면서 데드락이 빈번히 발생
  • 이에 대한 별도의 처리 로직이 없어서 응답 실패로 이어짐

해결 방법

• 락 획득 순서 통일 전략(productId 정렬) 실험
  • 동일한 순서로 락을 획득하도록 정렬하여 데드락을 회피했으나, 특정 상품에 락이 몰리며 병목 및 타임아웃 문제 발생
• SERIALIZABLE 격리 수준 실험 (실패)
  • SERIALIZABLE 격리 수준은 직렬화 보장을 위한 수단일 뿐, 데드락 회피를 위한 대안이 아님
• ✅ 재시도 기반 회복 전략 최종 채택
  • 데드락 발생 시 자동 재시도를 통해 빠르게 복구하는 방식으로 전환
  • 단순 코드 추가로도 응답 안정성과 성능 모두 확보, 실제 테스트에서 에러 응답률 0% 달성

결과

3️⃣ 결제 시스템 2차 추가 성능 개선 - Redis 기반 재고 시스템 도입

문제 상황

• DB 락 기반 재고 차감 방식은 높은 안정성을 보장하지만 다음과 같은 문제들이 발생
  • 락 경합으로 인한 병목 발생
  • 특히 인기 상품에 대한 동시 주문 시 응답 지연 및 결제 실패율 증가
  • 재시도 로직 도입 후에도 DB 자원 낭비와 낮은 처리량 문제 지속

해결 방법

• Redis 기반 재고 차감 구조로 전환
  • 재고 상태를 Redis로 이전하고, Lua 스크립트를 통해 원자적 재고 차감 처리
  • 기존 Pessimistic Write 제거, 재고 차감 시 발생하던 락 경합 구조 자체 제거
• Redis TTL 락으로 중복 결제 방지
  • SETNX + TTL 방식으로 결제(pid) 단위 락을 설정해 중복 승인 차단
• 이벤트 기반으로 MySQL 재고 이력 비동기 저장
  • 실시간 재고 처리는 Redis에서 빠르게 처리
  • StockHistory 등의 DB 이력 정보는 이벤트 리스너에서 비동기 저장하여 안정성과 데이터 정합성 확보

결과

추개 개선 전/후 비교

4️⃣ 검색 쿼리 성능 개선 - 검색 응답 시간 0.036초로 단축

문제 상황

• 43만 건의 상품 데이터와 160만 건 이상의 연관 테이블(브랜드, 카테고리, 상품 이미지)을 대상으로 한 검색에서 다음과 같은 성능 문제 발생
  • LIKE '%keyword%' 조건으로 B-Tree 인덱스 미사용, 풀 스캔 발생
  • OR 조건으로 인한 인덱스 푸시다운 미적용 → product 테이블 전체 스캔
  • 상품 이미지 조회 시 스칼라 서브쿼리 반복 실행
  • LEFT JOIN 사용으로 불필요한 행 로딩 및 조인 비용 증가

해결 방법

• Full-Text Index 도입
  • 상품명, 브랜드명, 카테고리명에 대해 Full-Text 인덱스를 적용하고 MATCH ... AGAINST 사용
• OR 조건 분리 → UNION 처리
  • 검색 키워드 조건을 OR가 아닌 3개의 UNION 쿼리 블록으로 분리해 인덱스 푸시다운 유도
• 스칼라 서브쿼리 제거 및 JOIN 전환
  • 이미지 조회 서브쿼리를 JOIN으로 변경하여 루프 반복 최소화
• JOIN 최적화
  • 불필요한 LEFT JOIN → INNER JOIN으로 전환하여 읽기 범위 축소

결과

🚀 트러블 슈팅

1️⃣ 부하 테스트 중 TCP 커넥션 유실 문제 발생

문제 상황

• 외부 서버에 1만 명 부하 테스트 중 요청의 80% 이상이 실패
• 로컬에서는 문제 없음 → 외부 서버에서만 연결 유실 발생
• Spring Actuator, Wireshark 등을 활용한 분석 결과:
  • 서버가 요청 자체를 수신하지 못함
  • Tomcat의 accept() 호출 이전, OS 레벨 TCP Backlog Queue가 포화 상태

원인 상세 분석

• Tomcat은 클라이언트 요청을 OS의 TCP 대기열(backlog)에 저장한 뒤 accept()를 통해 수락
• 이 때 accept-count 값이 낮으면 수락 대기열 공간이 부족해 연결 누락 발생
• 또한, OS의 somaxconn 값이 제한되어 있으면 Tomcat accept-count설정도 무의미해짐

해결 방법

• Tomcat 설정 조정: accept-count를 10000으로 확장
• OS 튜닝: somaxconn 값을 10000으로 변경 → sysctl -w net.core.somaxconn=10000

결과 및 인사이트

• 외부 부하 테스트에서 1만 개 요청 정상 수신
• TCP Backlog와 Tomcat accept-count 관계를 실전 환경에서 명확히 이해하고 적용

2️⃣ 쿠폰 발급 로직 – 락 해제 시점 문제로 인한 동시성 이슈

문제 상황

• 초기 MVP 개발 시에는 단일 인스턴스 환경을 전제로 애플리케이션 락으로 쿠폰 발급 동시성 제어
• 부하 테스트 결과, 락이 DB 트랜잭션 커밋보다 먼저 해제되며 중복 발급 발생
  • 커밋 이전 락 해제 → 다른 요청이 동일 쿠폰을 동시 발급 시도 → 데이터 정합성 깨짐

해결 방법

• 트랜잭션 커밋 이후에 락을 해제하도록 로직 구조 수정
  • 커밋 완료까지 락을 유지함으로써 동시성 충돌 완전 방지
  • DB 반영 이후만 다음 요청 허용 → 정합성 보장

3️⃣ 외부 결제 API 호출 제약 → Fake 서버로 테스트 환경 구성

문제 상황

• 실제 KakaoPay API는 성능 테스트 및 반복 호출에 제약이 존재
• 부하 테스트 시 외부 API 호출은 현실적으로 어려움

해결 방법

• KakaoPay 흐름을 모사한 Fake 결제 API 서버 자체 구축
  • 실제 API 시나리오를 유사하게 구현하여 성능 테스트가 가능한 유사 운영 환경 구성
• 테스트 시 외부 API 호출 없이도 성능 측정 및 병목 구간 정확히 진단 가능

---

📖 Wiki 및 참고 자료

프로젝트 진행 중 겪었던 문제 해결 과정과 기술적 결정에 대한 더 자세한 내용은 아래 Wiki 페이지에서 확인하실 수 있습니다.
Wiki로 이동하기!