@Transactional AOP 로직과 분산락 AOP 을 중첩해서 사용하는 경우에 @Transactional 을 나중에 실행시키고 싶었다. 이를 적용하기 위해 검토했던 코드 기록이다. 해당 내용은 kurly techblog 에서 분산락 내용을 보고 적용하는 과정에서 든 고민이다. 참고자료 : 풀필먼트 입고 서비스팀에서 분산락을 사용하는 방법 - Spring Redissonhttps://helloworld.kurly.com/blog/distributed-redisson-lock/ [1] 분산락은 락 점유/해제 블록 안에서 Transaction 를 묶어야 한다.분산락을 사용해야 하는 이유는 무엇일까? 그 이유는 분산 환경의 동시성 제어를 위함이다. 분산락은 임계 영역에 다른 요청이 접근을 막아 여러 컴..
전체 글

·test
[1] DB monitoringDB metric 을 학습하기 위해 로컬 환경에서 mysqld-exporter + prometheus + grapana 를 기반한 DB monitoring 구축한 내용에 관해 기록하고자 한다. (1) mysql-exporterPrometheus와 함께 사용되는 MySQL/MariaDB용 메트릭 수집 도구이다. MySQL 서버의 성능 및 상태 정보를 Prometheus가 수집할 수 있도록 HTTP 엔드포인트를 통해 노출하는 역할을 한다. InnoDB, 버퍼 풀, 트랜잭션, 쿼리 캐시, 연결 상태 등 다양한 지표 제공하며, Prometheus와 연동 가능해 mysqld-exporter의 메트릭을 가져와 시각화 및 경고 설정할 수 있다. (2) PrometheusPrometh..

[1] Pub/Sub Pattern 요약Pub/Sub (Publish/Subscribe)는 비동기 메시징 방식으로, 발행자(Publisher)가 메시지를 주제(Topic)에 게시하고, 구독자(Subscriber)가 해당 주제를 구독하여 메시지를 받는 방식이다. 이 패턴은 서버리스 및 마이크로서비스 아키텍처에서 자주 사용됩니다. 주요 개념은 다음과 같다 메시지: 주고받는 독립적인 통신 단위.발행자(Publisher): 메시지를 보내는 주체.구독자(Subscriber): 메시지를 받는 주체.주제(Topic): 특정 주제에 대한 메시지를 포함하는 채널.Pub/Sub의 핵심은 발행자와 구독자가 서로의 존재를 모를 수 있다는 점입니다. 즉, 발행자는 구독자가 누구인지 알 필요 없고, 구독자는 발행자가 누구인지 알..

콘서트 대기열 서비스를 개발하면서 토큰을 만료 스케줄링을 작업하면서 고민했던 내용이다. 같은 시간에 분산 환경에서 애플리케이션 서버들의 스케줄링 중복 실행을 방지하기 위해 shed lock 을 적용했다.처음 적용해본 개념에 관해 정리하기 위해 작성한 글이다. GitHub - pbg0205/concertContribute to pbg0205/concert development by creating an account on GitHub.github.com [1] ShedLock?ShedLock은 분산 시스템에서 스케줄러 작업(Scheduled Tasks)의 중복 실행 방지를 위해 사용되는 라이브러리이다. 여러 인스턴스에서 실행되는 애플리케이션이 동일한 스케줄러 작업을 동시에 실행하지 않도록 락(Loc..

[1] InnoDB 기본키와 B-Tree(1) InnoDB 기본 키의 중요성InnoDB 기본 키는 인덱스 정렬 저장 엔진(Index-Organized Storage Engine) 이다. 이는 기본 키를 B-Tree 를 사용해 데이터를 저장하며, 모든 InnoDB 테이블에 기본 키가 필수이다. 보조 인덱스 또한 B-Tree 로 구성되면, 여기서 저장된 값은 기본 키를 통해 데이터에 접근하게 된다. (2) B-TreeB-Tree 는 디스크와 같은 블록 디바이스에서 효율적으로 동작하도록 설계된 데이터 구조이다. 디스크에서 단일 바이트를 임의의 위치에서 읽는 데 소요하는 시간은 큰 블록을 읽는 데 걸리는 시간과 크게 다르지 않는 장점이 있다. 루트 노드로 부터 시작해 검색 키를 비교해 중간 노드, 데이터에 존재..
⚓️ 항해 플러스 백엔드 과정의 Chapter02 를 마무리하며 벌써 중간 지점이 지났다.앞으로 5주간의 항해를 위해 '콘서트 대기열 시스템' 이라는 주제의 서비스 뼈대를 완성했다.중간 지점을 지나오며 Chapter02 에서 경험했던 내용들에 관해 적어 보려고 한다. GitHub - pbg0205/concertContribute to pbg0205/concert development by creating an account on GitHub.github.com 1. 🎫 콘서트 대기열 시스템을 구현해보자. 우리조는 '콘서트 대기열 시스템' 서비스를 선택했다. 이번 기수에 e-커머스 서비스 요구사항이 개선되어 고민이 많았다. 하지만 가상 면접 사례로 배우는 대규모 시스템 설계 기초를 읽으며 대기열 서..