컨퍼런스&기술블로그
글또
-
높은 트래픽 환경에서의 현재 재고 처리 구조 고민
들어가며안녕하세요.이번 글에서는 가상의 시나리오를 통해 회사의 아키텍처를 어떻게 개선할 수 있을지 고민해 보고자 합니다. 저희 회사에는 주문 서비스와 창고 서비스가 존재합니다.이커머스에서 재고를 관리해 주문 수량을 제한하는 건 흔한 패턴입니다.하지만 저희 시스템은 고객이 주문할 때 재고를 실시간으로 확인하지 않습니다.이는 "무조건 배송"이라는 비즈니스 모델을 반영한 설계입니다.그렇다면, 만약 주문 시점에 재고를 체크해야 하고, 동시에 높은 트래픽이 몰린다면 어떤 문제가 발생할까요? 현재 구조현재 주문은 주문 서비스에 누적되며, 당일 주문 마감 시간이 되면 그제야 창고 서비스로 전달되어 배송 작업이 시작됩니다.창고 서비스는 사용자 트래픽을 직접 받지 않기 때문에 특정 시간 제외하고 트래픽으로부터 안전합니..
-
카프카 부하 분산: 동적 쓰로틀링과 캐시
들어가며안녕하세요.이번 글에서는 카프카 기반 쓰로틀링에 대해 이야기 해보려합니다. 서비스 특성상 특정 시간대에 카프카 트래픽이 집중되며 DB 병목이 발생하는 문제가 있었습니다.단순히 서버를 증설하는 방식보다는 현재 가지고 있는 자원을 활용해 문제를 해결하고자 했습니다. 해결 전략일반적으로 부하 해결을 위해 자주 사용하는 방법은 캐시, DB 읽기/쓰기 분리, 쓰로틀링 적용입니다.저희 서비스에는 아직 글로벌 캐시를 적용하지 않았습니다.또 트래픽이 항상 높은 게 아니라 특정 시점에만 몰리는 구조였기 때문에, 상시 유지되는 캐시는 오히려 불필요한 관리 포인트 증가라고 생각했습니다.결국, 현재 리소스 내에서 문제를 해결할 수 있는 방법으로 동적 쓰로틀링 전략을 선택하게 되었고, 필요에 따라 캐시를 결합해 트..
-
글또 10기 소감
안녕하세요.이번에는 글또 10기를 마무리하며 몇 자 적어보려 합니다. 벌써 지난 7기, 8기, 9기를 지나 10기를 마무리하는 시간이 다가왔습니다. 시간이 참 빠릅니다.10기를 시작할 때 “좋은 기술 글을 쓰자”는 목표를 품었지만, 실제로 기술 글은 많이 쓰지는 못했습니다.그럼에도 불구하고 열심히 글을 작성하면서 많은 배움이 있었고 만족감을 느낍니다.회사에서는 다양한 문제 상황이 발생할 때마다 이를 해결하는 과정을 기록하는 것을 좋아합니다.새로운 기술이나 이론을 찾아 정리하는 것도 물론 의미가 있지만, 실제로 겪은 문제를 해결하는 과정을 글로 남기며 공부하는 것이 더 효과적이라 생각하기 때문입니다.이번에도 회사에서 발생한 DB 장애, 애플리케이션 장애 등 여러 가지 문제 상황에 대해 글을 작성하였고, 그..
-
DB 장애 분석: Galera Cluster Segfault
들어가며안녕하세요.이번에는 DB장애 분석 글을 써보려합니다.현재 저희 회사에서 가장 큰 이슈는 DB 장애 문제였고, 이를 해결해 보면 좋겠다고 생각했습니다. 제가 문제를 해결하기 위해 시도한 방법과 과정을 써보고자 합니다. 글의 순서는 다음과 같습니다.문제 상황의심 사례 분석메모리 부족, 많은 스레드 부하: 부하 테스트 (Sysbench 활용)특정 시각의 배치 작업, 시나리오 테스트 (K6 활용)개선점마무리 문제 상황 저희 회사는 MariaDB를 EC2에서 구동하며 Galera Cluster를 사용하고 있습니다.그중 일부 노드가 간헐적으로 다운되는 현상이 발생했습니다.Cluster 내 3개 노드 중 일부가 장애를 일으켜도 동작은 가능했지만, Segmentation Fault(Segfault) 에러..
-
개발자를 위한 커리어 관리 핸드북
해당 리뷰는 한빛미디어의 후원으로 책을 받아 작성합니다. 들어가며안녕하세요.오늘은 책 한 권을 읽고 느낀 점을 적어보려고 합니다.운 좋게 한빛미디어에서 책을 후원해 주셔서 읽게 되었습니다.여러 후보 중에서 이 책을 선택한 이유는 다음과 같습니다."내가 잘하고 있는 걸까? 앞으로 나의 커리어가 정체되지는 않을까?"책을 읽고 나니 답변을 얻기보다는 질문이 바뀌었습니다."나에게 정말 중요한 것은 무엇일까?" 개발자를 위한 커리어 관리 핸드북 - 예스241:1 멘토링하듯 알려주는 커리어 관리 노하우* 네이버, 배민, 토스, 틱톡, 트위니 등 국내 개발자 10인의 커리어 이야기 수록커리어가 어느 시점에 이르면, 코드를 다루는 것보다 중요하고 복잡한www.yes24.com 이직의 신호제가 생각하는 회사의 일은..
최신 글
-
2025.06.19, 07.05 select for update, snapshotTIL 2025.07.05 12:22
이벤트를 처리하면서 락이 필요한 상황이 생겼다.가능한 한 락을 피하려 했지만, 구조상 공유 자원에 접근해야 했고, 현재 트래픽 수준에서는 락을 잡아도 무방하다고 판단했다.단순 update, insert where절도 고려대상이다.처음에는 select ... for update로 선점 락을 거는 방식을 생각했다.현재 트랜잭션의 격리 수준은 REPEATABLE READ였고, 이 격리 수준에서는 첫 select 실행 시점에 스냅샷(read view)이 생성된다.이후 트랜잭션 내에서는 이 스냅샷을 기준으로 데이터가 보이는지 여부를 판단한다.select ... for update는 select지만 DML로 간주되기 때문에 스냅샷이 생성되지 않는다고 알고 있었다.그런데 예외적인 케이스가 있었다. 좀 더 테스트가 필..
-
2025.07.02 재고 관리 다시 생각TIL 2025.07.02 22:08
높은 트래픽 환경에서의 현재 재고 처리 구조 고민들어가며안녕하세요.이번 글에서는 가상의 시나리오를 통해 회사의 아키텍처를 어떻게 개선할 수 있을지 고민해 보고자 합니다. 저희 회사에는 주문 서비스와 창고 서비스가 존재합니다.이커gisungcu.tistory.com 이전에 작성한 글과 프로젝트를 발전시키는 과정에서, 의문이 드는 구조가 생겼다.현재 구조에서는 재고를 담당하는 레디스 서비스가 주문까지 처리하는 형태다. 재고 차감이 완료된 후, 이벤트를 발행해 주문 서비스에 주문이 등록되는 방식이다. 그런데 이 흐름이 맞을까?결제가 붙게 된다면, 고민이 더 늘어난다.오히려 주문 서비스에서 재고 레디스를 호출하는게 자연스럽게 느껴진다.다만, 이 경우 timeout 같은 예외 상황을 고려해야한다.재고 차감은 성공..
-
높은 트래픽 환경에서의 현재 재고 처리 구조 고민글또 2025.06.29 17:41
들어가며안녕하세요.이번 글에서는 가상의 시나리오를 통해 회사의 아키텍처를 어떻게 개선할 수 있을지 고민해 보고자 합니다. 저희 회사에는 주문 서비스와 창고 서비스가 존재합니다.이커머스에서 재고를 관리해 주문 수량을 제한하는 건 흔한 패턴입니다.하지만 저희 시스템은 고객이 주문할 때 재고를 실시간으로 확인하지 않습니다.이는 "무조건 배송"이라는 비즈니스 모델을 반영한 설계입니다.그렇다면, 만약 주문 시점에 재고를 체크해야 하고, 동시에 높은 트래픽이 몰린다면 어떤 문제가 발생할까요? 현재 구조현재 주문은 주문 서비스에 누적되며, 당일 주문 마감 시간이 되면 그제야 창고 서비스로 전달되어 배송 작업이 시작됩니다.창고 서비스는 사용자 트래픽을 직접 받지 않기 때문에 특정 시간 제외하고 트래픽으로부터 안전합니..
-
2025.06.15 redis kafka shutdownTIL 2025.06.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.06.14 20:00
어제 이어서 캐시 TTL에 대해 이야기해 보면...단순히 요청이 많아서 redis 메모리 사용량이 증가하는 것은 아니다.요청으로 인해 redis에 적재되는 재고 데이터가 많아지면서 메모리 사용량이 증가하는 것이다.오히려 특정 키에 반복적으로 접근하는 핫 키 패턴의 경우, Redis가 LRU 정책을 사용하더라도 해당 키는 지속적으로 접근되기 때문에 쉽게 제거되지 않는다.이 경우에는 DB와의 최신화 속도를 크게 걱정하지 않아도 된다.문제는 반대 상황. 핫 키가 아닌 다양한 재고 키들에 대한 요청이 지속적으로 발생하면 , redis에 새로운 키-밸류 쌍이 계속해서 적재되고, 기존 키가 삭제되는 속도보다 더 빠르게 새로운 키가 유입될 때, 메모리 사용량이 증가한다.요약하자면, 하나의 키가 반복 갱신되는 경우보다..