[실전 레디스] Chaprter 01_레디스의 시작

 

 

들어가기에 앞서 PART 01은 기초적인 내용을 담고 있으며, 아래와 같은 순서로 정리되어 있다.

1장 레디스의 시작

2장 자료형과 기능

3장 고급 기능

4장 레디스를 활용한 애플리케이션 작성

 

그 중 1장 CHAPTER 01 레디스의 시작에 대해 읽은 내용을 정리해 보려고 한다.

Redis: 빠른 속도와 다양한 자료형을 제공하는 비관계형 데이터베이스

 

레디스를 한 줄로 정리해 보자면, 위와 같다. Chapter1의 전반적인 내용도 사실 위 한 줄을 넓은 범위로 풀어냈다고 느껴진다.

그 다음으로 이어지는 문장은 아래와 같은데, 어떻게 빠르게 동작할 수 있는지에 대한 내용이 더해졌다.

레디스는 인메모리 데이터 구조 저장소로써 인메모리에서 빠르게 동작하고, 자료형과 기능이 다양한 비관계형 데이터베이스 입니다.

 

 

1. 레디스의 특징

1) 속도가 빠르고 기능이 많은 인메모리 데이터 저장소

인메모리 동작 기반의 빠른 처리 속도
- 레디스의 빠른 처리 속도는 큰 장점이다. 인메모리, 작은 메모리 사용량, 이벤트 주도 요청 등으로 인해 아주 빠르게 동작한다.

- 트레이드오프도 고려해야한다. 레디스가 동작하는 메모리는 SSD/HDD에 비해 가격이 높아 용량 확보가 어렵다.

 

다양한 자료형과 명령어

- 빠른 속도 다음으로 많이 언급되는 특징은 자료형이다. String, List, Hash, Set, Sorted Set 등이 대표 자료형이며, 비트맵, 지리적 공간 인덱스의 보조 자료형을 사용할 수 있다.

- Pub/Sub 기능과 HyperLogLog가 있다.

- 레디스 스트림의 스트림 처리가 가능하다.

 

데이터 영속성

- 인메모리이기 때문에 데이터의 휘발성을 고려해야한다.

- 레디스에서 크게 두 가지 종류의 영속성을 제공한다.

    첫번째는 RDB의 스냅숏 생성 기능이며, 기본적으로 활성화되어있다.

    두번째는 RDB 외 장애 등이 발생했을 때 활용하기 쉬운 AOF이다.
    기본적으로 비활성화인데, RDB와 조합하여 활성화시키면 데이터의 손실 위험을 최소화하여 레디스의 재시작 시간을 단축할 수 있다.

 

레플리케이션 및 클러스터 기능을 통한 확장성 및 고가용성

- 설정에 따라 확장성 및 가용성 문제를 비교적 깔끔하게 해결할 수 있다.

 

클라이언트/서버 모델 기반의 요청/응답 통신

- 클라이언트/서버 모델을 채택하여 요청/응답 방식으로 통신하며, 다양한 환경에서도 사용할 수 있다.

- 많이 사용되는 CLI 클라이언트: redis-cli, 넷켓, 텔넷

- 50개 이상의 언어를 지원하여 언어에 구애받지 않고 레디스 도입이 가능하다.

 

루아를 통한 유연한 처리

- 레디스는 루아 스크립트 기능을 내장하고 있고, 이를 통해 여러 개의 레디스 명령어를 한번에 수행할 수 있다.

  이를 통해 유연성이 증가하고, 성능 이점도 기대할 수 있다.

- 루아 스크립트는 RDBMS의 저장 프로시저와 유사하다.

- 하나의 루아 스크립트는 하나의 레디스 명령어와 동일한 레벨로 수행되며, 이때 코드의 실행은 원자적으로 수행된다.

 

싱글 스레드 기반 요청 이벤트 주도 처리

- 레디스는 싱글 스레드 주도 처리 모델을 채택했다.

- 싱글 스레드지만 이벤트 루프를 형성하여 많은 요청을 처리할 수 있고 ae라는 고유 이벤트 주도 라이브러리를 사용한다.

- 완전한 싱글 스레드가 아니라 성능을 위해 부분적 멀티 스레드를 채택하고 있다.

- 레디스 6.0 이후로는 데이터 접근 부분은 여전히 싱글 스레드지만, 옵션을 통해 I/O 부분은 멀티 스레드 처리를 활성화할 수 있다. 이를 통해 효율적인 데이터 조작, 저장 및 검색이 가능하다.

 

2. 레디스의 동작 이미지

레디스가 어떻게 데이터를 저장하는지 그 내부를 알아보기 위한 단계이다.

여러 자료형의 복잡한 값이 키와 연결되어 있다는 점을 주목해 보자

3. 다른 데이터베이스와 비교

1) RDBMS와 비교

레디스를 제대로 활용하려면 RDBMS와 비교하는 것도 중요하다.

RDBMS에 대해 간략히 정리하자면,

- SQL을 통해 강력하고 편리한 표현으로 인해 데이터 모델을 매우 폭넓고 유연하게 표현할 수 있다.

- 데이터 일관성 등을 포함한 강력한 ACID 특성을 실현할 수 있는 가능성이 있다.

- 테이블 간 정합성 유지 및 정규화를 통한 중복 제거 등으로 전체적으로 최적화 가능한 설계를 할 수 있다.

 

RDBMS가 지원하는 기능이 다양하고, 범용성도 뛰어나다. 그래서 대부분의 경우 RDBMS가 사용된다. 하지만 완벽하지는 않다.

인덱스 설계를 통해 쿼리 속도 개선이 가능하지만 단독 사용 시 데이터 모델의 표현이나 속도 측면에서 불만스러울 수 있다.

따라서 RDBMS가 적합하지 않은 곳에서는 그 역할은 레디스에게 맡기는게 속도, 구현 측면에서 효율적이다.

 

RDBMS는 사전에 스키마가 정의된 것을 전제로 하는데, 이 경우 저장된 데이터가 분산되기 어렵다. 그와 반대로 정합성 유지는 쉽다는 이점이 있다.

 

RDBMS에서는 구조 정의가 명확하지 않은 희소한 대규모 데이터 세트를 처리하기 곤란하다. 반면, 레디스는 특정 용도에 특화되어 있어 RDBMS 같은 범용성은 없다.

 

레디스에는 RDBMS와 같은 강력한 ACID 특성이 없고, 트랜잭션 기능을 일부 희생하기도 한다.

(43 페이지의 표 1-2 ACID 특성 및 보장 방법 참고)

 

위와 같은 이유로 서로가 대체되긴 어렵고, 보완하는 관계라고 이해하는 것이 좋다.

 

2) Memcached와 비교

멤케시디는 레디스와 자주 비교되는 KVS이며, 레디스와 같이 인메모리 데이터를 저장한다.

RDBMS와 비교하면 멤케이시디와 레디스는 용도가 비슷하다.

 

멤케시디: 디스크 스토리지나 DB 같은 대규모 데이터 저장소의 부하를 줄이기 위해 캐시를 저장하는 도구

 

레디스와 비교하면 기능이 간단하여 용도가 한정되어 있다. 그렇다고 레디스가 멤케시디의 단순 상위호환은 아니다.

어떤 것을 사용할지 결정할 때 복잡한 데이터 모델이 될 것 같으면 레디스를, 단순 캐시 용도라면 레디스와 멤케시디 중 적절하게 고려하는 것이 좋다.

 

4. 레디스의 활용

1) Mysql과 레디스의 조합

위에서 언급했던 내용들을 토대로 RDBMS와 레디스를 서로 보완하며 사용하기 좋다는 것을 알 수 있다.

따라서 웹서비스에서는 MySQL과 레디스를 같이 구성하는 것이 대표적이다.

구체적으로는 아래와 같이 MySQL 앞단에 레디스를 배치하고, 레디스의 인메모리에서 데이터를 가져오는 구성으로 사용하는 것이다.

2) Pub/Sub 시스템 구축

책에는 자세히 언급되어 있지 않지만, Publish(발행)과 Sub(구독)방식의 메시지를 패턴 검색이 가능하다. 따라서 높은 성능을 요구하는 채팅, 실시간 스트리밍, SNS 피드 그리고 서버간 통신에 사용할 수 있다.

 

3) 배치 처리 메시지 큐

이 역시 책에는 자세히 언급되어 있지 않아서 구체적으로 설명되어 있는 아래 블로그를 참고하면 좋을 것 같다.

 

https://velog.io/@jeongyeon_kim/Redis%EB%A0%88%EB%94%94%EC%8A%A4%EB%A5%BC-%EB%A9%94%EC%8B%9C%EC%A7%80-%EB%B8%8C%EB%A1%9C%EC%BB%A4%EB%A1%9C-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0

[Redis]레디스를 메시지 브로커로 사용하기