Refactor/#151/use ehcache to improve performance(swm 426)

[D-w-nJ]

Motivation 🤔

• Ehcache를 사용하여 중복되어 사용되는 데이터를 캐시하여 백엔드 리소스와 latency를 줄입니다.

Key changes ✅

• 기존 컨텐츠 검색에는 1시간 이내로 업데이트 되어 db에 저장된 영상/재생목록 데이터가 아닌 경우(거의 100%) youtube data api를 호출하여 데이터를 받아왔습니다. 이때 비슷한 키워드로 검색하여 같은 컨텐츠가 포함되거나 다른 멤버가 같은 키워드로 검색하더라도 모든 컨텐츠에 대해 중복된 3rd-party API(youtube data api)가 사용되었습니다.
  • Ehcache를 사용해 같은 영상/재생목록이 조회되어 getRecentVideo(String videoCode), getRecentPlaylist(String playlistCode) 메서드가 호출될 경우 1시간동아 메모리에 저장되어 같은 영상/재생목록이 조회될 경우 이를 반환합니다.

TPS(trasactions per second) 측정이 가능한 ngrinder를 사용해 테스트를 먼저 진행

• 설정
  • 가상유저 (Vuser) : 10명
  • 테스트 시간 : 20초
  • timeToLiveSeconds (캐시된 데이터가 메모리에 남아있는 시간) : 10초
  • 타겟 API : /api/ehcache/video/{videoCode} (영상 정보를 불러오는 API, 캐시되지 않은 데이터라면 youtube data api사용 메서드를 호출한다.)
• 수행 결과
  
  • 평균 response time : 1.55ms
    • youtube data api를 사용했을 때, 평균 latency가 200ms이므로 속도가 100배 빨라졌다 (물론 캐시된 데이터를 사용하므로 그럴수밖에 없습니다.)
  • 82,000 가량의 api 호출이 있었고, 기존 방식이라면 82,000번 모두 youtube data api가 사용되었겠지만, Ehcache를 통해 총 11번의 외부 api 호출로 줄일 수 있었다 (영상 정보를 받아오기까지는 메모리에 저장되지 않았기 때문에 다수 호출되었고, 10초후 메모리에 해당 정보가 삭제되었기 때문에 다시 6번 가량 호출되었다)

Sroom에서의 Ehcache 사용 전략

• 사용 메서드 : getRecentVideo(String videoCode), getRecentPlaylist(String playlistCode)
  • 조회된 영상/재생목록 정보를 또다시 youtube data api를 호출하여 불러오는 것을 방지
• maxElementsInMemory : 100,000
  • 백엔드 컨테이너의 사용 가능한 메모리는 1400 MB
  • 영상 1개에 약 1000byte, 재생목록 1개에 약 700byte로, maxElementsInMemory을 각각 100,000으로 설정한다면 약100mb, 60mb 를 사용하게 된다.
• timeToLiveSeconds : 3600 (1시간)
  • 스룸에서 설정한 영상/재생목록의 업데이트 주기는 1시간이므로, 이와 동일하게 가져간다.
• memoryStoreEvictionPolicy : LRU
  • 알려져있는 LFU(Least Frequently Used) 를 쓰지 않은 이유 : LFU의 경우 가장 최근에 들어간 정보가 frequency가 낮기 때문에 먼저 eviction 될 가능성이 높다. 하지만 영상 컨텐츠는 최근 검색될수록 다시 검색될 확률이 높다고 보기 때문에 이 알고리즘을 배제하였다.
• overflowToDisk : false
  • 메모리 한계를 초과한다면 eviction 알고리즘을 사용하여 지우고, 디스크에 저장하지는 않는다.

성능

• /lectures?keyword=() API(키워드 검색) 테스트
  • 캐시를 사용하지 않는 기존 방식의 API 호출 latency : 1000~2000 ms (하단의 api 호출은 1600ms를 보임)
    
  • 검색된 모든 영상/재생목록 정보가 캐시되고, 다시 API 를 호출하면 다음과 같이 latency가 기존의 40%로 줄어든 것을 볼 수 있음 (하단의 api 호출은 700ms를 보임)
    

To reviewers 🙏

• 캐시 사용의 시나리오는 다음과 같습니다. 가능하시면 해당 시나리오대로 테스트서버에서 검색 또는 상세검색 해보시고 유의미한 성능 변화가 있는지 확인해주세요
  • 사용자가 비슷한 키워드로 다수 검색할 때, 제공되는 컨텐츠 중 일부가 중복 (스프링부트 검색 이후 자바스프링 검색)
  • 1시간 이내 다른 멤버가 검색한 키워드를 다른 멤버가 검색하는 경우
  • 재생목록 상세조회로 재생목록의 모든 영상 정보를 조회하고, 해당 재생목록 또는 유튜버를 검색할 시 제공되는 영상정보가 중복
• 캐시사용이 가능한(필요한) 메서드를 말씀해주세요 (다음으로 캐시를 시도할 메서드는 RecommendationService.getGeneralRecommends() 입니다.