Redis 활용

Redis를 그럼 한번 활용해볼까?

1. Cache
캐쉬란 한번 조회된 데이터를 미리 특정 공간에 저장해놓고, 똑같은 요청이 발생하게 되면 서버에게 다시 요청하지 말고 저장해놓은 데이터를 제공해서 빠르게 서비스를 제공해주는것을 의미

즉, 미리 결과를 저장하고 나중에 요청이 오면 그 요청에 대해서 DB 또는 API를 참조하지 않고 Cache를 접근하여 요청을 처리하는 기법

  1-0. Look aside Cache 패턴 
         캐시를 한 번 접근하여 데이터가 있는지 판단한 후, 있다면 캐시의 데이터를 사용하고 없으면 실제 DB 또는 API를 호출한다

         Look aside Cache 쿼리순서
         1) 클라이언트에서 데이터 요청
         2) 서버에서 캐시에 데이터 존재 유무 확인
         3) 데이터가 있다면 캐시의 데이터 사용 (빠른조회)
         4) 데이터가 없다면 실제 DB 데이터에 접근
         5) 그리고 DB에서 가져 온 데이터를 캐시에 저장하고 클라이언트에 반환

https://inpa.tistory.com/entry/REDIS-%F0%9F%93%9A-%EA%B0%9C%EB%85%90-%EC%86%8C%EA%B0%9C-%EC%82%AC%EC%9A%A9%EC%B2%98-%EC%BA%90%EC%8B%9C-%EC%84%B8%EC%85%98-%ED%95%9C%EB%88%88%EC%97%90-%EC%8F%99-%EC%A0%95%EB%A6%AC

Cache Miss : 메모리에 찾고자 하는 데이터가 없어서 디스크에 조회 할때
Cache Hit : 메모리에 찾고자 하는 데이터가 있을 때

Look Asdie Cache 패턴은 애플리케이션에서 캐싱을 이용할때 일반적으로 사용되는 기본적인 캐시 전략이다.

이 방식은 캐시에 장애가 발생하더라도 DB에 요청을 전달함으로써 캐시 장애로 인한 서비스 문제는 대비할수 있지만, Cache Store와 Data Store(DB)간 정합성 유지 문제가 발생할 수 있으며, 초기 조회 시 무조건 Data Store를 호출 해야 하므로 단건 호출 빈도가 높은 서비스에 적합하지 않다. 대신 반복적으로 동일 쿼리를 수행하는 서비스에 적합한 아키텍처이다.

이런 경우 DB에서 캐시로 데이터를 미리 넣어주는 작업을 하기도 하는데 이를 Cache Warming이라고 합니다.

[ Cache Warming ]

미리 cache로 db의 데이터를 밀어 넣어두는 작업을 의미한다.
이 작업을 수행하지 않으면 서비스 초기에 트래픽 급증시 대량의 
cache miss 가 발생하여 데이터베이스 부하가 급증 할 수 있다. (Thundering Herd)
다만, 캐시 자체는 용량이 작아 무한정으로 데이터를 들고 있을수는 없어 일정시간이 지나면 
expire되는데, 그러면 다시 Thundering Herd가 발생될 수 있기 때문에 
캐시의 TTL을 잘 조정할 필요가 있다.

 

   1-1. Read Through 패턴

• 캐시에서만 데이터를 읽어오는 전략 (inline cache)
• Look Aside 와 비슷하지만 데이터 동기화를 라이브러리 또는 캐시 제공자에게 위임하는 방식이라는 차이가 있음.
• 따라서 데이터를 조회하는데 있어 전체적으로 속도가 느림.
• 또한 데이터 조회를 전적으로 캐시에만 의지하므로, redis가 다운될 경우 서비스 이용에 차질이 생길수 있음.
• 대신에 캐시와 DB간의 데이터 동기화가 항상 이루어져 데이터 정합성 문제에서 벗어날수 있음
• 역시 읽기가 많은 워크로드에 적합

Read Through 방식은 Cache Aside 방식과 비슷하지만, Cache Store에 저장하는 주체가 Server이냐 또는 Data Store 자체이냐에서 차이점이 있다.

이 방식은 직접적인 데이터베이스 접근을 최소화하고 Read 에 대한 소모되는 자원을 최소화할 수 있다.

하지만 캐시에 문제가 발생하였을 경우 이는 바로 서비스 전체 중단으로 빠질 수 있다. 그렇기 때문에 redis과 같은 구성 요소를 Replication 또는 Cluster로 구성하여 가용성을 높여야 한다. 

  1-2. Write Back 패턴
         주로 쓰기작업이 굉장히 많아서, INSERT 쿼리를 일일히 날리지 않고 한꺼번에 배치 처리를 하기위하여 사용

         예를 들어 영어 듣기 평가를 온라인으로 진행하는 서비스가 있을 때, 여러 학생이 동시에 제출 버튼을 누르면서 DB에 많은
         쓰기 요청이 몰리게 되면 DB서버가 죽을 수도 있음
         이때 write back 기반의 캐시를 사용하면 캐시 메모리에 데이터를 저장해 놓고, 이후 DB 디스크에 업데이트 해 주면 안전

         단점 :DB에서 디스크를 접근하는 횟수가 줄어들기 때문에 성능향상을 기대 할 수 있지만 DB에 데이터를 저장하기전에
         캐시서버가 죽으면 데이터가 유실된다는 문제점이 있음 
         그래서 다시 재생 가능한 데이터나, 극단적으로 heavy한 데이터에서 write back 방식을 많이 사용한다.
         ex) 로그를 캐시에 저장하고 특정시점에 db에 한번에 저장하는 경우 

        쿼리순서
        1) 우선 모든 데이터를 캐시에 싹 저장
        2) 캐시의 데이터를 일정 주기마다 DB에 한꺼번에 저장 (배치)
        3) DB에 저장했으니 잔존 데이터를 캐시에서 제거

https://inpa.tistory.com/entry/REDIS-%F0%9F%93%9A-%EA%B0%9C%EB%85%90-%EC%86%8C%EA%B0%9C-%EC%82%AC%EC%9A%A9%EC%B2%98-%EC%BA%90%EC%8B%9C-%EC%84%B8%EC%85%98-%ED%95%9C%EB%88%88%EC%97%90-%EC%8F%99-%EC%A0%95%EB%A6%AC

1-3. Write Through 패턴

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

https://inpa.tistory.com/entry/REDIS-%F0%9F%93%9A-%EC%BA%90%EC%8B%9CCache-%EC%84%A4%EA%B3%84-%EC%A0%84%EB%9E%B5-%EC%A7%80%EC%B9%A8-%EC%B4%9D%EC%A0%95%EB%A6%AC

- Write Through 패턴은 Cache Store에도 반영하고 Data Store에도 동시에 반영하는 방식이다. (Write Back은 일정 시간을 두고 나중에 한꺼번에 저장)
-  그래서 항상 동기화가 되어 있어 항상 최신정보를 가지고 있다는 장점이 있다.
-  하지만 결국 저장할때마다 2단계 과정을 거쳐치기 때문에 상대적으로 느리며, 무조건 일단 Cache Store에 저장하기 때문에 캐시에 넣은 데이터를 저장만 하고 사용하지 않을 가능성이 있어서 리소스 낭비 가능성이 있다.

write throuth 패턴과 write back 패턴 둘 다 모두 자주 사용되지 않는 데이터가 저장되어 
리소스 낭비가 발생되는 문제점을 안고 있기 때문에, 이를 해결하기 위해 TTL을 꼭 사용하여
사용되지 않는 데이터를 반드시 삭제해야 한다. (expire 명령어)

 

1-4. Write Around 패턴

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

Write Around 패턴은 속도가 빠르지만, cache miss가 발생하기 전에 데이터베이스에 저장된 데이터가 수정되었을 때, 사용자가 조회하는 cache와 데이터베이스 간의 데이터 불일치가 발생하게 된다.

따라서 데이터베이스에 저장된 데이터가 수정, 삭제될 때마다, Cache 또한 삭제하거나 변경해야 하며, Cache의 expire를 짧게 조정하는 식으로 대처해야 한다.

Write Around 패턴은 주로 Look aside, Read through와 결합해서 사용된다.
데이터가 한 번 쓰여지고, 덜 자주 읽히거나 읽지 않는 상황에서 좋은 성능을 제공한다.

 

최적의 조합

캐시 읽기 + 쓰기 전략 조합

Look Aside + Write Around 조합

• 가장 일반적으로 자주 쓰이는 조합

 

Read Through + Write Around 조합

• 항상 DB에 쓰고, 캐시에서 읽을때 항상 DB에서 먼저 읽어오므로 데이터 정합성 이슈에 대한 완벽한 안전 장치를 구성할 수 있음