분류 전체보기
-
커스텀 메트릭 사용해보기글또 2025. 8. 17. 12:06
들어가며 안녕하세요.이번 글에서는 모니터링에 대해 다뤄보려고 합니다. 최근 회사에서 여러 서비스와 연동되는 기능을 개발하던 중, 기능 테스트 과정에서 “테스트 과정에서 보이는 수치들을 시각화할 수 있다면 검증이 훨씬 수월하겠다”는 생각을 하게 되었습니다.우선 1차적으로는 그라파나를 활용해 모니터링 환경을 구축했습니다. 각 DB에 직접 연결해 SQL을 조회하고, Mixed 패널을 통해 여러 DB 데이터를 한 화면에서 확인할 수 있도록 했습니다. 하지만 이 방식에는 빈틈이 있었습니다. 구현 상 DB에서 하드 딜리트된 데이터는 로그로만 남아 검증에서 누락되는 경우가 있었고, 이를 추적하기가 까다로웠습니다.이 문제를 해결하기 위해 로그로 남는 정보들을 메트릭화할 수 없을까 고민하다가 알게 된 것이 바로 커스텀 ..
-
2025.07.14 분산 트랜잭션 구조로 생각TIL 2025. 7. 14. 22:33
이전 이야기를 이어서 해보면..재고 트래픽을 처리하기 위해서 레디스를 전면에 배치했다.주문 전에 재고를 확인하고 재고 확인이 되면 주문 서비스로 이벤트가 전파되는 식이었다.근데 구조를 다시 생각해 보니 역으로 주문 서비스에서 재고 서비스를 호출하는 것이 맞아 보인다. 만약 결제까지 생각해보자.지금 구조에서는 재고 차감 후 결제 이벤트를 호출하거나, 결제 API를 호출해야 하는데, 이상한 구조이다.결제와 재고는 동기적으로 처리하고 주문완료 후 예약한 재고를 마감하고, RDB에도 반영하는 절차가 되어야 할 거 같다. 결국 분산 트랜잭션을 주문 서비스 내부에서 직접 처리하거나, 앞단에 오케스트레이터를 두어 재고 차감 => 결제 => 주문 완료 이벤트 흐름을 관리해야한다.주문 서비스가 오케스트레이터의 역할까지 ..
-
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. 6. 29. 17:41
들어가며안녕하세요.이번 글에서는 가상의 시나리오를 통해 회사의 아키텍처를 어떻게 개선할 수 있을지 고민해 보고자 합니다. 저희 회사에는 주문 서비스와 창고 서비스가 존재합니다.이커머스에서 재고를 관리해 주문 수량을 제한하는 건 흔한 패턴입니다.하지만 저희 시스템은 고객이 주문할 때 재고를 실시간으로 확인하지 않습니다.이는 "무조건 배송"이라는 비즈니스 모델을 반영한 설계입니다.그렇다면, 만약 주문 시점에 재고를 체크해야 하고, 동시에 높은 트래픽이 몰린다면 어떤 문제가 발생할까요? 현재 구조현재 주문은 주문 서비스에 누적되며, 당일 주문 마감 시간이 되면 그제야 창고 서비스로 전달되어 배송 작업이 시작됩니다.창고 서비스는 사용자 트래픽을 직접 받지 않기 때문에 특정 시간 제외하고 트래픽으로부터 안전합니..
-
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에 대한 명령어 수가 증가하..