TIL
-
2025.06.19, 07.05 select for update, snapshotTIL 2025. 7. 5. 12:22
이벤트를 처리하면서 락이 필요한 상황이 생겼다.가능한 한 락을 피하려 했지만, 구조상 공유 자원에 접근해야 했고, 현재 트래픽 수준에서는 락을 잡아도 무방하다고 판단했다.단순 update, insert where절도 고려대상이다.처음에는 select ... for update로 선점 락을 거는 방식을 생각했다.현재 트랜잭션의 격리 수준은 REPEATABLE READ였고, 이 격리 수준에서는 첫 select 실행 시점에 스냅샷(read view)이 생성된다.이후 트랜잭션 내에서는 이 스냅샷을 기준으로 데이터가 보이는지 여부를 판단한다.select ... for update는 select지만 DML로 간주되기 때문에 스냅샷이 생성되지 않는다고 알고 있었다.그런데 예외적인 케이스가 있었다. 좀 더 테스트가 필..
-
2025.07.02 재고 관리 다시 생각TIL 2025. 7. 2. 22:08
높은 트래픽 환경에서의 현재 재고 처리 구조 고민들어가며안녕하세요.이번 글에서는 가상의 시나리오를 통해 회사의 아키텍처를 어떻게 개선할 수 있을지 고민해 보고자 합니다. 저희 회사에는 주문 서비스와 창고 서비스가 존재합니다.이커gisungcu.tistory.com 이전에 작성한 글과 프로젝트를 발전시키는 과정에서, 의문이 드는 구조가 생겼다.현재 구조에서는 재고를 담당하는 레디스 서비스가 주문까지 처리하는 형태다. 재고 차감이 완료된 후, 이벤트를 발행해 주문 서비스에 주문이 등록되는 방식이다. 그런데 이 흐름이 맞을까?결제가 붙게 된다면, 고민이 더 늘어난다.오히려 주문 서비스에서 재고 레디스를 호출하는게 자연스럽게 느껴진다.다만, 이 경우 timeout 같은 예외 상황을 고려해야한다.재고 차감은 성공..
-
2025.06.15 redis kafka shutdownTIL 2025. 6. 15. 21:41
2025.06.01 높은 부하와 재고2이제 좀 더 흐름으로 설명하자면..트래픽이 많을 경우, RDB를 통해서 재고 차감은 성능상의 문제가 발생할 수 있습니다. 또 높은 트래픽을 RDB에 그대로 노출하는 것은 위험합니다.그래서 selling stogisungcu.tistory.com애플리케이션이 redis에서 재고를 차감한 뒤, kafka에 메시지를 발행하기 전에 죽는 경우에 대한 이야기다.물론 graceful shutdown 시간을 충분히 확보하면 대부분의 상황은 방지할 수 있다.하지만 OOM과 같은 비정상 종료 상황에서는 graceful shutdown이 동작하지 않기 때문에, 최악의 상황도 대비해야 한다고 생각한다. grafana를 활용한 모니터링이 있을 거 같다.예를 들어, redis에 저장된 ..
-
2025.06.12~14 redis와 kafka , DB동기화TIL 2025. 6. 14. 20:00
어제 이어서 캐시 TTL에 대해 이야기해 보면...단순히 요청이 많아서 redis 메모리 사용량이 증가하는 것은 아니다.요청으로 인해 redis에 적재되는 재고 데이터가 많아지면서 메모리 사용량이 증가하는 것이다.오히려 특정 키에 반복적으로 접근하는 핫 키 패턴의 경우, Redis가 LRU 정책을 사용하더라도 해당 키는 지속적으로 접근되기 때문에 쉽게 제거되지 않는다.이 경우에는 DB와의 최신화 속도를 크게 걱정하지 않아도 된다.문제는 반대 상황. 핫 키가 아닌 다양한 재고 키들에 대한 요청이 지속적으로 발생하면 , redis에 새로운 키-밸류 쌍이 계속해서 적재되고, 기존 키가 삭제되는 속도보다 더 빠르게 새로운 키가 유입될 때, 메모리 사용량이 증가한다.요약하자면, 하나의 키가 반복 갱신되는 경우보다..
-
2025.06.11 redis kafka 동기화TIL 2025. 6. 11. 23:46
2025.05.05 재고 트래픽과 캐시 3궁금한 점이 생겼습니다.캐시를 이용할 때 빈틈이 있습니다.캐시와 DB 두 곳을 재고 데이터의 스토어로 사용할 때입니다. 그간 예제로 사용했던, 캐시 업데이트 후 이벤트 발행입니다. 여태 이야gisungcu.tistory.com Kafka 발행량이 많아지면서 DB에 최종 반영되기까지 시간이 지연될 수 있다. 이때 Redis의 캐시 키가 만료되면, DB를 직접 조회하게 되는데, Kafka 이벤트를 아직 모두 소비하지 못한 상태라면 최신 값을 조회하지 못하는 문제가 발생한다.이런 상황에서는 어떻게 대응하는 것이 좋을까?한 가지 방법으로, Redis에서 get 요청이 발생할 때마다 TTL을 갱신하는 것을 고려해봤다. 하지만 이 방식은 Redis에 대한 명령어 수가 증가하..
-
2025.06.09 lua script with clusterTIL 2025. 6. 9. 21:04
Redis lua script execution failed using ReadFrom.REPLICA_PREFERRED in redis cluster · Issue #1244 · redis/lettuceBug Report https://jira.spring.io/browse/DATAREDIS-908 Current Behavior Stack trace org.springframework.data.redis.RedisSystemException: Error in execution; nested exception is io.lettuce.core.Redi...github.com lua 스크립트관련해서 클러스터 환경일 때 read from과 같이 사용할 수 없다는 글을 보았다.처음 들었던 생각은 안되면 쓰기용 ..
-
2025.06.01 높은 부하와 재고2TIL 2025. 6. 1. 23:14
이제 좀 더 흐름으로 설명하자면..트래픽이 많을 경우, RDB를 통해서 재고 차감은 성능상의 문제가 발생할 수 있습니다. 또 높은 트래픽을 RDB에 그대로 노출하는 것은 위험합니다.그래서 selling stock을 담고 있는 redis를 전면에 배치합니다.이후에 RDB는 최종 일관성을 가져가는 것이지요. DB 스키마는 아래와 같습니다.order item에는 product와의 의존성 제거를 위해 컬럼으로 product name, price 등이 들어갑니다. 주문 당시의 금액, 이름을 나타냅니다. 주문 플로우에서 이벤트 멱등성을 지키기 위해 order만의 유니크한 값을 가져야 합니다.주문 생성은 order 서비스에서 하니 PK 말고 kafka에 발행하는 서비스가 유니크한 키를 생성해 이벤트에 동봉합니다.or..
-
2025.05.29 높은 부하와 재고TIL 2025. 5. 29. 23:51
우리 회사는 재고와 트래픽이 만날 일이 없다.고객이 주문할 때 재고를 확인하지 않기 때문이다. 이건 비즈니스 모델과도 연관이 있는데, 각설하겠다. 만약 우리의 시스템에서 주문 시 재고를 봐야 한다면 어떻게 해야 할까?또 부하가 높아진다면 어떤 설계를 해야 할까? 이런 생각에서 토이 프로젝트를 구상하고 있다. 아래는 간단한 DB 스키마이다. 실제 재고는 단순히 숫자로만 관리되지 않고 유통기한, 수량, 구매처 등등이 함께 관리되어야 한다.근데 이게 앞에 글에서도 말했지만 사용자에게 노출될 필요는 없다.사용자는 구매가능한 재고만 알고 있으면 된다.또 구매가능한 재고는 실제 물리 재고와 일치할 필요가 없다.사용자가 아직 입고되지 않은 재고를 팔 수도 있는 것이기 때문이다.그래서 물리 재고(stock)와 판매 재..