제가 공부한 내용을 정리하는 블로그입니다.
아직 많이 부족하고 배울게 너무나도 많습니다. 틀린내용이 있으면 언제나 가감없이 말씀해주시면 감사하겠습니다😁

데이터의 영속성

  • 레디스는 스냅샷 기능을 제공하여 메모리의 내용을 .rdb 파일로 저장. 해당 시점으로 복구 가능.

기본-복제 아키텍처를 제공(복구 기능 및 확장)

  • 기본-복제 아키텍처를 사용하여 비동기식 복제를 지원하여 데이터가 여러 복제 서버에 복제 될 수 있음.
  • 따라서 main 서버가 장애가 발생하는 경우 요청이 여러 서버로 분산될 수 있음으로 향상된 읽기 성능과 더 빠른 복구 기능 사용.
  • scalue-up, scale-in, scale-out을 제공하여 클러스터를 확장하여 일관된 성능과 안정성을 제공.

Single Thread

레디스는 싱글 스레드 아키텍처를 사용. ⇒ 한번의 1개의 명령어만 실행

  • Memcached는 멀티 스레드 지원.
  • 하나의 요청이 병목이 되면 그 다음 요청이 계속 blocking 상태이므로 O(n)의 시간복잡도를 보여줌.
    • O(n)의 시간복잡도를 갖는 명령어: Keys, flushall, FLUSHDB, Delte COLLECTIONS, Get All COLLECTIONS
  • Event Loop를 이용하여 요청을 수행
    • 실제 명령에 대한 작업은 커널 IO 레벨에서 멀티플렉싱을 통해 처리하여 동시성을 보장.
    • 커널 IO에서는 스레드 풀을 이용

Redis에서의 CRUD

READ

  • 레디스 서버에서 사용자가 요청한 데이터가 있는지 확인.
  • 데이터가 존재하는 경우.
    • 만료 여부를 확인.
    • 정보 반환
  • 데이터가 만료되었거나 존재하지 않는 경우
    • 데이터가 만료되었을 경우, 데이터 삭제.
    • 메인서버에 요청.
    • 메인 서버로부터 받은 데이터를 캐싱 및 DB에 저장한 후 데이터를 반환 후 종료

CUD

  • 데이터에 변화가 생겼으므로 해당하는 값은 캐싱된 데이터가 아닌 실시간 정보를 보내주어야 함.
  • 방문자의 CUD를 메인 서버에 요청.
  • 메인 서버는 요청받은 CUD를 처리하고 업데이트
  • 변경되기 이전의 데이터 값은 레디스 서버에서 찾아서 삭제 후 종료.

Redis 캐싱전략

웹 서비스 환경에서 시스템 성능 향상을 기대하는 기술 일반적으로 캐시는 메모리(RAM)을 사용하기에 DB보다
훨씬 빠르게 데이터를 응답할 수 있어서 이용자에게 빠르게 서비스를 제공 가능

하지만 기본적으로 RAM 용량은 16~32G 정도라, 데이터를 모두 캐시에 저장해버리면 용량 부족 현상이 일어나 시스템이 다운 될 수 있기에 어느 종류의 데이터를 캐시에 저장할지, 얼만큼의 데이터를 캐시에 저장할지, 얼마동안 오래된 데이터를 캐시에서 제거하는지에 대한 전략이 필요.

캐시 읽기 전략

Look Aside (Lazy Loding)

캐시를 옆에 두고 필요할 때만 데이터를 캐시에 로드하는 전략

 

Look Aside Diagram

  • Cache Aside 패턴이라고 부르기도 함.
  • 데이터를 찾을 때 우선적으로 캐시를 확인하는 법
    • 없으면 DB에서 조회.
  • 반복적인 읽기가 많은 시스템에서 적합
  • 캐시와 DB가 분리되어 가용되기 때문에
    • 원하는 데이터만 별도로 구성하여 캐시에 저장
    • 캐시 장애 대비 구성이 되어 있음.
      • 캐시(Redis)가 다운되더라도 DB에서 데이터를 가져올 수 있어, 서비스에 큰 장애는 없음.
  • Cache Store와 Data Store(DB) 간 데이터 정합성 문제가 발생할 수 있음
    • DB에서 캐시로 데이터를 미리 넣어주는 작업을 진행하기도 함. => Cache Warming
💡 Cache Warming
미리 Cache로부터 DB의 데이터를 밀어 넣어두는 작업을 의미.
이 작업을 수행하지 않으면 서비스 초기에 트래픽 급증 시 대량의 cache miss가 발생하여 데이터베이스 부하가 급증할 수 있음.(Thundering Herd)
다만, 캐시 자체는 용량이 작아 무한정으로 데이터를 들고 있을 수는 없어 일정 시간이 지나면 expire 되는데, 그러면 다시 Thundering Herd가 발생될 수 있기 때문에 캐시의 TTL을 잘 조정할 필요가 있음.

 

  • flow
    • cache hit
      • 어플리케이션에서 레디스로 데이터를 읽어옴
    • cache miss
      • 데이터베이스에 데이터 요청
      • 데이터를 데이터베이스에 저장.
  • 장점
    • 데이터 접근 시간을 줄임.
    • 처리량을 늘림

Read Through 패턴

캐시에서만 데이터를 읽어오는 전략(inline cache)

Read Through

  • Look Aside와 비슷하지만 데이터 동기화를 라이브러리 또는 캐시 제공자에게 위임하는 방식
  • 데이터를 조회하는데에 있어 속도가 느림
  • 데이터 조회를 캐시에만 의존하므로, Redis가 다운될 경우 서비스 이용에 차질.
  • 캐시와 DB 간의 데이터 동기화가 이루어져 데이터 정합성은 항상 일치
  • 읽기가 많은 서비스에 적합
  • flow
    • cache Store에 검색하는 데이터가 있는지
    • cache hit
      • 데이터 반환
    • cache miss
      • 캐시에서 DB에 데이터를 조회
      • 캐시를 업데이트
      • 데이터 반환
  • 장점
    • 직접적인 데이터베이스의 접근을 최소화
    • 데이터 정합성 일치
    • read에 소모되는 자원 최소화
  • 캐시가 문제가 발생했을 때 서비스에 차질이 있을 수 있으므로 Replication 또는 Cluster로 구성해서 가용성을 높여야 한다.

캐시 쓰기 전략

Write Back 패턴

Write Behind 패턴으로 부르기도 함
캐시와 DB 동기화를 비동기적으로.

Write Back

  • 캐시와 DB 동기화를 비동기적으로 관리하기에 동기화 과정이 생략
  • 데이터를 저장할 때 DB에 바로 쿼리하지 않고, 캐시에 모아서 일정 주기 배치 작업을 통해 DB에 반영
  • 캐시에 모아놨다가 DB에 쓰기 때문에 쓰기 쿼리 회수 비용과 부하를 줄일 수 있음.
  • Write가 빈번하면서 Read 하는데 많은 양의 Resource가 소모되는 서비스에 적합.
  • 데이터 정합성 확보
  • 자주 사용되지 않는 불필요한 리소스 저장.
  • 캐시에서 오류가 발생하면 데이터를 영구 손실.
  • flow
    • 모든 데이터를 Cache Store에 저장
    • 일정 시간이 지난 뒤 DB에 저장
  • 캐시가 일종의 Queue의 역할을 겸하게 됨.
  • 장점
    • DB 쓰기 횟수 비용과 부하를 줄일 수 있음
      • 캐시에 데이터를 모았다가 한번에 DB에 저장하기 때문에
    • 데이터베이스에 장애가 발생하더라도 지속적인 서비스를 제공할 수 있도록 보장 가능
  • Replication이나 Cluster 구조를 적용함으로써 cache 서비스의 가용성을 높이는 것이 좋고
  • Read-Through와 결합하면 가장 최근에 업데이트된 데이터를 항상 캐시에서 사용할 수 있는 혼합 워크로드에 적합.

Write Through 패턴

데이터베이스와 Cache에 동시에 데이터를 저장하는 전략.
Cache Store에도 반영하고 Data Store에 동시에 반영하는 방식

Write Through 패턴

  • 데이터를 저장할 때 먼저 캐시에 저장한 다음 바로 DB에 저장.(모아놓았다가 나중에 저장이 아닌 바로 저장)
  • Read Through와 마찬가지로 DB 동기화 작업을 캐시에게 위임.
  • DB와 캐시가 항상 동기화가 되어 있어, 캐시의 데이터는 항상 최신으로 유지
    • 데이터의 일관성을 유지할 수 있어서 안정적
  • 데이터의 유실이 발생하면 안되는 상황에 적합
  • 자주 사용되지 않는 불필요한 리소스 저장
  • 매 요청마다 두번의 Write가 발생하게 됨으로써 빈번한 생성 및 수정이 발생하는 서비스에서는 성능 이슈 발생
  • 기억장치 속도가 느릴경우, 데이터를 기록할 때 CPU가 대기하는 시간이 필요하기 때문에 성능 감소.

Write Around 패턴

모든 데이터는 DB에 저장.

Write Around

  • Write Through보다 훨씬 빠름
  • 모든 데이터는 DB에 저장(캐시를 갱신하지 않음)
  • Cache miss가 발생하는 경우에만 DB와 캐시에도 데이터를 저장.
  • 따라서 캐시와 DB내의 데이터가 다를 수 있음(데이터 불일치)

캐시 읽기 + 쓰기 전략 조합

  • Look Aside + Write Around 조합
    • 가장 일반적인 조합
  • Read Through + Write Aound 조합
    • 항상 DB에 쓰고, 캐시에서 읽을때 항상 DB에서 먼저 읽어오므로 데이터 정합성 이슈에 대한 완벽한 안전 장치를 구성할 수 있음.
  • Read Through + Write Through 조합
    • 데이터를 쓸 때 항상 캐시에 먼저 쓰므로 읽어올 때 최신 캐시 데이터 보장
    • 데이터를 쓸 때 항상 캐시에서 DB로 보내므로, 데이터 정합성 보장.

캐시 저장 방침

캐시 솔루션은 자주 사용되면서 자주 변경되지 않는 데이터의 경우 캐시 서버에 적용하여 반영할 경우 높은 성능향상을 이뤄낼 수 있음.
이를 Cache Hit Rating이라고 한다.
  • 캐시는 메모리에 저장되는 형태를 선호
  • 수십기가정도의 저장소를 보유하게 되며, 자주 사용되는 데이터를 어떻게 뽑아 캐시에 저장하고 자주 사용하지 않느 데이터를 어떻게 제거해 나갈 것이냐를 지속적으로 고민해야할 필요성이 있다.
  • 캐시를 저장하는 기준은 자주 사용되며 자주 변경되지 않는 데이터
  • 캐시는 언제든지 데이터가 날라갈 수 있는 휘발성
  • 데이터의 유실 또는 정합성의 문제도 항상 고려

캐시 제거 방침

  • 캐시 데이터의 경우 캐시 서버에만 단독으로 저장되는 경우도 있지만, 대부분 영구 저장소에 저장된 데이터의 복사본으로 동작하는 경우가 많음.
  • 2차 저장소(영구 저장소)에 저장되어 있는 데이터와 캐시 솔루션의 데이터를 동기화하는 작업이 반드시 필요.
    • 개발 과정에 고려사항이 늘어난다는 점을 기억.
  • 캐시 서버와 데이터베이스에 저장되는 데이터의 commit 시점에 대한 고려.
  • 캐시 만료 정책이 제대로 구현되어 있지 않는 경우, 클라이언트의 데이터가 변경되었음에도 오래된 정보가 캐싱되어있어 오래된 정보를 사용할 수 있다는 문제점이 발생.
    • 캐시된 데이터가 기간 만료되면 캐시에서 데이터가 제거되고, 응용 프로그램은 원래 데이터 저장소에서 데이터를 검색해야함.
    • 캐시 만료 주기가 너무 짧으면 데이터는 너무 빨리 제거되고, 캐시를 사용하는 이점이 줄어듦.
    • 반대로 너무 길면 데이터가 변경될 가능성과 메모리 부족 현상이 발생하거나, 자주 사용되어야 하는 데이터가 제거되는 등의 역효과

캐시 공유 방식 지침

  • 각 애플리케이션 인스턴스가 캐시에서 데이터를 읽고 수정 가능.
  • 애플리케이션이 캐시에 보유하는 데이터를 수정해야 하는 경우, 애플리케이션의 한 인스턴스가 만드는 업데이트가 다른 인스턴스가 만든 변경을 덮지 않도록 해야함.
    • 데이터의 정합성 문제
  • 먼저 캐시 데이터를 변경하기 전에 데이터가 검색된 이후 변경되지 않았는지 확인.
    • 변경되지 않았다면 즉시 업데이트.
    • 변경되었다면 업데이트 여부를 애플리케이션 레벨에서 결정하도록 수정
  • 캐시 데이터를 업데이트하기 전에 Lock을 잡는 방식
    • 조회성 업무를 처리하는 서비스에 Lock으로 인한 대기 현상이 발생
    • 데이터의 사이즈가 작아 빠르게 업데이트가 가능한 업무와 빈번한 업데이트가 발생하는 상황에 적용하기 용이.

 

참조

'Database > Redis' 카테고리의 다른 글

[Redis] Redis Data Type  (0) 2024.05.16
[Redis] Redis 기본  (0) 2024.05.10
[Redis] NoSQL이란  (0) 2024.04.30
[OSSCA2024] Redis 과제 3  (0) 2024.04.25

+ Recent posts

티스토리툴바