Cache

taehee kim·2022년 5월 5일
0
post-thumbnail

1.Cache란?

  • 캐쉬란 데이터 요청 주체와 메모리 저장공간 사이에 위치하면서 메모리 저장공간에 대한 요청을 앞에서 먼저 대신 처리해주어 데이터 전송이 더 빠르게 이루어지게 할 수있는 하드웨어, 혹은 소프트웨어 요소이다.
  • 데이터 요청자는 먼저 cache에서 원하는 데이터가 존재하는지 찾아보고 있는 경우 cache의 데이터를 가져가고 없는 경우 데이터 저장공간에서 데이터를 가져오게 된다.
  • 직접적으로 데이터 처리 로직을 실행 하지않고 이전에 조회된 다시 데이터를 가져오는 방식이기 효율성을 얻기 적이지만 일관성을 일부 양보하는 전략이라고 할 수 있다. 💡 따라서 Read 보다 Write가 빈번하게 일어나는 데이터는 Cache를 사용하기 부적합하다.

1.0. Long tail 법칙

Untitled

  • 20%의 요구가 시스템 리소스의 대부분을 잡아먹는다는 법칙.
  • 자주 사용되는 20%의 기능에 캐시를 이용하면 리소스 사용량을 대폭 줄일 수 있어, 시스템의 성능을 대폭 향상 시킬 수 있다.

1.1. Hit ratio

  • 데이터를 cache에서 먼저 찾은 경우의 비율을 Hit ratio 라고 한다.
  • 이 비율이 높으면 cache로 인한 성능 향상이 효율적으로 이루어지고 있는 것이다.
  • 따라서 Hit ratio 를 높이는 방식으로 cache 에 데이터를 저장하는 것이 중요하며 이때 지역성의 원리가 적용된 알고리즘이 주로 사용된다.

1.2.지역성의 원리

Untitled

  • 시간 지역성(Temporal locality)
    • 최근에 요청된 데이터가 다시 요청될 확률이 높다.
    • For, while 같은 반복문에 사용되는 조건 변수처럼 한번 참조된 데이터는 잠시후 참조될 가능성이 높다.
  • 공간 지역성(Spatial locality)
    • 요청된 데이터 주변 메모리 데이터가 요청될 확률이 높다.
    • a[0], a[1]처럼 같은 데이터 배열에 연속적으로 접근할때 참조된 데이터 근처에 있는 데이터가 잠시 후 사용될 가능성이 높다.

1.3. Cache 데이터 대체 알고리즘

  • 어떤 cache의 데이터를 먼저 지울지 정하는 알고리즘이다.
  • Least Frequently Used
    • 가장 적게 요청된 데이터부터 지운다.
  • Least Recently Used
    • 가장 요청된지 오래된 데이터를 지운다.
  • Most Recently Used
    • 가장 최근에 요청된 데이터를 지운다.

1.4. Cache 사용의 장점

  • 성능이 빨라진다.
    • 예를들어  브라우저가 이전세션에서 받아온 데이터를 저장해놓거나, 데이터베이스에 캐쉬를 두어 하드디스크에서 직접 데이터를 주지 않도록 하면 속도가 빨라진다.
  • 오프라인으로 데이터를 받을 수 있다.
    • 로컬 캐쉬에 데이터가 이미 있다면 네트워크 연결이 끊어져 있는 경우에도 데이터를 받을 수 있다.
  • 자원을 효율적으로 사용한다.
    • 속도 외에도 빠른 캐시로의 접근은 전력이나 배터리를 적게 소모하게 만든다.

1-5. Cache 사용시 생길 수 있는 문제점

  • Corruption
    • data corruption이 발생할 수 있다.
  • Outdated infomation
    • 캐시에 있는 데이터가 업데이트 되지 않은 데이터인 경우 실제 최신 데이터가 전송 되지 않을 수 있다.

1-6. Cache Write Policies

  • Write-around cache
    • write 할때에 cache에는 쓰지않고 메모리에만 쓰는 경우이다
    • 장점은 메모리에 쓰는 양이 많은 경우 cache flooding 이 발생하는것을 어느정도 방지해준다.
    • 단점으로는 read하지 않으면 cache에 데이터가 반영되지 않는다.
    • 따라서 write operation이 대용량으로 발생하고 read operation이 적게 발생하는 경우에 적합하다.
  • Write-through cache
    • write 할때에 cache에도 쓰고 메모리에도 쓰는 경우이다
    • 장점은 cache데이터에 최근에 write 한 데이터가 많이 반영되어 read operation이 빨라진다.
    • 단점으로는 한번의 write 가 cache, memory에 모두 이루어 지기 전까지 종료 되지 않기 때문에 write latency가 높아진다.
  • Write-back cache
    • write를 cache에만 하는 경우이다. cache 에 데이터가 저장되면 write가 종료되고, 이 데이터가 cache에서 탈락될 때 메모리에 복사된다.
    • 장점은 write와 read 모두 latency가 적다.
    • 단점으로는 storage에 일관성을 관리하기 위한 방법이 필요하다는 부분이다.

2. Backend Cache

2.1.브라우저와 WAS 사이의 Cache들

  • ETag : 캐시 정책을 백엔드 개발자가 정함. web server와 browser사이에 있는 캐쉬들에 적용.
    • hash 된 etag 값을 비교하여 origin server와 값이 다르면 새로 값을 주고, 같은 경우 304 발생
    • 브라우저 캐시 : Client에 local 저장공간에 위치하는 캐시
    • 프록시 서버 캐시 : Client 와 Origin Server사이에 위치하는 Proxy server 에 저장 되는 캐시
  • CDN(Content Delivery Network)

2.2. WAS안쪽에 있는 Cache

2.2.1 Local Cache And Global Cache

  • Local Cache
    • 특징
      • WAS 인스턴스 각각의 메모리에 Hashmap 자료구조나 EHcache등을 사용하여 임시적으로 데이터를 저장한다.
    • 장점
      • 프로세스가 실행되는 곳의 메인 메모리에서 데이터를 가져올 수 있기 때문에 네트워크 통신, io 에서 사용되는 시간이 불필요해 매우 빠르다.
    • 단점
      • 각각의 WAS의 캐시 간의 데이터가 중복되고 불일치 할 수 있으므로 서로 동기화 시키는 비용이 든다.
      • 데이터 일관성이 중요한 경우 사용하기 힘들다.
  • Global Cache
    • 특징
      • WAS나 DB와 따로 위치하며 여러 서버에서 공동으로 접근하여 사용하는 캐시이다.
      • 주로 속도를 위해 Redis, Memcached 등의 in-memory DB를 사용하여 구현한다.
    • 장점
      • 별도의 Cache Server를 이용하기 때문에 서버 간 데이터 공유가 쉽다.
      • 데이터를 분산하여 저장 할 수 있다.
        • Replication - 데이터를 복제
        • Sharding - 데이터를 분산하여 저장
    • 단점
      • Local Cache에 비해 상대적으로 느리다. (네트워크 트래픽)

2.2.2 Redis vs Memcached

  • Redis vs Memcached
    • Redis
      • 특징
        • Single thread
        • in-memory data structure
        • key-value NOSQL
        • horizontal Scalability
      • 장점
        • set, hash, sorted set, string 등의 자료구조가 있어 데이터 처리가 매우 편리하다.
        • non-volatile
      • 단점
        • Memcached보다 메모리 단편화 문제로 메모리를 비효율적으로 사용한다.
    • Memcached
      • 특징
        • Multi thread
        • in-memory
        • vertical Scalability
      • 장점
        • 메모리 관리면에서 Redis보다 뛰어나고 비교적 메모리 단편화 문제를 잘 해결한다.
      • 단점
        • Redis 에서 처럼 자료구조를 제공하지 않기 때문에 데이터들을 다루기 불편하다.
        • volatile

2.2.3 Cache strategy

  • Cache-aside(lazy-loading)
    • 먼저 Cache를 보고 원하는 데이터가 있으면 가져온다.
    • 없으면 원본 DB에서 데이터를 가져온다.
    • 원본 DB에서 가져온 데이터를 바로 Cache에 쓴다.
  • Write-through
    • write 할때에 cache와 database에 모두 write한다.
    • cache invalidation을 사용하지 않고 데이터 일관성을 줄 수 있다.

3. 로그인 페이지와 Redis Cache

  • 로그인 정보를 관리하고 로그인 할 수있는 서버에서 로그인 데이터를 Redis Cache로 로딩해서 관리
    • 모든 WAS에서 같은 캐시 데이터를 공유 위해 Global Cache를 사용한다.
    • 로그인 정보는 write가 적고 최근에 write된 데이터가 read될 확률이 높다. 또한 write 보다 read가 훨씬 더 많이 일어날 것이다.
    • Cache와 DB간의 데이터 일치도 매우 중요하다.
    • 따라서 write-through를 사용한다.
    • non-volatile이면서 로그인정보 객체를 자료구조 형태로 저장하기 쉬운 Redis를 사용한다.
profile
Fail Fast

0개의 댓글