Redis

Redis Streams의 PEL(Pending Entries List)과 장애 복구 시나리오

Redis StreamsRedis Streams는 append-only 로그처럼 동작하면서도, 일반적인 append-only 로그의 한계를 넘어서는 여러 연산을 지원하는 데이터 구조입니다. O(1) 시간의 랜덤 액세스와 Consumer Group 같은 복합적인 소비 전략이 이에 해당합니다. 각 엔트리는 고유 ID(- 형식)와 필드-값 쌍으로 구성됩니다. XADD로 엔트리를 추가하고, XREAD나 XREADGROUP으로 소비하며, XRANGE로 특정 ID 구간을 조회할 수 있습니다. 아래와 같이 발행, 소비 구조를 나타낼 수 있습니다. 이를 활용할 수 있는 대표적인 사례로는 이벤트 소싱(사용자 행동·클릭 등 추적), 센서 모니터링(디바이스 데이터 수집), 알림 시스템(사용자별 알림 기록) 등이 있습니다. ..

2026. 3. 31.

Redis

Redisson의 tryLock은 Redis SETNX의 어떤 문제를 해결할까?

SETNX 명령으로 구현하는 분산락분산 환경에서 동시성을 제어해야 할 때, Redis의 SET 커맨드로 락을 구현할 수 있습니다.SET lock:key value NX EX 30 Redis는 싱글 스레드로 커맨드를 처리합니다. 여러 클라이언트가 동시에 SET NX를 보내더라도, Redis 내부에서는 하나씩 순서대로 실행됩니다. 따라서 동시성을 제어하기 적합합니다. SET은 Redis에 String 자료구조로 데이터를 저장할 때 사용하며, NX 옵션은 key가 존재하지 않을 때만 값을 설정합니다.따라서 먼저 요청한 프로세스가 key를 선점하고, 나머지는 실패하도록 구현할 수 있습니다.추가로 value에는 요청자를 식별할 수 있는 고유 값을 넣어, 해제 시 자신이 잡은 락인지 확인하는데에 활용할 수 있습니다..

2026. 3. 10.

Tomcat

큐에 21억 개가 담기는데, 왜 요청이 거부될까?

배경 이번 글에서는 톰캣 설정을 건드리다가 생긴 의문, 학습한 내용을 정리해보고자 합니다. server: tomcat: threads: max: 200 톰캣 공식 문서를 보면 maxThreads의 기본값이 200개입니다.maxThreads: If not specified, this attribute is set to 200.그리고 톰캣은 Thread per Request 모델을 사용합니다. 요청 하나당 스레드 하나가 할당되는 방식입니다.The Connector creates a separate thread for each incoming HTTP request. 또한 스레드 풀 개수가 200개 일 때, 201번째 클라이언트(사용자)의 요청은 큐에서 대기한 후 스레드가 반환되면 처리된..

2025. 12. 3.

Infra

Lambda로 파일 생성 서버 분리, DLQ로 운영 안정성 확보하기

배경지금까지 엑셀 생성 기능을 두 차례 개선했습니다.먼저 BlockingQueue를 활용해 이미지 다운로드를 병렬화했습니다. 순차 처리에서 병렬 처리로 전환하면서 다운로드 응답 시간을 단축했고 메모리 사용량도 제어할 수 있었습니다. 이어서 파일 생성을 비동기 스레드에서 수행하고 폴링으로 진행률을 제공했습니다. 사용자는 즉시 응답을 받고 진행률을 확인할 수 있게 되었습니다.하지만 Grafana로 모니터링하던 중 엑셀 생성 작업의 CPU 사용률이 20-30%임을 확인했습니다. 이는 피드백이 30개 쌓인 단체의 경우였고, 임의로 500개를 삽입한 뒤 다운로드 요청을 모니터링한 결과 CPU 사용률은 100%까지 상승했습니다. 파일 생성은 CPU 집약적인 작업이었고 이를 API 서버에서 처리하는 것은 적절하지 않..

2025. 12. 1.

Project

Transactional Outbox Pattern으로 비동기 작업 신뢰성 보장하기

배경두게더 서비스의 핵심 기능 중 하나는 챌린지 그룹 멤버들 사이의 상호작용입니다. 사용자가 투두를 완료하면 사진과 설명으로 인증을 요청하고, 같은 그룹의 다른 멤버가 그것을 검사해서 인정하거나 거절하는 방식입니다. 즉, 사용자는 투두 작성 → 인증 생성 → 알림 → 검사 이라는 흐름을 거치게 됩니다.알림을 통해 사용자들은 상호작용하며 챌린지를 이어가며, 인증 → 알림은 서비스에서 정말 중요한 기능이라고 할 수 있습니다. 현재 코드투두 인증 요청을 하게 되면 현재 다음과 같은 순서로 동작합니다.@Transactionalpublic void certifyDailyTodo( final Long memberId, final Long dailyTodoId, final String certify..

2025. 11. 4.

Infra

Blue-Green 무중단 배포 파이프라인 구축하기

"왜 이 작업을 해야 하나?"새로운 기능을 만들거나 개선할 때, 항상 이 질문부터 시작합니다. 기술은 문제를 해결하는 도구일 뿐이고, 도구를 먼저 고르는 건 올바른 순서가 아니라고 생각합니다. 피드줍줍 팀에서 무중단 배포 파이프라인을 구축하기로 결정한 과정도 마찬가지였습니다. 배포란 무엇일까?배포는 작성한 코드를 사용자가 실제로 사용할 수 있도록 만드는 과정입니다. 개발 환경에서 작동하는 애플리케이션을 운영 서버에 올리고, 사용자의 요청이 새 버전으로 전달되게 합니다.전통적인 배포 과정은 단순합니다.기존 서버를 중지새 버전을 배포서버를 다시 시작문제는 이 과정에서 서비스가 중단된다는 점입니다. 서버를 중지하는 순간부터 다시 시작할 때까지, 사용자는 서비스를 이용할 수 없습니다. 왜 무중단이어야 하는가..

2025. 10. 26.