Pink Spider Pink-Spider

분산 시스템에서 여러 대의 서버가 동일한 자원에 동시에 접근할 때, 데이터의 일관성을 유지하기 위해 사용하는 기술이 바로 **분산락(Distributed Lock)**입니다.

단일 서버 환경에서는 synchronized나 ReentrantLock 같은 자바 표준 API로 동시성을 제어할 수 있지만, 서버가 여러 대라면 각 서버의 로컬 락은 서로를 알지 못합니다. 이때 모든 서버가 공통으로 바라보는 외부 저장소를 활용해 “누가 자원을 선점했는지"를 기록하는 것이 핵심입니다.

1. 분산락이 필요한 이유

동일한 DB 레코드에 대해 여러 인스턴스가 동시에 수정 요청을 보낼 때, **레이스 컨디션(Race Condition)**이 발생하여 데이터가 꼬일 수 있습니다.

Redis를 활용한 메시징 시스템의 두 기능은 모두 “데이터를 전달한다"는 목적은 같지만, **철학(Philosophy)**과 데이터 보존 방식에서 결정적인 차이가 있습니다.

한마디로 요약하자면: **Pub/Sub은 ‘방송’**이고, **Streams는 ‘기록이 남는 로그’**입니다.

1. Redis Pub/Sub (Publish/Subscribe)

가장 전통적인 형태의 메시징 모델입니다. 발신자가 메시지를 던지면, 그 순간 연결되어 있는 모든 수신자에게 실시간으로 전달됩니다.

• 휘발성 (Fire and Forget): 메시지를 보낸 후 어디에도 저장하지 않습니다. 수신자가 오프라인 상태라면 그 메시지는 영원히 사라집니다.
• 실시간성: 지연 시간이 거의 없어 실시간 알림이나 채팅에 적합합니다.
• 팬아웃(Fan-out): 하나의 메시지를 수천 명의 구독자에게 동시에 뿌릴 때 매우 효율적입니다.

2. Redis Streams

Kafka와 유사한 기능을 Redis에 구현한 모델입니다. 단순 전달을 넘어 데이터의 ‘이력’을 관리합니다.

Spring Boot(또는 Java)에서 Future 패턴은 비동기 프로그래밍을 위한 핵심 디자인 패턴입니다. 쉽게 말해, **“지금 당장 결과를 줄 수는 없지만, 미래의 어느 시점에 작업이 완료되면 결과물을 넘겨주겠다”**는 약속(Promise)과 같습니다.

1. Future 패턴의 핵심 개념

일반적인 동기(Synchronous) 방식에서는 작업이 끝날 때까지 스레드가 아무것도 못 하고 기다려야 합니다(Blocking). 반면, Future 패턴을 사용하면 작업을 별도의 스레드에 맡기고 메인 스레드는 자기 할 일을 계속할 수 있습니다.

주요 특징

• 비차단(Non-blocking): 결과가 나올 때까지 기다리지 않고 다른 작업을 수행할 수 있어 효율적입니다.
• 지연 실행: 결과가 실제로 필요한 시점까지 데이터 계산을 미룰 수 있습니다.
• 결합성: 여러 비동기 작업의 결과를 합치거나, 순차적으로 실행하는 흐름을 만들 수 있습니다.

2. Spring Boot에서의 구현 방식

Spring Boot에서는 주로 CompletableFuture와 @Async 어노테이션을 조합하여 이 패턴을 구현합니다.

데이터베이스 설계에서 **정규화(Normalization)**와 **반정규화(Denormalization)**는 데이터의 **무결성(Integrity)**과 성능(Performance) 사이의 균형을 맞추는 핵심적인 개념입니다.

이 둘의 관계는 흔히 **“데이터 정합성 vs. 읽기 성능”**의 트레이드오프(Trade-off)로 요약할 수 있습니다. 각 개념의 특징과 트레이드오프 요소를 상세히 분석해 드리겠습니다.

1. 핵심 트레이드오프 요약

가장 먼저 이해해야 할 큰 그림은 다음과 같습니다.

• 정규화: 데이터를 쪼개서 중복을 제거하고 무결성을 지킵니다. (쓰기 성능 향상, 읽기 시 JOIN 비용 발생)
• 반정규화: 성능을 위해 의도적으로 데이터를 중복시킵니다. (읽기 성능 향상, 쓰기 시 동기화 비용 발생)

2. 정규화 (Normalization)

데이터의 중복을 최소화하고, 이상 현상(Anomaly)을 방지하기 위해 테이블을 분리하는 과정입니다.

장단점

스프링부트(Spring Boot)와 JPA(Hibernate) 환경에서 **스트리밍 쿼리(Streaming Query)**는 대용량 데이터를 처리할 때 메모리 문제를 해결하기 위해 사용하는 매우 중요한 기술입니다.

일반적으로 데이터를 List<T> 형태로 조회하면 모든 결과가 애플리케이션 메모리(RAM)에 적재되지만, 스트리밍 쿼리는 데이터베이스 커서(Cursor)를 사용하여 필요한 만큼만 조금씩 가져와 처리하는 방식입니다.

요청하신 스트리밍 쿼리의 특징과 장단점을 정리해 드립니다.

1. 스트리밍 쿼리의 주요 특징

스트리밍 쿼리는 Java 8의 Stream<T> API를 활용하여 DB 결과를 물 흐르듯 처리합니다.

• 커서(Cursor) 기반 동작: 데이터베이스 내부의 커서를 이동시키며 데이터를 순차적으로 읽어옵니다.
• 지연 로딩(Lazy Loading)과 유사: Stream 객체를 생성한 시점에는 쿼리만 실행되고, 실제 데이터는 stream.forEach()나 next() 등을 호출할 때 가져옵니다.
• 트랜잭션 의존성: 스트림 처리가 끝날 때까지 DB 연결(Connection)을 유지해야 하므로, 반드시 활성화된 트랜잭션 안에서 수행되어야 합니다.

2. 장점 (Pros)

대용량 데이터 처리(Batch 작업, 엑셀 다운로드 등)에서 강력한 이점을 가집니다.

Memcached와 Redis는 둘 다 고성능 인메모리(In-memory) 키-값(Key-Value) 저장소로, 주로 데이터베이스 부하를 줄이고 애플리케이션 속도를 높이는 캐시(Cache) 용도로 사용된다는 공통점이 있습니다.

하지만 “단순함과 멀티스레드(Memcached)” 대 **“강력한 기능과 유연성(Redis)”**이라는 명확한 차이가 있습니다.

두 기술의 핵심적인 차이를 4가지 관점(데이터 구조, 아키텍처, 영속성, 확장성)에서 정리해 드립니다.

1. 한눈에 보는 비교 (Executive Summary)

2. 상세 차이점 분석

① 데이터 구조 (Data Structures)

• Memcached: 오직 **문자열(String)**만 저장합니다. 리스트나 해시 같은 구조를 저장하려면 JSON 등으로 직렬화(Serialize)해서 문자열로 만든 뒤 저장해야 합니다. 데이터를 수정하려면 전체 데이터를 가져와서 수정한 뒤 다시 덮어써야 하는 단점이 있습니다.
• Redis: 다양한 자료구조를 지원합니다. 리스트(List)에 요소를 추가하거나, 해시(Hash)의 특정 필드만 수정하는 등 효율적인 데이터 조작이 가능합니다.
• 활용 예: ‘실시간 랭킹’ 구현 시 Redis의 Sorted Set을 쓰면 매우 쉽게 구현 가능합니다.

② 스레드 모델 (Architecture)

가장 큰 아키텍처 차이입니다.