이미지 업로드 작업과 서버 가용성

저번 포스트에서는 특정 API에 대해 부하테스트를 수행해보았고 결과를 바탕으로 해결책을 하나씩 제시하여 문제를 해결해 보았다. 간단하게 되짚어보자면,

과도하게 낮은 TPS
- 문제점 : DB 쿼리 작업이 서버 리소스를 많이 사용하여 API 요청에 대한 리소스가 부족하였음.
- 해결책 : CloudSQL을 이용, 리모트 DB를 통해 서버 리소스를 분산시켜 평균 700TPS로 개선.
너무 긴 응답시간
- 문제점 : 중복되는 요청이 많이 발생하는 최신 피드 요청에 대해 중복되는 쿼리 및 RDB 쿼리로 인한 평균 응답시간 증가.
- 해결책 : 최신 피드 요청에 한해서 cursor 기반 페이지네이션을 적용, 로컬 Redis에 캐싱하여 응답 시간을 400ms에서 25ms로 개선.

저번 부하테스트는 사실 제대로 된 테스트라고 보기는 어렵다. 단순히 동일한 API 요청에 대해서 테스트를 진행했기 때문이다. 이번 부하테스트는 쓰기작업과 읽기작업 요청을 섞어서 보내고 서버 부하 정도를 확인해 볼 예정이다.

읽기 요청은 이전과 동일하게 최신 피드를 처리하는 요청이다.
쓰기 요청은 5개의 이미지를 서버측에 전송하여 S3 스토리지에 업로드하는 요청으로 총 용량은 2MB 남짓이다. 물론, 테스트 용도이기 때문에 실제 이미지는 더 클 가능성이 높다.

이미지 업로드 요청은 사용자가 새로운 피드를 생성할 때 사용되므로 상대적으로 읽기 요청에 비해 적은 빈도를 가진다. 그렇기에 쓰레드 수를 차등 분배하여 테스트할 것이다. 테스트를 통해 알아볼 내용은 다음과 같다.

이미지 업로드 요청은 많은 리소스를 사용하며 읽기 요청에 비해 오랫동안 연결을 유지해야하므로 서버의 부하가 심할 것으로 예상된다. 따라서, 이미지 업로드 요청에 사용되는 리소스와 응답시간을 측정한다.
이미지 업로드 요청과 최신 피드 요청을 동시에 요청하여 업로드 요청이 가지는 부하를 가늠한다.

결과 요약

이미지 업로드 Transactions

이미지 업로드 Response Time

고작 10초간 100개의 트래픽을 처리하는데도 error가 무려 20%나 발생했다. TPS 만 보면 처리에는 이상이 없어 보이지만 응답시간이 평균 2000ms를 기록했고 최대 응답시간은 무려 4000ms가 넘어간다.

그렇다면 요청을 절반으로 줄여보자.

결과 요약

이미지 업로드 Transactions