Redis 를 어디에 쓸까

Redis필요한 곳

• 캐시 
• In menory  를 DB로 사용하는곳
• Ranking 저장용
  • Ex) 게임 랭킹에 맞춰 게임을 매치, 실시간으로 변경되는 랭킹 순
• Job Queue
  • Rabbit MQ, Kafka

사용 예

• Cache: Web API 의 요청을 Key 로 응답을 Value 에 저장
• 서비스의 Access Token 저장
• 요청 수 제한을 위한 Rate Limit
• Ranking 저장을 위한 Ranking 스코어 보드

 

캐시

• 같은 요청에 대해 같은 결과를 제공 할 때, 작업에 대한 결과를 계산해 두었다가 재요청이 오면 계산 없이 바로 돌려주는 것
  • ex) 이미 봤던 페이지를 DB 접근 없이바로 볼 수 있다.
• Reduces the distance from Resource 사용할 리소스와의 거리를 줄여준다.
• 캐시가 유용한 케이스
  • 적은 데이터가 빈번하게 접근 될 때 유용 = 특정 데이터만
• DB에 요청을 줄일 수 있어 성능 향상 가능. 

In memory 

• 장점
  • 접근 속도가 빠르다. SSD, HDD를 쓰는 것보다 속도가 빠름.
• 단점
  • 다른 스토리지에 비해 저장 용량이 작고 비싸다.
    • SSD 와 대략 20배 이상 차이가 난다.

성능이 중요할 때 사용한다.

파레토의 법칙에 의하면, 20%의 유저들이 80% 활동을 하기에 20% 를 캐시하면 서비스 대부분의 데이터를 커버할 수 있다.

 

어디에 캐시를 쓸까?

• ex) API 응답

고민해야 할 것

• 캐시를 적용해도 되는 API 인지
  • 자주 바뀌는 값은 안하는게 좋다.
  • 쓰기 API 는 캐시를 적용하는 것이 애매하다
  • 읽기 API 가 유리하다.
    • 읽기용이라 쓰기가 하나도 발생하지 않나?
• Key는 어떻게 정의할 것인지
  • Key 는 데이터를 구분하는 유일한 값이므로 Key 값은 유일해야 한다.
  • 유니크한 키 값을 만들어줘야 한다.
    • userId, age, date 등등 
  • Access Token를 캐시 한다면,  Access Token자체가 유효하므로 특별하게 정보를 추가하지 않아도 된다.
  • prefix를 추가하는 것이 좋다.
• Value 는 어떻게 정의할 것인지
  • 두가지 전략이 있다
    • 응답결과를 그대로 저장한다. 
      • 응답 결과가 항상 바뀌는 값이 없다면, 그대로 저장 가능하다
    • 실제 데이터 부분만 저장
      • 응답 결과의 일부분이 바뀌어야 한다면, DB에 저장된 데이터를 저장하고, 이를 토대로 응답을 새로 만든다.
    • user의 정보를 캐시 한다면: User Id,User 권한 
    • cache 사용 예시
      • 서비스에서 매번 로그인 하는 것을 피하기 위해 Access Token을 사용한다.
        • Access Token은 유효 기간이 존재하므로, 탈취 되어도 일정 시간 이후엔 사용 할 수 없다.
      • 보통 Access Token에 대응하는 유저 정보가 DB에 존제한다.
      • JWT 의 경우에는 해당 키가 유용한지 여부만 저장하고, 실제 유저 정보는 JWT 안에 저장하는 경우가 많다.
  • Rate Limit 사용 예시
    • 오픈 API 나 외부 특정  API 를 제공하는 서비스의 경우, 시간당 몇 회 호출, 하루 호출 수 제한을 걸어두는데 이를 구현하는데도 Redis가 많이 사용된다.
  • Rate Limit 사용 하는 이유?
    • 과도한 트래픽으로부터 서비스를 보호
    • Resource 사용에 대한 공정성과 합리성 유도
    • 트래픽 비용이 서비스 예산을 넘는 것을 방지
    • Rate 에 대해 과금을 부과하는  Business model로 활용
  • Rate Limit 의 키를 어떻게 정의해야할까
    • 특정 기간에 N회라는 제한.
    • N회는 지속적으로 바뀌는 값이므로, key 에 반영되기 어려움.
    • API 가 여러개라면 API 종류 값이 들어가야함
      • ex) api.maps
    • 유저별로 개수 제한이 존재하므로 user id가 필요함
      • api:maps:1234
    • 그런데 중요한 특정 기간의 정보가 필요함
      • 고려할 점
        • 5분마다 10회라고 한다면, 이 5분을 연속적5분으로 볼 것인가? 아니라면 0~5 분, 5분 00초 부터 10분까지로 볼 것인가 에 따라 구현 방식이 달라진다.
          • 참고: 서비스 가용성 확보에 필요한 Rate Limiting Algorithm에 대해 | Mimul Tech log
        •  시간이라는 정보는 계속 바뀌지만, 해당 시간이라는 정보는 바뀌지 않음.
          • 5분마다 N회를 위해 매분마다 호출 회수를 기록함
          • api:maps:1234:20240110 <- YYYYmmddHHMM
          • 현재 시간에서 이전 5분 데이터를 가져와 개수를 세어보는 것으로 처리 가능
            • 2024년 1월 10일 12시 9분 에 접속히면 5개의 key를 가져온다
    • Rate Limit value 는 어떻게?
      • 호출 회수만 저장하면 된다.