이번 포스팅에선, 한편의 수학 질문 게시판 성능 최적화 과정을 어떻게 이뤄냈는지 설명한다.1. 문제점 파악질문 게시판 기능뿐만 아니라 어플리케이션의 모든 기능들은 모놀리식 아키텍쳐로 구성됐다.200명 정도의 사용자임에 따라 문제가 없을거라 예상했지만, 게시판 동시 조회 시 응답속도가 현저히 낮아지는 문제가 발생했다.파악된 문제점들은 다음과 같았다.1. 조회수 락으로 인한 응답속도 저하조회수는 실시간성이 중요한 데이터 도메인이다.사용자는 자신의 조회수가 실시간으로 반영되어 있지 않다면, 사용감에 부정적인 영향을 줄 수 있다.또한 동시접근이 빈번함에 따라, race Condition이 빈번히 발생할 가능성이 존재한다.기존 모놀리식 어플리케이션에선 Row Level Lock ( X-LOCK )을 통해 race..

🙈 1. 문제 파악API 구성에는 인증과 인가가 항상 뒷따르게 됩니다.이와 관련된 보안 로직은 필수적이지만, API 응답을 직접적으로 테스트하려면, 인증과 인가 로직을 테스트 시 불필요하게 포함하지 않고, 원하는 로직만 검증하는 것이 중요합니다.기존에는 보안 관련 로직이 중복되면서, 입력 형식을 테스트하는 과정에서도 인증 정보가 반드시 필요하게 되어 다음과 같은 문제가 발생했습니다.입력 형식을 위한 테스트에 불필요한 인증 로직을 포함해야 하는 문제예: JsonBody가 매핑되는지 확인하기 위해 인증을 포함해야 했음.인가 테스트를 위해 현재 사용하고 있는 로그인 구현체에 의존해야 하는 문제예: Authorization 헤더를 통해 직접 토큰을 생성하는 방식에 의존하게 됨.💡 2. 해결 방안테스트 각각에..

🙈 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) 로그인 실패 카운트 기능계정별로 로그인 실패 횟수를 기록해야 한다.기존 테이블에 로그인 시도횟수를 기록하는 방법을 생각해 볼 수 있다.이를 위해,기존 데이터베이스 스..