목차
728x90
반응형
Redis란?
Redis는 Remote Dictionary Server의 약자로, 오픈 소스 기반의 인메모리 데이터 구조 저장소입니다.
키-값(Key-Value) 형태의 해시맵과 같은 구조를 가진 NoSQL(비관계형) 데이터베이스입니다.
별도의 쿼리문이 필요하지 않으며,
데이터를 인-메모리에 저장하기 때문에 디스크 기반 데이터베이스보다 훨씬 빠른 속도를 자랑합니다.
→ 평균 작업속도가 1ms보다 작은편입니다.
즉, Redis는 오픈소스의 인메모리 키-값 데이터 구조를 가지는 NoSQL 데이터베이스입니다.
뒤에 소개하겠지만.. 주로 캐싱, 세션 관리, pub/sub, 메시지 브로커, 랭킹 기능 구현 등에서 사용됩니다.
🎈인-메모리(In-Memory)
컴퓨터의 RAM에 데이터를 저장하게 되면 데이터를 저장 및 조회할 때 디스크를 거치지 않고 메모리 내부에서 처리되므로 속도가 매우 빠릅니다.
그러나, 서버의 메모리 용량을 초과할 경우 메모리의 휘발성인 특성에 의해 데이터가 유실될 수 있습니다.
Redis의 주요 특징
- 성능
- Redis는 디스크가 아닌 인메모리 방식으로 작동해서 평균 1ms 이하의 응답 속도를 제공합니다.
- Persistence 옵션(영속성)
- 필요 시 비동기적으로 메모리에 저장된 데이터를 디스크에 저장해서 데이터 영속성을 지원합니다.
- AOF(Append-Only File) : 모든 쓰기 작업을 기록해서 데이터 복구를 보장합니다.
- RDB(Redis Database File) : 특정 시점의 스냅샷을 생성해서 저장합니다. (주로 백업 목적으로 사용)
- 원자성
- 모든 명령어는 원자적으로 실행됩니다.
- 명령어를 집합으로 만들어 한 번에 실행할 수 있는 트랜잭션 기능도 제공합니다.
- 다양한 데이터 구조 : Redis의 데이터는 애플리케이션 요구사항에 맞는 다양한 데이터 타입을 활용할 수 있습니다.
- String : 가장 일반적인 Key-Value 구조의 형태를 갖습니다. 간단한 캐시 데이터 저장 시에 사용합니다.
- Lists : 배열 구조로, List를 사용하면 처음과 끝에 데이터를 삽입/삭제는 빠르지만 중간에 데이터를 삽입하거나 삭제하기 어렵습니다. 실시간 작업 큐를 구현할 때 사용합니다.
- Sets : 중복이 없는 String의 집합으로, 여러 개의 값을 하나의 Value에 넣을 수 있습니다. 포스트 태그와 같은 기능에서 유용하게 사용합니다.
- Sorted Sets : 정렬된 Set 구조로 순위 관리, 랭킹 보드 서버 같은 구현에 사용할 수 있습니다.
- Hash : 복잡한 데이터를 저장할 때 사용됩니다. 주로 사용자 프로필을 저장할 때 사용합니다.
- 개발 편리성
- Key, Value 구조이기 때문에 Redis는 쿼리문이 필요 하지 않고, 단순 명령 구조로 데이터의 저장 및 조회 등이 가능합니다.
- 싱글 스레드 방식
- Redis는 싱글 스레드 방식을 사용하여 한 번에 하나의 명령어만을 처리합니다.
- 장점 : 연산을 원자적으로 처리하여 레이스컨디션(Race Condition)이 거의 발생하지 않습니다.
- 단점 : 멀티 스레드를 지원하지 않기 때문에 CPU 집약적인 작업 시 성능 병목이 발생할 수 있습니다.
- → Redis 6 이후 버전부터 I/O 작업에서 멀티스레드를 지원하기 시작하긴 했음
Redis의 장단점
- 장점
- 빠른 속도 : 인메모리 기반으로 데이터 접근 속도가 빠르며, 캐싱 및 실시간 처리에 적합합니다.
- 다양한 데이터 구조 : 다양한 데이터 타입을 지원하므로 여러 요구사항에 대응이 가능합니다.
- 확장성 : 클러스터링과 복제 기능을 통해 데이터 분산 및 시스템 확장이 가능합니다.
- 간단한 사용법 : 복잡한 쿼리 사용 없이 단순 명령어로 데이터를 관리할 수 있습니다.
- 단점
- 네트워크 지연 : 별도의 인프라 설정이 필요하며, 네트워크를 통한 접근으로 인해 지연이 발생할 수 있습니다.
- 데이터 유실 가능성 : 장애 시 메모리에 저장된 데이터가 손실될 위험률이 높습니다.
- 메모리 한정성 : 메모리 기반이기 때문에 대규모 데이터 저장 시 비용이 증가할 수 있습니다.
- 싱글 스레드 제한 : 복잡한 연산이나 높은 처리량 요구에 비효율적일 수 있습니다.
- 사용 시기
- 분산 시스템에서 여러 서버 간의 데이터 일관성이 필요한 경우에 사용합니다.
- 확장성과 고가용성이 중요한 대규모 애플리케이션을 개발할 때 사용합니다.
- 세션 관리, 실시간 데이터 처리, 메시징 큐 등의 복잡한 데이터 처리가 필요할 때 사용합니다.
Redis 사용 시 주의할 점
Redis 캐시 서버에 장애가 발생했을 경우, 인메모리 데이터베이스 특성상 데이터가 유실될 수 있습니다..
그렇기 때문에 이러한 상황에 따른 운영 계획이 필요합니다.
Master-Slave 형식의 데이터 이중화 구조를 통해 Redis Replication, 분산 처리를 하기 위해 Redis cluster, 장애 복구 시스템 Redis Sentinel, Redis Topology, Redis Sharding, Redis Failover 등의 Redis를 더 효율적으로 사용하기 위한 개념이 존재합니다.
- 장애 대비
- Redis Sentinal : 캐시 서버에 장애가 발생했을 경우 장애 감지 및 자동 복구를 제공합니다.
- Redis Cluster : 데이터 분산 및 고가용성을 제공합니다.
Redis는 메모리 관리가 매우 중요합니다.
- 메모리 관리
- LRU(Least Recently Used) 알고리즘을 사용해서 오래된 데이터를 자동으로 제거합니다.
- 메모리 사용량 제한 설정을 통해 자원 낭비를 방지합니다.
Redis는 싱글 스레드이기 때문에, 한 번에 하나의 명령만 처리가 가능하며, 처리하는 데 시간이 오래 걸리는 요청은 피해야합니다.
- 명령어 선택
- 시간 복잡도가 높은 명령어(LRANGE 등)는 성능 문제를 유발할 수 있으므로 주의가 필요합니다.
Redis의 사용사례
- 캐싱 : 자주 조회되는 데이터를 캐싱하여 DB 부하를 감소시킬 수 있습니다.
- 채팅 서비스 : 실시간 메시징 서비스 또는 사용자의 상태를 관리할 때 사용할 수 있습니다.
- 메시지 큐 및 대기열 : Redis pub/sub 모델을 통해 실시간 비동기 작업 처리할 때 사용합니다.
- 랭킹 보드(순위표) : 정렬된 상태의 순위 데이터를 관리[저장 및 조회]가 필요할 때 사용합니다.
- 세션 관리 : 인증 토큰 저장 및 사용자의 상태를 레디스에 저장해서 웹 애플리케이션 세션 관리를 간소화시킵니다.
Redis를 사용하는 이유
데이터베이스가 있음에도 불구하고 인메모리 구조의 데이터 저장소인 Redis를 사용하는 이유는 무엇일까..?
데이터베이스는 데이터를 물리 디스크에 직접 사용하기 때문에 서버에 문제가 발생하더라도 데이터 손실이 최소화됩니다. 하지만 매번 디스크에 접근해야 하기 때문에 사용자가 많아질수록 부하가 많아진다는 단점이 있습니다.
일반적으로 서비스 초기의 경우 규모가 적거나 사용자가 많지 않기 때문에 WEB-WAS-DB 구조로 아키텍쳐를 설계해도 데이터베이스에 무리가 없습니다.
하지만 우리의 목적은 서비스 사용자를 늘려나가는거기 때문에 시간이 지날수록 서비스 사용자가 늘어날겁니다.
그러면 데이터베이스가 부하가 많이 걸리기 때문에 이 때 캐시 서버를 도입하여 대응할 수 있습니다.
대표적으로 캐시 서버로 이용할 수 있는 기술로는 Redis가 있습니다.
로컬 캐시 대신 Redis를 사용하는 이유?
로컬 캐시를 사용하는 경우가 접근 속도가 더 빠르고 설정이 가능하지만 일관성 문제, 메모리 제한 및 확장성이 부족하다는 단점이 있습니다. 하지만, Redis는 일관성 유지, 확장성, 데이터 영속성의 장점이 있지만 네트워크 지연으로 인한 관리 복잡성과 비용이 발생할 수 있는 단점이 있습니다. Redis는 특성상 빠른 데이터 처리가 필요한 다양한 시나리오에서 유용하게 사용이 가능하며, 설정과 관리가 비교적 간단해서 고성능을 필요한 애플리케이션에 적합합니다.
로컬 캐시
- 장점
- 빠른 접근 속도 : 네트워크를 거치지 않고 메모리에 접근하여 응답 속도가 매우 빠릅니다.
- 간편한 설정 : 별도의 인프라 없이 간단한 설정으로도 애플리케이션 서버 내부에 캐시 데이터를 저장해서 사용합니다.
- 단점
- 일관성 문제 : 여러 서버 간의 데이터 일관성을 유지하기 어렵습니다.
- 메모리 제한 : 서버 메모리 용량이 한정적입니다.
- 확장성 부족 : 서버 수가 늘어나면 캐시 관리가 복잡해집니다.
- 사용 시기
- 단일 서버 애플리케이션에서 빠른 데이터 접근이 필요한 경우
- 간단한 데이터 캐싱이 필요한 경우
캐시 서버에서 사용하는 디자인 패턴
- Look Aside Cache
- 클라이언트가 데이터를 요청
- 웹 서버는 데이터가 존재하는지 캐시 서버에 먼저 확인
- 캐시 서버에 데이터가 있으면 DB에 데이터를 조회하지 않고 캐시 서버에 있는 결과값을 클라이언트에게 바로 반환(Cache Hit)
- 캐시 서버에 데이터가 없으면 DB에 데이터를 조회하여 캐시 서버에 저장하고 결과값을 클라이언트에게 반환(Cache Miss)
- Write Back
- 웹 서버는 모든 데이터를 캐시 서버에 저장
- 캐시 서버에 특정 시간동안 데이터가 저장됨
- 캐시 서버에 있는 데이터를 DB에 저장
- DB에 저장된 캐시 서버의 데이터를 삭제
Insert 쿼리를 한 번씩 500번 날리는 것보다 Insert 쿼리 500개를 붙여서 한 번에 날리는 것이 더 효율적이라는 원리입니다. 이 방식은 들어오는 데이터들이 저장되기 때문에 메모리 공간에 머무르는데 이때 서버에 장애가 발생하여 다운된다면 데이터가 손실될 수 있다는 단점이 있습니다.
Ref.
728x90
반응형
728x90
반응형
Redis란?
Redis는 Remote Dictionary Server의 약자로, 오픈 소스 기반의 인메모리 데이터 구조 저장소입니다.
키-값(Key-Value) 형태의 해시맵과 같은 구조를 가진 NoSQL(비관계형) 데이터베이스입니다.
별도의 쿼리문이 필요하지 않으며,
데이터를 인-메모리에 저장하기 때문에 디스크 기반 데이터베이스보다 훨씬 빠른 속도를 자랑합니다.
→ 평균 작업속도가 1ms보다 작은편입니다.
즉, Redis는 오픈소스의 인메모리 키-값 데이터 구조를 가지는 NoSQL 데이터베이스입니다.
뒤에 소개하겠지만.. 주로 캐싱, 세션 관리, pub/sub, 메시지 브로커, 랭킹 기능 구현 등에서 사용됩니다.
🎈인-메모리(In-Memory)
컴퓨터의 RAM에 데이터를 저장하게 되면 데이터를 저장 및 조회할 때 디스크를 거치지 않고 메모리 내부에서 처리되므로 속도가 매우 빠릅니다.
그러나, 서버의 메모리 용량을 초과할 경우 메모리의 휘발성인 특성에 의해 데이터가 유실될 수 있습니다.
Redis의 주요 특징
- 성능
- Redis는 디스크가 아닌 인메모리 방식으로 작동해서 평균 1ms 이하의 응답 속도를 제공합니다.
- Persistence 옵션(영속성)
- 필요 시 비동기적으로 메모리에 저장된 데이터를 디스크에 저장해서 데이터 영속성을 지원합니다.
- AOF(Append-Only File) : 모든 쓰기 작업을 기록해서 데이터 복구를 보장합니다.
- RDB(Redis Database File) : 특정 시점의 스냅샷을 생성해서 저장합니다. (주로 백업 목적으로 사용)
- 원자성
- 모든 명령어는 원자적으로 실행됩니다.
- 명령어를 집합으로 만들어 한 번에 실행할 수 있는 트랜잭션 기능도 제공합니다.
- 다양한 데이터 구조 : Redis의 데이터는 애플리케이션 요구사항에 맞는 다양한 데이터 타입을 활용할 수 있습니다.
- String : 가장 일반적인 Key-Value 구조의 형태를 갖습니다. 간단한 캐시 데이터 저장 시에 사용합니다.
- Lists : 배열 구조로, List를 사용하면 처음과 끝에 데이터를 삽입/삭제는 빠르지만 중간에 데이터를 삽입하거나 삭제하기 어렵습니다. 실시간 작업 큐를 구현할 때 사용합니다.
- Sets : 중복이 없는 String의 집합으로, 여러 개의 값을 하나의 Value에 넣을 수 있습니다. 포스트 태그와 같은 기능에서 유용하게 사용합니다.
- Sorted Sets : 정렬된 Set 구조로 순위 관리, 랭킹 보드 서버 같은 구현에 사용할 수 있습니다.
- Hash : 복잡한 데이터를 저장할 때 사용됩니다. 주로 사용자 프로필을 저장할 때 사용합니다.
- 개발 편리성
- Key, Value 구조이기 때문에 Redis는 쿼리문이 필요 하지 않고, 단순 명령 구조로 데이터의 저장 및 조회 등이 가능합니다.
- 싱글 스레드 방식
- Redis는 싱글 스레드 방식을 사용하여 한 번에 하나의 명령어만을 처리합니다.
- 장점 : 연산을 원자적으로 처리하여 레이스컨디션(Race Condition)이 거의 발생하지 않습니다.
- 단점 : 멀티 스레드를 지원하지 않기 때문에 CPU 집약적인 작업 시 성능 병목이 발생할 수 있습니다.
- → Redis 6 이후 버전부터 I/O 작업에서 멀티스레드를 지원하기 시작하긴 했음
Redis의 장단점
- 장점
- 빠른 속도 : 인메모리 기반으로 데이터 접근 속도가 빠르며, 캐싱 및 실시간 처리에 적합합니다.
- 다양한 데이터 구조 : 다양한 데이터 타입을 지원하므로 여러 요구사항에 대응이 가능합니다.
- 확장성 : 클러스터링과 복제 기능을 통해 데이터 분산 및 시스템 확장이 가능합니다.
- 간단한 사용법 : 복잡한 쿼리 사용 없이 단순 명령어로 데이터를 관리할 수 있습니다.
- 단점
- 네트워크 지연 : 별도의 인프라 설정이 필요하며, 네트워크를 통한 접근으로 인해 지연이 발생할 수 있습니다.
- 데이터 유실 가능성 : 장애 시 메모리에 저장된 데이터가 손실될 위험률이 높습니다.
- 메모리 한정성 : 메모리 기반이기 때문에 대규모 데이터 저장 시 비용이 증가할 수 있습니다.
- 싱글 스레드 제한 : 복잡한 연산이나 높은 처리량 요구에 비효율적일 수 있습니다.
- 사용 시기
- 분산 시스템에서 여러 서버 간의 데이터 일관성이 필요한 경우에 사용합니다.
- 확장성과 고가용성이 중요한 대규모 애플리케이션을 개발할 때 사용합니다.
- 세션 관리, 실시간 데이터 처리, 메시징 큐 등의 복잡한 데이터 처리가 필요할 때 사용합니다.
Redis 사용 시 주의할 점
Redis 캐시 서버에 장애가 발생했을 경우, 인메모리 데이터베이스 특성상 데이터가 유실될 수 있습니다..
그렇기 때문에 이러한 상황에 따른 운영 계획이 필요합니다.
Master-Slave 형식의 데이터 이중화 구조를 통해 Redis Replication, 분산 처리를 하기 위해 Redis cluster, 장애 복구 시스템 Redis Sentinel, Redis Topology, Redis Sharding, Redis Failover 등의 Redis를 더 효율적으로 사용하기 위한 개념이 존재합니다.
- 장애 대비
- Redis Sentinal : 캐시 서버에 장애가 발생했을 경우 장애 감지 및 자동 복구를 제공합니다.
- Redis Cluster : 데이터 분산 및 고가용성을 제공합니다.
Redis는 메모리 관리가 매우 중요합니다.
- 메모리 관리
- LRU(Least Recently Used) 알고리즘을 사용해서 오래된 데이터를 자동으로 제거합니다.
- 메모리 사용량 제한 설정을 통해 자원 낭비를 방지합니다.
Redis는 싱글 스레드이기 때문에, 한 번에 하나의 명령만 처리가 가능하며, 처리하는 데 시간이 오래 걸리는 요청은 피해야합니다.
- 명령어 선택
- 시간 복잡도가 높은 명령어(LRANGE 등)는 성능 문제를 유발할 수 있으므로 주의가 필요합니다.
Redis의 사용사례
- 캐싱 : 자주 조회되는 데이터를 캐싱하여 DB 부하를 감소시킬 수 있습니다.
- 채팅 서비스 : 실시간 메시징 서비스 또는 사용자의 상태를 관리할 때 사용할 수 있습니다.
- 메시지 큐 및 대기열 : Redis pub/sub 모델을 통해 실시간 비동기 작업 처리할 때 사용합니다.
- 랭킹 보드(순위표) : 정렬된 상태의 순위 데이터를 관리[저장 및 조회]가 필요할 때 사용합니다.
- 세션 관리 : 인증 토큰 저장 및 사용자의 상태를 레디스에 저장해서 웹 애플리케이션 세션 관리를 간소화시킵니다.
Redis를 사용하는 이유
데이터베이스가 있음에도 불구하고 인메모리 구조의 데이터 저장소인 Redis를 사용하는 이유는 무엇일까..?
데이터베이스는 데이터를 물리 디스크에 직접 사용하기 때문에 서버에 문제가 발생하더라도 데이터 손실이 최소화됩니다. 하지만 매번 디스크에 접근해야 하기 때문에 사용자가 많아질수록 부하가 많아진다는 단점이 있습니다.
일반적으로 서비스 초기의 경우 규모가 적거나 사용자가 많지 않기 때문에 WEB-WAS-DB 구조로 아키텍쳐를 설계해도 데이터베이스에 무리가 없습니다.
하지만 우리의 목적은 서비스 사용자를 늘려나가는거기 때문에 시간이 지날수록 서비스 사용자가 늘어날겁니다.
그러면 데이터베이스가 부하가 많이 걸리기 때문에 이 때 캐시 서버를 도입하여 대응할 수 있습니다.
대표적으로 캐시 서버로 이용할 수 있는 기술로는 Redis가 있습니다.
로컬 캐시 대신 Redis를 사용하는 이유?
로컬 캐시를 사용하는 경우가 접근 속도가 더 빠르고 설정이 가능하지만 일관성 문제, 메모리 제한 및 확장성이 부족하다는 단점이 있습니다. 하지만, Redis는 일관성 유지, 확장성, 데이터 영속성의 장점이 있지만 네트워크 지연으로 인한 관리 복잡성과 비용이 발생할 수 있는 단점이 있습니다. Redis는 특성상 빠른 데이터 처리가 필요한 다양한 시나리오에서 유용하게 사용이 가능하며, 설정과 관리가 비교적 간단해서 고성능을 필요한 애플리케이션에 적합합니다.
로컬 캐시
- 장점
- 빠른 접근 속도 : 네트워크를 거치지 않고 메모리에 접근하여 응답 속도가 매우 빠릅니다.
- 간편한 설정 : 별도의 인프라 없이 간단한 설정으로도 애플리케이션 서버 내부에 캐시 데이터를 저장해서 사용합니다.
- 단점
- 일관성 문제 : 여러 서버 간의 데이터 일관성을 유지하기 어렵습니다.
- 메모리 제한 : 서버 메모리 용량이 한정적입니다.
- 확장성 부족 : 서버 수가 늘어나면 캐시 관리가 복잡해집니다.
- 사용 시기
- 단일 서버 애플리케이션에서 빠른 데이터 접근이 필요한 경우
- 간단한 데이터 캐싱이 필요한 경우
캐시 서버에서 사용하는 디자인 패턴
- Look Aside Cache
- 클라이언트가 데이터를 요청
- 웹 서버는 데이터가 존재하는지 캐시 서버에 먼저 확인
- 캐시 서버에 데이터가 있으면 DB에 데이터를 조회하지 않고 캐시 서버에 있는 결과값을 클라이언트에게 바로 반환(Cache Hit)
- 캐시 서버에 데이터가 없으면 DB에 데이터를 조회하여 캐시 서버에 저장하고 결과값을 클라이언트에게 반환(Cache Miss)
- Write Back
- 웹 서버는 모든 데이터를 캐시 서버에 저장
- 캐시 서버에 특정 시간동안 데이터가 저장됨
- 캐시 서버에 있는 데이터를 DB에 저장
- DB에 저장된 캐시 서버의 데이터를 삭제
Insert 쿼리를 한 번씩 500번 날리는 것보다 Insert 쿼리 500개를 붙여서 한 번에 날리는 것이 더 효율적이라는 원리입니다. 이 방식은 들어오는 데이터들이 저장되기 때문에 메모리 공간에 머무르는데 이때 서버에 장애가 발생하여 다운된다면 데이터가 손실될 수 있다는 단점이 있습니다.
Ref.
728x90
반응형
