주문·어드민 성능 문제의 분석 기준

주문과 관리자 기능의 성능 문제를 정리하면서 느린 쿼리뿐 아니라 요청이 지나가는 흐름을 함께 봤습니다. 조회와 가공이 같은 트랜잭션에 묶여 있거나, 관리자 기능이 대량의 자료를 다루면서 주문 처리와 자원을 공유하는 경우가 있었기 때문입니다.

당시 메모를 바탕으로 어떤 부분을 병목으로 구분했는지 정리했습니다. 이 글에서는 상세한 개선율보다 분석 대상과 적용 범위를 중심으로 설명합니다.

응답 지연을 나누는 기준

관리자 조회가 느릴 때도 원인은 같지 않았습니다. 트랜잭션이 오래 유지되는지, 조회 후 가공이 오래 걸리는지, DB에서 대기하는지를 나눠 볼 필요가 있었습니다.

같은 응답 시간이라도 DB 대기와 애플리케이션 처리의 비중이 다르면 수정할 곳도 달라집니다. 요청을 따라가며 트랜잭션과 쿼리를 같이 확인한 이유입니다.

재고 차감과 읽기 부하

주문에서는 같은 상품으로 요청이 몰릴 때 재고 차감의 락 경합을 확인해야 했습니다. range lock 성격의 경쟁이 있는 구간은 조회 쿼리 하나를 바꾸는 것만으로 설명하기 어려웠습니다.

한편 관리자 조회와 주문 조회의 읽기 부하를 분산하는 작업도 진행했습니다. ProxySQL 기반 Read/Write 분리와 트랜잭션 설정 조정은 이 범위에서 다뤘습니다. 읽기를 분리하는 것과 같은 재고에 대한 쓰기 경쟁을 없애는 것은 다른 문제였습니다.

큐로 재고 차감을 처리하는 방향은 후속 계획에 가까웠습니다. 당시 구현까지 이어진 결과로 포함하지 않았습니다.

개선 항목과 확인 범위

메모에는 Admin console과 주문 조회의 개선 항목이 따로 남아 있습니다. 화면 응답만 비교하기보다 어떤 요청에서 어떤 조회와 트랜잭션을 바꿨는지 함께 남기는 것이 필요했습니다.

주문과 관리자 기능을 같은 성능 문제로 묶기보다, 재고 차감의 락과 조회 부하, 트랜잭션 처리 범위를 나눠 정리했습니다. 이미 반영한 변경과 뒤에 검토할 개선안도 구분했습니다.

이 글에는 상세한 변경 전후 비교 로그를 담지 않았습니다. 따라서 특정 개선이 모든 기능에 같은 효과를 냈다고 볼 수는 없습니다. 다른 기능에 적용할 때도 요청과 부하 조건을 맞춘 비교가 필요합니다.

다음 시리즈에서는 성능 문제와 연결되는 배치 스케줄러 운영을 다룹니다.