컨퍼런스&기술블로그
글또
-
커스텀 메트릭 사용해보기
들어가며 안녕하세요.이번 글에서는 모니터링에 대해 다뤄보려고 합니다. 최근 회사에서 여러 서비스와 연동되는 기능을 개발하던 중, 기능 테스트 과정에서 “테스트 과정에서 보이는 수치들을 시각화할 수 있다면 검증이 훨씬 수월하겠다”는 생각을 하게 되었습니다.우선 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.11.24~ 토스 결제TIL 2025.11.26 23:51
여러 가지 결제 방법.토스 개발자 문서가 잘되어 있길래, 연습 삼아 연동을 해보려 했다.시작하기부터 잘 설명되어 있다.https://docs.tosspayments.com/guides/v2/get-started잘되어 있는데, 수수료도 쌀까? 토스에서 제공해 주는 결제 위젯이라는 게 있다. 인증과 승인을 알아야 한다.인증으로 front에서 결제를 먼저 하고, 서버가 맞는지 최종 승인을 하는 것이다.문서에도 금액 위변조에 대비해 프런트에서 결제요청하기 전에 서버에 결제 금액을 저장하고 승인 시 검증하라고 한다. 카드 등록해서 쓰는 자동 결제https://docs.tosspayments.com/reference#%EC%9E%90%EB%8F%99%EA%B2%B0%EC%A0%9C 구독 서비스 등에서 카드를 등록..
-
2025.11.08~09 외부api 7 + 장부TIL 2025.11.08 23:05
이어서 생각해 보니.. 장부와 주문주문의 결제와 장부의 결제는 따로 생각해야 한다.주문은 일반 유저가 결제를 진행하고, 월, 주 결제는 어드민, 시스템에 의해서 이뤄진다.주문은 결제 상태를 주문단위로 가질 수 있지만, 장부 결제는 결제 상태를 가게 단위로 관리해야 한다.장부 결제는 주체가 가게이기 때문에 하나의 외부 api가 끝나야 다음 api를 요청할 수 있도록 관리하는 것뿐이다. 분산락 + 상태를 관리하는 형태이다.그래서 상태 관리는 주문과 장부의 결제 상태 두 가지로 관리해야 이중결제를 막을 수 있다.실제 장부는 delta방식(다만 쿼리에서 last의 값을 사용)의 insert only로 관리되기 때문에 반영 순서는 상관없다. 각 상태관리를 상태머신을 코드로 관리하면 더 가독성이 나을 것 같다. 콜..
-
2025.11.06 외부api 6 + 정산TIL 2025.11.06 23:14
2025.11.01~2 외부API 5외부 API를 호출하는 로직에서는 다양한 실패 상황을 고려해야 한다.생각해볼 수 있는것들이 많다.단순한 예제로 외부 호출 후 DB작업을 한다고 해보자. 여러가지를 고려할 수 있다. 응답외부 호gisungcu.tistory.com이전 글에 이어서..사실 어느 정도 끝까지 왔다고 생각했는데, 새로운 요구 사항이 있다.위의 설계는 주문당 결제의 개념이다. 일반적인 이커머스는 대부분 이럴 것이다.근데, 지금의 상황은 좀 다르다. 월결제, 주결제로 운영이 되는 업체들이 있다. 그럼 이전의 설계에서 이중 결제를 막기 위해서 주문의 결제 상태를 관리했던 것처럼, 가게의 결제를 관리해야 한다.월 누적 금액을 가게의 장부에 기록하고 있기 때문이다.(결제 대기 상태의 주문 금액을 모두 ..
-
2025.11.05 ab testTIL 2025.11.05 22:11
2024.06.27 canary, AB testbliki: Canary ReleaseA canary release occurs when you roll out a new version of some software to a small subset of your user base to see if there are any problems before you make it available to everyone.martinfowler.com 매일 배포하는 팀이 되gisungcu.tistory.com과거 피쳐 토글을 활용한 ab 테스트를 구현했다.다른 회사는 어떻게 구현하는지 살펴본다.생각해보니 어떻게 구현보다 데이터로 뭘 볼지, 뭘 분석할지가 더 중요한 것 같다.a/b 테스트 목적에 따라 다르지만.예로 신..
-
2025.11.04 insert select not exists / event sourcing, current, historyTIL 2025.11.05 00:11
MySQL :: MySQL 8.4 Reference Manual :: 17.7.3 Locks Set by Different SQL Statements in InnoDB17.7.3 Locks Set by Different SQL Statements in InnoDB A locking read, an UPDATE, or a DELETE generally set record locks on every index record that is scanned in the processing of an SQL statement. It does not matter whether there are WHERE conditions indev.mysql.com insert문으로 레이스컨디션을 해결할 때가 있다.insert se..