업무 · 헥토데이터
Sellpick OMS 개발·운영
여러 판매 채널의 주문을 한곳에서 처리하는 OMS의 백엔드와 연동 시스템을 개발하고 운영합니다.
주요 성과
주문 조회 첫 페이지 약 20초 → 5초, 뒤 페이지 약 100초 → 6초
2단계 페이징을 포함한 주문 조회 전체 개선의 측정 결과입니다. 현재 페이지의 PK를 먼저 선택해 비싼 상세 조회 범위를 줄이고, 측정한 페이지에서 응답 시간을 최소 75% 단축했습니다.
동시 주문 수집의 중복 처리를 Redis 분산 락으로 제어
멀티 채널 수집 작업이 겹치는 상황에서 중복 수집을 처리해 주문 정합성을 확보했습니다.
성능 변경 전후의 조회 결과와 실행 범위를 검증
정렬과 복합 PK 연결을 맞추고 페이지별 건수·PK 순서·반환 컬럼을 비교했습니다. 실행 계획에서 비용이 큰 노드의 반복 범위도 확인했습니다.
반환하지 않을 주문의 상세 조회 비용 줄이기
같은 검색 조건과 페이지 크기에서도 뒤 페이지로 갈수록 조회가 느려졌습니다. 기존 쿼리는 상품·재고·금액·상태 정보를 계산한 뒤 OFFSET으로 앞의 주문을 버리고 있었습니다. 최종 반환 건수보다 훨씬 많은 주문에 상세 조회 비용을 쓰는 구조였습니다.
검색·정렬 조건으로 현재 페이지의 PK를 먼저 고른 뒤, 선택된 주문에만 상세 정보를 붙이는 2단계 페이징을 적용했습니다. 건너뛸 키를 확인하는 작업은 유지하되, 비싼 상세 조회가 페이지 번호에 따라 함께 늘어나지 않도록 범위를 옮겼습니다.
조회를 빠르게 바꿔도 결과는 같아야 하기
키 선택과 상세 조회를 나누면 검색·조인·정렬 조건이 달라질 수 있었습니다. 정렬값이 같은 주문의 순서가 흔들리면 페이지를 이동할 때 중복이나 누락도 생길 수 있어 성능과 결과 동등성을 함께 확인해야 했습니다.
동적 정렬 조건을 같은 SQL 조각으로 사용하고 PK를 타이브레이커로 추가했습니다. 복합 PK 연결과 검색 조건을 맞춘 뒤 페이지별 건수·PK 순서·반환 컬럼을 비교했습니다. 실행 계획에서는 비용이 큰 노드의 반복 범위가 페이지 크기 수준으로 줄었는지 확인했습니다. 여러 개선을 함께 적용한 측정 결과 첫 페이지는 약 20초에서 5초, 뒤 페이지는 약 100초에서 6초로 줄었습니다.
여러 수집 작업이 겹칠 때의 주문 정합성
멀티 채널 주문 수집에서는 각각의 작업이 정상이어도 실행이 겹치면서 같은 주문을 중복 수집할 수 있었습니다. 개별 수집 기능과 동시 실행의 정합성을 구분해서 다뤄야 했습니다.
Redis 분산 락으로 중복 수집 문제를 제어했습니다. 운영 중에는 쇼핑몰 API 변경과 배치 실패를 추적하고, Grafana와 OpenLens로 지표·파드·배포 상태를 확인했습니다.