이번 포스팅을 작성하게 된 이유와 직접 실험을 해본 이유는 아래와 같다.이유: 지금까지는 `Redis`를 활용한 `Redisson Lock`으로 주로 분산 락을 구현해왔다.그저 `MySQL`의 `Named Lock`이나 `PostgreSQL`의 `pg_advisory_lock`, `pg_advisory_xact_lock`를 몰라서 그랬던 것은 아니었다.(학습해오며 음.. 이런게 있구나하고 이해하고 기억하고 넘어갔었다.)주로 `Redis`를 활용해 온 이유는 창피하지만 `Docker`를 공부 및 활용해오다보니 자연스럽게 계속하여손쉽게 `Redis`를 캐시(토큰 저장소), 분산 락 등으로 사용해왔기 때문이다. 하지만, 내가 회사에 다니고 여러 팀, 토이 프로젝트를 진행해보며 느낀건 `Redis`는 저렴하지 ..

`Spring Batch` 관련 두번째 포스팅을 진행하려고 한다. 이번 포스팅은 내가 `JECT`라는 개발 동아리에 참가하면서 `Youtube Data API`를 사용하며 접했고, 개선해온 `Spring Batch` 관련 지식을 공유하기 위해 작성했다. 바로 시작해보자.단일 스레드에서 왜 파티셔닝을 적용?로컬 파티셔닝을 적용한 Step 내용은 매일 인기 카테고리 영상에 등재된 채널들의 각종 Metric 정보들의 INSERT/UPDATE 작업이었다. 초기에 생각했을 땐 "음.. 오래걸릴 것 같긴하지만, 아직 초기이기도 하고 엄청 오래걸릴 것 같지는 않은데" 였다.그렇기에 내가 알고 있는 방법인 단일 스레드에서 `Step`을 돌리는 방식으로 그대로 구현을 했다. 아래는 관련 코드다. Youtube Data ..

오늘 작성할 포스팅은 포스팅 제목에 적혀있는 것처럼 `Spring Batch`에서 `JPA`와 기반의 Reader인`JpaPagingItemReader`의 동작 방식과 한계를 알고, 그 부분을 보완하기 위한 `CustomNoOffsetPagingItemReader`를 기록하고 정리하기 위한 포스팅이다. JpaPagingItemReader 란?`JpaPagingItemReader`는 이름 그대로 데이터를 페이지 단위로 처리하는 `ItemReader`다.전체 데이터를 일정 수의 페이지만큼 읽고 내가 블로그에서 직접 다루지는 않았지만 `JdbcPagingItemReader`와 유사하다. 하지만, 내부적으로 JPA 구현체를 사용한다는 점, 그리고 가장 중요한 페이징 방식에서 `JdbcPagingItemReade..

사실 일전에 블로그 포스팅에서 SSE에 다룬적이 있다. 2024.11.04 - [Spring/WebSocket] - [Spring WebSocket] SSE vs WebSocket [Spring WebSocket] SSE vs WebSocketSSE와 WebSocket, 그들은 왜 실시간 통신 환경에서 자주 비교될까?우리가 알림과 실시간 채팅 같은 서비스를 구현할 때, 우리는 자연스럽게 두 가지 기술 사이에서 고민한다.`SSE`와 `WebSocket`은 각기hdbstn3055.tistory.com 하지만, 회사에서 패션 리테일 챗봇(Spring Boot, FastAPI) 사용 간 SSE를 사용할 일이 많았기에,그 속에서 얻은 지식, 고민, 결정을 정리하고자 이렇게 포스팅을 하게 되었다. 크게 아래 순서로..

우리는 지난 포스팅에서 `Redis` 모니터링 아키텍처를 설계했다. 2026.03.24 - [DB/Redis] - [Redis] Redis를 Prometheus와 Grafana를 활용해 모니터링 해보자 - 1 이번 포스팅에서는 잘 알려진 `14091` 대시보드의 각 요소에 관해서 설명하려고 한다. 해당 대시보드를 통해 `Redis`가 활용되는 전체적인 모습을 파악할 수 있기 때문에 따로 포스팅하게 되었다. Redis에 부하를 준 후 그라파나에 보이는 차트 Commands per second초당 명령어 처리 수를 볼 수 있는 차트로 TPS라고 생각하면 편하다.Redis가 1초에 몇개의 명령어를 처리하고 있는지 볼 수 있다.해당 차트의 `View`를 보면 어떤 명령어가 많이 사용되는지 색갈별로 볼 수 있다..

우리는 `Redis` 활용시 `INFO` 명령어를 통해 메모리 사용량, 최대 메모리 등을 파악할 수 있다. 하지만, `INFO` 명령어는 `현재 시점`의 상태만 텍스트 형태로 보여주기 때문에`Redis`가 지금 사용 의도에 맞게 잘 사용되고 있는지, 캐시 히트 비율이 지속적으로 높은 지 등을 한눈에 파악하기에는 어렵다. 특히 실무에서는 아래 기능이 필수적이다.과거 데이터 추적: "서버가 느려졌다.", "갑자기 Redis 서버가 OOM으로 죽었다.", "Redis 서버 커넥션이 갑자기 폭증했다." 등을 확인하기 위해서는 과거의 데이터가 필요하다.시각화: 만약 시간대별로 텍스트로만 수치를 파악한다면 정말 가독성이 안좋을 것이다. 따라서, 우리는 차트와 같은 시각화 정보를 봐야 즉각적인 이상 탐지가 가능하다...