Caching 도입 기술 선정 관련 비교

구분	Redis	Memcached
범용성	높음 (올인원)	낮음 (단일 목적)
성능	다양한 기능 + 빠름	초경량 + 매우 빠름
확장성	클러스터, HA 지원	단순 분산 (client-side)
데이터 유지	영속 가능(AOF, RDB)	휘발성 전용
지원 데이터 타입	hash, set, list, string 등	only string

• Redis는 Memcached와 다르게 다양한 데이터 타입을 넣을 수 있음(Memcached : only String)
• 장애상황에 유연한 대응 가능
  • AOF, RDB 스냅샷을 통하여 failback 가능(인메모리지만 준영속화)
  • Replication을 통하여 failover 가능 ** 결론 : 캐싱 도구로 Redis 사용**

현 시점 캐싱 없이 예상되는 문제 및 예상 해결 시나리오

모든 api의 캐싱전략은 다음 두 조건에 대해 실험 후 최종 결정 예정

• 조건 1) 데이터 등록 시 캐시 삭제 후 다시 DB 조회 시 캐싱
• 조건 2) 데이터 등록 시 캐시값을 동적으로 수정

앨범 조회 관련 api

1. 메인페이지(/api/album/monthly?yearMonth=)

• 문제 : 메인페이지로 가장 많은 조회가 예상됨.
• 해결 : 연산 속도가 낮을걸로 예상되는 hasNext나 nextYearMonth는 캐싱하지 않고 앨범 리스트를 캐싱

통계 관련 api

1. 유저 전체 생산 album 수 조회(/api/user/statistics)

• 문제 : 메인페이지에 보여지는 데이터들로 가장 많은 조회 예상, 현재 사용되는 response 데이터 중 AlbumCount는 userAlbumRepository에서 user에 따라 count하는 방식
• 해결 : user별로 album 수를 미리 카운트하여 캐싱 후 캐싱된 것이 있는지 먼저 조회, 앨범 추가 생성 시 캐싱전략은 실험을 통해 결정

2. 월단위 유저 일간 사진 등록 개수(/api/user/statistics/picture?yearMonth={yearMonth})

• 문제 : 일간 등록 사진을 조회하기 위해서 picture과 user의 join이 잦고 Date에 대해 비교가 잦아서 조회 시 성능 저하
• 해결 : 유저별로 일간 사진 개수를 맵 형태로 캐싱하여 저장하되 최신 월이 아니라면 삭제, 사진 추가 시 캐싱전략은 실험을 통해 결정
  • 다만 해당 지표는 유저 상세페이지에 진입해야 볼 수 있는 데이터로 상대적으로 호출이 적을 것으로 예상됨에 따라 TTL을 짧게 설정 예

3. 월단위 유저 태그 등록 개수(/api/user/statistics/tag?yearMonth={yearMonth})

• 문제 : 월별 유저 최다기록 태그와 사진을 조회하기 위해서 picture, user join이 잦고, 해당 태그별로 가장 많이 등록된 사진 4개를 리턴해야 하기 때문에 연산이 많음
• 해결 : 각 유저별 월간 최다기록 태그와 그에 따른 사진 4개를 캐싱하여 저장. 사진 추가 시 캐싱전략은 실험을 통해 결정
  • 다만 해당 지표는 유저 상세페이지에 진입해야 볼 수 있는 데이터로 상대적으로 호출이 적을 것으로 예상됨에 따라 TTL을 짧게 설정 예정

측정 도구 및 지표, 예상 부하테스트 시나리오

측정 도구, 환경

• 도구 : k6 선정
  • js로 간단한 시나리오 구축 가능, 터미널로 js 실행 시 로컬에서 대시보드 확인 가능
  • 인덱스 성능 테스트 시 이미 사용한 경험 있음. 러닝커브 적음
• 환경 : localhost
  • 캐싱 성능측정이므로 인스턴스 대상 부하테스트와 크게 관련없을 것으로 예상
  • 캐싱 전략 채택 후 dev 환경 대상 부하테스트 예정(클라우드와 상의 필요)

측정 시나리오 및 체크리스트

점진적 Ramp up, 일정 시간 Plateau, 점진적 Ramp down

모든 시나리오는 90% 확률로 GET, 10% 확률로 POST하여 캐싱 무효화 전략도 테스트 예정 Ramp up : 1분, 목표 VUs 2000(초당 약 33명 사용자 추가) Plateau : 1분, VUs 2000유지 Ramp down : 1분, 목표 VUs 0(초당 약 33명 사용자 감소)

• 서비스 사용자가 부족한 현 시점에서 실제와 같은 시나리오 설계 불가로 가상의 시나리오 채택
• 핫딜과 같이 많은 사람들이 급격히 몰리는 시스템이 아니므로 VUs 급격히 증가하는 시나리오는 미채택
• 명확한 성능상 차이를 확인하기 위해 의도적으로 VUs 높게 설정

체크리스트 및 향후 실행 예정 목록

현시점 체크리스트

• TTL 전략, key 네이밍 전략 구상
• 캐싱 전 부하테스트 실시(쿼리 발행 개수 확인)
• 캐싱전략 수립 후 부하테스트 실시

향후 과제

• FailOver 시 복구전략, HA 공부 및 적용(AOF, RDB, 클러스터링, 샤딩 등) => 클라우드 담당과 논의 후 진행