조건부 캐싱 및 로드밸런싱 성능 테스트

캐시는 디스크 접근을 줄여 데이터 조회 속도를 높이는 데 유용하다. 하지만 무분별한 캐시 적용은 예기치 못한 문제를 초래할 수 있다. 그렇다면 현재 진행 중인 프로젝트에서 어떤 상황에 캐시를 적용하는 것이 가장 효과적일까?

캐시 적용에 적합한 조건

• 자주 변경되지 않는 데이터
• 데이터 유실이 큰 문제가 되지 않는 데이터
• 높은 정합성이 요구되지 않는 데이터

간단하게 세가지로 살펴볼 수 있는데 우선 중고거래 플랫폼의 주요 핵심 서비스를 생각해보자

주요 서비스 기능

핵심 기능	효율성
거래 ( 플랫폼에서 제공하는 페이 )	데이터 정합성이 매우 중요한 영역이므로 캐시 적용이 적합하지 않다. 예를 들어, 당근페이 같은 거래 시스템에 캐시를 사용하면 입금 금액 오류나 포인트 잘못 저장 등 예상치 못한 문제들이 발생할 수 있다.
채팅	실시간으로 빠른 응답이 요구되며, 데이터 변동성이 높기 때문에 캐시 적용에 부적합하다. 또한 채팅 메시지는 자주 생성되므로, 캐시를 사용하면 메모리 사용량이 급격히 증가해 시스템에 부담을 줄 수 있다. 대신, Redis의 pub/sub 모델을 활용하는 것이 더 적절한 선택이다.
중고 물품 조회	중고 물품 조회에 캐시를 적용하는 것은 효율적일 수 있다. 다만, 사용자가 게시물을 수정하거나 삭제할 때 캐시된 데이터가 남아 있으면 문제가 될 수 있다. 이를 해결하기 위해 데이터 변경 시점에 캐시 무효화를 통해 일관성을 유지할 수 있다.

내 프로젝트에서는 다양한 캐시 전략 중 기본적인 Look-Aside 패턴을 적용해 구현했다.

Local에서 테스트한 캐싱 적용 사항

카테고리 캐시 적용

• 게시물을 등록한다.(카테고리는 변하지 않는 값이기에 캐싱 적용 O)

• DB에서 추가된 게시물 데이터를 확인한다.

• Redis에 캐싱된 데이터를 확인한다.

게시물 조회 캐시 적용

• 위 등록한 게시물을 아래 URL과 같이 주소를 추가하여 첫번째 조회

• 주소 값으로 캐싱 적용이 되지 않아 SQL이 실행된 것을 알 수 있음

• 캐시 Miss로 인해 Redis 캐시 서버에 해당 반환 값을 캐싱하여 저장

재 조회 시 DB 직접 접근이 아닌 Redis 캐시 서버에서 조회한다.

캐싱 성능 측정 ( Local )

AWS로 대용량으로 경험해보면 좋았겠지만 비용 문제로 인하여 로컬 환경과 AWS 프리티어를 사용하여 각각 테스트를 기록했다. 이번 테스트 목적은 캐싱이 TPS와 응답시간에 미치는 영향과 Scale Out과 로드밸런싱과 조합하여 사용 시 미치는 영향에 중점을 두었다.

초기 서버 구성

• WAS 서버 1대
• Master / Slave로 구성된 동일한 스펙의 Mysql 서버

게시물 조회 테스트 (캐싱 전)

초당 처리 가능한 요청인 TPS는 평균치 57.9으로 측정되었고 테스트 시간은 138.46 ms로 측증되었다.

게시물 조회 테스트 (캐싱 후)

동일한 조건으로 캐싱된 데이터를 Redis로 조회한 결과 TPS가 158로 초당 트랜잭션 처리가 100이나 상승하였다. 테스트 시간 또한 캐싱 전은 138 ms 였다면 캐싱 후는 50ms로 거의 반타작 이상 감소되었으며 총 실행 테스트 수 또한 대폭 증가하였다

캐싱 후 결과 요약

• TPS : 82 → 158
• 평균 테스트 시간 : 138 → 50
• 총 실행 횟수 : 3131 → 8574

AWS 테스트 진행 - 단일 환경 서버

서버 구성

• [db.t3.micro] Mysql RDS 20GB 1vCPU, 1GB Mem ( freetier )
• [t2.micro] AWS EC2 WAS 8GB 1vCPU, 1GB Mem ( freetier )

게시물 조회 테스트 ( 캐싱 미적용 )

이번 테스트는 1000명의 가상 사용자를 기준으로 진행되었습니다. 테스트 결과, 초당 처리 가능한 요청 수(TPS)는 평균 231.7로 측정되었으며, 지연 시간은 약 3300ms에 달했습니다.

가상 사용자 1000명이 요청하더라도, t2.micro 사양의 서버는 총 3249번의 요청밖에 처리하지 못했습니다. 이는 I/O에서 직접적으로 데이터를 조회하는 방식이 성능 저하에 기여했음을 보여줍니다.

해당 서버 사양은 대규모 서비스에는 적합하지 않지만, 이번 토이 프로젝트에서는 정해진 조건 내에서 Scale Out과 캐싱 적용이 성능에 미치는 영향을 분석하는 데 중점을 두어 테스트를 수행했습니다.

서버 구성

• [db.t3.micro] Mysql RDS 20GB 1vCPU, 1GB Mem ( freetier )

• [t2.micro] AWS EC2 WAS 8GB 1vCPU, 1GB Mem ( freetier )

• [t2.micro] AWS EC2 Redis 1 8GB 1vCPU, 1GB Mem ( freetier )

게시물 조회 테스트 ( 캐싱 적용 )

• TPS
  • 이전 테스트: 231.7 TPS
  • 이번 테스트: 822.1 TPS

캐싱을 적용한 결과, TPS가 약 3.5배 증가했습니다. Redis 캐시를 활용함으로써 요청의 상당 부분이 데이터베이스에 도달하지 않고 캐시에서 직접 처리되어, 전체 성능이 크게 향상되었습니다.

• 평균 응답 시간:
  • 이전 테스트: 3,363.13ms
  • 이번 테스트: 1,012.79ms

평균 응답 시간이 약 70% 감소했습니다. 이는 캐시를 통해 데이터베이스에 대한 직접 접근을 줄였기 때문이며, 보다 신속한 응답을 제공할 수 있게 되었습니다. 캐시에서 직접 데이터를 제공함으로써 서버의 부하도 감소했습니다.

• 총 테스트 횟수:
  • 이전 테스트: 3,249번
  • 이번 테스트: 11,521번

더 많은 요청을 처리할 수 있었던 이유는 캐싱 덕분에 서버와 데이터베이스의 부하가 줄어들어, 동일한 시간 내에 더 많은 요청을 수용할 수 있었기 때문입니다. 캐시를 통해 데이터 접근 속도가 크게 향상되어 요청 처리량이 증가했습니다.

vUser 2000명

vUser 2,000명을 기준으로 테스트한 결과, 이전 테스트에 비해 에러 없이 더 향상된 성과를 확인할 수 있었습니다.

AWS 테스트 진행 - 다중 환경 서버 (로드밸런싱)

서버 구성

• [db.t3.micro] Mysql RDS 20GB 1vCPU, 1GB Mem ( freetier )

• [t2.micro] AWS EC2 WAS1 8GB 1vCPU, 1GB Mem ( freetier )

• [t2.micro] AWS EC2 WAS2 8GB 1vCPU, 1GB Mem ( freetier )

• [t2.micro] AWS EC2 Redis 8GB 1vCPU, 1GB Mem ( freetier )

• [t2.micro] AWS EC2 Nginx 8GB 1vCPU, 1GB Mem ( freetier )

게시물 조회 vUser 1000명

• TPS
  • 이전 테스트 (캐시 적용): 822.1 TPS
  • 이번 테스트 (로드 밸런싱 적용): 1,091.2 TPS

TPS가 약 32% 증가했습니다. 이는 두 대의 WAS와 Nginx 로드 밸런싱을 통해 요청 부하를 효과적으로 분산할 수 있었기 때문입니다. 여러 WAS 인스턴스가 동시에 요청을 처리함으로써 서버의 처리 능력이 크게 향상되었습니다.

• 평균 응답 시간
  • 이전 테스트 (캐시 적용): 1,012.79 ms
  • 이번 테스트 (로드 밸런싱 적용): 462.75 ms

응답 시간이 절반 이상 단축되었습니다. 여러 WAS 인스턴스와 Nginx를 통한 부하 분산 덕분에 요청 처리 속도가 개선되었습니다.

• 총 테스트 횟수
  • 이전 테스트 (캐시 적용): 11,521회
  • 이번 테스트 (로드 밸런싱 적용): 19,171회

캐시와 로드 밸런싱을 도입함으로써 총 테스트 횟수가 크게 증가했습니다. 이는 시스템의 효율성이 높아져 한정된 시간 내에 더 많은 요청을 처리할 수 있음을 보여줍니다.

• 에러 수
  • 이전 테스트 (캐시 적용): 0 에러
  • 이번 테스트 (로드 밸런싱 적용): 3,879 에러

WAS의 수가 증가함에 따라 부하 분산 효과는 좋았지만, 3,879 횟수의 에러가 발생한 것으로 보아 아무래도 AWS 프리티어 스펙으로 인해 Nginx 워커 프로세스도 적게 가져갈 수밖에 없어 VUser를 크게 잡고 테스트하면 위와 같이 특정 요청을 처리하지 못하는 상황이 발생하였습니다. 해당 에러는 keep_alive 타임으로 인한 지연 보다는, OS 이벤트 큐에 오래 대기하는 이벤트로 인하여 발생한 에러로서 이번은 테스트였지만 실제로는 서버 스펙을 조금 높여 적절한 Nginx 설정이 필요할 것 같습니다.

마무리하며..

이번 테스트 결과를 통해 캐시와 로드 밸런싱의 효과를 명확하게 확인할 수 있었습니다. TPS가 약 32% 증가하고 평균 응답 시간이 절반 이상 단축된 것은 시스템 성능 향상에 있어 매우 긍정적인 지표라고 생각합니다. 특히, 여러 WAS 인스턴스를 활용한 부하 분산이 요청 처리 속도를 높여 사용자가 보다 빠르고 원활한 서비스를 경험할 수 있도록 기여한 점이 인상적이었습니다.

또한, 총 테스트 횟수가 크게 증가한 것은 시스템의 처리 용량이 향상되었음을 의미하며, 이는 향후 더 많은 사용자 요청을 효과적으로 처리할 수 있는 기반이 될 것입니다. 서비스의 확장성과 안정성 측면에서도 매우 중요한 발전이라고 느꼈습니다.

반면, 에러 수의 증가도 중요한 교훈을 주었습니다. 로드 밸런싱을 적용하면서 발생한 에러는 시스템의 복잡성을 높이고 안정성에 부정적인 영향을 미칠 수 있습니다. 이를 통해 Nginx의 설정 및 WAS의 자원 관리가 얼마나 중요한지 다시금 깨달았습니다. 향후에는 이러한 문제를 해결하기 위한 추가적인 최적화 작업이 필요할 것이라 생각합니다.

이번 테스트는 시스템 성능 개선의 가능성을 보여주었고, 향후 개선점을 파악할 수 있는 귀중한 경험이었습니다. 앞으로도 지속적으로 시스템을 모니터링하고 최적화하여 더 나은 사용자 경험을 제공할 수 있도록 노력해야겠다고 다짐했습니다.