Redis 기반의 캐싱 및 대기열 관리를 통한 콘서트 예약 서비스 성능 개선

 

들어가며

이번 시간에는 콘서트 예약 서비스의 성능을 개선하기 위해 현재 시나리오의 조회 API 중 캐싱을 적용할 부분에 대해 고민해 보고, 기존 RDB에서 작동되고 있던 대기열 로직을 Redis로 이관하는 과정에 대해 살펴보겠습니다. 또 캐싱 전후 테스트 결과 비교를 통해 얼마나 성능이 개선되는지도 체크해 보도록 하겠습니다.

 

 

 

 

캐시 적용 기준

우선 캐시를 적용할 때 고려해야 할 기준은 아래와 같습니다.

 

1. 조회 비용이 높은지

데이터베이스에서 데이터를 조회하는 비용이 큰 경우 캐싱을 통해 성능을 개선할 수 있습니다.

 

2. 얼마나 자주 조회되는지

반복적인 요청이 많은 경우 캐시를 활용하여 효율성을 높일 수 있습니다.

 

3. 데이터 정합성에 이슈가 없는지

캐시를 사용할 경우, 캐시된 데이터와 원본 데이터 간의 정합성을 유지할 수 있는지 확인해야 합니다. 캐시를 적절히 갱신할 수 있다면 캐싱을 적용하는 것이 좋습니다.

 

캐시 적용을 고려할 때는 캐시 히트율이 가장 중요한 요소입니다. 높은 히트율을 유지하는 것이 캐싱 효과를 극대화하는 데 필요합니다. 이를 통해 데이터베이스 부하를 줄이고, 시스템의 응답 속도를 크게 개선할 수가 있습니다.

 

 

 

 

조회 API 별 분석

현재 콘서트 예약 서비스에는 다양한 조회 API가 존재합니다. 각 API에 대한 분석과 캐시 적용 여부를 판단해보겠습니다.

 

1. 콘서트 정보 및 날짜 목록 조회 API ✅

특정 콘서트의 정보와 예약 가능한 날짜를 조회하는 API입니다.

  - 조회 비용 : 데이터 양이 크고 복잡하기 때문에 조회 비용이 큽니다.

  - 조회 빈도 : 사용자들이 콘서트를 검색할 때 자주 요청되는 API입니다.

  - 데이터 정합성 : 날짜 정보가 자주 변경되지 않아 캐싱 적용이 적당합니다. 다만, 날짜별 예약 가능 여부는 실시간으로 변경되므로 예약 가능 좌석 수를 동기화하는 스케줄링 주기에 맞춰 정합성을 맞출 수 있습니다.

 

2. 대기열 상태 조회 API ❌

사용자가 대기열에서 몇 번째에 위치해 있는지를 확인하는 API입니다.

  - 조회 비용 : 대기열 순위 정보 조회 자체는 가벼우나, 실시간 데이터가 필요합니다.

  - 조회 빈도 : 대기 중인 사용자가 자주 조회하지만, 항상 최신 정보가 필요합니다.

  - 데이터 정합성 : 실시간 정보가 필요하여 캐싱을 적용할 경우 정합성 문제가 발생할 수 있습니다.

 

3. 좌석 상태 조회 API ❌

특정 콘서트 날짜의 좌석 정보를 조회하는 API입니다.

  - 조회 비용 : 좌석 상태는 복잡한 정보이므로 조회 비용이 비교적 큽니다.

  - 조회 빈도 : 좌석 상태는 예약이 진행될 때 자주 조회됩니다.

  - 데이터 정합성 : 예약이 자주 변경되기 때문에 정합성 유지가 어려울 수 있습니다.

 

4. 잔액 조회 API ❌

특정 사용자의 현재 잔액을 조회하는 API입니다.

  - 조회 비용 : 잔액 조회 자체는 간단하여 비용이 크지 않습니다.

  - 조회 빈도 : 사용자가 충전 또는 결제 전후로 자신의 잔액을 자주 확인할 수 있습니다.

  - 데이터 정합성 : 잔액 정보는 실시간성이 요구될 수 있지만, 충전/결제 시 캐시를 적절히 갱신한다면 캐싱을 적용할 수도 있습니다.

 

 

이 API 중, 콘서트 정보 및 날짜 목록 조회는 데이터 양이 크고 갱신 주기가 비교적 느리며 동일한 요청이 반복될 가능성이 높기 때문에 캐싱 적용의 필요성이 크다고 생각됩니다. 반면 대기열 상태 조회, 좌석 상태 조회는 실시간성을 요구하고 잔액 조회는 비용이 비교적 크지 않기 때문에 캐시 적용 대상에 넣지 않았습니다.

다만, 대기열 상태 조회는 Redis로 대기열 관리를 하기 때문에 캐싱이 아니어도 빠른 조회 방식으로 개선할 수 있습니다.

 

 

 

 

캐시 전후 성능 비교

캐시 적용 전후의 성능을 비교하기 위해 Grafana와 k6를 활용하여 부하 테스트를 진행했습니다.

 

테스트 결과, 캐시 적용 전에는 평균 1.56, 최대 10의 활성 커넥션이 있었지만, 캐시 적용 후에는 활성 커넥션이 0으로 줄어들어 데이터베이스에 대한 직접적인 요청이 거의 없었습니다. 또한, 동시 요청이 많을 때 풀 사이즈의 한계에 도달해 대기 커넥션이 발생했던 것과 비교해, 캐시 적용 후에는 대기 커넥션이 없었습니다.

캐시 적용 후, 동일 시간 내 요청 처리량이 소폭 증가했으며, 서버의 단건 요청 처리 시간도 짧아진 것을 확인했습니다. 

 

아래는 주요 결과를 요약한 표와 Grafana 결과 캡쳐입니다.

 

항목	캐시 적용 전	캐시 적용 후
HikariCP 활성 커넥션 (평균)	1.56	0.0
HikariCP 활성 커넥션 (최대)	10.0	0.0
HikariCP 대기 커넥션 (평균)	0.222	0.0
HikariCP 대기 커넥션 (최대)	2.0	0.0
API 요청 수 (평균)	183.0	198.0
API 요청 수 (최대)	453.0	486.0
HTTP 요청 지속 시간 (평균)	14.1	13.08
HTTP 요청 지속 시간 (최대)	264.95	182.45

 

 

테스트 결과 ( 캐시 적용 전 )

 

 

테스트 결과 ( 캐시 적용 후 )

 

이를 통해 캐싱이 데이터베이스 부하를 줄이고 응답 시간을 단축시키는 데 기여하는 것을 확인할 수 있었습니다.

 

 

 

 

 

대기열 로직을 RDB에서 Redis로 이관

기존의 대기열 로직은 RDB를 사용하여 관리하고 있었습니다. 하지만 이 방식은 실시간 성능을 요구하는 대기열 시스템에 적합하지 않았으며, 대용량 트래픽 처리 시 데이터베이스에 높은 부하를 유발할 수 있습니다. 이에 따라 대기열 로직을 Redis로 이관하였습니다.

 

Redis로 이관하면서 ActiveToken(예약 가능 활성 토큰)과 WaitingToken(대기 토큰)을 분리하여 관리하는 방향을 설정하였습니다. 각 대기/활성 토큰은 콘서트 스케줄 ID를 Key로 가지는 ZSet(Sorted Set)으로 관리하였습니다. 

이를 통해, WaitingToken에서는 ZRANK 명령어를 사용하여 O(log(N)) 의 시간복잡도로 순위를 가져올 수 있습니다. 또한 ActiveToken에서는 Score에 만료 시간을 기록하여 ZREMRANGEBYSCORE 명령어로 만료된 토큰을 빠르게 삭제할 수 있습니다.

WaitingToken과 ActiveToken

 

또 각 토큰을 별도의 Hash 구조로 저장하여, 토큰을 key로 사용하고 value에는 스케줄 ID, 상태값, 만료일자를 저장하도록 구성했습니다. 이를 통해 특정 토큰에 대한 조회 시 데이터 접근 속도를 크게 향상시킬 수 있었습니다.

토큰 별 정보를 담고있는 Hash

 

 

코드 변경점으로는 기존 JPA를 사용하는 로직을 RedisTemplate를 사용한 로직으로 변경하였으며, 만료 시간 관리와 상태 변경 역시 Redis로 처리할 수 있도록 리팩터링 하였습니다.

 

아래는 토큰 발급 시 RedisTemplate을 사용하여 Redis에 저장하도록 변경한 코드 예시입니다.

@Repository
class WaitingQueueRedisRepository(
    private val redisTemplate: RedisTemplate<String, Any>,
) : WaitingQueueRepository {
    companion object {
        const val WAITING_TOKEN_PREFIX = "WaitingToken"
        const val ACTIVE_TOKEN_PREFIX = "ActiveToken"
        const val TOKEN_INFO_PREFIX = "TokenInfo"
    }

    override fun addWaitingQueue(waitingQueue: WaitingQueue): WaitingQueue {
        // 1. WaitingToken 저장
        redisTemplate.opsForZSet().add(
            "$WAITING_TOKEN_PREFIX:${waitingQueue.scheduleId}",
            waitingQueue.token,
            System.currentTimeMillis().toDouble(),
        )
        redisTemplate.expire("$WAITING_TOKEN_PREFIX:${waitingQueue.scheduleId}", Duration.ofHours(1))

        // 2. TokenInfo 저장
        val key = "$TOKEN_INFO_PREFIX:${waitingQueue.token}"
        val fields =
            mapOf(
                "scheduleId" to waitingQueue.scheduleId.toString(),
                "status" to waitingQueue.status.name,
            )
        redisTemplate.opsForHash<String, String>().putAll(key, fields)
        redisTemplate.expire(key, Duration.ofHours(1))
        return waitingQueue
    }
    
    /* ... */
}

 

 

 

 

마치며

콘서트 예약 서비스의 성능을 개선하기 위해 조회 API에 캐싱을 적용하고, 대기열 로직을 Redis로 이관하는 과정을 정리해 보았습니다. 캐싱을 통해 반복적인 조회 요청의 성능을 개선하고, Redis를 활용하여 대기열 로직의 실시간 성능을 향상시킬 수 있었습니다. 이번 과정을 통해 캐싱을 적용하는 기준과 Redis를 활용한 성능 최적화 기법을 토대로 추후에 실무에 적용해 볼 수 있을 것 같습니다.