본 보고서는 콘서트 예약 시스템에 캐시를 적용하기 위한 보고서입니다. 캐시를 활용하여 데이터베이스 부하를 줄이고, 높은 트래픽 상황에서도 빠른 응답을 제공함으로써 사용자 경험을 개선하고자 합니다. 기타 캐시 적용 이점과, 도입하려는 전략에 대해서는 이전보고서인 RedisCacheStrategy.md 를 참고 부탁드립니다.

콘서트 예약 시스템은 다수의 사용자가 동시에 접속하여 실시간으로 좌석 정보를 조회하고 예약을 진행하는 서비스입니다. 특히 인기 콘서트의 예매 시작 지점에는 트래픽이 급증하여 데이터베이스에 과부하가 발생할 수 있습니다. 이는 시스템 장애로 이어질 수 있습니다. 따라서 캐시를 활용하여 데이터베이스의 부하를 분산시키고, 빠른 응답을 제공하여 시스템 안정성을 높이고자 합니다.

1. 캐시 크기 관리
   • 모든 콘서트 일정을 캐시하면 시간이 지날수록 과거의 콘서트 데이터가 쌓여 캐시 크기가 비대해질 수 있습니다.
   • 적절한 캐시 크기를 선택하고 관리 방안을 마련해야 합니다.
2. 불필요한 데이터 캐싱 방지
   • 예약이 종료된 콘서트는 호출 빈도가 낮습니다. 따라서 캐시에 남아 있다면 메모리 낭비가 될 수 있습니다.
   • **TTL(Time To Live)**을 적절히 설정하여 일정 시간이 니자면 캐시에서 제거되도록 합니다.
3. 데이터 일관성 유지
   • 좌석이나 콘서트 정보가 변경되었을 때 캐시와 데이터베이스 간의 데이터 불일치가 발생하지 않도록 해야합니다.
   • 데이터 변경 시 캐시를 무효화하거나 갱신하는 전략이 필요합니다.

---

• 해당 일정은 빈번하게 수정되지 않으며, 예매일에 많은 트래픽이 발생할 수 있습니다.
• 캐시를 적용하면 데이터베이스 부하를 줄이고 빠른 응답을 제공하여 더 나은 사용자 경험을 제공할 수 있습니다.

• 캐시 장애시 안정성을 보장 : 캐시와 DB가 분리되어 있어 캐시 장애시에도 DB 에서 데이터를 조회하여 운영이 가능합니다.

• 캐시 히트율 향상 : 예매일에 캐시 미스로 인한 성능 저하를 방지하기 위해 예약 시작 전에 콘서트 및 좌석 정보를 미리 캐시에 로딩합니다.

• TTL 설정 : 데이터 최신성을 보장하기 위해 캐시의 TTL을 1주일로 설정합니다.
• 캐시 무효화 : 데이터 변경 시 즉시 해당 캐시를 삭제 또는 갱신하여 일관된 정보를 제공합니다 (미구현)

본 전략을 통해 사용자에게 빠르고 안정적인 예약 서비스를 제공할 수 있을 것으로 기대합니다.

--

• 테스트 대상 API: /api/seats
• 데이터량: Seat 데이터 50개
• 테스트 도구: Postman
• 테스트 방법:
  • 캐시 초기화 후 첫 번째 요청으로 캐시 미스(Cache Miss) 상태에서의 응답 시간 측정
  • 이후 동일한 요청을 여러 번 보내어 캐시 히트(Cache Hit) 상태에서의 응답 시간 측정
  • 부하 테스트는 진행하지 않고, 간단한 요청을 통해 캐시 적용의 기본적인 성능 향상 효과를 확인하였습니다.

• Cache Miss 시 응답 시간: 데이터베이스 조회에 따른 수백 밀리초의 응답 시간이 예상됩니다.
• Cache Hit 시 응답 시간: 메모리에서 데이터를 가져오기 때문에 데이터 베이스 조회보다 두 배 이상의 성능 향상을 기대합니다.
• 성능 개선 기대치 : 캐시 적용으로 약 50% 이상의 응답 시간 감소를 기대합니다.

테스트 결과

요청 회차	캐시 상태	응답 시간(ms)
1	Cache Miss	496
2	Cache Hit	9
3	Cache Hit	13
4	Cache Hit	19
5	Cache Hit	8

• 추가 테스트: 캐시 초기화 후 재요청 시에도 60~80ms의 응답 시간을 확인하여, 첫 번째 요청의 응답 시간이 항상 일정하지 않을 수 있음을 고려해야합니다.

• Cache Miss

• Cache Hit

1. 응답 시간 감소 효과
   • 캐시 적용 전(Cache Miss)의 응답 시간은 평균 496ms였으나, 캐시 적용 후(Cache Hit)에는 평균 12ms로 약 98%의 성능 향상을 확인했습니다.
2. 데이터량 증가 시 효과:
   • 데이터베이스는 데이터량이 증가할수록 조회 시간이 늘어납니다.
   • 캐시는 메모리에서 데이터를 조회하므로 데이터량 증가에 따른 응답 시간 변화가 적습니다.
   • 따라서 데이터량이 많아질수록 캐시의 이점은 더욱 커집니다.

• 간단한 테스트 선택 이유

  • 본 테스트는 캐시 적용의 기본적인 성능 개선 효과를 확인하기 위한 것으로, 부하 테스트를 진행하지 않고 간단한 요청을 통해 측정하였습니다.
  • 이는 초기 단계에서 캐시의 효용성을 파악하기 위한 적절한 접근이었다고 판단됩니다.

• 추후 보완성 :

  • 실제 서비스 환경에서는 대규모 트래픽 상황을 고려한 부하 테스트를 통해 캐시의 성능을 테스트 해볼 필요가 있습니다.

---

• 메모리 사용량 추정:

  • 좌석 데이터(각 키)의 평균 메모리 사용량: 약 1,344바이트
  • 콘서트 정보(각 키)의 평균 메모리 사용량: 약 512바이트

• 콘서트 일정 수: 예를 들어 100개의 콘서트 일정이 있다고 가정

  • 51,200바이트 (100개 × 512바이트) + 134,400바이트 (100개 × 1,344바이트) * 10% (오버헤드)
  • 204,160바이트 (약 200KB)

시스템 자원 측면에서 큰 부담이 없는 수준이며, 향후 콘서트 수 증가에 따라 캐시 정책을 조정하면 됩니다.

• 관리 방안:
  • TTL 조정: 캐시 데이터의 생존 시간을 조정하여 불필요한 메모리 사용을 방지합니다.
  • LRU 알고리즘 활용: Least Recently Used 정책을 통해 사용 빈도가 낮은 데이터를 자동으로 제거합니다.

---

캐시를 적용함으로써 콘서트 예약 시스템의 응답 시간이 크게 개선되었으며, 이는 사용자 경험 향상과 시스템 안정성 확보에 긍정적인 영향을 미칩니다.

1. 부하 테스트 수행: 실제 트래픽 상황을 가정한 부하 테스트로 캐시의 성능과 안정성을 검증합니다.
2. 캐시 정책 최적화: 데이터 사용 패턴을 분석하여 TTL 및 캐시 관리 전략을 최적화합니다.

본 보고서는 캐시 적용의 효과와 그 구현 방법에 대해 정리하였으며, 간단한 테스트를 통해 성능 향상을 확인하였습니다. 해당 보고서는 로컬에서 진행된 사항이라, 실제 트래픽 상황에서는 다르게 작동할 수 있습니다.