큐에 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.

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

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

2025. 12. 1.

분산 환경에서 Redisson Watchdog으로 알림 중복 발송 문제 해결하기

배경이전 글(Transactional Outbox Pattern으로 비동기 작업 신뢰성 보장하기)에서 Transactional Outbox 패턴으로 알림 발송의 신뢰성을 보장했습니다. 사용자가 인증할 때 인증 정보를 저장함과 동시에 Outbox 테이블에 "알림을 발송하겠다"는 작업을 저장합니다. 이후 스케줄러가 주기적으로 Outbox를 폴링하면서 실제 알림을 발송합니다.문제 상황: 스케줄러 중복 실행하지만 여러 인스턴스로 운영되는 분산 환경에서 이 스케줄러가 중복으로 실행되는 문제가 발생할 수 있었습니다. 두 인스턴스가 동시에 Outbox를 조회하고 같은 알림을 중복하여 발송하는 상황입니다. 사용자가 짧은 시간 안에 중복 알림을 받으면 사용자 경험이 저해됩니다. 중복 발송을 막으려면 하나의 인스턴스가 작..

2025. 11. 14.

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

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

2025. 11. 4.

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

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

2025. 10. 26.