[Loop:PAK] 4주차 회고

이번 주는 DB 수준에서의 동시성 제어를 주문 로직에 적용하는 작업을 진행했다. 단순히 @Transactional을 거는 것 외에, 락 전략을 어떻게 선택할지와 그 이유를 명확히 하기 위해 DB의 트랜잭션과 격리 수준, MVCC 구조, Undo Log 동작 방식 등을 먼저 학습해 보았다. 이 과정을 거치니 락이 실제로 어떤 상황에서 동작하고 성능에 어떤 영향을 주는지 더 이해가 잘 됐다.

주문 로직에서 락이 필요한 지점은 쿠폰 사용, 포인트 사용 그리고 재고 차감 부분이었다. 각 자원의 특성과 경합 가능성을 고려해서 쿠폰과 포인트는 낙관적 락, 재고는 비관적 락을 적용했다. 특히 포인트는 두 방식 다 사용해도 될 것 같아 어떤 락을 선택할지 고민을 많이 했었다. 1000건 정도의 요청이 들어올 것을 가정해 테스트를 진행하여 요청시간을 보고 낙관적 락으로 최종 선택했다. 그런데 아직 API를 작성하지 않아 부하테스트를 진행한 것이 아니라 제대로 된 비교결과가 되지 못한 것 같아 조금 아쉬웠다. 여기는 나중에 API 작성하게 되면 추가로 테스트를 해봐야겠다.

테스트는 MySQL InnoDB 환경에서 단일 인스턴스를 가정하고, CountDownLatch와 ExecutorService를 사용해 멀티 스레드 상황을 시뮬레이션했다. 결과로는 성공 요청 수, 실패 요청 수, DB 에 반영된 최종 상태를 검증했다. 테스트 결과 일단 단일 인스턴스에서는 DB 락 전략과 트랜잭션 범위 설정만 잘한다면 안정적으로 굴릴 수 있지 않을까 라는 생각도 들었다. 하지만 보통 운영은 멀티 인스턴스를 사용하니 추가로 그런 환경을 고려해야 할 필요성도 느꼈다.

이번 주는 읽기, 쓰기 상황에서 정합성을 유지하는 것에 집중했다. DB 수준의 락 전략을 적용해 데이터를 처리하도록 수정하고 테스트를 통해 검증했다. 다음주는 한걸음 더 나아가서 읽기 성능 최적화에 집중해보려 한다. DB 인덱스를 설정하고, 필요한 경우 캐시를 적용해 읽기 부하를 줄이는 전략을 시도해 볼 예정이다.