로컬 스토리지 캐싱 vs Redis 캐싱

• 지속성 (Persistence)

  • 로컬 스토리지

    일반적으로 로컬 메모리에 저장된 캐시는 프로세스나 서비스가 종료되면 소멸

  • Redis

    Redis는 옵션에 따라 데이터를 디스크에 지속적으로 저장가능. 이를 통해 서버가 재시작되거나 다운될 경우에도 데이터를 복구가능

• 분산 환경

  • 로컬 스토리지

    각 인스턴스는 자체 캐시를 가지고 있기 때문에, 여러 서버 인스턴스가 실행되는 환경에서 캐시 데이터의 일관성을 유지하기 어려움

  • Redis

    Redis는 중앙화된 캐싱 솔루션을 제공하여 여러 서버 인스턴스 간에 캐시 데이터를 공유가능

• 용량과 확장성

  • 로컬 스토리지

    로컬 캐시의 크기는 서버의 RAM 용량에 제한

  • Redis

    Redis는 클러스터링을 지원하여 캐시 용량을 확장가능

• 데이터 구조와 기능

  • 로컬 스토리지

    기본적인 키-값 저장소 형태로 제한

  • Redis

    리스트, 셋, 해시, 정렬된 셋 등 다양한 데이터 구조 지원 및 풍부한 연산 및 명령어 집합 제공

• 복잡성 및 관리

  • 로컬 스토리지

    설정 및 관리가 간단

  • Redis

    별도의 서비스로 실행되므로 설치, 구성, 모니터링 및 관리가 필요

• 네트워크 지연

  • 로컬 스토리지

    데이터는 로컬 메모리에 있으므로 액세스 속도가 매우 빠릅니다.

  • Redis

    네트워크를 통해 Redis 서버에 접근하기 때문에 로컬 캐시에 비해 약간의 지연이 발생할 수 있음.
    그러나 Redis는 매우 빠른 인메모리 데이터 저장소이므로 일반적으로 이 지연은 미미

• 복구 및 장애 복구

  • 로컬 스토리지

    로컬 캐시는 일반적으로 복구 메커니즘이 없음

  • Redis

    데이터 백업, 복제(replication) 및 장애 복구 기능을 제공

결론적으로, 선택은 요구 사항과 환경에 따라 달라짐
간단한 캐싱 요구 사항이 있고 분산 환경이나 지속성이 필요하지 않은 경우 로컬 스토리지 캐싱이 적합할 수 있음
반면, 고성능, 확장성, 지속성 및 여러 서버 인스턴스 간의 캐시 공유가 필요한 경우 Redis와 같은 외부 캐싱 솔루션을 고려해야 함

API로 조회한 데이터를 로컬스토리지에 저장해두는 것은 캐싱인지 상태관리인지?

API로 조회한 랭킹 데이터를 로컬 스토리지에 저장하는 행위는 캐싱 및 상태 관리의 성격을 모두 포함할 수 있음

• 캐싱

  캐싱의 주요 목적은 데이터의 재사용을 통해 성능을 최적화하고, 반복적인 데이터 요청을 줄이는 것
  
  
  예를 들어, 사용자가 랭킹 페이지를 여러 번 방문할 때마다 API를 호출하지 않고 로컬 스토리지에 저장된 데이터를 사용하면, 이는 캐싱의 전형적인 사용 사례

• 상태 관리

  상태 관리의 주요 목적은 애플리케이션의 상태를 일관성 있게 유지하고, 다양한 컴포넌트나 페이지에서 해당 상태에 접근하거나 변경할 수 있게 하는 것
  
  
  랭킹 데이터가 애플리케이션 내의 여러 위치에서 사용되며, 이 데이터를 기반으로 UI가 업데이트되어야 하는 경우, 로컬 스토리지에 데이터를 저장하는 행위는 상태 관리의 일부로 볼 수 있음

따라서, 로컬 스토리지에 랭킹 데이터를 저장하는 행위가 캐싱인지 상태 관리인지는 해당 데이터의 사용 목적과 컨텍스트에 따라 달라짐
특정 상황에서는 두 가지 측면을 모두 포함할 수 있음