통계를 세던 사람이
서버를 세우고 있습니다

자바·스프링으로 API를 만드는 백엔드 신입 자리를 찾고 있습니다.

주문·정산처럼 숫자가 틀리면 안 되는 도메인에 관심이 있습니다. 통계학을 전공하며 데이터가 어긋났을 때 원인을 되짚는 일을 오래 해 봤고, 그 습관이 서버 쪽에서도 그대로 쓰인다고 느낍니다.

동시에 들어온 요청이 같은 자원을 건드릴 때 무엇이 어긋나는지를 보고 있습니다.

재고 차감에서 수량이 음수가 된 적이 있었고, 그때부터 잠금과 트랜잭션 경계를 다시 공부했습니다. 아래 프로젝트의 절반은 그 뒤에 다시 쓴 것입니다.

모르는 것은 모른다고 적어 둡니다. 대신 어디까지 확인했는지를 함께 남깁니다.

팀 프로젝트에서는 주로 API 설계와 리뷰를 맡았습니다. 규칙을 먼저 정하고 시작하는 편이 나중에 덜 다툰다는 것을 네 번의 팀 작업에서 배웠습니다.

네 개 모두 코드가 공개되어 있습니다. 카드를 누르면 무엇을 왜 그렇게 했는지가 펼쳐집니다.

혼자 만든 것과 팀으로 만든 것을 나눠 적었고, 팀 프로젝트는 제가 맡은 부분만 적었습니다.

증상 — 주문 테스트를 200건 동시에 넣었더니 재고가 -3이 됐습니다. 한 건씩 넣을 때는 멀쩡했습니다.

원인을 좁힌 과정 — 먼저 로그에 재고 조회값과 차감 후 값을 함께 찍었습니다. 같은 재고값을 여러 요청이 동시에 읽고 있었습니다. 조회와 차감 사이가 원자적이지 않다는 뜻이었습니다.

고친 방법 — 상품 단위로 Redis 잠금을 잡고, 잠금 안에서만 조회·차감을 하도록 바꿨습니다. 데이터베이스 비관적 잠금도 후보였지만, 재고 서비스가 나중에 분리될 예정이라 서비스 밖에서도 통하는 쪽을 골랐습니다.

남은 숙제 — 잠금을 잡지 못했을 때의 대기 시간을 아직 상수로 두고 있습니다. 부하에 따라 조정하는 방법을 찾고 있습니다.

증상 — 새벽 2시에 시작한 정산 배치가 8시가 넘어 끝났습니다. 데이터는 맞았지만 시간이 문제였습니다.

확인한 것 — 10만 건을 한 건씩 INSERT하고 있었습니다. 쿼리 자체는 빨랐지만 왕복 횟수가 10만 번이었습니다.

고친 방법 — 1,000건씩 묶어 쓰도록 청크 단위를 잡고, 커넥션을 재사용하게 했습니다. 묶음 크기는 100·500·1,000·5,000으로 재 보고 정했습니다. 5,000부터는 메모리만 늘고 시간은 거의 줄지 않았습니다.

결과와 배운 것 — 52분에서 14분이 됐습니다. 느린 원인이 쿼리가 아니라 횟수일 수 있다는 것을 이때 처음 알았습니다.