🙈 1. 문제 파악현재 진행 중인 프로젝트에서는 이미지 업로드 API의 응답 시간을 단축하고, 처리량(Throughput)을 향상시키기 위해 비동기 처리를 도입하고자 했습니다.스프링에서는 AOP(Aspect-Oriented Programming)로 @Async 어노테이션을 통해 비동기 처리를 지원하고 있습니다. 그러나 기존의 MediaStorage 구현체에 @Async를 직접 적용하는 상황에서, 몇 가지 문제가 발생했습니다.문제점1. UploadFile 구현에 따른 의존성 문제@Async를 MediaStorage의 구현체에 직접 추가하면, 기존 MediaStorage를 의존하는 모든 서비스들에 대해 비동기 처리가 적용됩니다. 하지만 UploadFile 자체가 비동기를 지원하지 않으면 (예: Multip..

☁️ 이미지 업로드 API에서의 트랜잭션 병목과 비동기 처리 전략1. 문제 파악 – 응답시간이 8초?최근 진행 중인 프로젝트에서 이미지 업로드 기능을 독립적인 API로 설계하고 있었습니다.사용자는 이미지와 함께 간단한 정보를 전송하며, 서버는 이를 데이터베이스에 기록한 뒤 이미지 파일을 저장합니다.단순한 API라 여겼지만, 부하 테스트 결과는 충격적이었습니다.200 Threads x 10 Loop = 총 2000회 요청평균 응답 시간: 약 8초Throughput: 33 requests/sec단순 이미지 업로드임에도, 트래픽이 몰리자 응답 시간이 기하급수적으로 증가했습니다.원인을 찾기 위해 서버의 흐름을 다시 점검했습니다.2. 근본 원인 – 트랜잭션과 I/O의 결합애플리케이션 구조는 아래와 같았습니다:문제..

어플리케이션의 규모가 커지고, API의 종류가 다양해지면서 입력값 검증 로직이 여러 레이어에 흩어져 관리되는 문제가 발생했습니다.특히 같은 도메인 필드에 대한 검증 코드가 각기 다른 DTO에 중복 작성되면서, 유지보수성과 일관성에 어려움이 뒤따랐습니다.이러한 문제를 해결하기 위해, 검증 책임의 위치를 조정하고 통합해가는 과정을 다음과 같이 정리해보았습니다검증 방식 발전 과정1. Request에 대해서만 검증하자.1-1. 구현 방식 : DTO에 대한 검증일반적인 스프링 MVC 어플리케이션에서 입력값 검증을 위해 Jakarta Validation API를 제공합니다.입력값에 대한 검증을 위해 아래와 같이 해당 API를 사용했습니다.public class MemberRegisterRequest { @Le..

🙈 1. 문제 파악현재 서비스에서는, 일일 문자인증 시도 횟수를 제한하고 있다.이에 따라, 테이블에는 문자 인증 전송 횟수, 인증 중 상태, 인증 코드, 인증 시작 시간 에 관련한 칼럼이 있다.일별 문자 인증 전송 횟수 초기화를 위해 아래와 같은 로직이 섞여있었다.@Service@RequiredArgsConstructorpublic class AccountScheduler { private final MemberRepository memberRepository; @Scheduled(cron = "0 0 0 * * *") @Transactional public void resetVerificationStatus() { memberRepository.stream().for..

🙈 1. 문제 파악현재 시스템은 계정당 로그인 시도 횟수 제한이 없어, 무차별 대입 공격(Brute Force Attack) 에 취약한 상태이다.로그인 실패에 대한 제어 장치가 부재할 경우, 장시간에 걸친 자동화된 공격이 가능해짐에 따라 공격자는 사용자 비밀번호를 탈취할 수 있으며, 이는 계정 탈취 및 정보 유출로 이어질 수 있다.최악의 경우, 관리자 게정이 탈취되어 서비스가 중단될 수 있다.따라서, 현재 로그인 시도 횟수 제한을 위한 방어 메커니즘 도입이 시급하다.💡 2. 해결 계획방어 메커니즘을 위해 필요한 기능은 다음과 같다.(1) 로그인 실패 카운트 기능계정별로 로그인 실패 횟수를 기록해야 한다.기존 테이블에 로그인 시도횟수를 기록하는 방법을 생각해 볼 수 있다.이를 위해,기존 데이터베이스 스..