Side Projects

취업 준비를 하면서 이력서를 다듬다 보니 이런 고민이 생겼습니다.“내가 뭘 만들었는지는 쓸 수 있는데… 내가 뭘 개선했는지, 숫자로 증명할 수 있을까?”채용 공고나 기술 블로그를 보면 성과를 수치화해서 보여주는 사례가 많습니다.API 응답 속도 80% 단축트래픽 5배

사이드 프로젝트를 하면서 늘 고민이 있었습니다.“내 서비스가 잘 동작하는 건 알겠는데, 성능이나 장애는 어떻게 확인하지?”특히 EC2 프리티어 환경에서 돌리는 서비스라서,요청이 몰렸을 때 어디서 병목이 생기는지,장애가 발생했을 때 어디서 로그를 확인해야 하는지,성능을

들어가며1편에서는 모니터링을 왜 도입했는지, 그리고 OTEL + Grafana 스택을 띄우고 첫 번째 지표를 확인한 과정을 다뤘습니다.이번 2편에서는 Spring Boot 애플리케이션에서 실제로 메트릭과 로그를 수집하는 과정을 정리합니다.제가 선택한 도구들, 설정 과정

1편에서는 OTEL + Grafana 스택을 띄우고 첫 번째 지표 확인,2편에서는 Spring Boot → Prometheus/Loki 로그·메트릭 수집을 정리했습니다.이번 3편에서는,수집된 데이터(메트릭·로그)를 운영 친화적인 Grafana 대시보드로 정비하는 과정을

앞선 3편에서는 보이는 것(메트릭·로그) 을 다듬었다면, 이번 4편은 보이지 않던 요청 흐름(Trace) 을 꺼내는 단계다.나는 SDK 대신 Java Agent를 택했다. 코드 수정 없이 시작·중단이 가능해서, 실험 → 측정 → 개선 루프를 빠르게 돌리기에 유리했기 때

1~4편을 통해 수집·저장·탐색·Trace/Logs 연동까지 확보했다.이번 글은 “이제 그 데이터를 운영과 로컬에서 어떻게 다르게 활용했는가”에 집중한다.운영 = 빠른 감지와 추적로컬 = 세밀한 분석과 실험이 두 가지는 다르다는 걸 몸소 겪으면서, 대시보드 설계도 달라

이번 글은 제가 Pinup 서비스 /post/list/{storeId} API 병목을 실제로 어떻게 개선했는지 기록한 글입니다.앞선 글들(1편 OTEL + 모니터링 구축, 2편 수집기/대시보드 기본 구성, 5편 대시보드 커스텀)에서 관측 기반을 마련했다면, 이번엔 실제

요약@Transactional은 프록시(proxy) 경유 시만 적용. 자기호출(Self-Invocation) 은 미적용.REQUIRES_NEW는 외부 빈 호출일 때만 부모 Suspend → 자식 새 트랜잭션. 부모 미커밋은 자식에서 가시성 없음(FK 실패 가능).Hik

최근 목표는 트랜잭션을 공부 → 가설 세우기 → 실제 서비스에 적용 → 로그로 검증이었다.이번 글은 그중 “범위(Scope)”에만 집중한다. 요지는 간단하다.업로드 같은 I/O는 트랜잭션 밖에서 먼저 끝내고, DB에는 URL만 짧게 반영한다.그리고 auto-commit

이 문서는 PostgreSQL의 트랜잭션 격리 수준(Isolation Level)과 MVCC(Multi-Version Concurrency Control) 동작 방식을 종합적으로 정리한 자료입니다.단순한 표면적 차이뿐 아니라, xmin/xmax 기반의 스냅샷 판정·Va

MVCC는 “무엇이 보이느냐(가시성)”를, 락은 “누가 먼저 쓰느냐(경합)”을 다룬다.행 락과 대기 전략(NOWAIT / SKIP LOCKED)을 통해 “기다릴지 / 포기할지 / 건너뛸지”를 설계한다.타임아웃·데드락 표준으로 “영원 대기”를 방지하며, 인덱스·FK가 락

동시성(concurrency)을 다룰 때 가장 중요한 문제는“여러 트랜잭션이 동시에 같은 데이터를 수정하려 할 때어떻게 데이터의 일관성을 보장할 것인가?”이다.예를 들어 두 사용자가 같은 게시글에 동시에 좋아요를 누른다고 가정해보자.사용자 A: 좋아요 수를 10 → 1

2편에서 살펴본 낙관적 락은 “충돌을 허용하고, 커밋 시점에 감지한다.”이 방식은 동시성 제어의 유연성을 높이지만, OptimisticLockException이 발생하면 트랜잭션이 롤백된다.즉, 충돌이 발생한 사용자는 아무 일도 일어나지 않은 것처럼 보이게 된다.좋아요

이전 단계에서 ExponentialBackOffPolicy를 적용한 결과,VU 200 이상 구간에서 성공률이 급격히 하락하며 최대 응답 시간이 17초를 초과하는 현상이 나타났다.초기 설정은 다음과 같았다.initialInterval: 200~300msmultiplier

— Spring Cache 추상화 원리부터 JVM 내부 구조까지“왜 Caffeine인가?”이 글은 Spring Cache 추상화의 기본 원리부터 Caffeine 캐시의 내부 동작까지, JVM 수준에서 캐시가 어떻게 작동하는지를 완전히 해부합니다.2편에서는 이 개념을 기

PinUp의 게시글/이미지 조회 요청은 읽기 비율이 90% 이상으로,로컬 JVM 캐시만으로도 상당한 부하 절감이 가능했다.단, 단일 정책(caffeine.spec)으로는 다음과 같은 문제점이 있었다.이에 따라 Spring Cache의 기본 구성을 확장하여“타입 안전한