목적- 현재 이커머스 시나리오에서 성능이 중요한 요소 중 하나는 데이터베이스에서 조회하는 시간입니다. 특히 자주 호출 되는 API에서 응답 시간이 길어지면 사용자 경험에 부정적인 영향을 미칠 수 있습니다.
- 따라서, 데이터베이스에 반복적으로 접근해야 하는 조회성 쿼리에 대해 Redis 캐싱을 적용하여 응답 속도를 개선하는 것이 이번 과제의 목표입니다. Redis 캐시를 적용함으로써 특정 조회 API에 대한 응답을 메모리 기반으로 즉시 제공하고, 데이터베이스에 대한 부담을 줄여 시스템 전반의 성능을 향시키려 합니다.
분석 배경- 분석 결과, 조회가 빈번하고 성능에 영향을 주는 몇 가지 API가 확인되었습니다.
- 예를 들어, 상품 조회 API와 사용자 잔액 조회 API는 데이터베이에 접근하여 상품 및 잔액 정보를 가져와야 하기 때문에 데이터베이스 부하가 발생할 수 있습니다. 또한, 조회 요청이 빈번할수록 같은 데이터가 반복적으로 데이터베이스에서 조회되어 성능 병목이 발생할 가능성이 큽니다.
- 이런 조회 요청(예: 상품의 기본 정보, 사용자 잔액 등)은 실시간으로 변동되지 않는 정보인 경우가 많으므로, 데이터를 캐싱해둠으로써 동일한 데이터를 반복 조회할 필요가 없도록 하여 성능 최적화를 도모할 수 있습니다.
Redis 선택 이유- Redis는 메모리 기반의 NoSQL 데이터베이스로, 매우 빠른 속도를 제공합니다. 이 덕분에 조회 응답 시간을 크게 줄일 수 있습니다.
- 데이터 무결성이 중요한 트랜잭션성 데이터는 RDBMS에 저장하고 자주 조회되지만 실시간 갱신이 필요 하지 않은 데이는 Redis에 캐싱하여 조회할 수 있도록 하면, 두 시스템의 장점을 극대화 할 수 있습니다.
- 데이터 TTL(Time-to-Live) 설정이 가능하여, 캐시된 데이터가 오래된 정보로 남아있지 않도록 주기적으로 갱신할 수 있습니다. 이를 통해 시스템의 최신성을 유지하면서도 응답 속도를 개선할 수 있습니다.
- 또한, Redis는 다양한 데이터 구조를 지원하고 확장성이 높기 때문에, 현재와 같은 간단한 조회 요청 캐싱 외에 다양한 요구 사항을 수용할 수 있는 유연성이 있습니다.
주요 분석 항목
- 상품 조회 API
- 적용 대상 : 상품의 일반 정보(상품명, 카테고리, 가격)
- 분석 : 상품 조회 API는 사용자 요청에 대해 상품의 기본 정보를 제공하며, 응답 속도가 중요합니다. Redis를 통해 상품명, 카테고리, 가격 같은 변경 빈도가 낮은 데이터를 캐싱하면 효율적입니다. 다만, 상품의 재고 정보는 실시간 데이터로 관리해야 하므로 캐싱에 부적합할 수 있습니다.
- 해결 방안: 상품 정보 중 재고 정보를 제외한 기본 정보를 캐싱하여 조회 속도를 개선합니다. 재고 데이터는 실시간 조회가 필요하기 때문에 데이터베이스에서 직접 조회하는 방식을 유지하거나, TTL을 짧게 설정하여 부분적으로 캐시 활용이 가능하도록 합니다.
- 잔액 조회 API
- 적용 대상 : 사용자 잔액 정보
- 분석 : 사용자 잔액은 자주 조회되지만, 실제 잔액 변경은 상대적으로 드문 편입니다. Redis에 캐싱해둔다면 대부분 조회 요청에 대해 빠른 응답을 제공 할 수 있습니다.
- 해결 방안 : 잔액 조회 API의 캐싱 주기를 적절히 설정하여, 캐시된 데이터와 실제 데이터가 크게 차이 나지 않도록 관리할 수 있습니다. 잔액이 변경될 때에는 Redis 캐시를 갱신해 최신 데이터를 반영하고, 이를 통해 조회 요청 시 빠른 응답을 보장합니다.
잔액 조회에 캐시를 적용하는 것에 대한 생각 변경점
- 기존에는 사용자 잔액이 자주 변경되지 않는다고 판단하여, 잦은 조회에 대비해 Redis 캐시를 활용하는 방안을 고려했습니다. 하지만 실제로 사용자들이 잔액을 자주 조회할지에 대해 다시 생각해보니, 조회 빈도가 예상보다 낮을 수 있다는 결론에 이르렀습니다. 또한, 일부 사용자들은 상품을 자주 구매하거나 포인트를 자주 충전하는 경우가 많아 잔액이 빈번히 변경될 가능성도 크다고 판단했습니다.
결론
이러한 이유로 잔액 조회에 캐시를 적용할 필요성이 낮다고 판단했습니다.
캐시 적용 시 이점을 얻기 위해서는 데이터 조회 빈도가 매우 높아야 하고, 데이터 변경 빈도는 낮아야 합니다.
하지만 잔액 조회는 상대적으로 빈도가 낮고, 잔액 변경이 더 빈번하게 일어날 가능성이 커 캐시를 유지하는 비용이 오히려 증가할 수 있습니다. 따라서 캐시를 적용하지 않는 것이 더 효율적일 것이라고 결론지었습니다.
캐싱 방식 설명
- Read-Through 캐시 방식
- 설명: Read-Through 캐시는 애플리케이션이 데이터 조회 요청을 할 때 먼저 Redis에 캐시된 데이터가 있는지 확인하고, 없을 경우 데이터베이스(DB)에서 조회한 후 Redis에 캐시를 저장하는 방식입니다.
- 적용 대상: 조회 요청 빈도가 높고, 데이터 갱신 주기가 비교적 긴 경우에 적합합니다. 예를 들어 상품 정보나 상위 인기 상품 조회 API에 효과적입니다.
- Write-Through 캐시 방식
- 설명: Write-Through 캐시는 데이터가 DB에 쓰일 때 Redis 캐시에 함께 저장하여, 데이터 변경 시 DB와 캐시가 동시에 갱신되도록 하는 방식입니다.
- 적용 대상: 잔액 조회와 같이 조회와 갱신이 빈번히 발생하는 데이터에 적합합니다. 캐시와 DB 간 데이터 불일치를 방지하는 데 유용합니다.
TTL (Time-To-Live) 설정
- 설정 목적: 오래된 데이터가 캐시에 남아있지 않도록 각 데이터의 특성에 맞는 TTL을 설정하여 데이터 유효성을 관리합니다.
- 설정 방안
- 상품 정보: 비교적 업데이트 빈도가 낮으므로 1시간 혹은 하루 단위의 TTL을 설정하여 캐싱된 데이터를 주기적으로 갱신합니다.
잔액 조회: 실시간 반영이 중요한 데이터이므로 캐싱 기간을 짧게 설정하거나 Write-Through 방식으로 갱신 시점에 캐시를 업데이트합니다.
캐시 무효화 조건
-
상품 정보: 상품 가격이나 카테고리와 같은 변경 시에는 캐시 무효화를 통해 새로운 정보가 반영되도록 합니다. 주기적 갱신이 아닌 실시간 갱신이 필요한 경우에는 이벤트 기반 무효화 방식을 추가적으로 활용할 수 있습니다.
-
잔액 정보: 사용자가 잔액을 충전하거나 결제할 때 즉시 무효화하여, 변경된 잔액이 조회 API에서 바로 반영될 수 있도록 합니다.
캐시 적용시 성능 비교
테스트 코드로 각각 100,000번 호출했을 때 나오는 시간을 측정해봤습니다. 단순 조회하는 로직이지만 캐시 적용했을 때 성능이 확실히 좋아지는걸 확인했습니다.
- 잔액 조회
- 상품 조회
