DHistory

[Spring] Self-Invocation?

DHistory — Mon, 1 Jun 2026 07:49:34 +0900

Question

Spring @Transactional이 같은 클래스 내 메서드 호출 시 트랜잭션이 적용되지 않는 이유는 무엇인가요?

이를 해결하는 방법과 각 방법의 트레이드 오프는 무엇인가요?

Answer 1) @Transactional 동작 과정

> @Transactional은 Spring AOP 프록시 기반으로 동작

> @Transactional은 Proxy 객체 메서드 진입 시 시작

> 같은 클래스 내 this.method()는 Proxy 객체가 아닌 원본 객체를 직접 호출

> this.method() 에 선언된 @Transactional 동작 무시

> 코드 작성 의도와 런타임 시 코드 수행 동작 차이 발생

class PaymentService {

    @Transactional
    public void processOrder() {
        // 트랜잭션이 분리되지 않고 processOrder 트랜잭션과 함께 처리
        this.pay()
    }
    
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void pay() { ... }
}

Answer 2) 외부 클래스로 분리

> 외부 클래스로 분리하여 Proxy 객체 호출

> SRP 원칙을 준수하고 명확하고 테스트 용이

> But. 클래스 증가

Answer 3) AspectJ Weaving 으로 해결 가능 여부

> AspectJ 로 해결이 가능, Bytecode 조작으로 성능 향상 이점 (AOP 적용 시 Reflection, Interceptor Chain 사용)

> But. 빌드 복잡도, 디버깅, 오류 발견 시점 지연 (컴파일 -> 런타임), 팀 러닝커브 증가 문제

Answer 4) Event Publishing으로 Transaction 경계 분리

> DDD, Hexagonal Architecture에서 Application Service Layer 단위가 하나의 Transaction 단위가 되고 내부 도메인 서비스와 분리

> 레이어 경계를 따르면 자연스러운 분리

> But. 내부 이벤트 유실 가능성

> Transactional Outbox Pattern 도입으로 해결 가능

	@EventListener	@TransactionalEventListener
시점	이벤트 발행 즉시	트랜잭션 커밋 후
트랜잭션 관계	발행자 트랜잭션에 편승	독립적
롤백 시	같이 롤백	실행 X
용도	같은 트랜잭션에 묶고 싶을 때	커밋 확정 후 후처리

ETC.

Self Injection @Lazy 기반

> 의도 불명확

class PaymentService(
    @Lazy private val self: PaymentService
) {

    fun processOrder() {
        self.pay()
    }
    
    @Transactional
    fun pay() { ... }
}

Application Context

> Spring 강결합, 테스트 복잡도 증가

> 의도 불명확, 가독성 저하

class PaymentSerivce(
    private val applicationContext: ApplicationContext
) {

    fun processOrder() {
         val self = applicationConext.getBean(PaymentService:class.java)
         self.pay()
    }
    
    @Transactional
    fun pay() { ... }
}

AopProxy.currentProxy()

> AOP 프레임워크 강결합

> 의도 불명확, 가독성 저하

class PaymentService {

    fun processOrder() {
        (AopContext.currentProxy() as PaymentService).pay()
    }
    
    @Transactional
    fun pay() { ... }
}

팀 자율 의사결정 기반의 개발 조직 체계 구축

DHistory — Wed, 11 Mar 2026 19:29:01 +0900

서론

당시 회사의 업무 구조에서는 오퍼레이션팀이 엔지니어팀에 직접 기능 개발을 요청하거나 PM의 요청이 별도의 기획 리뷰 없이 바로 개발로 이어지는 경우가 많았습니다.

이로 인해 어떤 기능이 왜 만들어지는지에 대한 맥락이 공유되지 않았고 제품의 정책이나 방향성과 어긋나는 요구사항도 그대로 제품에 반영되는 문제가 반복되었습니다.

결과적으로 상반된 정책을 가진 기능들이 누적되며 제품의 정체성과 완성도는 점차 훼손되고 있었습니다.

문제는 개인의 판단이 아니라 업무를 결정하고 검증하는 프로세스 자체에 있었습니다.

이러한 한계를 해결하기 위해 회사는 스쿼드 기반 조직으로 전환하며 PM / Product Lead Engineer(이하 PLE) 구조를 도입했고 저는 제품의 방향성과 기술적 실행을 함께 책임지는 PLE 역할을 맡게 되었습니다.

이 글에서는 2025년도에 PLE로서 기존 업무 프로세스를 어떻게 재정의하고 개선했는지 그리고 그 변화가 팀과 제품에 어떤 영향을 주었는지를 공유하고자 합니다.

본론

요청과 의사결정이 분리되지 않은 구조

기존 업무 프로세스의 가장 큰 문제는 업무 요청과 의사결정이 분리되지 않았다는 점이었습니다.

오퍼레이션팀의 요청이 곧바로 개발로 이어졌을 뿐만 아니라 PM의 요청 또한 별도의 기획 리뷰나 제품 관점의 검증 없이 개발이 진행되는 구조였습니다.

이로 인해 해당 기능이 제품의 방향성과 정책에 부합하는지 기존 사용자 경험과 충돌하지는 않는지 검토하는 단계가 존재하지 않았습니다.

이러한 구조에서는 다음과 같은 문제가 발생했습니다.

제품 관점의 의사 결정 부재
PM이 기능 개발을 사전에 검토하지 않다보니 각 요청은 개별적으로 합리적으로 보이나 전체 제품 관점에서는 정체성에 어긋나고 정책이 서로 충돌하는 경우가 종종 발생했습니다.

그 결과 하나의 제품 안에서 서로 다른 사용자 경험이 공존하게 되었고 운영 과정에서 이를 보완하기 위해 데이터를 수정 및 예외 처리 요청이 지속적으로 증가했습니다.
업무 가시성 부족 및 팀 간 단절
어떤 기능이 왜 개발되고 있는지 공유되고 있지 않기 때문에 PM뿐만 아니라 엔지니어 팀 내부에서도 현재 진행 중인 업무의 맥락을 이해하기 어려운 상황이 지속되었습니다.

그 결과 중복 개발, 우선 순위 혼선, 불필요한 커뮤니케이션 비용 증가로 이어지며 팀 전체의 생산성을 점진적으로 저하시켰습니다.
단기 요청 중심 개발 문화
요청을 일정 내에 처리하는 것이 성과로 인식되면서 기능의 확장성, 유지보수, 장기적인 제품 가치에 대한 고민은 자연스럽게 뒤로 밀리게 되었습니다.

그 결과 제품의 복잡도가 증가하여 새로운 기능을 만드는 비용과 유지보수에 필요한 비용이 늘어나는 상태로 변해가고 있었습니다.
책임 주체의 불명확성
기획 리뷰와 명확한 의사결정 과정이 부재하다 보니 어떤 기능이 어떤 판단을 거쳐 만들어졌는지 기록이 남지 않았고 그 결정에 대한 책임 또한 명확하지 않았습니다.

그 결과 문제가 발생했을 때 팀 차원의 개선으로 이어지기보다는 특정 개인에게 책임이 귀속되는 방식으로 대응되는 경우가 반복되었고 이는 조직이 학습하지 못하고 같은 문제가 재발하는 구조적 원인이 되었습니다.

PLE로서 역할 정의

앞서 언급한 문제들은 특정 개인의 역량이나 태도의 문제가 아니라 업무 요청을 판단하고 검증하는 역할이 정의되어 있지 않았던 구조적 한계에서 비롯된 것이었습니다.

저는 이러한 문제를 해결하기 위해 PLE의 역할을 단순히 개발을 리드하는 포지션이 아니라 제품 관점에서 의사결정의 기준을 세우고 이를 실행으로 연결하는 역할로 정의했습니다.

PLE로서 제가 정의한 책임과 역할은 다음과 같습니다.

모든 개발 요청의 검증 지점이 되는 역할
오퍼레이션팀이나 PM으로부터 들어오는 모든 기능 요청은 바로 개발로 이어지지 않고 기획 리뷰와 제품 관점 검토를 거쳐 개발 여부와 우선순위를 판단하도록 했습니다.

- 제품 정책 및 방향성, 정합성
- 기존 사용자 경혐 충돌 여부
- 기술적 복잡도와 장기 유지보수 비용

위와 같은 기준으로 판단을 내리는 역할을 맡았습니다.
무엇을 만들지 말지를 결정하는 책임
모든 요청을 수용하는 것이 곧 성과라고 판단하지 않았습니다.
오히려 제품의 방향성과 일관성을 지키는 것이 더 중요한 역할이라고 생각했습니다.
이를 통해 팀은 요청이 왔으니 만든다가 아니라 이 기능이 지금 제품에 필요한가를 먼저 질문하는 방식으로 사고하게 되었습니다.
기획 맥락을 공유하는 역할
엔지니어가 단순히 요구사항을 구현하는 역할에 머무르지 않도록 각 기능이 만들어지는 배경, 목적 기대 효과를 명확히 공유했습니다.
이로 인해 엔지니어는 주어진 문제를 해결하는 단계에서 나아가 스스로 문제를 정의할 수 있는 단계로 발전하였습니다.
팀 내부에서는 어떤 의도로 이 방식으로 결정했는지 설명할 수 있는 기준과 공통 언어가 형성되었으며 업무에 대한 이해도와 책임감 또한 자연스럽게 높아졌습니다.
개인의 판단이 아닌 팀의 기준을 만드는 역할
특정 개인의 경험이나 직관에 의존하지 않기 위해 의사결정 기준과 리뷰 프로세스를 정리하고 공유했습니다.
기준이 생겼기 때문에 PLE 뿐만 아니라 모든 엔지니어가 공통된 기준으로 판단할 수 있는 환경을 조성했습니다.

업무 프로세스 개선

이에 따라 업무 흐름을 요청 → 리뷰 → 결정 → 공유 → 개발 단계로 재설계하였습니다.

모든 요청은 단일 채널(PM, PLE)로 수집
문제 정의 중심의 기획 리뷰 진행
PM/PLE 공동 의사결정
결정의 맥락을 팀에 공유 후 개발 진행

결과

업무 프로세스 개선 이후 다음과 같은 변화가 있었습니다.

제품 정책과 충돌하는 기능 사전 차단
운영 단계에서 예외 처리 및 데이터 수정 요청 감소
팀 내 업무 가시성과 공통 이해도 향상
요청 처리 속도를 유지하며 의사결정 개선

무엇보다 중요한 변화는 단순 개발에 그치지 않고 이 기능을 왜 만들어야 하는가를 먼저 고민하는 환경이 되었다는 점입니다.

특히 운영 단계에서 발생했던 예외 처리와 데이터 수정 요청이 눈에 띄게 줄어들었고 기능 개발 이후 운영 안정성도 함께 개선되었습니다.

회고

당시에는 문서 없이도 기존 구성원 간의 신뢰를 기반으로 의사결정 구조가 충분히 작동하고 있었습니다.

서로가 어떤 기준으로 판단하는지 암묵적으로 공유하고 있었기 때문에 말로 설명하는 것만으로도 빠른 합의와 실행이 가능했습니다.

그러나 팀이 확장되며 새로운 팀원 두 명이 합류하면서 이러한 방식이 모두에게 동일하게 전달되기는 어렵다는 한계를 느끼게 되었습니다.

기존 구성원에게는 당연한 판단 기준과 결정의 맥락이 신규 구성원에게는 충분히 설명되지 않은 채 결과만 전달되는 상황이 발생했기 때문입니다.

이에 최근에는 문서를 업무를 강제하기 위한 수단이 아니라 의사결정의 판단 근거와 맥락을 공유하기 위한 도구로 재정의하고 있습니다.

이를 통해 개인 간 신뢰에 의존하던 구조를 넘어 새로운 구성원이 합류하더라도 동일한 기준으로 판단하고 논의할 수 있는 확장 가능한 의사결정 구조로 발전시키고자 합니다.

이러한 경험을 통해 저는 리더의 역할에 대해서도 다시 생각하게 되었습니다.

나만의 리더십 원칙

저는 리더의 역할이 사람 위에서 통제하는 것이 아니라 팀이 스스로 판단하고 움직일 수 있는 환경을 만드는 것이라고 생각합니다.

이를 위해 회사가 추구하는 방향을 명확히 이해하고 조직의 목표와 개인의 성장 사이에서 균형을 찾도록 돕는 역할을 중요하게 생각합니다.

또한 리더는 문제를 사람에게 돌리기보다 구조와 기준을 통해 팀이 지속적으로 성장할 수 있는 시스템을 만드는 사람이라고 믿습니다.

[Java] JVM - Garbage Collector

DHistory — Mon, 16 Dec 2024 21:00:05 +0900

Overview

Garbage Collector는 사용하지 않는 자원의 메모리를 해제하여 프로그램 메모리를 확보합니다.

GC(Garbage Collection)를 하게 되면 GC 관련 Thread을 제외한 모든 Thread를 멈춥니다.

이를 Stop The World(STW) 라고 합니다.

GC의 동작 과정

Mark & Sweep Algorithm을 사용하여 어느 곳에서도 참조하고 있지 않는 객체를 GC 대상으로 선정하여 제거합니다.

Mark: Root Space(Stack, Method Aread, Native Method Stack)에서 참조하는 객체를 마킹합니다.

Sweep: 마킹되지 않은 객체를 Heap에서 제거합니다.

Compact: 분산된 객체를 Heap의 시작 주소로 모아 메모리가 할당된 부분과 할당되지 않은 부분으로 압축합니다

Heap영역

Young Generation

Eden: 객체 생성 시 처음 위치 하는 공간, GC 이후 살아남은 객체를 Survivor 영역으로 보냅니다.

Survivor 0/Survivor 1: 최소 1번의 GC 이상 살아남은 객체가 존재하는 영역입니다. Survivor 0 혹은 Survivor 1 둘 중 하나의 영역은 비어있어야 합니다.

⇒ Minor GC가 일어나며 Max Age가 될 때까지 반복합니다. (Eden → S0 → S1 → S0 → S1 …)

public class Main {
    public static void main(String[] args) {
        HotSpotDiagnosticMXBean bean = ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class);
        System.out.println("MaxTenuringThreshold(age): " + bean.getVMOption("MaxTenuringThreshold").getValue());
    }
}
// MaxTenuringThreshold(age): 15

Old Generation

Survivor 영역에서 살아남은 객체 중 Max Age를 넘은 경우 Old Generation으로 이동합니다.

Old Generation이 가득 찬 경우 Major GC가 일어납니다.

Permanent

Java 7 버전까지는 Heap Area에 존재 / 8 버전부터 Native Method Stack에 편입했습니다.

GC Algorithm의 종류

Serial GC

GC 쓰레드 1개
STW 가장 김

Parallel GC

Java 8의 기본 GC
CPU 개수 = GC 쓰레드 개수
Young 영역의 Minor GC를 멀티 쓰레드로 수행
Serial GC에 비해 STW 시간 감소

Parallel Old GC

CPU 개수 = GC 쓰레드 개수
Young + Old 영역 멀티 쓰레드로 수행
Mark-Summary-Compact 방식 이용

특성	Mark Sweep Compact	Mark Summary Compact
단계	Mark, Sweep, Compact	Mark, Summary, Compact
단편화	높음	낮음
정지 시간	상대적으로 김	상대적으로 짧음
구현 복잡성	낮음	높음
메모리 관리	전체 대상 수집	부분 대상 수집 및 요약 정보 활용

G1 GC

Java 9의 기본 GC
Region 개념을 도입
G1 GC 부터는 Eden → Survivor 0 → Survivor 1 → Old 로 순차 이동을 하지 않고 효율적인 위치로 객체 할당

Shenandoah GC

Java 12에 Release
G1이 가진 Pause 이슈 해결
Java Thread와 GC Thread 병렬적으로 실행
Init Marking → Concurrent Marking → Final Marking → Concurrent Compaction

ZGC

Java 15에 Release
ZPage 개념을 도입
G1의 Region 크기 고정이지만, ZPage는 2mb 배수로 동적 운영
STP 시간 10ms를 넘지 않음

ElasticSearch vs MySQL FullText vs MySQL Like Performance

DHistory — Sun, 3 Nov 2024 11:06:45 +0900

개요

대용량 데이터 검색을 진행함에 있어 ElasticSearch, MySQL FullText, MySQL Like의 성능을 비교를 했습니다.

검색을 진행한 조건은 다음과 같습니다.

1. "abc" 로 시작하는 단어가 포함된 경우 → "def abcd gcf"

2. "abc" 문자가 포함된 경우 → "def dabc gcf"

Performance 비교는 hey를 활용하였습니다.

Table Schema

현재 데이터 건수는 275,684건이며 title에 index / fulltext 가 정의되어있습니다.

Create Table: CREATE TABLE `post` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '(AI)   ID',
  `title` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL,
  `contents` varchar(3000) COLLATE utf8mb4_unicode_ci NOT NULL,
  `image_url` varchar(2083) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_at` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_post_m2` (`title`),
  FULLTEXT KEY `idx_post_m1` (`title`)
) ENGINE=InnoDB AUTO_INCREMENT=275685 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

MySQL Like

가장 구현하기 쉬운 Like 구문입니다.

하나의 Like 구문으로 Case 1, 2를 모두 만족할 수 있습니다.

explain
select *
from post
where title like '%abc%';

%abc%로 진행했기 때문에 index를 활용할 수 없어 Full Scan을 진행했습니다.

@Service
@RequiredArgsConstructor
public class SearchService {

    private final PostJpaRepository postJpaRepository;

    public List<PostResponse> database(String keyword) {
        List<Post> posts = postJpaRepository.findByTitleContaining(keyword);

        return posts.stream()
            .map(post -> new PostResponse(post.getTitle(), post.getContents()))
            .toList();
    }
}

가장 간단히 구현했지만 API 호출 시 Latency가 5초 이상 소요되었습니다.

다음으로 성능 테스트를 진행해보겠습니다.

Hey를 이용하여 성능 테스트 진행

3000건의 요청 중 14건만 성공하였습니다.

이 외 2986건은 Timeout(30초)으로 인해 요청이 실패했습니다.

성공한 요청에 대해서도 P90 Latency가 거의 20초 가량 소요됩니다.

데이터가 많아질수록 사용하기 어렵습니다.

MySQL FullText

FullText 사용 전 Index 생성 과정을 알아야합니다.

MySQL에서 기본적으로 제공하는 과정은 ngram을 활용하여 단어를 Index를 생성합니다.

→ ngram은 단어 단위 (Whitespace) 로 구분합니다.

그 결과

Case 1을 검색할 수 있지만, Case2는 검색이 불가능합니다.

상황에 따라 특정 단어가 들어간 경우만을 찾을 수 있기 때문에 성능을 확인해보겠습니다.

explain
select *
from post
where match(title) against('abc*' in boolean mode);

FullText 기반으로 검색하기 때문에 index를 활용할 수 있습니다.

@Service
@RequiredArgsConstructor
public class SearchService {

    private final PostJpaRepository postJpaRepository;

    public List<PostResponse> fullTextDatabase(String keyword) {
        List<Post> posts = postJpaRepository.findByTitleFullText(keyword + "*");

        return posts.stream()
            .map(post -> new PostResponse(post.getTitle(), post.getContents()))
            .toList();
    }
}

public interface PostJpaRepository extends JpaRepository<Post, Long> {
    @Query(value = "SELECT * FROM post WHERE MATCH (title) AGAINST (?1 IN BOOLEAN MODE)", nativeQuery = true)
    List<Post> findByTitleFullText(String keyword);
}

Like 방식 보다는 복잡하지만 API 호출 시 Latency가 167ms가 소요되었습니다.

다음으로 성능 테스트를 진행해보겠습니다.

Hey를 이용하여 성능 테스트 진행

전체 요청이 성공했습니다.

성공한 요청 중 P90 Latency가 거의 916ms 가량 소요되었습니다.

(현재 요청은 랜덤한 문자 2글자에 대한 요청입니다.)

ElasticSearch

ElasticSearch의 Tokenizer는 기본으로 Standard Token을 사용합니다.

Whitespace를 기준으로 Token화 하는 과정은 FullText Index 생성시와 유사합니다.

다만, ElasticSearch로 검색 시 BM25(Best Matching 25) 알고리즘을 사용하여 검색합니다.

GET /_search
{
  "query": {
    "wildcard": {
      "title": {
        "value": "*abc*",
        "case_insensitive": true
      }
    }
  }
}

wildcard 방식을 활용하여 MySQL Like와 비슷하게 Case 1, Case 2 방식을 모두 만족합니다.

@Service
@RequiredArgsConstructor
public class SearchService {

    private final ElasticsearchTemplate elasticsearchTemplate;

    public List<PostResponse> elasticSearch(String keyword) {
        Query title = QueryBuilders.wildcard()
            .field("title")
            .value("*" + keyword + "*")
            .caseInsensitive(true)
            .build()
            ._toQuery();

        NativeQuery query = new NativeQueryBuilder()
            .withQuery(title)
            .withMaxResults(100)
            .build();

        SearchHits<PostDocument> search = elasticsearchTemplate.search(query, PostDocument.class);
        List<SearchHit<PostDocument>> searchHits = search.getSearchHits();

        return searchHits.stream()
            .map(this::convertPostResponse)
            .toList();
    }

    private PostResponse convertPostResponse(SearchHit<PostDocument> searchHit) {
        PostDocument post = searchHit.getContent();
        return new PostResponse(post.getTitle(), post.getDescription());
    }
}

FullText 방식 보다는 복잡하지만 API 호출 시 Latency가 245ms가 소요되었습니다.

다음으로 성능 테스트를 진행해보겠습니다.

Hey를 이용하여 성능 테스트 진행

전체 요청이 성공했습니다.

성공한 요청 중 P90 Latency가 거의 490ms 가량 소요되었습니다.

(현재 요청은 랜덤한 문자 2글자에 대한 요청입니다.)

그렇다면 Case 1의 경우 FullText와 비교하여 ElasticSearch가 항상 빠른걸까요?

답은 그렇지 않다입니다.

위 예제들에서는 text 길이를 2로 설정했습니다.

MySQL의 설정을 살펴보면 ft_min_word_len의 길이를 확인할 수 있습니다.

최소 길이가 4이기 때문에 FullText의 성능을 최대로 발휘할 수 없었습니다.

그럼 랜덤 문자 길이를 4글자 요청으로 성능 테스트를 진행해보겠습니다.

FullText vs ElasticSearch

	FullText	ElasticSearch
TPS	2406	341
P90 Latency	0.074	0.309

FullText의 Performace가 높은 내용을 확인할 수 있습니다.

Learning Point

1. 단어가 포함된 검색이라면 ElasticSearch를 활용
➢ Like: 5370ms / ElasticSearch: 496ms

2. 단어로 시작하는 경우라면 FullText를 고려

➢ FullText: 74ms / ElasticSearch: 309ms

FanOut을 활용하여 NewsFeed Performance 향상

DHistory — Sun, 3 Nov 2024 08:52:44 +0900

개요

SNS NewsFeed 조회 시 팔로잉 유저들의 최신 게시글을 조회해야합니다.

팔로잉한 유저의 수가 1800명이고 각 유저들이 1000개씩 글을 작성했다고 가정합니다.

게시글의 전체 데이터 개수는 1,800,000 건입니다.

Table 구조

팔로잉한 유저들의 게시글 중 최근 100개의 게시글을 조회를 진행해보겠습니다.

일반 쿼리 조회 구현 시

단순한 구조

피드 목록 조회 시 비용이 비싼 쿼리를 조회해야합니다.

(Post의 Dummy Data를 대규모 데이터로 넣기 위해선 시간이 오래 걸리므로 비싼 쿼리로 만들어 진행)

@Service
@RequiredArgsConstructor
public class FeedService {

    private final PostRepository postRepository;
    private final RedisClient redisClient;

    @Transactional(readOnly = true)
    public List<FeedResponse> getNewsFeed(Long accountId) {
        List<Post> posts = postRepository.getNewsFeed(accountId);

        return posts.stream()
            .map(post -> new FeedResponse(post.getId(), post.getTitle(), post.getContents()))
            .toList();
    }
}

@Repository
public class PostRepository {

    private final JPAQueryFactory jpaQueryFactory;

    public PostRepository(JPAQueryFactory jpaQueryFactory) {
        this.jpaQueryFactory = jpaQueryFactory;
    }

    public List<Post> getNewsFeed(Long accountId) {
        return jpaQueryFactory.select(post)
            .from(post)
            .join(follow).on(post.account.id.eq(follow.following.id))
            .where(follow.follower.id.eq(accountId))
            .orderBy(post.createdAt.desc())
            .limit(1000)
            .fetch();
    }
}

팔로우한 유저도 늘어나고 게시글 수도 늘어나게 된다면 쿼리 시간이 증가하기 때문에 Latency는 자연스레 늘어납니다.

그 결과 유저는 NewsFeed 조회 시 1분 이상 대기를 해야합니다.

일반 Query 조회

Q) 매 번 비싼 쿼리를 수행하지 않고 NewsFeed 조회를 진행할 수 있는 방법을 무엇이 있을까요?

A) 최근 조회한 NewsFeed의 Post ID를 Redis에 저장한다면 비용이 높은 쿼리를 수행하지 않고 최신 NewsFeed를 여러 번 조회할 수 있습니다.

Redis를 사용하여 NewsFeed 목록 캐싱

Caching 구조

사용자의 정보를 Key로 설정하고 NewsFeed의 정보를 Value로 설정합니다.

이 후 NewsFeed 조회 시 다음과 같은 동작을 수행합니다.

1. 사용자에 해당하는 Redis 데이터 조회

2. Redis 데이터가 없는 경우 DB 조회 및 Redis 저장

@Service
@RequiredArgsConstructor
public class FeedService {

    private static final String POST_KEY = "account:%d:posts";

    private final PostJpaRepository postJpaRepository;
    private final PostRepository postRepository;
    private final AccountRepository accountRepository;
    private final RedisClient redisClient;

    @Transactional(readOnly = true)
    public List<FeedResponse> getNewsFeed(Long accountId) {
        Account account = accountRepository.findById(accountId)
            .orElseThrow(() -> new NotFoundAccountException(accountId));

        List<Post> posts = getPosts(account);

        return posts.stream()
            .map(post -> new FeedResponse(post.getId(), post.getTitle(), post.getContents()))
            .toList();
    }

    private List<Post> getPosts(Account account) {
        Long accountId = account.getId();
        List<Long> postIds = redisClient.getList(POST_KEY.formatted(accountId));

        if (postIds.isEmpty()) {
            List<Post> posts = postRepository.getNewsFeed(accountId);

            redisClient.setList(POST_KEY.formatted(account.getId()), posts.stream()
                .sorted(Comparator.comparing(Post::getId))
                .map(Post::getId)
                .toList());

            return posts;
        } else {
            return postJpaRepository.findAllByIdInOrderByCreatedAtDesc(postIds);
        }
    }
}

NewsFeed 게시글 ID 캐싱

Redis 캐싱 데이터 사용

그 결과 NewsFeed 조회 시 0.2초 이내로 줄어든 것을 확인할 수 있습니다.

Q) 그렇다면 팔로잉한 사용자의 최신 게시글을 조회하려면 어떻게 해야할까요?

A) TTL을 짧은 시간으로 설정하여 최신글을 자주 보여줄 수 있지만 이 경우에도 비용이 높은 쿼리를 수행해야합니다.

Q) 비용이 높은 쿼리를 수행하지 않고 실시간으로 사용자가 최신 게시글을 조회하려면 어떤 방식을 활용해야 할까요?

A) 게시글 작성 시 나를 팔로우한 사용자의 Redis 데이터에 최신 Post ID를 추가합니다. (Fan Out)

Fan Out 방식 적용

나를 팔로우하는 사용자들의 Redis Cache를 업데이트를 진행한다면 팔로워들은 비용이 높은 쿼리를 수행하지 않고도 최신 게시글을 조회할 수 있습니다.

@Service
@RequiredArgsConstructor
public class PostService {

    private static final String POST_KEY = "account:%d:posts";

    private final PostJpaRepository postJpaRepository;
    private final AccountRepository accountRepository;
    private final FollowJpaRepository followJpaRepository;
    private final RedisClient redisClient;

    @Transactional
    public void registerPost(RegisterPostRequest request, Long userId) {
        String title = request.title();
        String content = request.content();
        String imageUrl = request.imageUrl();

        Account account = accountRepository.findById(userId)
            .orElseThrow(() -> new NotFoundAccountException(userId));

        Post post = postJpaRepository.save(new Post(title, content, imageUrl, account));
        fanOut(account, post);
    }

    private void fanOut(Account account, Post post) {
        Long followerCount = followJpaRepository.countByFollowing(account);

        if (followerCount < 1000)  {
            List<Follow> followers = followJpaRepository.findAllByFollowing(account);

            for (Follow follower : followers) {
                Long id = follower.getFollower().getId();

                // 가장 오래된 데이터를 제거합니다.
                redisClient.rightPop(POST_KEY.formatted(id));
                // 최신 데이터를 저장합니다.
                redisClient.leftPush(POST_KEY.formatted(id), post.getId());
            }
        }
    }
}

이후 게시글을 올리게 된다면 팔로워들은 새로운 게시글을 빠르게 조회할 수 있습니다. :)

Learning Point

1. Redis 사용하여 Caching 으로 Performance 향상
➢ 80s → 0.2s

2. 팔로워가 많아지는 경우 Fan Out의 비용이 높을 수 있다는 점

➢ Silver Bullet은 없으니 적재적소에 기술을 사용해야한다는 점

3. Caching 을 활용할 데이터 선정 방식

➢ 정합성이 맞지 않아도 복구할 수 있는 데이터로 진행해야한다는 점

JIT Compiler?

DHistory — Sun, 22 Sep 2024 23:17:32 +0900

Overview

JIT Compiler는 프로그램을 실제 실행하는 시점에 기계어로 번역하는 컴파일 기법입니다.
처음 실행 시 interpret를 하면서 자주 쓰이는 코드를 캐시에 담아두었다가 재사용합니다.
Runtime 시 적용되는 기술이며 interpret과 compile을 혼합하여 사용합니다.

→ 처음 실행 시 interpret하면서 실행

→ 다음 실행 시 캐싱된 기계어 파일을 읽음 (like compile)

Interpret vs Static Compile

Interpret: 실행 중인 프로그램 코드를 읽어가면서 기계어로 번역

Static Compile: 실행하기 전에 프로그램 코드를 기계어로 번역

Java에서는 어떻게 사용할까?

Compiler는 .java 파일을 .class 파일(bytecode)로 변경합니다. (Compile)
JIT Compiler는 class 파일을 읽어 기계어로 번역 후 캐시에 저장합니다. (Interpret & Compile)
- Interpret: 프로그램 실행 시 기계어로 번역
- Compile: 번역한 기계어를 캐시에 저장 후 동일한 내용 실행 시 재사용

JIT Compiler는 bytecode를 각 플랫폼(OS)이 읽을 수 있는 기계어 형식으로 번역합니다.

→ WORA (Write Once Run Anywhere)

[Baekjoon] DFS - 24481 알고리즘 수업 - 깊이 우선 탐색 3

DHistory — Fri, 6 Sep 2024 22:15:42 +0900

문제

https://www.acmicpc.net/problem/24481

풀이

1. 시작점으로 부터 모든 노드의 깊이(depth)를 구하는 문제

2. 깊이는 현재 노드의 깊이 + 1

예시

코드

import sys

sys.setrecursionlimit(130000)

n, m, r = map(int, sys.stdin.readline().rstrip().split())
edges = [[] for _ in range(n + 1)]
visited = [-1] * (n + 1)

for _ in range(m):
    x, y = map(int, sys.stdin.readline().rstrip().split())
    edges[x].append(y)
    edges[y].append(x)


for edge in edges:
    edge.sort()


def dfs(r, depth):
    visited[r] = depth

    for v in edges[r]:
        if visited[v] == -1:
            dfs(v, visited[r] + 1)


dfs(r, 0)
print(*visited[1:], sep="\n")

[Baekjoon] 구현 - 12933 오리

DHistory — Thu, 5 Sep 2024 20:26:33 +0900

문제

https://www.acmicpc.net/problem/12933

풀이

한 마리의 오리가 여러 번 소리를 낼 수 있습니다.

녹음 중에서 여러 번 소리를 낸 오리를 찾아야합니다.

단, 녹음이 올바르지 않은 경우도 있습니다.

1) q 로 시작하지 않는 경우

2) k 로 끝나지 않는 경우

3) 5의 배수가 아닌 경우

이 경우를 제외하고는 녹음이 제대로 되었습니다.

방문하지 않은 문자열을 순차적으로 방문하여 울음 소리(quack)를 찾습니다.

예시

  녹음: quqaquuacakcqckkuaquckqauckack
오리 1: ____q_u__a___ck_______________
오리 2: __q__u_ac_k_q___ua__ckq_u__ack
오리 3: qu_a_______c___k__qu___a_ck___

코드

import sys

text = sys.stdin.readline().rstrip()
quack = 'quack'

def solution(text: str):
    # 예외 처리 (ex. qquack)
    if text[0] != "q" or text[-1] != "k" or len(text) % 5:
        return -1

    visited = [False] * len(text)
    result = 0

    for _ in range(len(text)):
        queue = []
        index = 0
        for i, v in enumerate(text):
            if visited[i]:
                continue

            if not queue and v == "q":
                queue.append(v)
                visited[i] = True
            elif queue and queue[-1] == quack[index % 5] and v == quack[(index + 1) % 5]:
                queue.append(v)
                visited[i] = True
                index += 1
        
        if len(queue) and len(queue) % 5 == 0:
            result += 1

    return result if result and all(visited) else -1


print(solution(text))

[Baekjoon] DP - 1793 타일링

DHistory — Mon, 2 Sep 2024 20:16:56 +0900

문제

https://www.acmicpc.net/problem/1793

풀이

문제가 상당히 이상하니 추가 조건을 확인 후 풀어야합니다.

[추가 조건]

1. n이 0인 경우 1 출력

2. 1x2도 사용 가능

예제

n이 1인 경우

1x2 1개

n이 2인 경우

2x2 1개, 2x1 2개, 1x2 2개

코드

import sys

d = [0] * (250 + 1)

d[0] = 1
d[1] = 1

for i in range(2, 251):
    d[i] = 2 * d[i - 2] + d[i - 1]

while True:
    try:
        n = int(sys.stdin.readline().rstrip())
        print(d[n])
    except:
        break

[Baekjoon] DP - 9658 돌 게임 4 (오답노트)

DHistory — Mon, 2 Sep 2024 19:50:22 +0900

문제

https://www.acmicpc.net/problem/9658

풀이

d[n]: 돌의 수가 n 개인 경우 우승자

상근이가 먼저 시작하기 때문에 "한 번"이라도 창영이가 마지막 돌을 가져가게 된다면 상근이의 승리

예시

d[1] = 1 (상근 마지막돌, 창영 승)

d[2] = 1 1 (창영 마지막돌, 상근 승)

d[3] = 1 1 1 (상근 마지막돌, 창영 승)

3 (상근 마지막돌, 창영 승)

d[4] = 1 3 (창영 마지막돌, 상근 승)

3 1 (창영 마지막돌, 상근 승)

4 (상근 마지막돌, 창영 승)

코드

import sys

n = int(sys.stdin.readline().rstrip())
d = [False] * (n + 5)

# False: 창영이 우승, True: 상근이 우승
d[1] = False
d[2] = True
d[3] = False
d[4] = True

for i in range(5, n + 1):
    # 마지막 돌을 상근이만 가져갈 수 있으면 
    if d[i - 1] and d[i - 3] and d[i - 4]:
        d[i] = False # 창영이 승
    else:
        d[i] = True

print("SK" if d[n] else "CY")