부하테스트

[My-Storage] 재귀 호출에서 발생할 수 있는 데드락

부하 테스트를 진행하며 위와 같이 서버가 죽어버리는 상황이 발생했다.처음에는 죽었는지 몰라서 DB가 처리를 너무 늦게 하나..?라는 생각을 했었다. 사실 120초라서 말이 안되긴 하지만..DB에는 문제가 없었고,다른 요청을 보내 봤는데, 요청 자체를 처리하지 못하는 것을 볼 수 있었다.힙이 가득 차서 뭔가 처리를 못하고 있나..? 그래서 GC가 계속 돌아가는데 아무것도 지우지 못해서 처리를 못하나..?라는 생각에 확인해 보았다.너무 멀쩡했다!혹시 소켓 수준에서 문제가 있나?라는 생각에 소켓 상태도 확인해 보았다.소켓 상태를 보면 08인 상태들이 대부분이었다. 이건 CLOSE_WAIT을 의미한다.부하테스트가 끝났기에 클라이언트가 연결을 종료했고, 서버는 처리중인 어떠한 작업을 완료하기 전에 CLOSE_WA..

[My-Storage] 폴더 이동 로직에서 사용한 분산락 작업 개선

이전 로직의 문제점기존 폴더 이동은 각각의 root 폴더의 ID 값을 기준으로 락을 획득하고 이동 작업을 진행했다. 그러다 보니 한 번에 하나의 이동 작업만 처리할 수 있었고, 동시에 여러 이동 작업을 처리할 수 없었다.이렇게 했던 이유는 폴더의 순환 구조를 막기 위함이었다. 최근 더 나은 방법이 생각나서 변경하고 테스트를 진행해 보았다. 아이디어이동 작업이 발생한 폴더의 ID를 기준으로 락을 요청한다. 락 획득이 가능하면 획득 후, 해당 폴더를 기준으로 상위로 탐색하며 탐색한 폴더의 ID를 기준으로 락이 걸려 있는지 확인한다. 만약 락이 걸려 있다면 나보다 먼저 이동 작업이 진행 중인 폴더가 존재한다는 것이다. 이 경우 획득한 락을 해제하고 이동 작업에 실패한다. 즉, 현재 이동 작업이 진행 중인 폴더..

[My-Storage 개선하기] 데드락 해결, DB lock 사용 줄이기(2) - 테스트

테스트 환경 설정DB, Redis, Spring 모두 별도의 환경에서 테스트를 하고자 했다. 개선 전의 서버와 비교를 하려면 동일한 환경을 보장하는 것이 중요하다고 생각했기 때문이다. 서버를 살 돈은 없었기에 로컬에서 도커를 사용해서 컨테이너 환경에서 cpu와 메모리를 제한했다.Dockerfile# 1. 빌드 단계: Gradle 이미지 사용FROM gradle:7.6-jdk17 AS build# 2. 작업 디렉토리 설정WORKDIR /app# 3. 필요한 파일 복사COPY --chown=gradle:gradle . .# 4. Gradle을 사용해 JAR 파일 빌드RUN gradle clean build --no-daemon --stacktrace || (echo "Build failed. Check bu..

[우아한 테크 캠프 팀 프로젝트]동기 처리 vs 비동기 처리, 비동기 처리에서 발생한 OOM 문제 My-Storage(2)

내가 학습한 CS를 바탕으로 비동기가 더 적절하다고 가정하고 파일 업로드 기능을 구현했다. 그리고 파일 쓰기 작업을 비동기 처리하며 순차적으로 쓰고, 정확히 잘 써졌는지 확인하는 다른 작업들이 추가되었다. 이론적으론 비동기가 리소스를 많이 사용하더라도 결국 I/O 작업이 가장 오래 걸리기 때문에 동기 처리보다 빨라야 할 것이다. 그래서 두 방식을 직접 비교하는 테스트를 진행했다. 사실 테스트는 가장 마지막에 했지만, 정리하는 글이니까 순서상 먼저 정리하려고 한다. 그 과정에서 여러 문제를 만나고 나름 해결했지만 그건 뒤에서 다시 정리하고 여기선 단순히 비교한 결과를 정리한다.테스트 환경우선 사용한 t3 micro 인스턴스는 대역폭이 5Gbps라서 부하를 주었을 때 서버 처리 속도가 더 빨라서 정확한 비교..