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