1. 설계 배경

PinUp의 게시글/이미지 조회 요청은 읽기 비율이 90% 이상으로,

로컬 JVM 캐시만으로도 상당한 부하 절감이 가능했다.

단, 단일 정책(caffeine.spec)으로는 다음과 같은 문제점이 있었다.

이에 따라 Spring Cache의 기본 구성을 확장하여

“타입 안전한 정책 바인딩 + per-cache 주입 + 이벤트 기반 무효화”를 설계했다.

목표

• L1(Local Cache)만으로도 높은 캐시 적중률 확보
• 추후 L2(Redis)로 자연스럽게 확장 가능한 구조 설계

1-2. 참고 사례

1-3. 설계 개요

캐시 설계 순서

2부. 설계편 — 정책·코드 구조

2-1) 설계 원칙(Design Checklist)

관측성 SLO(초기안)

• SLO-1: URI p95(상세 조회) 목표치 설정 및 추적
• SLO-2: Cache Hit Rate(캐시별) 목표치 설정 및 추적
• SLO-3: Evictions/Removals 이벤트율(업데이트 직후 스파이크 정상 여부)
• SLO-4: Build/Load 비용 p95(미스 후 로드 시간)
• L2 도입 시 추가: 전파 지연(무효화 Pub/Sub → 모든 인스턴스 적용 ≤ 1s), L2 RTT ≤ 20ms, L2 Hit ≥ 0.95

2-2) 정책 관리 구조 및 설계 비교

캐시 정책은 단일 전역 정책(spec)으로는 한계가 있으므로,

PinUp에서는 아래 구조로 설계했다.

spring:
  cache:
    type: caffeine
    strict: true
    app:
      defaults: { maximumSize: 40000, ttlSec: 300 }
      caches:
        "post:detail": { maximumSize: 20000, ttlSec: 300 }
        "post:images": { maximumSize: 20000, ttlSec: 1800 }

이 구조를 통해 각 캐시에 다른 TTL·Size 정책을 적용할 수 있으며,

운영 중에도 타입 안전하게 정책을 수정·확장할 수 있다.

왜 caffeine.spec 대신 spring.cache.app 구조인가

요약하면,

caffeine.spec은 “설정” 중심,

spring.cache.app은 “설계” 중심이다.

전자는 단순히 Builder에 파라미터를 전달하는 문자열 기반 설정이며,

후자는 캐시 정책을 체계적으로 관리하기 위한 정책 저장소 계층이다.

PinUp에서는 운영 중 TTL 변경, 캐시 추가·삭제, 통계 설정 등을

명시적이고 안전하게 관리하기 위해 spring.cache.app 구조를 채택했다.

병행 불가능 및 실무 기준 정리

두 구조(caffeine.spec / app.*)는 병행이 불가능하다.

Spring Boot 자동 구성과 수동 CacheManager 빌더가 동시에 실행되어

Caffeine.newBuilder() 설정이 중복 적용되며,

maximumSize()나 expireAfterWrite() 중복 지정 시

IllegalStateException이 발생할 수 있다.

⚠️ Caffeine Builder는 불변(immutable) 객체이므로,

동일 속성 재설정은 런타임 예외로 이어진다.

2-3) 바인딩 활성화 (중요 한 줄)

AppCacheProps가 실제로 바인딩되도록 아래 둘 중 하나는 반드시 선언해야 한다.

이 줄이 없으면 props.caches()가 null → 부팅 시 NPE 발생.

// 방법 A
@Configuration
@EnableConfigurationProperties(AppCacheProps.class)
public class CacheConfig {}

// 방법 B
@SpringBootApplication
@ConfigurationPropertiesScan  // @ConfigurationProperties 자동 스캔
public class PinupApplication {}

// AppCacheProps — 정책 바인딩 DTO
@ConfigurationProperties(prefix = "spring.cache.app")
public record AppCacheProps(Defaults defaults, Map<String, Spec> caches) {
  public record Defaults(Long maximumSize, Integer ttlSec) {}
  public record Spec(Long maximumSize, Integer ttlSec) {}
}

역할

• application.yml의 캐시 정책을 타입 안전하게 바인딩
• “캐시 정책용 DTO”처럼 작동
• 부팅 시 오타/누락 방지, 이후 CacheConfig에서 바로 props.caches() 접근 가능

2-4) CacheConfig — 정책 주입형 CacheManager

@Configuration
@EnableConfigurationProperties(AppCacheProps.class)
public class CacheConfig {
  @Bean
  public CacheManager cacheManager(AppCacheProps props) {
    return new CaffeineCacheManager() {
      { setAllowNullValues(false); setCacheNames(props.caches().keySet()); }
      @Override protected CaffeineCache createCaffeineCache(String name) {
        var b = Caffeine.newBuilder().recordStats();
        var d = props.defaults(); var s = props.caches().get(name);
        Long max = (s!=null&&s.maximumSize()!=null)? s.maximumSize() : (d!=null? d.maximumSize():null);
        Integer ttl= (s!=null&&s.ttlSec()!=null)? s.ttlSec() : (d!=null? d.ttlSec():null);
        if (max!=null) b = b.maximumSize(max);
        if (ttl!=null) b = b.expireAfterWrite(Duration.ofSeconds(ttl));
        return new CaffeineCache(name, b.build(), false);
      }
    };
  }
}

주의

• maximumSize() / expireAfterWrite()는 한 번만 설정 가능
• “한 트리”로 합쳐 쓰는 경우 특히 중복 호출 금지
• 최종값 계산 → 1회 세팅 패턴 사용

2-5) 캐시 어노테이션 의미와 핵심 속성, SpEL 키

어노테이션 한 줄 정의

• @Cacheable: 메서드 호출 전 캐시 조회, 미스면 실행 후 결과 저장
• @CachePut: 메서드를 항상 실행하고 반환 결과로 캐시 갱신
• @CacheEvict: 캐시 항목/전체 제거(운영 시 전체 제거는 신중)
• @Caching: 한 메서드에 여러 캐시 어노테이션 조합

공통/핵심 속성(짧게)

• value / cacheNames: 캐시 이름(키 스페이스)
• key: SpEL로 키 지정(생략 시 파라미터 기반 SimpleKey 자동 생성)
• condition: 호출 전 “캐싱 시도 여부”(입력 기준, #result 사용 불가)
• unless: 호출 후 “저장 제외 조건”(반환값 기준, #result 사용 가능)
• sync (Cacheable 전용): 동일 키 동시 미스 single-flight
• beforeInvocation (Evict 전용): 실행 전 제거(예외 나도 제거)
• allEntries (Evict 전용): 해당 캐시 전체 제거

SpEL 키 가이드(요약)

• 정의: SpEL 키 = 캐시 키를 만드는 식이고, 입력(파라미터)로 충분히 구분되는, 불변·안정적인 키여야 함.
• 컨텍스트: 파라미터 #p0/#id, 메타 #root.methodName/#root.args, 정적 호출 T(...). #result는 키에서 사용 불가(호출 전 평가) — unless 등 호출 후 평가에서만 사용.
• 생략 시 기본: key가 없으면 파라미터로 SimpleKey 생성(0개=EMPTY, 1개=그 값, 2개+=합성).

2-6) 이벤트 기반 무효화의 장점 및 리스너

@Component
@RequiredArgsConstructor
public class PostCacheInvalidationListener {

  private final CacheManager cacheManager;

  @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
  public void on(PostCacheEvent e) {
    switch (e.kind()) {
      case UPDATED -> {
        if (e.detailChanged()) cacheManager.getCache(CacheNames.POST_DETAIL).evict(e.postId());
        if (e.imagesChanged()) cacheManager.getCache(CacheNames.POST_IMAGES).evict(e.postId());
      }
      case DISABLED -> cacheManager.getCache(CacheNames.POST_DETAIL).evict(e.postId());
      case DELETED -> {
        cacheManager.getCache(CacheNames.POST_DETAIL).evict(e.postId());
        cacheManager.getCache(CacheNames.POST_IMAGES).evict(e.postId());
      }
    }
  }
}

3부. 적용편 — PinUp 실제 적용 및 검증

3-1) 이번 릴리스 적용 범위(L1: 로컬 캐시)

• 정책 레이어: spring.cache.app(per-cache TTL/size) 적용, strict + setCacheNames로 비선언 캐시 사용 금지
• 이름 상수: CacheNames.POST_DETAIL, CacheNames.POST_IMAGES 적용
• 무효화: @TransactionalEventListener(AFTER_COMMIT) 기반 PostCacheEvent 정밀 타격(evict by postId)
• sync=true: 핫키에 한정 적용(단일 키 동시 미스가 많을 때만)
• 관측: recordStats() + Micrometer로 Hit/Miss/Put/Evict/Size, URI p95, 로드 시간 p95 대시보드 구성
• 유보(차기): L1→L2 체인, Pub/Sub 전파 표준, L2용 SLO(전파 지연/RTT/Hit)

3-2) 도메인별 캐시 전략 (서비스 코드 예시 포함)

전략 표

트랜잭션/이벤트 흐름

1. Post 수정/삭제 요청
2. @Transactional 내부에서 DB 조작(Post, PostImage)
3. Commit 후 PostCacheEvent(updated or deleted) 발행
4. PostCacheInvalidationListener.evict("post:detail", postId)
5. PostCacheInvalidationListener.evict("post:images", postId)
6. 다음 조회 시 캐시 miss → DB 재적재 → put → 최신화

• AFTER_COMMIT 보장으로 롤백 시 캐시 무효화 없음
• detail/images만 정밀 타격(evict)하여 불필요한 캐시 파괴 방지

서비스 코드 예시

sync=true 적용 기준(운영 가이드)

sync=true는 동일 키에 single-flight를 걸어 스탬피드 방지. 핫키 한정 적용이 정석.

단건 상세 캐시 (Hot key + 정합 민감)

@Cacheable(
  value = CacheNames.POST_DETAIL,
  key = "#p0",
  condition = "!#p1",  // isDeleted == false일 때만 캐시
  sync = true
)
public PostResponse getPostById(Long id, boolean isDeleted) {
  return postRepository.findByIdAndIsDeleted(id, isDeleted)
      .map(PostResponse::from)
      .orElseThrow(PostNotFoundException::new);
}

이미지 목록 캐시 (읽기 비용 큼 + 변경이 드문)

@Cacheable(
  value = CacheNames.POST_IMAGES,
  key = "#p0",
  sync = true
)
@Transactional(readOnly = true)
public List<PostImageResponse> findImagesByPostId(Long postId) {
  var postImages = postImageRepository.findByPostId(postId);
  return postImages.stream().map(PostImageResponse::from).collect(Collectors.toList());
}

위 예시는 정밀 무효화 이벤트(→ 3-2 본문, 2-6절)와 결합해 정합성 + 성능을 동시에 달성한다.

3-3) 동작 다이어그램

부팅 시 흐름

@SpringBootApplication
   |
   | @EnableConfigurationProperties(AppCacheProps.class)
   v
ConfigurationPropertiesBinder  →  AppCacheProps 생성
   |
   v
CacheConfig.cacheManager(props) → setCacheNames(...) → createCaffeineCache(...)

런타임 요청 흐름

[Client]→[Controller]→[Service @Cacheable]
                         |
                         | CacheInterceptor(AOP)
                         v
                   [Cache get(name,key)] ── hit? → return
                         |
                         └─ miss → [load] → [put] → return

쓰기/갱신

[Service] → (DB) → publish(PostCacheEvent) → Listener → cache.evict(name,key)

3-4) 운영 검증 결과

StepWatch 로그 발췌

[PostService.updatePost]
  2.4.3 delete selected images          : 13 ms
  2.4.4 query remaining & maybe update  : 6 ms
  2.4.5 publish cache event             : 1 ms
→ PostCacheInvalidationListener.evict(detail, images)

• 캐시 무효화 → 다음 조회 시 miss → put → 이후 hit으로 회복되는 순환이 로그로 확인됨

3-5) 트러블슈팅 요약

운영 대시보드 예시(Prometheus + Grafana)

• cache_hit_rate{cache="post:detail"}
• cache_evictions_total{cache="post:detail"}
• http_server_requests_seconds_bucket{uri="/api/post/{postId}"} (p95, p99)

대시보드의 “Cache Suite” 행에 URI p95와 Hit Rate를 나란히 배치해 즉시성 변화를 시각적으로 검증.

요약

• PinUp의 L1 캐시 적용 후 DB read 부하 약 80% 감소, 상세 응답 3배 단축
• 썸네일/이미지 일관성도 이벤트 기반 무효화로 안정 확보
• 향후 Redis Pub/Sub 기반 L2 확장 시에도 그대로 재사용 가능

3-6)Spring Cache(Caffeine) 검증 시나리오 요약

1. 조회 기반 캐시 등록 + 캐시 히트 확인

(1) 첫 조회 — 캐시 미스(DB 조회 발생)

2025-10-30T00:00:05.301+09:00 DEBUG 43764 --- [pinup] [nio-8080-exec-1]  k.c.p.posts.controller.PostController    : 게시글 상세 뷰 진입: postId=10026
2025-10-30T00:00:05.302+09:00 DEBUG 43764 --- [pinup] [nio-8080-exec-1]  k.c.p.posts.service.PostService          : 게시글 단건 요청: postId=10026, isDeleted=false
2025-10-30T00:00:05.309+09:00  INFO 43764 --- [pinup] [nio-8080-exec-1]  p6spy                                    : select p1_0.id,p1_0.title,p1_0.content from posts p1_0 where p1_0.id=10026 and p1_0.is_deleted=false

→ 의미: 캐시에 데이터가 없어서 DB 접근이 발생함.

→ 결과: @Cacheable 메서드 종료 시점에 post:detail 캐시에 저장됨.

(2) 두 번째 동일 조회 — 캐시 히트(DB 접근 없음)

2025-10-30T00:00:12.653+09:00 DEBUG 43764 --- [pinup] [nio-8080-exec-2]  k.c.p.posts.controller.PostController    : 게시글 상세 뷰 진입: postId=10026
(이 시점에는 p6spy select 로그가 출력되지 않음)

→ 의미: DB 쿼리가 발생하지 않음 → 캐시에서 즉시 반환됨.

→ 결과: Caffeine 내부 hit 증가 (hitCount++).

2. 수정 → 이벤트 기반 무효화 → 재조회 시 캐시 재적재

(1) 게시글 수정 완료 → AFTER_COMMIT 이벤트 발생

2025-10-30T00:00:14.636+09:00  INFO 43764 --- [pinup] [nio-8080-exec-9]  k.c.p.custom.logging.StructuredLogger    : {"className":"PostApiController","methodName":"updatePost","targetId":"10026","details":{"kind":"UPDATED"},"message":"PostCacheEvent 수신"}
2025-10-30T00:00:14.637+09:00  INFO 43764 --- [pinup] [nio-8080-exec-9]  k.c.p.custom.logging.StructuredLogger    : {"className":"PostCacheInvalidationListener","methodName":"on","targetId":"10026","details":{"cache":"post:detail"},"message":"post:detail 캐시 무효화"}
2025-10-30T00:00:14.637+09:00  INFO 43764 --- [pinup] [nio-8080-exec-9]  k.c.p.custom.logging.StructuredLogger    : {"className":"PostCacheInvalidationListener","methodName":"on","targetId":"10026","details":{"cache":"post:images"},"message":"post:images 캐시 무효화"}

→ 의미: 트랜잭션 커밋 후 @TransactionalEventListener가 두 캐시를 모두 비움.

→ 결과: post:detail, post:images 캐시 evict 성공.

(2) 수정 직후 상세 재조회 — 캐시 미스(DB 재조회 발생)

2025-10-30T00:00:15.203+09:00 DEBUG 43764 --- [pinup] [nio-8080-exec-10]  k.c.p.posts.controller.PostController    : 게시글 상세 뷰 진입: postId=10026
2025-10-30T00:00:15.203+09:00  INFO 43764 --- [pinup] [nio-8080-exec-10]  p6spy                                    : select p1_0.id,p1_0.title,p1_0.content from posts p1_0 where p1_0.id=10026 and p1_0.is_deleted=false

→ 의미: 캐시 무효화 직후이므로 DB 재조회 발생.

→ 결과: 조회 결과가 다시 post:detail 캐시에 저장됨 (재적재 완료).

(3) 그 다음 재조회 — 캐시 히트(DB 접근 없음)

2025-10-30T00:00:22.412+09:00 DEBUG 43764 --- [pinup] [nio-8080-exec-11]  k.c.p.posts.controller.PostController    : 게시글 상세 뷰 진입: postId=10026
(이 시점에는 p6spy select 로그가 출력되지 않음)

→ 의미: DB 접근 없이 캐시에서 직접 반환됨.

→ 결과: 수정 이후에도 캐시 갱신 및 HIT 정상 작동 확인.

정리 요약

4. 마무리

• 설정은 yml, 동작은 CacheManager, 무효화는 이벤트 기반
• L1(Local Cache)만으로도 충분히 실효성 있고, 나중에 Redis Pub/Sub만 붙이면 L2로 자연 확장된다
• recordStats() + Micrometer 기반 SLO 모니터링으로 hit/miss를 수치로 관리하며 캐시 효율을 안정적으로 추적하라

부록 A. ApplicationEventPublisher와 이벤트 발행 구조

A-1. ApplicationEventPublisher란

스프링 컨텍스트 내에서 이벤트를 발행하고, 등록된 리스너로 디스패치하는 컴포넌트.

서비스와 캐시 무효화 로직을 분리해 롤백-안전, 확장성을 확보한다.

@Service
@RequiredArgsConstructor
public class PostService {
    private final ApplicationEventPublisher events;

    @Transactional
    public void disable(Long postId) {
        postRepository.disable(postId);
        events.publishEvent(PostCacheEvent.disabled(postId)); // 커밋 후 리스너 실행
    }
}

A-2. @TransactionalEventListener(phase = AFTER_COMMIT)

publishEvent()는 즉시 발행되지만, @TransactionalEventListener는 트랜잭션 상태에 따라 실행 타이밍이 결정된다.

AFTER_COMMIT은 트랜잭션 커밋이 완료된 후 실행 → 롤백 시 캐시 무효화가 발생하지 않음.

A-3. 직접 evict 호출 대신 이벤트를 쓰는 이유

A-4. PostCacheEvent 설계 포인트

public record PostCacheEvent(Long postId, Kind kind, boolean detailChanged, boolean imagesChanged) {
    public enum Kind { UPDATED, DISABLED, DELETED }
    public static PostCacheEvent updated(Long id, boolean detail, boolean images) { ... }
    public static PostCacheEvent disabled(Long id) { ... }
    public static PostCacheEvent deleted(Long id) { ... }
}

• 명시적 팩토리 메서드로 의도 표현
• Kind에 따라 detail/images 정밀 무효화 분기
• 이벤트 확장 시 구조가 흔들리지 않음

A-5. 테스트 및 운영 팁

• @TransactionalEventListener는 테스트에서 커밋이 없으면 실행되지 않음

  → 실제 커밋이 발생하는 통합 테스트나 @Commit 사용 필요

• 캐시 무효화 외의 부수 작업(알림, 감사 등)을 리스너로 확장 가능

• 멀티 인스턴스 시에는 Redis Pub/Sub로 이벤트 전파 확장

• cache_removals_total과 http_server_requests_seconds(p95)를 한 행에 배치해 효과 모니터링

A-6. 핵심 정리

왜 ApplicationEventPublisher인가?

• 서비스는 “무엇이 바뀌었다”만 알리고, 커밋 이후 무효화는 리스너가 담당
• 트랜잭션 롤백-안전, 관심사 분리, 확장성, Redis Pub/Sub 확장 용이

— Spring Cache 추상화 원리부터 JVM 내부 구조까지

“왜 Caffeine인가?”

이 글은 Spring Cache 추상화의 기본 원리부터 Caffeine 캐시의 내부 동작까지, JVM 수준에서 캐시가 어떻게 작동하는지를 완전히 해부합니다.

2편에서는 이 개념을 기반으로 PinUp 서비스에 실제 적용한 설계 구조를 다룹니다.

1. Spring Cache 추상화 기본 구조

1-1. Cache Abstraction 개요

핵심 개념: Cache Abstraction, @Cacheable, CacheManager, AOP Proxy, CacheInterceptor

Spring Cache는 다양한 캐시 엔진(Caffeine, Ehcache, Redis 등)을 공통 인터페이스로 감싸고,

AOP 프록시를 통해 메서드 호출을 가로채 캐싱 로직을 적용합니다.

동작 흐름

`

⚠️ 주의: 같은 클래스 내에서 자기 자신 메서드를 호출(self-invocation)하면 프록시를 우회해 캐시가 적용되지 않습니다.

구조 분리 또는 인터페이스 추출을 권장합니다.

1-2. CacheManager ↔ Cache 구현체 연결 구조

@Configuration
@EnableCaching
public class CacheConfig {
  @Bean
  public CacheManager cacheManager() {
    var cm = new CaffeineCacheManager("posts", "users");
    cm.setCaffeine(com.github.benmanes.caffeine.cache.Caffeine.newBuilder()
        .maximumSize(10_000)
        .expireAfterWrite(java.time.Duration.ofMinutes(10))
        .recordStats());
    return cm;
  }
}

1-3. Spring Boot 자동 구성 원리

Spring Boot는 클래스패스에 존재하는 라이브러리를 자동 감지해 적절한 CacheManager를 구성합니다.

우선순위 예시

JCache → Ehcache → Hazelcast → Infinispan → Couchbase → Redis → Caffeine → Simple

• 별도의 라이브러리가 없으면 기본적으로 SimpleCacheManager(ConcurrentMap 기반) 사용
• 단, TTL/Size 제한 없음 → 운영 환경에는 부적합

cach 관련해서 yml 을 작성이랑 어떻게 작동하는지 이런것에대해서 적는게 어떠할까???

2. Local vs Global Cache

Local: 초저지연·단순 운용이 강점이나 다노드 일관성이 과제

Global: 일관성·공유성은 뛰어나지만 네트워크 비용·운영 복잡성 존재

3. Java 캐시 엔진 비교

오프힙/디스크 티어링이 필요하면 Ehcache,

단일 JVM 초저지연이면 Caffeine이 가장 효율적입니다.

4. Caffeine vs Ehcache 3 심층 비교

“노드 1~N의 초저지연, 단기 TTL 중심” → Caffeine

“대용량/지속성/클러스터 필요” → Ehcache 3

5. Caffeine 내부 구조 및 JVM 동작 원리

5-1. Caffeine이 빠른 이유

Caffeine은 JVM 내부에서 직접 작동하는 고성능 인메모리 캐시입니다.

직렬화나 네트워크 hop 없이 Java 객체를 그대로 힙 메모리에 유지합니다.

Cache<String, User> cache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .weakKeys()
    .expireAfterWrite(5, TimeUnit.MINUTES)
    .build();

특징 요약

• On-Heap 구조 → 네트워크·직렬화 비용 없음
• 나노초 단위 접근 → JVM 메모리 직접 접근
• GC 친화적 관리 → weakKeys(), softValues()
• 명시적 크기 제한으로 OOM 방지

5-2. 내부 구조 개요

Caffeine의 핵심 클래스는 BoundedLocalCache이며,

내부적으로 ConcurrentHashMap + TTL + Eviction + Concurrency 계층으로 구성됩니다.

5-3. Cache-Aside 패턴

Caffeine은 cache.get(key, mappingFunction)으로 Cache-Aside 패턴을 지원합니다.

Spring의 @Cacheable 내부 동작과 동일합니다.

User user = cache.get(userId, id -> repository.findById(id));

1. 캐시 miss → DB 조회
2. DB 결과를 캐시에 저장
3. 이후 동일 key 요청 → 캐시 hit

5-4. TTL / Eviction / 통계 관리

Caffeine은 W-TinyLFU(Window TinyLFU) 알고리즘을 사용합니다.

최근성(Recency)과 사용 빈도(Frequency)를 결합하여 높은 적중률을 제공합니다.

Cache<String, User> cache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(10, TimeUnit.MINUTES)
    .recordStats()
    .build();

CacheStats stats = cache.stats();
System.out.printf("HitRate=%.2f, MissRate=%.2f%n", stats.hitRate(), stats.missRate());

TTL과 Eviction이 핵심: 오래된 데이터는 자동 만료되고, 자주 사용된 데이터는 오래 유지됩니다.

5-5. Lock-Free 동시성 구조

Caffeine은 CAS(Compare-And-Swap) + LongAdder 기반의 락-프리 구조입니다.

• CAS 기반 갱신: 락 대신 원자적 비교·갱신
• LongAdder: 다중 스레드 환경에서도 contention-free 통계 집계
• 비동기 Eviction: 쓰기 경로 방해 없이 제거 처리

5-6. GC 협력 방식

크기 제한을 지정하지 않으면 GC pause 증가 및 OOM 위험이 있습니다.

5-7. W-TinyLFU 알고리즘 구조

단계별 흐름

1. 새 항목은 Window(LRU)에 임시 저장
2. 용량 초과 시 기존 항목과 접근 빈도 비교
3. 더 자주 사용된 항목을 유지
4. hit 발생 시 Probation → Protected 구역 승격
5. TTL 만료 항목은 TimeWheel로 제거

최근성 + 빈도 기반의 하이브리드 구조로 높은 hit rate 달성.

5-8. JVM 내부 구조 요약

┌───────────────────────────────────────────┐
│              JVM Process                  │
│   ┌────────────────────────────────────┐  │
│   │ Caffeine On-Heap Cache (Bounded)   │  │
│   │  - ConcurrentHashMap 기반 Store    │  │
│   │  - Eviction(W-TinyLFU)             │  │
│   │  - TTL / Weak & Soft Reference     │  │
│   │  - Lock-free Concurrency (CAS)     │  │
│   │  - LongAdder 기반 통계 집계        │  │
│   └────────────────────────────────────┘  │
└───────────────────────────────────────────┘

6. Cache 설정(application.yml) 구성과 작동 원리

Spring Boot에서 캐시는 크게 두 계층으로 설정할 수 있다.

6-1. Spring 기본 설정층 (spring.cache.*)

Spring Boot는 spring.cache 네임스페이스를 통해 CacheManager의 전역 동작을 구성한다.

spring:
  cache:
    type: caffeine
    cache-names: 명칭, 명칭
    caffeine:
      spec: maximumSize=10000,expireAfterWrite=10m,recordStats

이 구조는 모든 캐시가 동일한 정책으로 동작할 때 간단하게 사용할 수 있다.

그러나 캐시별로 TTL이나 Size를 세분화해야 하는 경우 한계가 있다.

6-2. 사용자 확장 설정층 (spring.cache.app.*)

도메인별 TTL과 용량 정책이 달라야 할 경우,

Spring의 기본 설정 위에 타입 안전한 확장 레이어를 추가한다.

spring:
  cache:
    type: caffeine
    strict: true
    app:
      defaults: { maximumSize: 40000, ttlSec: 300 }
      caches:
        "명칭": { maximumSize: 20000, ttlSec: 300 }
        "명칭": { maximumSize: 20000, ttlSec: 1800 }

이 구조는 defaults를 기본값으로 두고, caches로 각 캐시의 오버라이드 정책을 적용하는 방식이다.

실제 코드에서는 AppCacheProps를 통해 바인딩되고 CacheManager에서 per-cache로 주입된다.

(해당 구현은 2편에서 다룬다.)

6-3. 주요 항목 정리

이 항목들만으로도 대부분의 운영 환경에서 완전한 캐시 구성을 구현할 수 있다.

6-4. 선택적 확장 옵션

6-5. 요약

• spring.cache는 CacheManager의 기본 엔진을 구성한다.
• spring.cache.app은 캐시별 TTL·Size 정책을 확장 관리한다.
• defaults와 caches 구조로 전역·개별 정책을 병행할 수 있다.
• 핵심 8개 항목만으로도 실무 환경에서 완전한 캐시 구성이 가능하다.

2편에서는 이 설정이 실제 코드(AppCacheProps, CacheManager)로 어떻게 연결되는지,

그리고 왜 전역 spec 대신 per-cache 구조를 선택했는지를 다룬다.

7. 결론

Caffeine은 JVM 내부에서 작동하는 경량·고성능 로컬 캐시입니다.

ConcurrentMap 기반 구조 위에 TTL, Eviction, Lock-Free, 통계 계층을 결합해

“JVM 친화적 캐싱 엔진”을 완성했습니다.

특징 요약

• 네트워크 hop 없음
• GC 협력(weakKeys / softValues)
• 락 없는 동시성 구조
• TTL 및 Eviction 자동 관리
• Micrometer 통합으로 운영 모니터링 가능

Caffeine = JVM 친화적 + Lock-Free + 고성능 캐시.

단일 인스턴스 환경에서는 Redis보다 빠를 수 있으며,

내부 동작을 이해하면 캐시의 성능과 안정성을 동시에 확보할 수 있습니다.

이전 단계에서 ExponentialBackOffPolicy를 적용한 결과,

VU 200 이상 구간에서 성공률이 급격히 하락하며 최대 응답 시간이 17초를 초과하는 현상이 나타났다.

초기 설정은 다음과 같았다.

• initialInterval: 200~300ms
• multiplier: 1.5~2.0
• maxAttempts: 8~10회

테스트 결과, 100명 이하에서는 안정적이었으나

시각 요소 설명: 파란 곡선들 → 각기 다른 요청의 재시도 시점 x축(Time) / y축(Request 수) 빨간 “Lock Contention” 구간 → 재시도 타이밍이 겹치며 병목 발생 의미: “단순 지수 증가(backoff)는 있지만, 타이밍 분산이 없다 → 경합 집중”

재시도 타이밍이 동일하게 맞물리며 락 경합이 집중되는 문제가 발생했다.

락이 해제된 시점에 모든 요청이 동시에 재시도되면서

성공률은 80%대에 머물렀고 응답 시간은 급격히 증가했다.

이는 단순히 “대기 간격의 길이”보다 “재시도 타이밍의 일치”가 병목의 근본 원인임을 보여준다.

2. 테스트 환경

2.1 서버 및 DB 설정

application.yaml

server:
  tomcat:
    max-threads: 1000
    accept-count: 3000

spring:
  datasource:
    hikari:
      maximum-pool-size: 400
      minimum-idle: 100
      idle-timeout: 30000
      connection-timeout: 15000

postgresql.conf

max_connections = 300

이 설정을 통해 Tomcat 스레드 수와 DB 커넥션 풀 크기를 확대하여

100~200명 수준의 동시 요청에서도 병목 없이 안정적인 처리가 가능하도록 구성했다.

로그인, 인증, 데이터베이스 락 대기 등의 구간에서 병목이 완화되었으며,

이는 재시도 정책 실험의 전제 조건이 되었다.

3. ExponentialBackOffPolicy 결과 요약

주요 현상

• 100명(VU) 이하에서는 성공률 98~100% 유지
• 200명 이상부터 성공률 급감, 최대 응답 시간 17초 이상
• 재시도 타이밍이 동일하게 겹치며 락 경합 집중

주요 결과

요약

VU 200 이상에서 락 재경합으로 인한 실패율 상승이 두드러졌다.

재시도 정책이 동일하게 동작하여 재시도 타이밍이 집중되며,

최대 응답 시간은 17초 이상으로 지연이 급격히 증가했다.

결국 ExponentialBackOffPolicy는 “대기 간격의 증가”는 제공하지만

“재시도 시점의 분산”은 보장하지 않는다.

4. ExponentialRandomBackOffPolicy 적용

4.1 정책 변경 의도

시각 요소 설명: x축(Time) / y축(BackOff Interval) 각 점 → 재시도 타이밍 “Random Jitter” 표기된 화살표 → 각 요청마다 약간의 지연이 무작위로 추가됨 의미: “같은 지수 증가지만, 재시도 시점이 어긋나 충돌 분산됨”

ExponentialBackOffPolicy는 재시도 시마다 간격을 지수적으로 늘려 충돌 빈도를 완화하지만,

모든 트랜잭션이 동일한 타이밍으로 재시도하는 문제를 근본적으로 해결하지는 못한다.

이에 따라 고정된 지수 간격 대신, 무작위성(Random Jitter)을 포함한

ExponentialRandomBackOffPolicy를 적용하였다.

이 정책의 목표는 다음과 같다:

• 동일한 간격의 재시도가 동시에 발생하지 않도록 타이밍 분산
• 락 해제 직후 요청 집중을 완화
• 대규모 동시성 환경에서도 성공률·응답 시간 안정화

4.2 원리

ExponentialRandomBackOffPolicy는 ExponentialBackOffPolicy를 확장한 구현이다.

각 재시도 간격(nextInterval)을 계산할 때 무작위(Random Jitter) 값을 더해

스레드 간 타이밍이 미세하게 달라지도록 설계되어 있다.

nextInterval = currentInterval * (1 + random[0,1))

이로써 재시도 타이밍이 서로 어긋나며,

락 경합이 집중되는 현상을 방지할 수 있다.

이후 내부 동작 구조(RetryTemplate의 Context, BackOff 계산, Callback 루프)는

아래 내부 구조 분석(4.3) 에서 상세히 다룬다.

4.3 내부 동작 분석 — BackOffPolicy와 RetryTemplate 구조

(1) 개념 요약

Spring Retry의 핵심은 특정 대상을 식별해 재시도하는 것이 아니라,

execute() 단위로 실행 세션(RetryContext)을 생성하고

그 세션 안에서 동일한 Callback을 반복 실행하는 구조다.

즉,

“재시도 대상은 특정 엔티티나 ID가 아니라 RetryContext 자체이며,

RetryTemplate은 이 Context에 연결된 Callback을 반복 실행한다.”

(2) ExponentialRandomBackOffPolicy의 동작

해당 정책은 기본적으로 ExponentialBackOff 구조를 유지하면서

각 재시도 간격에 무작위(Random Jitter)를 추가한다.

@Override
public void backOff(BackOffContext context) {
    ExponentialRandomBackOffContext c = (ExponentialRandomBackOffContext) context;
    long next = (long) (c.getCurrentInterval() * (1 + Math.random()));
    Thread.sleep(Math.min(next, maxInterval));
    c.setCurrentInterval(next * multiplier);
}

이 메서드는 RetryTemplate의 내부 루프에서 호출된다.

즉, RetryPolicy가 “재시도 가능”이라고 판단할 때마다

backOff()가 호출되어 대기 시간과 Context 상태를 함께 갱신한다.

이는 단순히 “지연시간을 늘리는 것”이 아니라

Context에 저장된 상태(currentInterval, multiplier)를 기반으로

동적으로 대기 시간을 계산·조정하는 방식이다.

(3) RetryTemplate 내부 구조 요약

┌──────────────────────────────────────────────────────────┐
│                      RetryTemplate                      │
│──────────────────────────────────────────────────────────│
│ ① RetryCallback (람다 함수) → 비즈니스 로직 실행        │
│ ② RetryContext (세션 상태 저장)                         │
│ ③ RetryPolicy (재시도 여부 판단)                        │
│ ④ BackOffPolicy (대기 시간 계산, Random Jitter 적용)    │
│ ⑤ Callback 재실행 (Context 기반 루프)                   │
└──────────────────────────────────────────────────────────┘

각 구성 요소는 독립적인 책임을 가지며,

RetryTemplate이 전체 제어 흐름을 관리한다.

(4) 실행 흐름 (Pseudo-code)

RetryContext context = retryPolicy.open(null); // 세션 시작

while (retryPolicy.canRetry(context)) {
    try {
        return retryCallback.doWithRetry(context);  // 비즈니스 로직 실행
    } catch (Exception e) {
        context.registerThrowable(e);               // 예외 기록
        backOffPolicy.backOff(context.getBackOffContext()); // 대기 후 재시도
    }
}

retryPolicy.close(context); // 세션 종료

이 루프 내에서:

• RetryContext: 재시도 세션의 상태를 저장

• BackOffPolicy: 다음 재시도까지의 대기 시간을 계산

• execute() 호출 = 하나의 재시도 세션

  → 이 Context 단위로 상태가 누적·관리된다.

(5) 주요 구성 요소 역할

(6) RetryTemplate의 재시도 단위와 Context 구조

Spring Retry는 재시도 대상을 객체나 ID로 구분하지 않는다.

즉, “postId=1인 요청을 재시도한다”는 개념이 아니라,

하나의 execute() 호출 자체를 하나의 재시도 세션(RetryContext)으로 인식한다.

(1) 재시도 단위: execute() 호출

RetryTemplate은 execute() 메서드가 호출될 때마다

새로운 RetryContext를 생성하고,

그 세션(Context) 내에서 동일한 RetryCallback을 반복 실행한다.

retryTemplate.execute(context -> {
    // 이 블록 전체가 하나의 재시도 세션
    return someBusinessOperation();
});

이 “execute() 호출”이 곧 RetryTemplate이 인식하는 하나의 재시도 대상 단위이며,

각 Context는 재시도 횟수, 예외, BackOff 상태 등을 내부적으로 관리한다.

(2) 내부 동작 구조

RetryTemplate 내부는 다음과 같이 동작한다.

public <T, E extends Throwable> T execute(RetryCallback<T, E> retryCallback) throws E {
    RetryContext context = retryPolicy.open(null); // 세션 생성
    try {
        do {
            try {
                return retryCallback.doWithRetry(context);
            } catch (Exception e) {
                if (retryPolicy.canRetry(context)) {
                    backOffPolicy.backOff(backOffContext); // 대기 후 재시도
                } else {
                    throw e;
                }
            }
        } while (true);
    } finally {
        retryPolicy.close(context); // 세션 종료
    }
}

이 구조에서 RetryContext는 재시도 세션의 상태 저장소이자 식별자 역할을 한다.

즉, RetryTemplate은 “대상을 찾아서 재시도”하지 않고,

“동일한 Callback을 같은 Context 안에서 반복 실행”한다.

(3) Context = 대상의 정체성(Identity)

Spring Retry는 “이 요청이 어떤 ID를 가진 대상인가”를 인식하지 않는다.

대신, open()으로 생성된 하나의 RetryContext가

그 실행 세션의 정체성(Identity)으로 작동한다.

이 Context는 다음과 같은 순서로 재사용된다.

open() → canRetry() → registerThrowable() → backOff() → close()

즉, 하나의 execute() 호출 = 하나의 Context = 하나의 재시도 세션이다.

이 세션 단위로 재시도 상태가 누적·관리된다.

(4) 필요 시 대상 정보를 명시적으로 추가

RetryTemplate은 내부적으로 postId 등의 식별자를 추적하지 않는다.

그러나 개발자가 Context에 직접 속성을 추가할 수 있다.

retryTemplate.execute(context -> {
    context.setAttribute("postId", postId);
    context.setAttribute("operation", "like");
    ...
});

이후 재시도 중 예외가 발생하면 다음과 같이 로그로 확인할 수 있다.

catch (Exception e) {
    log.warn("Retry failed for postId={} (attempt {})",
        context.getAttribute("postId"),
        context.getRetryCount());
}

이 구조는 RetryTemplate이 본질적으로 “대상 추적 기능”을 내장하지 않고,

필요 시 개발자가 Context를 확장하여

모니터링, 디버깅, 장애 분석에 활용할 수 있게 설계된 것이다.

(5) 요약

정리:

RetryTemplate은 “특정 대상을 다시 찾는 구조”가 아니라

하나의 execute() 세션(Context)을 하나의 실행 단위로 반복한다.

즉, RetryContext가 곧 재시도 단위이며,

Spring Retry는 이 Context를 기반으로 재시도 횟수·대기 간격·상태를 제어한다.

5. 실제 코드 적용 구조

5.1 RetryConfig.java

@Configuration
public class RetryConfig {

    @Bean
    public RetryTemplate retryTemplate() {
        RetryTemplate template = new RetryTemplate();

        ExponentialRandomBackOffPolicy backOffPolicy = new ExponentialRandomBackOffPolicy();
        backOffPolicy.setInitialInterval(200);
        backOffPolicy.setMultiplier(1.5);
        backOffPolicy.setMaxInterval(3000);

        SimpleRetryPolicy retryPolicy = new SimpleRetryPolicy(10, Map.of(Exception.class, true));

        template.setBackOffPolicy(backOffPolicy);
        template.setRetryPolicy(retryPolicy);
        return template;
    }
}

설명

• 기존 ExponentialBackOffPolicy를 ExponentialRandomBackOffPolicy로 교체
• 초기 간격, 배수, 최대 간격은 동일하게 유지하여 실험 조건 일치
• 예외 매핑을 통해 OptimisticLockingFailureException 포함

5.2 PostLikeRetryExecutor.java

@Component
@RequiredArgsConstructor
public class PostLikeRetryExecutor {

    private final RetryTemplate retryTemplate;
    private final TransactionTemplate transactionTemplate;

    public <T> T likeWithRetry(Callable<T> action) {
        return retryTemplate.execute(context -> {
            log.debug("재시도 시작 (attempt {})", context.getRetryCount());

            try {
                return transactionTemplate.execute(status -> {
                    try {
                        return action.call();
                    } catch (Exception e) {
                        if (e instanceof RuntimeException) throw (RuntimeException) e;
                        throw new RuntimeException(e);
                    }
                });
            } catch (Exception e) {
                log.warn("재시도 실패 (attempt {}): {}", context.getRetryCount(), e.getMessage());
                throw e;
            }
        });
    }
}

설명

• RetryTemplate 내부에서 TransactionTemplate을 함께 사용하여

  매 재시도 시 새로운 트랜잭션을 열고 롤백 후 다시 시도하도록 구성

• RetryContext는 자동으로 관리되며, 별도 context.setAttribute() 호출 불필요

• OptimisticLockingFailureException 발생 시 자동 재시도

• 시도 횟수(context.getRetryCount()) 기반 로깅으로 디버깅 용이

5.3 PostLikeService.java

@Service
@RequiredArgsConstructor
public class PostLikeService {

    private final PostRepository postRepository;
    private final PostLikeRetryExecutor retryExecutor;

    @Transactional
    public void likePost(Long postId) {
        retryExecutor.likeWithRetry(() -> {
            Post post = postRepository.findByIdWithOptimisticLock(postId)
                    .orElseThrow(PostNotFoundException::new);
            post.increaseLikeCount();
            postRepository.save(post);
            return null;
        });
    }
}

설명

• 낙관적 락 충돌 시 발생하는 예외는 RetryExecutor 내부의 재시도 루프로 전달됨
• 서비스 계층은 비즈니스 로직만 유지하며, 재시도 및 트랜잭션 제어는 외부화됨
• 트랜잭션 안정성과 로직 단순화를 동시에 확보

6. ExponentialRandomBackOffPolicy 성능 결과

비교 요약

7. 결론

ExponentialBackOffPolicy는 동일한 간격 증가 로직으로 인해

대규모 동시 요청 시 재시도 타이밍이 집중되는 구조적 한계를 가진다.

반면 ExponentialRandomBackOffPolicy는 무작위성을 부여함으로써

재시도 타이밍이 분산되고, DB 락 경합 및 실패율이 현저히 감소했다.

서버 및 DB 설정 확장(Tomcat, Hikari, PostgreSQL)을 기반으로

VU 200 이상 환경에서도 99~100%의 성공률을 유지했으며,

지수적 증가 + 무작위 오프셋 조합이 가장 안정적인 패턴으로 확인되었다.

최종 결론

• ExponentialRandomBackOffPolicy는 락 충돌 완화와 재시도 타이밍 분산에 탁월하다.

• TransactionTemplate 결합 구조는 재시도마다 트랜잭션 재시작을 보장한다.

• RetryTemplate 기반 설계는 비즈니스 로직과 정책을 완전히 분리하여

  확장성과 유지보수성을 동시에 확보했다.

💡 두 사용자가 동시에 같은 데이터를 수정할 때 발생하는 낙관적 락 충돌. 충돌 시점에 예외가 발생하고 트랜잭션이 롤백된다.

2편에서 살펴본 낙관적 락은 “충돌을 허용하고, 커밋 시점에 감지한다.”

이 방식은 동시성 제어의 유연성을 높이지만, OptimisticLockException이 발생하면 트랜잭션이 롤백된다.

즉, 충돌이 발생한 사용자는 아무 일도 일어나지 않은 것처럼 보이게 된다.

좋아요 기능처럼 즉시 반응성과 데이터 정합성을 모두 요구하는 기능에서는

이 단점이 그대로 사용자 체감 오류로 이어진다.

이 문제를 해결하기 위해, 충돌 후 재시도(retry) 가 필요하다.

다만 단순 반복이 아니라, “정책(policy)”으로 설계된 재시도여야 한다.

2. 단순 반복이 아닌 정책 기반 접근

단순히 for 문으로 감싸는 것은 임시방편이다.

for (int i = 0; i < 3; i++) {
    try {
        updateLikeCount();
        break;
    } catch (OptimisticLockException e) {
        // 재시도
    }
}

이런 구조는 간단하지만 다음과 같은 문제가 있다:

• 재시도 간 간격 제어 불가
• 예외별 재시도 정책 분리 불가능
• 동일 시점에 다수의 재시도가 겹침 (락 충돌 재발)

따라서 재시도 로직은 RetryPolicy와 BackOffPolicy로 분리되어야 한다.

3. Spring Retry의 정책 구조

Spring Retry는 재시도를 독립된 템플릿으로 제공한다.

RetryTemplate
 ├── RetryPolicy: 재시도 횟수와 조건 정의
 ├── BackOffPolicy: 재시도 간 대기 시간 제어
 └── RetryCallback: 실제 수행할 로직

이 구조를 활용하면

“언제, 몇 번, 어떤 간격으로” 다시 시도할지를 독립적으로 설정할 수 있다.

4. Spring 기반 재시도 구현 방식 비교

좋아요 기능은 짧은 트랜잭션, 높은 빈도, 즉시성 중심이므로

② RetryTemplate + ExponentialBackOffPolicy 조합이 가장 적합하다.

5. RetryTemplate 적용 예시

🔁 실패 시 BackOff 대기 후 재시도를 반복하며, 성공 시 루프를 종료하는 RetryTemplate의 동작 흐름.

@Configuration
public class RetryConfig {

    @Bean
    public RetryTemplate retryTemplate() {
        RetryTemplate template = new RetryTemplate();

        SimpleRetryPolicy retryPolicy = new SimpleRetryPolicy(
            3, Map.of(OptimisticLockException.class, true)
        );

        ExponentialBackOffPolicy backOffPolicy = new ExponentialBackOffPolicy();
        backOffPolicy.setInitialInterval(300);
        backOffPolicy.setMultiplier(2.0);
        backOffPolicy.setMaxInterval(2000);

        template.setRetryPolicy(retryPolicy);
        template.setBackOffPolicy(backOffPolicy);
        return template;
    }
}

• 최대 3회 재시도
• 300ms → 600ms → 1200ms 간격으로 대기
• OptimisticLockException 발생 시 재시도

6. 좋아요 기능 적용

@Service
@RequiredArgsConstructor
public class PostLikeService {

    private final RetryTemplate retryTemplate;
    private final PostRepository postRepository;
    private final PostLikeRepository postLikeRepository;

    @Transactional
    public void toggleLike(Long postId, Long memberId) {
        retryTemplate.execute(context -> {
            Post post = postRepository.findByIdWithOptimisticLock(postId)
                    .orElseThrow(PostNotFoundException::new);

            boolean liked = postLikeRepository.existsByPostIdAndMemberId(postId, memberId);
            if (liked) {
                postLikeRepository.deleteByPostIdAndMemberId(postId, memberId);
                post.decreaseLikeCount();
            } else {
                postLikeRepository.save(new PostLike(postId, memberId));
                post.increaseLikeCount();
            }

            return null;
        });
    }
}

이제 낙관적 락 충돌이 발생하더라도 자동으로 재시도가 수행된다.

그러나 이 정책이 실제 부하 환경에서도 효과적일까?

7. ExponentialBackOffPolicy 적용 후 K6 테스트 결과

이 구조가 실전에서 얼마나 안정적으로 동작하는지를 확인하기 위해

K6 부하 테스트를 수행했다.

테스트 개요

• 테스트 대상: /post/{id}/like API
• 목적: 동시에 같은 게시글에 좋아요 요청 시 성공률 검증
• 환경: VU 100 → 200까지 점진적 증가
• 정책: Retry 8~10, Multiplier 1.5~2.0, Initial 200~300ms

7-1. 테스트 결과 요약

7-2. 분석

• VU 100 수준에서는 성공률 80~90%로 비교적 양호
• 그러나 200 이상에서는 성공률이 급격히 하락
• 재시도 횟수를 늘려도 개선 폭이 제한적
• 최대 응답 시간은 최대 17초 이상까지 증가

이 현상은 모든 요청이 같은 간격(지수 증가)으로 재시도되기 때문이다.

즉, 재시도 타이밍이 다시 겹치며 락 경합이 재발생했다.

8. ExponentialBackOffPolicy의 구조적 한계와 개선 방향

ExponentialBackOffPolicy는 재시도 시마다 대기 시간을 지수적으로 늘리는 방식이다.

이론적으로는 부하를 완화하기 위한 구조지만,

모든 트랜잭션이 동일한 알고리즘과 파라미터로 동작하면

다음과 같은 현상이 발생한다.

1. 재시도 타이밍이 일치한다.
2. 락 경합이 다시 집중된다.
3. 성공률이 하락하고 응답 지연이 증가한다.

결과적으로, “한 발 늦게 재시도하려던 설계”가

현실에서는 “모두 동시에 늦게 재시도”하는 구조로 변해버린다.

즉, 지수 백오프는 네트워크 장애나 일시적 처리 지연에는 효과적이지만,

동시성 충돌을 완화하는 데에는 한계가 있다.

VU 200 이상 테스트에서 이 문제가 명확히 드러났으며,

락 충돌이 완전히 해소되지 않아 성공률이 80~90% 수준에 머물렀다.

9. ExponentialRandomBackOffPolicy로의 전환

📊 Exponential은 동일 간격으로 증가하지만, RandomBackOff는 각 요청의 대기 간격을 무작위로 분산시켜 충돌 타이밍을 줄인다.

이 시점에서 문제의 본질은 “대기 시간의 형태”가 아니라 “타이밍의 일치”였다.

즉, 모두가 같은 시점에 재시도하기 때문에 락 충돌이 반복되는 구조였다.

이를 해결하기 위해 선택한 접근이

ExponentialRandomBackOffPolicy,

즉 무작위 지연(Random Jitter)을 도입하는 방식이다.

이 정책은 기존 지수 백오프 구조를 유지하면서도,

각 요청마다 재시도 간격을 미세하게 달리해 재시도 타이밍을 분산시킨다.

• 기존: 300 → 600 → 1200ms (고정된 간격)
• 개선: 300600 → 6001200 → 1200~2400ms (무작위 분산)

결과적으로 각 요청이 서로 다른 타이밍으로 재시도되어

락 해제 시점이 자연스럽게 분산되고,

DB 부하 및 충돌 확률이 감소하게 된다.

이제 다음 편에서는

ExponentialBackOffPolicy와 ExponentialRandomBackOffPolicy를 같은 조건에서 비교 실험하고, 무작위 분산이 실제로 시스템 성공률과 안정성에 어떤 차이를 만드는지 테스트 데이터와 내부 동작 코드를 기반으로 검증한다.

동시성(concurrency)을 다룰 때 가장 중요한 문제는

“여러 트랜잭션이 동시에 같은 데이터를 수정하려 할 때

어떻게 데이터의 일관성을 보장할 것인가?”이다.

예를 들어 두 사용자가 같은 게시글에 동시에 좋아요를 누른다고 가정해보자.

• 사용자 A: 좋아요 수를 10 → 11로 증가
• 사용자 B: 동시에 10 → 11로 증가

이 두 요청이 동시에 처리되면,

결과는 12가 아니라 11로 덮어씌워지는 문제가 발생한다.

이것이 바로 동시 수정 충돌(Write Conflict)이다.

데이터베이스는 이러한 충돌을 방지하기 위해 Lock(잠금)을 사용한다.

락은 쉽게 말해 “이 데이터는 지금 누군가 수정 중이니 잠깐 기다려라”라는 신호다.

하지만 이 락을 언제 거는지가 문제다.

너무 일찍 잠그면 병목이 생기고, 너무 늦게 감지하면 충돌이 생긴다.

이 시점의 선택이 바로 비관적 락(Pessimistic Lock)과 낙관적 락(Optimistic Lock)의 차이를 만든다.

2. 두 철학의 차이 — “미리 막을 것인가, 나중에 감지할 것인가”

비관적 락 (Pessimistic Lock)

“언제 충돌이 날지 모르니, 미리 잠가두자.”

비관적 락은 말 그대로 “비관적인” 가정에서 출발한다.

충돌이 언제든 발생할 수 있다고 보고,

트랜잭션이 데이터를 수정하기 전에 먼저 락을 건다.

SELECT * FROM post WHERE id = 1 FOR UPDATE;
UPDATE post SET like_count = like_count + 1 WHERE id = 1;

이 경우 다른 트랜잭션은 해당 Row가 해제될 때까지 기다린다.

즉, 항상 순서를 보장하지만 대기 시간이 생긴다.

• 장점: 충돌이 아예 발생하지 않는다.
• 단점: 락 대기열로 인한 병목, 데드락 가능성.
• 적합 예: 은행 송금, 재고 감소, 결제 승인 등.

한 줄 요약: “안전하지만 느리다.”

낙관적 락 (Optimistic Lock)

“충돌은 드물다. 일단 진행하고, 나중에 확인하자.”

낙관적 락은 트랜잭션이 데이터를 수정하더라도

락을 걸지 않고 자유롭게 진행한다.

단, 커밋 시점에서 데이터의 버전을 비교하여

누군가 먼저 변경했다면 예외를 발생시킨다.

@Entity
class Post {
    @Id @GeneratedValue
    private Long id;

    @Version
    private Long version;

    private int likeCount;
}

@Version 필드는 데이터의 버전을 의미한다.

A가 먼저 저장하여 version이 2가 되면,

B가 나중에 커밋할 때 version이 맞지 않아 예외가 발생한다.

• 장점: 대기 없음, 빠른 처리.
• 단점: 충돌 발생 시 실패 → 재시도 필요.
• 적합 예: 좋아요, 조회수, 포인트 적립 등.

한 줄 요약: “빠르지만 충돌 시 실패한다.”

3. 실제 프로젝트에 락을 적용해보기

이론을 이해했다면 이제 실무에서 이를 적용해볼 차례다.

사이드 프로젝트의 게시판(Post) 서비스에서

좋아요 기능을 구현하면서 락 전략을 직접 실험해보기로 했다.

좋아요는 동시에 여러 사용자가 같은 게시글을 수정할 수 있지만,

금융 거래처럼 강한 정합성이 필요한 기능은 아니다.

즉, 충돌이 자주 발생하지 않으며, 빠른 응답이 더 중요하다.

그래서 “락을 미리 거는 비관적 락”보다

“충돌 시점에서 감지하는 낙관적 락”이 더 적합하다고 판단했다.

4. 설계 — Post와 PostLike의 분리

좋아요 기능은 다음 두 가지 데이터가 필요하다.

1. “누가 좋아요를 눌렀는가”
2. “해당 게시글의 좋아요 총합은 몇 개인가”

이 두 역할을 각각 PostLike와 Post로 나누었다.

@Entity
class PostLike {
    @Id @GeneratedValue
    private Long id;

    private Long postId;
    private Long memberId;
}

PostLike는 사용자별 좋아요 여부만 관리하며

중복을 막기 위해 UNIQUE(post_id, member_id) 제약을 둔다.

@Entity
class Post {
    @Id @GeneratedValue
    private Long id;

    @Version
    private Long version;

    private int likeCount;
}

Post의 likeCount는 총 좋아요 수를 단순 정수 컬럼으로 관리한다.

이렇게 하면 다음과 같은 장점이 생긴다.

즉, Post 하나만으로도 좋아요 수를 바로 응답할 수 있으므로

조회 성능과 캐시 효율성이 크게 향상된다.

5. 서비스 로직 — 낙관적 락 적용

@Transactional
public void toggleLike(Long postId, Long memberId) {
    Post post = postRepository.findByIdWithOptimisticLock(postId)
            .orElseThrow(PostNotFoundException::new);

    boolean liked = postLikeRepository.existsByPostIdAndMemberId(postId, memberId);
    if (liked) {
        postLikeRepository.deleteByPostIdAndMemberId(postId, memberId);
        post.decreaseLikeCount();
    } else {
        postLikeRepository.save(new PostLike(postId, memberId));
        post.increaseLikeCount();
    }
}

• 낙관적 락(@Version)으로 동시 수정 충돌을 감지한다.
• PostLike 테이블을 JOIN하지 않고 likeCount만으로 응답한다.
• 충돌 시 OptimisticLockException이 발생한다.

6. 테스트 — 동시 요청에서 발생한 충돌

좋아요 기능의 동시성 안정성을 검증하기 위해

K6를 이용해 약 100명의 사용자가 동시에 같은 게시글을 좋아요 요청하는 상황을 시뮬레이션했다.

테스트 결과,

낙관적 락(@Version)을 적용했기 때문에 데이터 불일치는 발생하지 않았지만,

일부 요청이 커밋 시점에서 OptimisticLockException으로 실패했다.

이는 낙관적 락의 정상 동작 결과다.

트랜잭션이 자유롭게 실행되다가,

커밋 시점에서 동일한 Row를 갱신한 다른 트랜잭션이 있으면

DB가 충돌을 감지하고 예외를 던진다.

즉, 정합성은 확보되었지만,

일부 요청은 실패로 끝나는 상황이 발생한다.

이 시점에서 자연스럽게 다음 고민이 생긴다.

“충돌이 발생했을 때, 단순히 실패로 끝낼 것인가?

아니면 자동으로 다시 시도해 복구할 것인가?”

7. 결론 — 충돌을 허용하고 복구하는 설계

비관적 락은 정합성이 절대적인 시스템에서 유리하지만, 짧은 트랜잭션이 반복되는 서비스에서는 병목을 만든다. 낙관적 락은 충돌을 허용하지만, 그 대신 빠른 처리와 높은 처리율을 제공한다. 좋아요 기능은 후자에 속한다. 따라서 “충돌 감지 → 재시도” 구조를 선택하는 것이 합리적이다. 이제 남은 과제는 단 하나다.

충돌을 어떻게, 어떤 정책으로 재시도할 것인가.

MVCC는 “무엇이 보이느냐(가시성)”를, 락은 “누가 먼저 쓰느냐(경합)”을 다룬다.

행 락과 대기 전략(NOWAIT / SKIP LOCKED)을 통해 “기다릴지 / 포기할지 / 건너뛸지”를 설계한다.

타임아웃·데드락 표준으로 “영원 대기”를 방지하며, 인덱스·FK가 락의 범위를 결정한다.

1. 일반적인 트랜잭션 락 (RDB 공통 원리)

1) 핵심 개념

트랜잭션 락은 데이터의 일관성(Consistency)과 격리성(Isolation)을 보장하기 위한 경합 제어 도구다.

DB는 동시에 여러 사용자가 같은 데이터를 수정하려 할 때

“누가 먼저 접근할 것인가”를 결정하기 위해 락을 건다.

즉, 한 트랜잭션이 데이터를 수정 중이면

다른 트랜잭션은 그 데이터에 접근할 수 없도록 “잠금(Lock)”을 설정한다.

모든 RDBMS는 이 락을 통해 읽기·쓰기 충돌이 발생했을 때의 처리 방식을 정한다.

이때 시스템은 보통 아래 세 가지 중 하나로 대응한다.

• 대기(WAIT): 락이 해제될 때까지 기다림
• 포기(NOWAIT): 락이 걸려 있으면 즉시 실패
• 재시도(RETRY): 실패 후 일정 조건에서 다시 시도

핵심 문장:

락은 여러 트랜잭션이 동시에 실행되더라도

데이터를 순서 있게, 일관되게 유지하기 위한 장치다.

2) 동작 구조 요약

인덱스가 없는 WHERE 조건으로 UPDATE를 실행하면

DB는 어떤 행이 바뀔지 알 수 없으므로 테이블 전체를 스캔하며 락을 걸게 된다.

3) 일반 RDBMS의 처리 흐름 (MySQL / Oracle / SQL Server 공통)

1. Transaction A → UPDATE row1 → X락 획득
2. Transaction B → UPDATE row1 → 대기 상태(WAIT)
3. Timeout 설정 시 일정 시간 후 실패
4. Deadlock 발생 시 DB 엔진이 한쪽 트랜잭션을 강제 ROLLBACK

핵심 문장:

일반적인 트랜잭션 락은 “대기”를 허용하는 구조다.

즉, 동시에 같은 데이터를 수정하려 하면

시스템이 락 큐(Lock Queue)를 만들어 “순서대로 처리”한다.

2. PostgreSQL 트랜잭션 락 (엔진 특성)

PostgreSQL은 같은 문제를 MVCC(Multi-Version Concurrency Control) 구조로 재해석했다.

즉, “락 중심 제어” 대신 “버전 기반 가시성”으로 읽기와 쓰기를 분리한다.

1) MVCC — “무엇이 보이느냐(가시성)”

PostgreSQL은 각 행(row)에 xmin, xmax를 기록한다. 트랜잭션은 Snapshot을 통해 “보이는 버전만 읽기” 때문에

SELECT는 락을 걸지 않는다.

즉, 읽기-쓰기 간 충돌이 사라지고 “쓰기 간” 락만 남는다.

결과

• 읽기는 “버전 분리”
• 쓰기는 “락 경쟁”

2) Lock — “누가 먼저 쓰느냐(경합)”

PostgreSQL은 쓰기 충돌만 Row-Level Lock으로 제어한다.

3) WAIT — 순차 일관성(Consistency) 우선

설명: 기본 모드. 잠긴 행이 풀릴 때까지 대기한다.

적용 시점: 결제, 재고, 송금 등 정합성이 중요한 업무

UPDATE accounts
SET balance = balance - 1000
WHERE id = 1
FOR UPDATE;

이미 다른 트랜잭션이 같은 계좌를 수정 중이라면 순서대로 대기 후 실행된다.

• 장점: 데이터 일관성 보장
• 단점: 대기 시간 증가 가능

비즈니스 예시:

A 사용자가 결제 중일 때 B가 결제를 시도하면

B는 A의 트랜잭션이 끝날 때까지 대기한다.

→ 이중 결제나 중복 승인 방지에 유용하다.

4) NOWAIT — 빠른 실패(Fast-Fail) 전략

설명: 잠긴 행이 있으면 즉시 실패 (ERROR: could not obtain lock)

적용 시점: 빠른 응답이 필요한 API, 포인트 적립, 예약 등

UPDATE points
SET amount = amount + 100
WHERE user_id = 42
FOR UPDATE NOWAIT;

락이 걸려 있으면 바로 예외 발생 → 재시도 큐에 등록

• 장점: 빠른 응답, 타임아웃 불필요
• 단점: 실패 시 재시도 로직 필요

비즈니스 예시:

포인트 적립 중 다른 요청이 이미 처리 중이라면

“처리 중입니다” 메시지를 띄우고 종료.

→ 서버 부하를 줄이고 재시도 큐에서 나중에 처리한다.

5) SKIP LOCKED — 병렬 효율(Parallelism) 극대화

설명: 잠긴 행을 건너뛰고 처리 가능한 행만 선택

적용 시점: 주문 큐, 배치, 멀티 워커 시스템

SELECT * FROM orders
WHERE status = 'READY'
FOR UPDATE SKIP LOCKED
LIMIT 10;

이미 다른 워커가 처리 중인 주문은 건너뛰고, 남은 주문만 선택한다.

• 장점: 병렬 처리 효율 극대화, 락 대기 없음
• 단점: 일부 레코드는 나중에만 처리됨 (비동기적)

비즈니스 예시:

여러 워커(worker)가 동시에 주문 큐를 가져갈 때,

이미 잠긴 주문은 건너뛰고 처리 가능한 주문부터 가져간다.

→ 병렬성을 높이고 락 경합을 최소화한다.

6) 대기 전략 비교 요약

3. 타임아웃 · 데드락 제어

PostgreSQL은 “영원 대기”를 허용하지 않는다.

충돌 시 항상 실패 후 재시도가 정석 패턴이다.

4. 인덱스와 FK의 영향

정리:

인덱스가 MVCC의 효율을 결정한다.

잘못된 인덱스 설계는 불필요한 블로킹을 유발한다.

5. PostgreSQL 트랜잭션 락 정리

핵심 정리

정리 문장:

일반적인 트랜잭션 락은 ‘누가 먼저 쓰느냐’의 싸움이지만,

PostgreSQL의 트랜잭션 락은 ‘무엇이 보이느냐’를 분리한 뒤

‘누가 먼저 쓰느냐’를 최소 범위에서만 결정한다.

결론 — “대기 정책도 비즈니스 로직이다”

PostgreSQL은 단순히 트랜잭션 동작을 통제하는 수준을 넘어,

WAIT / NOWAIT / SKIP LOCKED 세 가지 대기 정책을

비즈니스 특성에 맞게 설계할 수 있도록 SQL 레벨에서 개방했다.

즉, “트랜잭션 제어”는 더 이상 엔진의 몫이 아니라

시스템 설계자의 선택 영역이다.

최종 요약

• MVCC는 “보이는 세계(가시성)”를,
• Lock은 “질서의 세계(순서)”를 다룬다.
• PostgreSQL은 이 둘을 가장 세련된 방식으로 결합한 데이터베이스다.

“지금까지는 데이터베이스가 동시성을 어떻게 제어하는지, 즉 MVCC와 트랜잭션 락이 ‘보이는 세계(가시성)’와 ‘쓰는 세계(경합)’를 분리하는 방식을 살펴봤습니다. 다음 편에서는 비관적 락 vs 낙관적 락 두 가지 접근 방식을 비교하며, 내가 직접 구현 중인 “좋아요 기능”에 어떤 방식이 더 적합한지 실제 프로젝트 수준에서 분석하고 적용해보겠습니다.

이 문서는 PostgreSQL의 트랜잭션 격리 수준(Isolation Level)과 MVCC(Multi-Version Concurrency Control) 동작 방식을 종합적으로 정리한 자료입니다.

단순한 표면적 차이뿐 아니라, xmin/xmax 기반의 스냅샷 판정·Vacuum 동작·Lost Update 시나리오·Serializable(SSI) 충돌 처리 등 실제 운영과 밀접한 내용을 포함합니다.

특히 실무에서 자주 고민하는 READ COMMITTED vs REPEATABLE READ 전환 문제와, DB 전역 vs 메서드별 격리 수준 설정 전략, 테스트 계획까지 다룹니다.

1. 격리 수준별 특징 정리

Phantom: 같은 트랜잭션 내 동일 조건 재조회 시, *새로운 “행”**이 보이는 현상.

1-1. 주요 이상(Phenomena) 미니 사전

1-2. DB별 차이 요약

2. MVCC (Multi-Version Concurrency Control)

2-1. 기존 락 기반 방식의 한계와 MVCC의 필요성

• Shared/Exclusive Lock 중심 모델은 쓰기 하나로 대기 행렬을 만들고, 읽기 많은 서비스에서 TPS 급감을 유발.
• MVCC는 다중 버전으로 읽기-쓰기 비차단을 지향해 병목을 줄인다.

2-2. 개념(핵심 정의)

• RC(문장 단위): SELECT 시작 시점의 최신 커밋본을 스냅샷으로 사용 → 재조회 결과가 달라질 수 있음.
• RR(트랜잭션 단위): 트랜잭션 시작 시점 스냅샷 고정(Snapshot Isolation) → Non-repeatable/대부분의 Phantom 차단, 단 Write-Skew 가능.
• SRLZ: RR + 커밋 시 충돌 감지로 직렬 가능성 보장 → 충돌 시 예외, 재시도 필요.

2-3. 장단점

2-4. PostgreSQL MVCC 내부 동작 상세

1) xmin / xmax

• 모든 행에는 xmin(생성 트랜잭션 ID), xmax(삭제/갱신 트랜잭션 ID)가 있다.
• INSERT → xmin 기록, UPDATE → 기존 행 xmax 설정 + 새 버전 INSERT.

2) Snapshot Visibility Rule

• 스냅샷과 xmin/xmax로 가시성 판단:
  1. xmin이 스냅샷 이전에 커밋 → 보임
  2. xmin이 현재 트랜잭션 → 보임
  3. xmax가 스냅샷 이전에 커밋 → 보이지 않음
• RC는 SELECT마다 새 스냅샷, RR은 트랜잭션 시작 시 스냅샷 고정.

3) Vacuum

• 어떤 스냅샷에서도 보이지 않는 dead tuple을 제거해 공간 회수·성능 유지.
• 장수 트랜잭션이 많으면 Vacuum 지연 → 전체 성능 저하 가능.

4) Snapshot 생성 시점 차이

3. READ COMMITTED vs REPEATABLE READ 실제 활용

PostgreSQL에서는 대부분 RC로 유지할지, RR로 올릴지가 핵심 고민입니다.

3-1. READ COMMITTED(RC)

• 특성: SELECT마다 스냅샷 재취득 → 재조회 값/행 변동 가능. 기본값이며 빠르고 단순.
• 적합: 목록/일반 조회처럼 최신 상태 반영이 자연스러운 API/화면.

3-2. REPEATABLE READ(RR)

• 특성: 트랜잭션 전체 스냅샷 고정, Non-repeatable/대부분의 Phantom 차단. 단, Write-Skew 가능.
• 적합: 폼 로드→검증→저장 등 트랜잭션 단위 일관성이 중요한 구간.

3-3. 선택 가이드

4. 전역(DB) 격리 수준 vs 메서드별 어노테이션 적용을 어떻게 사용하나?

4-1. 전역 상향은 지양(예외적 상황만)

• 규제/감사 요구, 단일 전용 DB, 코드 차원 제어가 구조적으로 불가한 경우 등 특수 상황만 고려.
• 가능하면 세션/ROLE 단위, 전용 커넥션 풀로 범위를 최소화.

4-2. 메서드 단위 적용(권장)

• 전역은 RC 유지, 특정 구간만 RR/SRLZ로 격리 강화.

@Transactional(isolation = Isolation.REPEATABLE_READ)
public void processCriticalOperation() { ... }

@Transactional(isolation = Isolation.SERIALIZABLE)
public void settleLedger() { ... }

• 고격리 전용 DataSource/Hikari Pool로 분리 가능.
• SERIALIZABLE 사용 시 재시도 로직은 필수(커밋 충돌 대비).

5. 테스트 대상 · 범위 · 방법 (Non-repeatable Read / Phantom Read)

5-1. 작성 의도 & 결정 로그

• 초기 계획: RC/RR × Non-repeatable/Phantom 2×2 전체 검증.
• 실행 중 변경: H2의 RR ≠ PostgreSQL RR(Snapshot Isolation) → PG 보장 증명으로 쓰기 부적절.
  • RR 요청을 JDBC SERIALIZABLE로 승격하는 트릭 사용(오해 소지).
  • PG 직렬화 충돌은 보통 40001인데 H2의 예외/락 판단이 달라 학습 자료로 부정확.
  • 엔진/버전/옵티마이저에 따라 결과 변동 위험.
• 최종 방침: RC 현상(Non-repeatable/Phantom “발생”)만 시연, RR/SRLZ 보장은 문헌 요약으로 처리.
  • 동일 시나리오의 PG(Testcontainers) 실습은 별도 글에서 재현 예정.

5-2. 실험 설계 매트릭스(최종)

5-3) 구현 포인트 — 어떤 함수/기능을 어떻게 썼나 (코드 기반, 합본)

NOTE-1 (H2 전용 트릭): 본 시연에서는 H2의 의미 차이를 보완하려고 toJdbcIso()에서 RR 요청을 JDBC SERIALIZABLE로 승격합니다. PostgreSQL 실습(Testcontainers)에서는 RR→RR, SRLZ→SRLZ 그대로 매핑하세요.

NOTE-2 (타이밍): conn.setTransactionIsolation(...)은 해당 트랜잭션에서 첫 SQL이 나가기 전에 반드시 적용되어야 스냅샷/락 컨텍스트가 일관합니다.

① 트랜잭션 경계 & 격리수준 지정: inTx / inTxQuiet

• 목적: T1/T2 각각의 격리수준과 커밋 타이밍을 정밀 제어.
• 방법: TransactionTemplate + Session#doWork로 JPA가 쓰는 동일 커넥션에서 JDBC 격리수준을 직접 설정.

void inTx(int springIsolation, String who, Runnable work) {
    TransactionTemplate tt = new TransactionTemplate(tm);
    out(who, "BEGIN (requestIsolation=%s)", springIsolation);

    tt.execute(status -> {
        em.unwrap(Session.class).doWork(conn -> {
            // 중요: 어떤 SQL도 나가기 전에 격리수준을 먼저 적용해야 동일 트랜잭션 스냅샷이 보장됩니다.
            int prev = conn.getTransactionIsolation();
            int eff  = toJdbcIso(springIsolation); // H2 시연 안정화를 위한 RR→SER 승격
            conn.setTransactionIsolation(eff);

            // URL의 DEFAULT_LOCK_TIMEOUT과 중복이지만, 세션 단위 보장을 위해 한 번 더 설정 (무해)
            try (var st = conn.createStatement()) { st.execute("SET LOCK_TIMEOUT 2000"); }

            try {
                work.run();
            } finally {
                conn.setTransactionIsolation(prev);
            }
        });
        return null;
    });

    out(who, "COMMIT");
}

private int toJdbcIso(int springIsolation) {
    return switch (springIsolation) {
        case TransactionDefinition.ISOLATION_READ_COMMITTED  -> Connection.TRANSACTION_READ_COMMITTED;
        case TransactionDefinition.ISOLATION_REPEATABLE_READ -> Connection.TRANSACTION_SERIALIZABLE; // H2 트릭
        case TransactionDefinition.ISOLATION_SERIALIZABLE    -> Connection.TRANSACTION_SERIALIZABLE;
        default -> Connection.TRANSACTION_READ_COMMITTED;
    };
}

// 필요 시: 람다에서 체크예외 억제용 등 간단 래퍼
void inTxQuiet(int springIsolation, Runnable work) {
    inTx(springIsolation, "TX", work);
}

② “같은 물리 커넥션” 고정: withSameConn

• 왜: 1차 캐시/세션 차이를 배제하고, 스냅샷·락 컨텍스트를 JPA/JDBC 간 일치.

private <T> T withSameConn(Function<Connection, T> f) {
    return em.unwrap(Session.class).doReturningWork(f::apply);
}

③ 캐시 영향 제거 + 이중 검증

• 의도: Non-repeatable/Phantom이 진짜 DB 스냅샷 변화인지 확인.

em.clear();
String secondJpa  = em.find(Post.class, postId).getTitle();
String secondJdbc = readTitleJdbc(postId); // 같은 커넥션에서 직접 JDBC
assertEquals(secondJpa, secondJdbc);       // 캐시 영향 아님

④ 정확한 타이밍 제어: CyclicBarrier & CountDownLatch (+ 예외 로깅)

• 시나리오: T1 1차 조회→대기 → T2 갱신·커밋 → T1 2차 조회.

static void await(CyclicBarrier b, String who, String where) {
    try {
        out(who, "⏸ barrier @%s (await)", where);
        b.await();
        out(who, "▶ proceed @%s (passed)", where);
    } catch (InterruptedException | BrokenBarrierException e) {
        out(who, "❗ barrier failed @%s : %s", where, e.toString());
        Thread.currentThread().interrupt();
        throw new RuntimeException(e);
    }
}

⑤ 픽스처 생성: newPostFixture() 등

• 포인트: 재현 가능한 상태(예: posts.title="HELLO", 댓글 0건) 보장을 위해 persist() 후 즉시 flush()로 DB 반영/ID 확보.

private Long newPostFixture() {
    final Long[] id = new Long[1];
    inTxQuiet(TransactionDefinition.ISOLATION_READ_COMMITTED, () -> {
        // Member/Store/Category 등 최소 데이터 생성
        // ...
        em.persist(post);
        em.flush();           // ID/상태 보장
        id[0] = post.getId();
    });
    return id[0];
}

⑥ 병행 실행 프레임: 스레드 이름 지정

• 가독성: 로그 분석 편의를 위해 스레드 이름을 부여.

Thread t1 = new Thread(() -> inTx(TransactionDefinition.ISOLATION_READ_COMMITTED, "T1-RC", () -> {
    // 1차 조회 → barrier 대기 → 2차 조회
}), "T1-RC");

Thread t2 = new Thread(() -> inTx(TransactionDefinition.ISOLATION_READ_COMMITTED, "T2-updater", () -> {
    // UPDATE/INSERT → COMMIT
}), "T2-updater");

t1.start(); t2.start();
t1.join();  t2.join();

⑦ 읽기 헬퍼: 동일 커넥션에서 JPA/JDBC 동시 제공

String readTitleJdbc(long postId) {
    return withSameConn(conn -> {
        try (PreparedStatement ps = conn.prepareStatement("select title from posts where id=?")) {
            ps.setLong(1, postId);
            try (ResultSet rs = ps.executeQuery()) { rs.next(); return rs.getString(1); }
        } catch (SQLException e) { throw new RuntimeException(e); }
    });
}

int countCommentsJdbc(Long postId) {
    return withSameConn(conn -> {
        try (PreparedStatement ps = conn.prepareStatement("select count(*) from comments where post_id=?")) {
            ps.setLong(1, postId);
            try (ResultSet rs = ps.executeQuery()) { rs.next(); return rs.getInt(1); }
        } catch (SQLException e) { throw new RuntimeException(e); }
    });
}

int countCommentsJPA(Long postId) {
    Long cnt = em.createQuery(
        "select count(c) from Comment c where c.post.id = :pid", Long.class)
        .setParameter("pid", postId)
        .getSingleResult();
    return cnt.intValue();
}

⑧ 시나리오 구현 요약(테스트 메서드 기준)

• Non-repeatable Read @ RC — nonRepeatable_RC_occurs_STABLE
  1. T1: 1차 조회(HELLO) → Barrier 대기
  2. T2: UPDATE title='UPDATED-...' → COMMIT
  3. T1: em.clear() 후 2차 조회(JPA/JDBC 동일) → 값 변경 확인
  4. assertNotEquals(first, secondJpa)
• Phantom Read @ RC — phantom_RC_occurs_STABLE
  1. T1: COUNT(*) 1차 조회(0) → Barrier 대기
  2. T2: 동일 조건 INSERT → COMMIT
  3. T1: 동일 커넥션에서 2차 COUNT(*) → 증가 확인
  4. assertTrue(c2 > c1)

5-4) 시나리오 1 — Non-repeatable Read @ RC (nonRepeatable_RC_occurs_STABLE)

구현 흐름

1. 픽스처: newPostFixture() → posts(id, title="HELLO")
2. T1(RC): 1차 조회 → Barrier 대기
3. T2(RC): UPDATE title='UPDATED-…' → COMMIT
4. T1: em.clear() 후 동일 커넥션에서 JPA/JDBC 2차 조회
5. 검증
   • secondJpa == secondJdbc → 캐시 영향 아님
   • first != secondJpa → NR 발생

타임라인(로그 해석)

[T1-RC] first='HELLO'             ← 1차 조회(스냅샷 S1)
[T2-updater] updated='UPDATED-...'
[T2-updater] COMMIT               ← T2 커밋
[T1-RC] second JPA='UPDATED-...', JDBC='UPDATED-...'
ASSERT: NR @ RC -> 'HELLO' vs 'UPDATED-...'

핵심 코드

first[0] = em.find(Post.class, postId).getTitle(); // "HELLO"
await(barrier, "T1-RC", "after-first-read");

p.update("UPDATED-...", p.getContent());           // in T2
em.flush();                                        // inTx 종료 시 COMMIT

em.clear();                                        // 캐시 제거
secondJpa[0]  = em.find(Post.class, postId).getTitle();
secondJdbc[0] = readTitleJdbc(postId);             // 동일 커넥션 JDBC

assertEquals(secondJpa[0], secondJdbc[0]);         // 캐시 아님
assertNotEquals(first[0], secondJpa[0]);           // NR 발생

5-5) 시나리오 2 — Phantom Read @ RC (phantom_RC_occurs_STABLE)

구현 흐름

1. 픽스처: 대상 post_id 댓글 0건
2. T1(RC): COUNT(*) 1차 조회 → Barrier 대기
3. T2(RC): 동일 조건 INSERT → COMMIT
4. T1: 동일 커넥션에서 JPA/JDBC 2차 COUNT(*)
5. 검증
   • c2Jpa == c2Jdbc → 캐시 영향 아님
   • c2 > c1 → Phantom 발생

타임라인(로그 해석)

[T1-RC] first count JPA=0, JDBC=0   ← 1차 카운트(스냅샷 S1)
[T2-inserter] COMMIT                 ← 새 댓글 INSERT
[T1-RC] second count JPA=1, JDBC=1
ASSERT: PH @ RC -> 0 -> 1

핵심 코드

c1Jpa.set(countCommentsJPA(postId));
c1Jdbc.set(countCommentsJdbc(postId));            // 동일 커넥션 JDBC
await(barrier, "T1-RC", "after-first-count");

em.persist(Comment.builder().post(post).member(m).content("hi").build()); // in T2
em.flush();                                      // inTx 종료 시 COMMIT

c2Jpa.set(countCommentsJPA(postId));
c2Jdbc.set(countCommentsJdbc(postId));

assertEquals(c2Jpa.get(), c2Jdbc.get());          // 캐시 아님
assertTrue(c2Jpa.get() > c1Jpa.get());            // PH 발생

5-6)RR 테스트를 본문에서 뺀 이유(요약)

• H2의 RR ≠ PostgreSQL RR(SI): 보장/예외/락 동작이 다름.

1) H2의 RR ≠ PostgreSQL의 RR(Snapshot Isolation)

• PostgreSQL의 RR은 Snapshot Isolation(스냅샷 고정) 의미다.

• 반면 H2의 RR 의미/내부 동작은 동일하지 않다.

  → 같은 테스트라도 보장 수준과 예외 양상이 PG와 다를 수 있음.

2) 시연 편의상 “RR→JDBC SERIALIZABLE 승격” 트릭을 사용

• 코드에서 RR 요청 시 toJdbcIso()로 JDBC SERIALIZABLE로 승격했다.

• 즉, H2에서의 RR 테스트는 실제로는 SERIALIZABLE 시나리오에 가깝다.

  → “RR 보장 증명”으로 오해될 수 있어 본문에 싣지 않음.

3) 예외/락 동작이 PG와 다름

• PostgreSQL의 직렬화 충돌은 보통 SQLSTATE 40001(serialization_failure)로 떨어진다.
• H2는 예외 타입/메시지/락 판단 기준이 다를 수 있어 학습 자료로 부정확하다.

4) 결과가 DB/버전/옵티마이저에 따라 흔들릴 위험

• 같은 개념 테스트라도 엔진 차이로 결과가 바뀔 수 있다.
• 블로그에 실으면 “PG에서 이렇게 보장된다”라는 잘못된 인상을 줄 수 있음.

5) 그래서 선택한 편집 방침

• 본문에서는 H2로 RC 현상(Non-repeatable / Phantom “발생”)만 시연해 독자가 현상 자체를 체감하게 한다.
• RR/Serializable의 보장은 공식 문서 기반으로 요약만 한다.
• 진짜 증명은 추후 PostgreSQL(Testcontainers) 실습 글에서 같은 시나리오로 재현하여 싣는다.

💬 PostgreSQL 격리 수준 동작 방식 — 블로그 & 영상 인용

Engineer Insight 블로그쉬운코드 유튜브

“PostgreSQL은 READ COMMITTED에서도 MVCC 기반의 Snapshot을 사용한다. 하지만 엄밀한 의미의 Snapshot Isolation은 REPEATABLE READ부터 적용된다.”

— 쉬운코드 유튜브

“READ COMMITTED에서는 각 SELECT가 실행될 때마다 새로운 snapshot을 가져오기 때문에, 동일 트랜잭션 내에서도 재조회 결과가 달라질 수 있다. REPEATABLE READ에서는 트랜잭션 시작 시점 snapshot을 고정해 snapshot isolation을 제공한다.”

— Engineer Insight 블로그

📌 Lost Update — 본 글에서는 제외

본 글은 격리 수준·MVCC에 초점을 둡니다. Lost Update의 정의·재현·해결(비관적/낙관적 락)은

다음 글: Lock과 동시성 제어(실무 편)에서 사례 코드와 함께 다룹니다.

📌 Serializable (SSI)

PostgreSQL의 SERIALIZABLE은 SSI(Serializable Snapshot Isolation) 방식으로, Write Skew를 포함한 anomaly를 방지합니다.

커밋 시 충돌이 감지되면 SQLSTATE 40001(serialization_failure)로 실패할 수 있으며, 재시도 로직이 필요합니다.

이번 글은 그중 “범위(Scope)”에만 집중한다. 요지는 간단하다.

업로드 같은 I/O는 트랜잭션 밖에서 먼저 끝내고, DB에는 URL만 짧게 반영한다.

그리고 auto-commit=false + provider_disables_autocommit=true로 커넥션 점유 구간을 최소화한다.

0) 사전 실험 요약(한 줄씩)

• 1️⃣ @Transactional 없이 베이스라인 측정 → 커넥션을 언제 빌리는지 감 잡기
• 2️⃣ REQUIRED vs REQUIRES_NEW → 경계 분리가 미치는 영향 확인
• 3️⃣ Self-invocation → 프록시 미적용 구간 드러남
• 4️⃣ auto-commit=false + hibernate.connection.provider_disables_autocommit=true → 점유 시간 큰 폭 감소

이제 이 원리를 실제 핀업 흐름에 녹였다.

1) A/B 흐름 정의

그림 — 왼쪽: A안(업로드가 트랜잭션 안이라 active=1 유지), 오른쪽: B안(업로드 먼저, DB는 짧게 active=1→0). auto-commit=false + provider_disables_autocommit=true 적용.

A안(기존)

• 흐름: [요청] → first SQL(=post save) → post_images save → (업로드) → thumbnail update → commit
• 특징: 업로드가 트랜잭션 내부에 포함 → DB 커넥션 점유 시간이 길다.

B안(변경)

• 흐름: [요청] → (업로드만) → first SQL(=post save) → post_images save → thumbnail update → commit
• 특징: 업로드를 트랜잭션 밖에서 먼저 끝내고, DB에는 URL만 짧게 반영한다.

2) 적용 설정

커넥션 지연획득을 돕고 트랜잭션 경계를 최소화하기 위해 다음만 적용했다.

spring:
  datasource:
    hikari:
      auto-commit: false
  jpa:
    properties:
      hibernate.connection.provider_disables_autocommit: true

• auto-commit=false: 커밋 시점을 애플리케이션이 통제.
• hibernate.connection.provider_disables_autocommit=true: 하이버네이트가 드라이버의 오토커밋을 건드리지 않아 커넥션 점유 구간 축소.

3) 변경 포인트 (서비스 레벨)

3-1) PostImageService — 업로드/저장 분리 + 보상 삭제

기존에는 업로드 + DB 저장을 하나의 메서드에서 처리했다. 이를 아래 3개 역할로 분리했다(코드는 비공개, 메서드 역할만 명시).

1. 업로드만 수행하고 URL 리스트만 반환 — uploadImagesOnly(...)
2. 업로드된 URL을 이용해 post_images만 DB 저장 — saveImageUrls(...)
3. 보상 삭제(Compensation): DB 실패 시 업로드했던 URL 리스트로 S3 객체를 조용히 삭제(예외는 삼켜서 DB 예외를 덮지 않음) — deleteS3ByUrlsQuietly(...)

3-2) PostService — 전/후 비교가 명확

A안(기존) — 업로드가 트랜잭션 내부

@Transactional
public PostResponse createPost(MemberInfo memberInfo,
                               CreatePostRequest createPostRequest,
                               CreatePostImageRequest createPostImageRequest) {
    Post post = createPostEntity(memberInfo, createPostRequest);
    post = postRepository.save(post);

    appLogger.info(new InfoLog("게시글 생성 완료")
            .setStatus("201")
            .setTargetId(post.getId().toString())
            .addDetails("writer", post.getMember().getNickname(), "title", post.getTitle()));

    // 업로드 + DB 저장이 같은 경계 안
    List<PostImage> postImages = postImageService.savePostImages(createPostImageRequest, post);

    if (!postImages.isEmpty()) {
        post.updateThumbnail(postImages.get(0).getS3Url());
    }
    return PostResponse.from(post);
}

B안(변경) — 업로드 먼저, DB 실패 시 보상 삭제

@Timed("post.create")
@Transactional
public PostResponse createPost(MemberInfo memberInfo,
                               CreatePostRequest createPostRequest,
                               CreatePostImageRequest createPostImageRequest) {
    StepWatch sw = new StepWatch("PostService.createPost");

    // 1) 업로드만 먼저 (S3) — 트랜잭션 밖 I/O
    sw.start("1. upload only");
    List<String> uploadedUrls = postImageService.uploadImagesOnly(createPostImageRequest);
    sw.stop();

    try {
        // 2) post insert
        sw.start("2. post insert");
        Post post = createPostEntity(memberInfo, createPostRequest);
        post = postRepository.save(post);
        sw.stop();

        // 3) post_images DB 저장
        sw.start("3. postImages save");
        List<PostImage> postImages = postImageService.saveImageUrls(post, uploadedUrls);
        sw.stop();

        // 4) 썸네일 업데이트
        sw.start("4. thumbnail update");
        if (!postImages.isEmpty()) {
            post.updateThumbnail(postImages.get(0).getS3Url());
        }
        sw.stop();

        return PostResponse.from(post);

    } catch (Exception e) {
        // DB 단계 실패 시 → 이미 업로드된 S3 보상 삭제
        postImageService.deleteS3ByUrlsQuietly(uploadedUrls);
        throw e; // 원래 예외를 그대로 전파하여 트랜잭션 롤백
    }
}

포인트

• 업로드는 트랜잭션 밖에서 선행되므로 DB 커넥션을 점유하지 않음
• DB 실패 시 deleteS3ByUrlsQuietly(...)로 S3 고아 객체 방지
• @Timed와 StepWatch로 단계별 시간을 남겨 병목을 확인

4) 측정 결과 (로그 기반)

** DB 점유: p6spy SQL 시작~커밋 로그 간격

최적 비교(설정 전 · A안 → 설정 후 · B안)

• Tx: 448 → 208ms (−54%)
• DB 점유: 431 → 39ms (−91%)
• 전체: 402 → 194ms (−52%)

트랜잭션/커넥션 점유 시간 감소가 응답 시간 개선으로 직결되었다.

5) 증빙 로그

설정 전 · A안 (업로드가 트랜잭션 안)

핵심 포인트: 업로드가 트랜잭션 내부에 있어 커넥션이 긴 시간(active=1) 점유된다.

18:00:06.210  Creating new transaction ... [PostService.createPost]

# (트랜잭션 시작 직후부터 DB 점유)
18:00:06.223  select ... from members where nickname='흥미로운 허브'
18:00:06.333  insert into posts (...)
18:00:06.340  HikariPool-1 - Pool stats (total=10, active=1, idle=9, waiting=0)   <-- active=1 유지 시작

# (업로드가 Tx 안에서 수행됨 → DB 커넥션 계속 점유)
18:00:06.458  S3 PUT /pinup/post/2620c004-..._1697261010140.jpg
18:00:06.515  S3 200 OK
18:00:06.568  S3 PUT /pinup/post/5565cfb8-..._full-stack-developer.jpg
18:00:06.583  S3 200 OK

# (이미지 메타 저장 + 커밋)
18:00:06.618  insert into post_images (...)
18:00:06.622  insert into post_images (...)
18:00:06.658  commit
18:00:06.658  HikariPool-1 - Pool stats (total=10, active=0, idle=10, waiting=0)   <-- 커밋 후 반납

요약

• 업로드 구간: active=1 (트랜잭션 내부이므로 DB 커넥션 계속 점유)
• DB 구간: 업로드 포함 전체가 하나의 긴 점유 구간
• 측정값: DB 점유 ≈ 431ms, Tx ≈ 448ms, 전체 ≈ 402–406ms

설정 후 · B안 (업로드 먼저, DB는 짧게)

핵심 포인트: 업로드를 먼저 끝낸 뒤 필요한 순간에만 DB 커넥션을 잠깐 빌린다.

18:37:31.792  Creating new transaction ... [PostService.createPost]

# (업로드 전용 구간) — DB 미사용
18:37:31.801  S3 PUT /pinup/post/3e140853-..._지도도.webp
18:37:31.823  S3 200 OK
18:37:31.851  S3 PUT /pinup/post/9d6ba0d9-..._통합본.jpg
18:37:31.929  S3 200 OK
18:37:31.930  HikariPool-1 - Pool stats (total=10, active=0, idle=10, waiting=0)   <-- 업로드 동안 active=0

# (DB 구간 진입) — 짧게 빌리고 바로 반납
18:37:31.961  select ... from members where nickname='흥미로운 허브'
18:37:31.966  select ... from stores where id=9
18:37:31.975  HikariPool-1 - Pool stats (total=10, active=1, idle=9, waiting=0)    <-- DB 커넥션 점유 시작(스파이크)

18:37:31.974  insert into posts (...)
18:37:31.980  insert into post_images (...)
18:37:31.985  insert into post_images (...)
18:37:31.991  update posts set ... thumbnail_url=...
18:37:32.000  commit
18:37:32.000  HikariPool-1 - Pool stats (total=10, active=0, idle=10, waiting=0)   <-- 커밋 즉시 반납

요약

• 업로드 구간: active=0 (DB 커넥션 미점유)
• DB 구간: 잠깐 active=1 → 커밋 직후 다시 0
• 측정값: DB 점유 ≈ 39ms, Tx ≈ 208ms, 전체 ≈ 194ms

위 Pool stats 라인은 업로드 종료/첫 SQL 직후/커밋 직후 등 스텝 경계에서 출력했다. 이 지점만 찍어도 active=0 → 1 → 0 패턴이 선명히 드러난다.

6) 결론

• 원리: 업로드를 트랜잭션 경계 밖으로 분리하고, DB에는 URL만 짧게 반영한다.
• 설정: auto-commit=false + hibernate.connection.provider_disables_autocommit=true 조합으로 커넥션 점유 구간을 줄인다.
• 정합성: DB 실패 시 S3 보상 삭제로 고아 파일을 방지한다.
• 효과: Tx −54%, DB 점유 −91%, 전체 −52%. 최종 응답 시간이 의미 있게 단축되었다.

요약

• @Transactional은 프록시(proxy) 경유 시만 적용. 자기호출(Self-Invocation) 은 미적용.
• REQUIRES_NEW는 외부 빈 호출일 때만 부모 Suspend → 자식 새 트랜잭션. 부모 미커밋은 자식에서 가시성 없음(FK 실패 가능).
• HikariCP auto-commit=false + hibernate.connection.provider_disables_autocommit=true로 첫 SQL 전까지 커넥션 미획득을 실제 로그로 확인(풀 점유/동시성에 유리).

Creating new transaction with name [MemberService.isAccessTokenExpired]
No need to create transaction for [SimpleJpaRepository.findByEmailAndProviderTypeAndIsDeletedFalse]: This method is not transactional.
Completing transaction for [MemberService.isAccessTokenExpired]
Initiating transaction commit
Committing JPA transaction on EntityManager [...]
commit
Closing JPA EntityManager [...] after transaction

PostApiController : 게시글 생성 요청 수신: writer=흥미로운 허브, title=test
TX-PLAY: baseline - PostService.createPost (no @Transactional)

No need to create transaction for [SimpleJpaRepository.findByNickname]: This method is not transactional.   // 비트랜잭션 조회
Creating new transaction with name [SimpleJpaRepository.findById] ... ,readOnly                         // 읽기전용 짧은 트랜잭션
Completing transaction for [SimpleJpaRepository.findById]
Initiating transaction commit
Committing JPA transaction on EntityManager [...]
commit

Creating new transaction with name [SimpleJpaRepository.save]
insert into posts (...)
Completing transaction for [SimpleJpaRepository.save]
Initiating transaction commit
Committing JPA transaction on EntityManager [...]
commit

S3Service.uploadFile ... "이미지 업로드 성공" (HTTP 200)   // DB 트랜잭션과 무관

Creating new transaction with name [SimpleJpaRepository.saveAll]
insert into post_images (...)      // 1건
insert into post_images (...)      // 1건
Completing transaction for [SimpleJpaRepository.saveAll]
Initiating transaction commit
Committing JPA transaction on EntityManager [...]
commit

2025-09-23T16:24:00.111+09:00 DEBUG ... JpaTransactionManager : Creating new transaction with name [MemberService.isAccessTokenExpired]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
2025-09-23T16:24:00.115+09:00 TRACE ... TransactionInterceptor : Getting transaction for [MemberService.isAccessTokenExpired]
2025-09-23T16:24:00.251+09:00 INFO  p6spy : select ... from members where email='pinup0106@gmail.com' and provider_type='GOOGLE' and not(is_deleted)
2025-09-23T16:24:00.252+09:00 DEBUG ... JpaTransactionManager : Committing JPA transaction on EntityManager [...]
2025-09-23T16:24:00.254+09:00 INFO  p6spy : commit

2025-09-23T16:24:00.325+09:00 INFO  PostApiController : 게시글 생성 요청 수신: writer=흥미로운 허브, title=test REQUIRES_NEW
2025-09-23T16:24:00.326+09:00 DEBUG ... JpaTransactionManager : Creating new transaction with name [PostService.createPost]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
2025-09-23T16:24:00.327+09:00 INFO  PostService : TX-PLAY: baseline - PostService.createPost ( @Transactional)

2025-09-23T16:24:00.327+09:00 TRACE ... No need to create transaction for [SimpleJpaRepository.findByNickname]
2025-09-23T16:24:00.333+09:00 INFO  p6spy : select ... from members where nickname='흥미로운 허브'
2025-09-23T16:24:00.335+09:00 TRACE ... Getting transaction for [SimpleJpaRepository.findById]
2025-09-23T16:24:00.337+09:00 INFO  p6spy : select ... from stores where id=9

2025-09-23T16:24:00.339+09:00 TRACE ... Getting transaction for [SimpleJpaRepository.save]
2025-09-23T16:24:00.400+09:00 INFO  p6spy : insert into posts (...) values ('test REQUIRES_NEW','2025-09-23T16:24:00.361+0900',false,0,1,9,NULL,'test REQUIRES_NEW',0)
2025-09-23T16:24:00.415+09:00 INFO  StructuredLogger : 게시글 생성 완료 targetId=10009

2025-09-23T16:24:00.482+09:00 DEBUG ... Sending Request: PUT /pinup/post/28f94855-....jpg
2025-09-23T16:24:00.509+09:00 DEBUG ... Received successful response: 200
2025-09-23T16:24:00.533+09:00 INFO  StructuredLogger : 이미지 업로드 성공 url=http://127.0.0.1:4566/pinup/post/28f94855-....jpg

2025-09-23T16:24:00.415+09:00 DEBUG ... Suspending current transaction, creating new transaction with name [PostImageService.savePostImages]
2025-09-23T16:24:00.418+09:00 INFO  PostImageService : TX-PLAY: baseline - PostImageService.savePostImages ( @Transactional REQUIRES_NEW)
2025-09-23T16:24:00.559+09:00 TRACE ... Getting transaction for [SimpleJpaRepository.saveAll]
2025-09-23T16:24:00.572+09:00 INFO  p6spy : insert into post_images (created_at,post_id,url) values ('2025-09-23T16:24:00.560+0900',10009,'http://127.0.0.1:4566/pinup/post/28f94855-....jpg')
2025-09-23T16:24:00.575+09:00 ERROR SqlExceptionHelper : ERROR: insert or update on table "post_images" violates foreign key constraint ...
Detail: Key (post_id)=(10009) is not present in table "posts".

2025-09-23T16:24:00.589+09:00 DEBUG ... Rolling back JPA transaction on EntityManager [...]   // 자식 REQUIRES_NEW 롤백
2025-09-23T16:24:00.592+09:00 DEBUG ... Resuming suspended transaction after completion of inner transaction
2025-09-23T16:24:00.592+09:00 TRACE ... Completing transaction for [PostService.createPost] after exception ...
2025-09-23T16:24:00.593+09:00 INFO  p6spy : rollback                                                // 부모도 롤백

2025-09-23T16:26:10.932+09:00 DEBUG ... Creating new transaction [MemberService.isAccessTokenExpired]
2025-09-23T16:26:11.066+09:00 INFO  p6spy : select ... from members where email='pinup0106@gmail.com' and provider_type='GOOGLE' and not(is_deleted)
2025-09-23T16:26:11.070+09:00 INFO  p6spy : commit

2025-09-23T16:26:11.167+09:00 INFO  PostApiController : 게시글 생성 요청 수신: writer=흥미로운 허브, title=test REQUIRED
2025-09-23T16:26:11.168+09:00 DEBUG ... Creating new transaction with name [PostService.createPost]: PROPAGATION_REQUIRED
2025-09-23T16:26:11.169+09:00 INFO  PostService : TX-PLAY: baseline - PostService.createPost ( @Transactional)

2025-09-23T16:26:11.175+09:00 INFO  p6spy : select ... from members where nickname='흥미로운 허브'
2025-09-23T16:26:11.181+09:00 INFO  p6spy : select ... from stores where id=9

2025-09-23T16:26:11.270+09:00 INFO  p6spy : insert into posts (...) values ('test REQUIRED','2025-09-23T16:26:11.220+0900',false,0,1,9,NULL,'test REQUIRED',0)
2025-09-23T16:26:11.284+09:00 INFO  StructuredLogger : 게시글 생성 완료 targetId=10010

2025-09-23T16:26:11.363+09:00 DEBUG ... Sending Request: PUT /pinup/post/7e2be727-....jpg
2025-09-23T16:26:11.392+09:00 DEBUG ... Received successful response: 200
2025-09-23T16:26:11.426+09:00 INFO  StructuredLogger : 이미지 업로드 성공 url=http://127.0.0.1:4566/pinup/post/7e2be727-....jpg

2025-09-23T16:26:11.285+09:00 INFO  PostImageService : TX-PLAY: baseline - PostImageService.savePostImages ( @Transactional REQUIRED)
2025-09-23T16:26:11.480+09:00 INFO  p6spy : insert into post_images (...) values ('2025-09-23T16:26:11.472+0900',10010,'http://127.0.0.1:4566/pinup/post/7e2be727-....jpg')
2025-09-23T16:26:11.483+09:00 INFO  p6spy : insert into post_images (...) values ('2025-09-23T16:26:11.481+0900',10010,'http://127.0.0.1:4566/pinup/post/04699b9c-....jpg')
2025-09-23T16:26:11.485+09:00 INFO  StructuredLogger : 이미지 저장 완료 count=2

2025-09-23T16:26:11.485+09:00 TRACE ... Completing transaction for [PostService.createPost]
2025-09-23T16:26:11.508+09:00 INFO  p6spy : update posts set ... thumbnail_url='http://127.0.0.1:4566/pinup/post/7e2be727-....jpg', updated_at='2025-09-23T16:26:11.491+0900', version=1 where id=10010 and version=0
2025-09-23T16:26:11.517+09:00 INFO  p6spy : commit

// PostService.createPost(@Transactional) 내부에서 같은 클래스 메서드를 호출:
txPrivateNewProbe();    // private + REQUIRES_NEW
txProtectedNewProbe();  // protected + REQUIRES_NEW
txStaticNewProbe();     // static + REQUIRES_NEW

... JpaTransactionManager : Found thread-bound EntityManager [...] for JPA transaction
... JpaTransactionManager : Participating in existing transaction
... TransactionInterceptor : Getting transaction for [SimpleJpaRepository.count]
// 기대했던 "Suspending current transaction ..." / "Opened new EntityManager ..." 없음

@EnableAspectJAutoProxy(exposeProxy = true, proxyTargetClass = true)

((PostService) AopContext.currentProxy()).txPublicNewProbe(); // public + @Transactional(REQUIRES_NEW)

... JpaTransactionManager : Found thread-bound EntityManager [SessionImpl(931946576<open>)] for JPA transaction
... JpaTransactionManager : Suspending current transaction, creating new transaction with name [kr.co.pinup.posts.service.PostService.txPublicNewProbe]
... JpaTransactionManager : Opened new EntityManager [SessionImpl(64740231<open>)] for JPA transaction
... TransactionInterceptor : Getting transaction for [PostService.txPublicNewProbe]
... PostService : txPublicNewProbe (public, REQUIRES_NEW) start
... SimpleJpaRepository.count
... JpaTransactionManager : Initiating transaction commit
... JpaTransactionManager : Committing JPA transaction on EntityManager [SessionImpl(64740231<open>)]
... p6spy : commit | connection 1
... JpaTransactionManager : Resuming suspended transaction after completion of inner transaction
... JpaTransactionManager : Found thread-bound EntityManager [SessionImpl(931946576<open>)] for JPA transaction

2025-09-17T17:10:20.913+09:00 DEBUG ... Creating new transaction with name [com.example.demo.service.UserService.join]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
2025-09-17T17:10:20.920+09:00 DEBUG ... Exposing JPA transaction as JDBC [...]
2025-09-17T17:10:33.608+09:00 DEBUG ... HikariPool-1 - Pool stats (total=10/10, idle=9/10, active=1, waiting=0)   <-- 슬립 중 active=1
2025-09-17T17:11:01.016+09:00 DEBUG ... org.hibernate.SQL : insert into users (email,name,id) values (?,?,default)
2025-09-17T17:11:41.085+09:00 DEBUG ... Committing JPA transaction on EntityManager [...]

2025-09-17T17:17:58.267+09:00 DEBUG ... Creating new transaction with name [com.example.demo.service.UserService.join]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
2025-09-17T17:18:01.595+09:00 DEBUG ... HikariPool-1 - Pool stats (total=10/10, idle=10/10, active=0, waiting=0)   <-- 슬립 중 active=0
2025-09-17T17:18:38.315+09:00 DEBUG ... org.hibernate.SQL : insert into users (email,name,id) values (?,?,default)  <-- 첫 SQL
2025-09-17T17:19:01.602+09:00 DEBUG ... HikariPool-1 - Pool stats (total=10/10, idle=9/10, active=1, waiting=0)   <-- SQL 직후 active=1
2025-09-17T17:19:18.364+09:00 DEBUG ... Committing JPA transaction on EntityManager [...]

# Tomcat (Web Thread)
server.tomcat.max-threads: 32
server.tomcat.accept-count: 100
server.tomcat.connection-timeout: 15000

# HikariCP (DB Connection Pool)
spring.datasource.hikari.maximum-pool-size: 30
spring.datasource.hikari.minimum-idle: 10
spring.datasource.hikari.connection-timeout: 15000

# JVM Heap
-Xmx: 4096m
-Xms: 512m

return posts.stream()
    .map(post -> PostResponse.fromPostWithComments(
        post,
        commentRepository.countByPostId(post.getId()),
        postLikeRepository.existsByPostIdAndMemberId(post.getId(), member.getId())
    ))
    .collect(Collectors.toList());

SELECT p.id, p.title, p.created_at, COUNT(c.id) AS comment_count
FROM posts p
LEFT JOIN comments c ON c.post_id = p.id
WHERE p.store_id = :storeId
GROUP BY p.id
ORDER BY p.created_at DESC;

CREATE INDEX IF NOT EXISTS idx_comment_post_id   ON comments(post_id);
CREATE INDEX IF NOT EXISTS idx_post_store_id     ON posts(store_id);
CREATE INDEX IF NOT EXISTS idx_post_created_at   ON posts(created_at DESC);

CREATE INDEX IF NOT EXISTS idx_comment_post_id ON comments(post_id);
CREATE INDEX IF NOT EXISTS idx_posts_store_created ON posts(store_id, created_at DESC);

EXPLAIN (ANALYZE, BUFFERS)
SELECT p.id, p.title, p.created_at, COUNT(c.id) AS comment_count
FROM posts p
LEFT JOIN comments c ON c.post_id = p.id
WHERE p.store_id = 1
GROUP BY p.id
ORDER BY p.created_at DESC;

포인트: `Seq Scan + HashAggregate`, `shared_blks_read` 매우 큼.

포인트: `Index Scan`로 전환, 정렬비용 잔존.

포인트: **필터+정렬 동시 충족** → 추가로 1ms 정도 더 단축.

SELECT
  calls,
  round(total_exec_time::numeric, 2)  AS total_ms,
  round(mean_exec_time::numeric, 2)   AS mean_ms,
  round(stddev_exec_time::numeric, 2) AS stddev_ms,
  rows, shared_blks_hit, shared_blks_read, query
FROM pg_stat_statements
WHERE query ILIKE '%FROM posts p%'
  AND query ILIKE '%GROUP BY p.id%'
  AND query ILIKE '%ORDER BY p.created_at%'
ORDER BY total_exec_time DESC
LIMIT 5;

return posts.stream()
    .map(post -> PostResponse.fromPostWithComments(
        post,
        commentRepository.countByPostId(post.getId()),
        postLikeRepository.existsByPostIdAndMemberId(post.getId(), member.getId())
    ))
    .collect(Collectors.toList());

@Query("""
SELECT new kr.co.pinup.posts.model.dto.PostResponse(
  p.id,
  p.member.nickname,
  p.title,
  p.thumbnail,
  p.createdAt,
  COUNT(c.id),     -- 댓글 수
  p.likeCount,     -- 유지된 좋아요 수
  CASE
    WHEN :memberId IS NOT NULL AND
         EXISTS (SELECT 1 FROM PostLike pl WHERE pl.post.id = p.id AND pl.member.id = :memberId)
    THEN TRUE ELSE FALSE
  END
)
FROM Post p
LEFT JOIN Comment c ON c.post.id = p.id
WHERE p.store.id = :storeId
  AND p.isDeleted = :isDeleted
GROUP BY p.id, p.member.nickname, p.title, p.thumbnail, p.createdAt, p.likeCount
ORDER BY p.createdAt DESC
""")
List<PostResponse> findPostListItems(Long storeId, boolean isDeleted, Long memberId);

-- 초기화
DROP INDEX IF EXISTS idx_comment_post_id;
DROP INDEX IF EXISTS idx_post_store_id;
DROP INDEX IF EXISTS idx_post_created_at;
DROP INDEX IF EXISTS idx_posts_store_created;

-- 전략 A: 단일 3개
CREATE INDEX IF NOT EXISTS idx_comment_post_id ON comments(post_id);
CREATE INDEX IF NOT EXISTS idx_post_store_id ON posts(store_id);
CREATE INDEX IF NOT EXISTS idx_post_created_at ON posts(created_at DESC);

-- 전략 B: 복합 + 보조 1개 (A 제거 후)
DROP INDEX IF EXISTS idx_post_store_id;
DROP INDEX IF EXISTS idx_post_created_at;
CREATE INDEX IF NOT EXISTS idx_comment_post_id ON comments(post_id);
CREATE INDEX IF NOT EXISTS idx_posts_store_created ON posts(store_id, created_at DESC);

ANALYZE posts;
ANALYZE comments;

SELECT pg_stat_statements_reset();

-- 동일 세션에서 50회 반복 실행
SELECT p.id, p.title, p.created_at, COUNT(c.id)
FROM posts p
LEFT JOIN comments c ON c.post_id = p.id
WHERE p.store_id = 1
GROUP BY p.id
ORDER BY p.created_at DESC;

-- 집계
SELECT
  calls,
  round(total_exec_time::numeric, 2)  AS total_ms,
  round(mean_exec_time::numeric, 2)   AS mean_ms,
  round(stddev_exec_time::numeric, 2) AS stddev_ms,
  rows, shared_blks_hit, shared_blks_read, query
FROM pg_stat_statements
WHERE query ILIKE '%FROM posts p%'
  AND query ILIKE '%GROUP BY p.id%'
  AND query ILIKE '%ORDER BY p.created_at%'
ORDER BY total_exec_time DESC
LIMIT 5;

services:
  docker-stats-exporter:
    image: wywywywy/docker_stats_exporter:latest
    container_name: docker-stats-exporter
    ports:
      - "9487:9487"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro

scrape_configs:
  - job_name: 'docker-stats'
    static_configs:
      - targets: ['docker-stats-exporter:9487']

-javaagent:C:/dev/otel-agent/opentelemetry-javaagent.jar ^
-Dotel.service.name=pinup-service ^
-Dotel.exporter.otlp.endpoint=http://localhost:4318 ^
-Dotel.resource.attributes=deployment.environment=local

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

exporters:
  otlphttp/tempo:
    endpoint: http://tempo:4319
  loki:
    endpoint: http://loki:3100/loki/api/v1/push
  debug:
    verbosity: detailed   # 로컬 실험용(필수 아님)

processors:
  batch: {}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/tempo]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [loki]

service.name = "pinup-service"

span.name = "GET /actuator/prometheus"

<appender name="LOKI" class="com.github.loki4j.logback.Loki4jAppender">
  <http>
    <url>http://localhost:3100/loki/api/v1/push</url>
  </http>
  <format>
    <json>
      <field name="timestamp" pattern="%d{yyyy-MM-dd'T'HH:mm:ss.SSSXXX}" />
      <field name="level" pattern="%level" />
      <field name="message" pattern="%msg" />
      <field name="traceId" pattern="%X{traceId}" />
    </json>
  </format>
</appender>

# postgresql.conf
shared_preload_libraries = 'pg_stat_statements'

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

SELECT query, total_exec_time, mean_exec_time, calls
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 10;

# 수정 예시
label_values(http_server_requests_seconds_count, job)
label_values(http_server_requests_seconds_count, instance)

management:
  endpoints:
    web:
      exposure:
        include:
          - health
          - info
          - prometheus
  metrics:
    distribution:
      percentiles-histogram:
        http.server.requests: true
      percentiles:
        http.server.requests: 0.5, 0.95, 0.99

modulelist=com.p6spy.engine.logging.P6LogFactory
logMessageFormat=com.p6spy.engine.spy.appender.SingleLineFormat
appender=com.p6spy.engine.spy.appender.Slf4JLogger
logLevel=info

<appender name="LOKI" class="com.github.loki4j.logback.Loki4jAppender">
  <http>
    <url>http://localhost:3100/loki/api/v1/push</url>
  </http>
  <format>
    <json>
      <field name="timestamp" pattern="%d{yyyy-MM-dd'T'HH:mm:ss.SSSXXX}" />
      <field name="level" pattern="%level" />
      <field name="message" pattern="%msg" />
      <field name="traceId" pattern="%X{traceId}" />
    </json>
  </format>
</appender>

services:
  prometheus:
    image: prom/prometheus
    user: root
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro

  loki:
    image: grafana/loki:2.9.2
    ports:
      - "3100:3100"

  promtail:
    image: grafana/promtail:2.9.2
    volumes:
      - ./logs:/app/logs
      - ./promtail-config.yaml:/etc/promtail/config.yaml
    command: -config.file=/etc/promtail/config.yaml

  grafana:
    image: grafana/grafana
    ports:
      - "3000:3000"
    environment:![](https://velog.velcdn.com/images/minpractice_jhj/post/d3d9b717-f161-48fa-9970-bb70323c982d/image.png)

      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=admin

services:
  prometheus:
    image: prom/prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro

  grafana:
    image: grafana/grafana
    ports:
      - "3000:3000"

  loki:
    image: grafana/loki:2.9.2
    ports:
      - "3100:3100"

  tempo:
    image: grafana/tempo:2.3.1
    ports:
      - "3200:3200"

# application-local.yml
management:
  endpoints:
    web:
      exposure:
        include:
          - health
          - info
          - prometheus
  metrics:
    distribution:
      percentiles-histogram:
        http.server.requests: true
      percentiles:
        http.server.requests: 0.5, 0.95, 0.99

# prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'spring-boot'
    metrics_path: '/actuator/prometheus'
    static_configs:
      - targets: ['host.docker.internal:8080']

ab -n 1000 -c 50 http://localhost:8080/

sudo apt-get update
sudo apt-get install ca-certificates curl

sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

sudo docker run hello-world

sudo docker images
sudo docker version

sudo systemctl enable docker
sudo systemctl start docker
sudo service docker status

sudo apt update
sudo apt install snapd

sudo snap set system homedirs=/var/lib

sudo chmod 666 /var/run/docker.sock

sudo snap install hello-world

sudo snap install kubectl --classic

cd /usr/bin
chmod +x ./ncp-iam-authenticator
ls -l /usr/bin/ncp-iam-authenticator

sudo cp kubeconfig.yaml ~/.ncloud

# 현재 권한 확인
ls -l /var/run/docker.sock

# 권한을 777로 변경
sudo chmod 777 /var/run/docker.sock

# 변경 후 권한 확인
ls -l /var/run/docker.sock

# Jenkins GPG 키 다운로드
sudo wget -O /usr/share/keyrings/jenkins-keyring.asc \
  https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key

# Jenkins 소스 목록 추가
echo "deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] https://pkg.jenkins.io/debian-stable binary/" | \
  sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null

# 패키지 목록 업데이트
sudo apt-get update

sudo apt-get install jenkins

sudo apt update

#OpenJDK 17 JDK **설치**
sudo apt install fontconfig openjdk-17-jre

# Java 버전 확인
java -version

# Jenkins 서비스 부팅 시 자동 시작 설정
sudo systemctl enable jenkins

# Jenkins 서비스 시작
sudo systemctl start jenkins

# Jenkins 서비스 상태 확인
sudo systemctl status jenkins

bash
복사편집
pwd  # 현재 작업 중인 디렉터리 출력

bash
복사편집
cd 디렉터리명  # 특정 디렉터리로 이동
cd ..  # 상위 디렉터리로 이동
cd ~  # 홈 디렉터리로 이동
cd -  # 이전 작업 디렉터리로 이동

bash
복사편집
ls  # 현재 디렉터리 파일 및 폴더 목록 출력
ls -l  # 상세 정보 포함
ls -a  # 숨김 파일 포함
ls -lh  # 사람이 읽기 쉬운 형식으로 크기 표시
ls -lt  # 최근 수정된 순서대로 정렬

bash
복사편집
mkdir 디렉터리명  # 새 디렉터리 생성
mkdir -p 경로/하위디렉터리  # 상위 디렉터리까지 포함하여 생성

bash
복사편집
rmdir 디렉터리명  # 비어있는 디렉터리 삭제
rm -r 디렉터리명  # 디렉터리와 내부 파일까지 강제 삭제

bash
복사편집
cp 원본 대상  # 파일 복사
cp -r 원본디렉터리 대상디렉터리  # 디렉터리 복사

bash
복사편집
mv 파일명 새파일명  # 파일 이름 변경
mv 파일명 디렉터리/  # 파일 이동

bash
복사편집
rm 파일명  # 파일 삭제
rm -rf 디렉터리  # 디렉터리 및 내부 파일 강제 삭제

bash
복사편집
cat 파일명  # 파일 내용 출력
less 파일명  # 파일 내용을 페이지 단위로 보기 (↑↓로 이동)
more 파일명  # less와 비슷하지만 이전 페이지로 이동 불가

bash
복사편집
grep "검색어" 파일명  # 특정 단어가 포함된 줄 찾기
grep -r "검색어" 디렉터리/  # 디렉터리 내 모든 파일에서 검색
grep -i "검색어" 파일명  # 대소문자 무시하고 검색

bash
복사편집
find /경로 -name "파일명"  # 특정 파일 찾기
find . -type f -name "*.txt"  # 현재 디렉터리에서 모든 .txt 파일 찾기

bash
복사편집
ps aux  # 실행 중인 모든 프로세스 목록 보기
top  # 실시간으로 프로세스 및 시스템 상태 확인
htop  # top의 개선된 버전 (설치 필요)

bash
복사편집
kill PID  # 특정 프로세스 종료
pkill 프로세스이름  # 특정 이름을 가진 프로세스 종료
kill -9 PID  # 강제 종료

bash
복사편집
free -h  # 메모리 사용량 확인
df -h  # 디스크 사용량 확인
du -sh 디렉터리/  # 특정 디렉터리의 용량 확인

bash
복사편집
whoami  # 현재 로그인한 사용자 출력
id  # 사용자 ID 및 그룹 정보 확인
who  # 현재 시스템에 접속한 사용자 목록

bash
복사편집
su - 사용자명  # 다른 사용자로 전환
sudo 명령어  # 관리자 권한으로 명령 실행

bash
복사편집
chmod 755 파일명  # 소유자: 읽기/쓰기/실행, 그룹&기타: 읽기/실행
chmod +x 파일명  # 실행 권한 추가
chown 사용자:그룹 파일명  # 파일 소유권 변경

bash
복사편집
ping 도메인/IP  # 특정 서버에 연결 확인
curl -I URL  # 웹 서버 응답 확인
wget URL  # 파일 다운로드

bash
복사편집
netstat -tulnp  # 열린 포트 및 서비스 확인
ss -tulnp  # netstat 대체 명령어

bash
복사편집
ip a  # 네트워크 인터페이스 및 IP 주소 확인
ifconfig  # (구버전) 네트워크 설정 확인

bash
복사편집
tar -cvf archive.tar 파일/디렉터리  # tar 압축 파일 만들기
tar -xvf archive.tar  # tar 압축 파일 풀기
zip -r archive.zip 파일/디렉터리  # zip 압축 파일 만들기
unzip archive.zip  # zip 압축 해제

bash
복사편집
shutdown -h now  # 즉시 시스템 종료
shutdown -r now  # 즉시 재부팅
reboot  # 시스템 재부팅
poweroff  # 시스템 종료

bash
복사편집
history  # 이전에 실행한 명령어 목록 확인

time 명령어  # 실행 시간 측정

명령어 &  # 명령어를 백그라운드에서 실행
nohup 명령어 &  # 로그아웃해도 실행 유지

ps -ef | grep pinup-0.0.1-BETA.jar

kill -9 5613

nohup java -jar -Dspring.profiles.active=prod pinup-0.0.1-BETA.jar > pin-up.log 2>&1 &

nohup java -jar -Dspring.profiles.active=prod /home/ec2-user/pinup-0.0.1-BETA.jar > pin-up.log 2>&1 &

bash
복사편집
ps -ef | grep pinup-0.0.1-BETA.jar

yaml
복사편집
# 기본 설정
spring:
  datasource:
    driver-class-name: org.postgresql.Driver
    url: jdbc:postgresql://localhost:5432/pinup

---
# test 프로파일
spring:
  config:
    activate:
      on-profile: test
  datasource:
    driver-class-name: org.h2.Driver
    url: jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE

---
# prod 프로파일
spring:
  config:
    activate:
      on-profile: prod
  datasource:
    driver-class-name: org.postgresql.Driver
    url: jdbc:postgresql://172.17.0.2:5432/pinup

spring:
  application:
    name: pinup

  profiles:
    default: local

  servlet:
    multipart:
      enabled: true
      max-file-size: 10MB
      max-request-size: 10MB

springdoc:
  packages-to-scan: com.colabear754.springdoc_example.controllers
  default-consumes-media-type: application/json;charset=UTF-8
  default-produces-media-type: application/json;charset=UTF-8
  swagger-ui:
    path: /springdoc.html
    disable-swagger-default-url: true
    display-request-duration: true
    operations-sorter: alpha

server:
  servlet:
    context-path: /
    encoding:
      enabled: true
      charset: UTF-8
      force: true

spring:
  config:
    activate:
      on-profile: local

  datasource:
    driver-class-name: org.postgresql.Driver
    url: jdbc:postgresql://localhost:5432/pinup
    username: 
    password: 

  jpa:
    hibernate:
      ddl-auto: update
    show-sql: true
    database: postgresql
    properties:
      hibernate:
        format_sql: true

  security:
    oauth2:
      client:
        registration:
          naver:
            client-id: 
            client-secret: 
            scope:
              - name
              - email
            client-name: Naver
            authorization-grant-type: authorization_code
            redirect-uri: http://localhost:8080/api/members/oauth/naver
          google:
            client-id: 
            client-secret: 
            scope:
              - profile
              - email
            client-name: Google
            authorization-grant-type: authorization_code
            redirect-uri: http://localhost:8080/api/members/oauth/google
          kakao:
            client-id: your-kakao-client-id
            client-secret: your-kakao-client-secret
            scope:
              - profile
              - email
            client-name: Kakao
            authorization-grant-type: authorization_code
            redirect-uri: http://localhost:8080/api/members/oauth/kakao

        provider:
          naver:
            authorization-uri: https://nid.naver.com/oauth2.0/authorize
            token-uri: https://nid.naver.com/oauth2.0/token
            user-info-uri: https://openapi.naver.com/v1/nid/me
            user-name-attribute: response
          google:
            authorization-uri: https://accounts.google.com/o/oauth2/v2/auth
            token-uri: https://oauth2.googleapis.com/token
            user-info-uri: https://www.googleapis.com/oauth2/v3/userinfo
            user-name-attribute: sub
          kakao:
            authorization-uri: https://kauth.kakao.com/oauth2/authorize
            token-uri: https://kauth.kakao.com/oauth2/token
            user-info-uri: https://kapi.kakao.com/v2/user/me
            user-name-attribute: id

cloud:
  aws:
    s3:
      bucket: pinup
      endpoint: http://127.0.0.1:4566  # LocalStack의 S3 엔드포인트 주소
    region.static: us-east-1
    stack.auto: false
    credentials:
      accessKey: test
      secretKey: test

spring:
  config:
    activate:
      on-profile: prod

  datasource:
    driver-class-name: org.postgresql.Driver
    url: jdbc:postgresql://172.17.0.2:5432/pinup
    username: 
    password: 

  jpa:
    hibernate:
      ddl-auto: create
    show-sql: true
    database: postgresql
    properties:
      hibernate:
        format_sql: true

  security:
    oauth2:
      client:
        registration:
          naver:
            client-id: 
            client-secret: 
            scope:
              - name
              - email
            client-name: Naver
            authorization-grant-type: authorization_code
            redirect-uri: http://43.201.64.159:8080/api/members/oauth/naver
          google:
            client-id: 
            client-secret: 
            scope:
              - profile
              - email
            client-name: Google
            authorization-grant-type: authorization_code
            redirect-uri: http://43.201.64.159:8080/api/members/oauth/google
          kakao:
            client-id: your-kakao-client-id
            client-secret: your-kakao-client-secret
            scope:
              - profile
              - email
            client-name: Kakao
            authorization-grant-type: authorization_code
            redirect-uri: http://43.201.64.159:8080/api/members/oauth/kakao

        provider:
          naver:
            authorization-uri: https://nid.naver.com/oauth2.0/authorize
            token-uri: https://nid.naver.com/oauth2.0/token
            user-info-uri: https://openapi.naver.com/v1/nid/me
            user-name-attribute: response
          google:
            authorization-uri: https://accounts.google.com/o/oauth2/v2/auth
            token-uri: https://oauth2.googleapis.com/token
            user-info-uri: https://www.googleapis.com/oauth2/v3/userinfo
            user-name-attribute: sub
          kakao:
            authorization-uri: https://kauth.kakao.com/oauth2/authorize
            token-uri: https://kauth.kakao.com/oauth2/token
            user-info-uri: https://kapi.kakao.com/v2/user/me
            user-name-attribute: id

cloud:
  aws:
    s3:
      bucket: bucket0127
    region.static: ap-northeast-2
    stack.auto: false
    credentials:
      accessKey: AKIA47GCAGT5K52CCLVA
      secretKey: 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

spring:
  config:
    activate:
      on-profile: test

  datasource:
    driver-class-name: org.h2.Driver
    url: jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE
    username: sa
  jpa:
    show-sql: true
  output:
    ansi:
      enabled: always

  security:
    oauth2:
      client:
        registration:
          naver:
            client-id: 
            client-secret: 
            scope:
              - name
              - email
            client-name: Naver
            authorization-grant-type: authorization_code
            redirect-uri: http://localhost:8080/api/members/oauth/naver
          google:
            client-id: 
            client-secret: 
            scope:
              - profile
              - email
            client-name: Google
            authorization-grant-type: authorization_code
            redirect-uri: http://localhost:8080/api/members/oauth/google
          kakao:
            client-id: your-kakao-client-id
            client-secret: your-kakao-client-secret
            scope:
              - profile
              - email
            client-name: Kakao
            authorization-grant-type: authorization_code
            redirect-uri: http://localhost:8080/api/members/oauth/kakao

        provider:
          naver:
            authorization-uri: https://nid.naver.com/oauth2.0/authorize
            token-uri: https://nid.naver.com/oauth2.0/token
            user-info-uri: https://openapi.naver.com/v1/nid/me
            user-name-attribute: response
          google:
            authorization-uri: https://accounts.google.com/o/oauth2/v2/auth
            token-uri: https://oauth2.googleapis.com/token
            user-info-uri: https://www.googleapis.com/oauth2/v3/userinfo
            user-name-attribute: sub
          kakao:
            authorization-uri: https://kauth.kakao.com/oauth2/authorize
            token-uri: https://kauth.kakao.com/oauth2/token
            user-info-uri: https://kapi.kakao.com/v2/user/me
            user-name-attribute: id

cloud:
  aws:
    s3:
      bucket: pinup
      endpoint: http://127.0.0.1:4566
    region.static: us-east-1
    stack.auto: false
    credentials:
      accessKey: test
      secretKey: test

./gradlew build -x test -Dspring.profiles.active=prod

java -jar -Dspring.profiles.active=prod build/libs/your-app.jar