그쪽도 홍박사(Redis)님을 아세요? (1)

이번에 정리한 내용은 팀 문화 중 하나인 지식 공유 시간에 Redis에 대해 간략하게 발표한 자료입니다. 

 

[서론]

• 레디스(Redis)를 설명하기에 앞서 캐시(Cache)에 대해서 먼저 간단하게 설명하고자 합니다.

범용성 있게 일반적으로 3 tier Architecture의 구조 채택

• Client
• Server
• DataBase

이러한 계층형 구조를 Layerd Architecture(레이어드 아키텍쳐 / 계층형 아키텍쳐 ) 라고 칭함

 

그러나!!!

 

윗 구조에서는 명확한 한계점이 존재!

바로 서비스가 폭발적으로 성장해 사용자가 많아지고, 실시간으로 요청하는 API 수가 많아짐에 따라 서비스의 부하가 상승하는 경우

우리는 아키텍쳐를 분리하거나 캐싱이라는 기능을 사용해 서비스 어플리케이션에서 발생하는 성능의 문제를 해결할 수 있음

What is Caching?

• 캐싱 (Caching)
  • 설명
    • 데이터의 원래 소스보다 더 빠르고 효율적으로 데이터를 엑세스 할 수 있는 임시 데이터 저장소
    • 우리가 평소에 많이 사용하는 JPA의 영속성 컨텍스트(Persistent Context)도 캐싱 기능을 사용
  • Cache Hit
    • 서비스 어플리케이션에서 원하는 데이터를 캐시에서 조회 했을 때 존재하면 해당 데이터를 바로 반환
  • Cache Miss
    • 캐시에 데이터가 존재하지 않아 DB를 통해 데이터를 찾아와서 반환

캐싱의 가장 중요한 포인트는 동일한 데이터에 대해 반복적으로 접근해야 할 때!

즉, 데이터에 관한 액세스가 한 번 이상일 때 의미있는 데이터라는 점!

(번외로 잘 변하지 않는 데이터에 캐싱이라는 방법을 적용하면 더욱 효과적으로 사용 가능)

데이터 베이스와 함께 사용한다면 정합성 문제를 잘 고려해야한다는 점!

유실되어도 크게 문제가 없는 데이터에 캐싱 기능을 젹용한다면 더욱 좋다는 점!

• 이러한 캐싱 기능을 지원하는데 딱 알맞은 저장소가 바로 Redis(레디스)

(물론 레디스가 캐싱뿐만 아니라 실시간 채팅, 메시지 브로커, 임시 작업 큐 등 다양한 역할 소화 쌉가능!)

Redis

선생님 Redis가 뭔가요?

• 레디스(Redis)는 key-value의 단순한 구조
  • 어떤 데이터도 쉽게 저장이 가능
• In-memory 데이터 저장소(RAM)
  • 이는 굉장히 빠르다를 의미!
• 빠른 성능
  • 평균 작업 속도 < 1m
  • 초당 수백만 건의 작업 가능
• 싱글 스레드
  • 한번에 하나씩의 명령만 처리해서 Race Condition이 거의 발생하지 않음

[ 캐싱 전략(Caching Strategies)]

읽기 전략

• Look Aside(Lazy Loading)
  • 캐시에 데이터가 없을 때 → DB를 조회해서 데이터를 읽어오는 전략
  • 장점
    • 캐시에 문제가 발생하면 DB로 요청을 위임 가능
    • 레디스가 죽더라도 DB에서 데이터를 가지고 올 수있어 서비스 장애를 막을 수 있음
  • 단점
    • 캐시와 DB 사이의 데이터 정합성 유지에 어려움
    • 첫 조회 시 DB 부하 발생
  • 예시
    • 사용자의 요청 → 서비스 어플리케이션 → 원하는 데이터를 캐시에서 가지고 옴(데이터가 있다면) → 데이터가 없다면 aside를 봄(DB에서 데이터를 가지고 옴) → 앞서 DB에서 가지고 온 데이터를 캐시에 올려서 사용
  이러한 상황에서 여러 개의 커넥션이 한번에 DB에 붙을 수도 있어 부하가 발생할 수 있기에 DB에서 레디스(Redis)로 미리 데이터를 밀어는 전략을 가지고 가야함
• 이를 Cache Warming 이라고 함
• Read Through
  • 항상 캐시를 통해서 읽는 전략
  • 장점
    • 항상 데이터의 정합성이 보장됨
  • 단점
    • 캐시가 죽어버리면 서비스 어플리케이션도 죽을 수 있음
  • 예시
    • 사용자의 요청 → 서비스 어플리케이션 → 원하는 데이터를 캐시에서 가지고 옴(데이터가 있다면) → 데이터가 없다면 Redis가 DB로부터 데이터를 직접 가지고 온 다음 그 데이터를 서비스 어플리케이션이 사용함

쓰기 전략

• Write - Around
  • 모든 데이터를 DB에만 데이터를 저장
  • Cache Miss가 발생한 경우에만 Redis에서 데이터를 가지고 옴
  • 장점
    • 성능이 매우 좋음 (DB자원을 바로 써서)
    • 불필요한 데이터를 캐시에 올리지 않기에 리소스를 아낄 수 있음
  • 단점
    • Redis와 DB의 데이터 정합성이 안맞을 수 있음
• Write - Through
  • Redis와 DB에 모두 데이터를 저장
    • 장점
      • 캐시의 데이터는 항상 최신 데이터!
    • 단점
      • 데이터에 관한 저장을 두 곳이나 관리해야하는 점 ! (상대적으로 느림)
      • 저장한 데이터가 사용되지 않을 수 있음 (리소스 낭비)
  • 그래서 해당 전략을 사용할 때 Expired Time을 줘서 관리를 하게 되는데, 이 부분이 장애 포인트가 될 수도 있음

[ Redis는 자체적으로 다양한 자료 구조를 제공 ]

• Strings
  • 가장 기본적인 데이터 타입
  • SET 명령어로 데이터 넣으면 다 Strings 타입
• Bitmaps
  • Strings의 변형으로 bit 단위로 데이터 저장
• Lists
  • 데이터를 순서대로 저장, Queue로 사용하기 적절
• Hashes
  • 하나의 키 내부에 또 다시 여러개의 필드와 값을 저장
• Sets
  • 중복되지 않은 문자열의 집합
• Sorted Sets
  • set처럼 중복되지 않은 문자열을 저장하지만 모든 값은 스코어(Score)라는 숫자값으로 정렬
  • 데이터가 저장될 때부터 score 순으로 정렬되며 만약에 score가 겹치면 사전순으로 저장
• HyperLogLogs
  • 중복되지 않는 값의 개수를 카운트 할 때 사용
• Streams
  • 로그를 저장하기 가장 좋은 자료구조