참고사이트: https://architecturenotes.co/redis/
1. 위 사이트의 내용을 번역하고 필요 내용은 찾아 정리하였습니다.
2. 영어로 자연스레 통용되는 것들은 영어와 한국어를 병행 표기하였습니다.
3. 그림은 저작권 문제가 있어, 따로 첨부하진 않았습니다.
😎 What is Redis?
- Redis: Remote DIctionary Service
- 오픈소스로 되어있는 메모리 key-value database이다.
1. In-memory database
- 데이터를 저장하는 방법에 대표적으로 두 가지가 있다.
- Disk-based DB는 메모리를 디스크에 저장하는 것이다. (i.e. MySQL)
- In-memory DB는 데이터를 메모리(e.g. RAM, cache)에 저장하는 것이다.
- 메모리에 저장되기 때문에 빠르게 액세스할 수 있고 메모리와 디스크 간 병목 현상이 없다.
- Redis는 MySQL 또는 PostgreSQL과 같은 "진짜 데이터베이스"의 앞단에서 캐시로서 사용되어 애플리케이션의 성능을 높여준다
2. 왜 In-memory DB를 사용하는 것일까?
-
가장 큰 이유는 데이터는 비정기적으로 바뀌고 너무 자주 액세스 요청이 되기 때문에, 디스크에서 데이터를 읽어오기까지의 비용이 높아진다.
이 때의 비용이란, 디스크에 액세스 하는데 걸리는 시간을 포함하는 말이다.
-
디스크에 저장되지 않아도 되는 데이터(mission_critical(필수불가결힌) data)는 폭발적으로 증가하여 발생하는 경향이 있기 때문에, 디스크에 저장하는 비용(저장 시간, 저장 디스크 등)이 많이 들 수 있다.
이러한 데이터가 필요하다면 저장해야겠지만, 필요하지 않고 사라지는 경우도 많기 때문에 "비용"이라는 리스크를 감수할 필요가 없다.
3. Redis가 전통적으로 사용되었던 방식
- Redis는 MySQL 앞단에 놓여 캐시로서 사용되었다.
- 캐시에 찾아보고 찾는 데이터가 있다면 영어로는 hit data라고 표현되었다. , 데이터를 반환한다.
- 데이터가 없다면 persistent datastore (=Disk DB)에서 데이터를 찾아 반환한다.
- 캐시에 디스크에서 찾은 데이터를 저장한다.
4. 기본 DB로 사용될 수 있을만큼 강력해진 Redis!
- Redis와 HA(High Availability) setup들과 함께 Redis는 상당한 양의 시나리오(data)와 workload(작업량)
High Availability
- 시스템 고장 발생 시, 빠른 시간내에 치료가 되어 정상적으로 복구되는 것이다.
- 백업, 장애극복처리, 데이터 저장, 액세스의 역량이 어느정도 되는지에 따라 달라진다.
- 이외에도, 메모리의 성능이 올라가면서 cache와 datastore의 경계가 모호해졌다.
SSD나 HDD에 접근하는 것보다 Redis에 접근하는 것이 훨씬 빠르기 때문에 매력적일 수밖에 없다. 용량이 확보된다면 간단한 작업이나 정보의 경우 Redis를 통해 사용하는 것이 시간적 측면에서 효율적이다.
5. Memcached와의 비교
1) Memcached란?
- Redis보다 6년 정도 빨리 등장하였고 당시 사실상 캐싱 툴의 기본이라 할 수 있다.
2) Redis와의 차이점
- Redis와의 차이점은 데이터 타입이 없다는 것과 LRU(Least Recently Used) 라는 제한된 eviction(데이터 삭제) 정책을 가지고 있다.
- Redis는 Single-threaded이나, Memcached는 multithreaded이다.
- Memcached는 엄격한 캐싱 환경에서 성능을 발휘하는 반면, 분산 클러스터에서 일부 설정을 수정해야 한다.- Redis는 분산 클러스터에서 즉시 적용하여 사용할 수 있다.
- Redis는 snapshot을 지원하지만, Memcached는 snapshot을 지원하지 않는다.
snapshot: 특정 시점에 스토리지의 파일 시스템을 포착해서 보관하는 기술 (≈ 복구)
스냅샷과 스냅샷 간의 데이터가 손실될 수 있다는 단점이 있다.
6. Redis의 장점
📣 본 글에서는 Redis의 장점이 확장성(분산시스템)과 속도, 오픈소스인점에 대해 강조하고 있습니다. 그러나 Redis가 속도적 측면에서 얼마정도의 성능상 이점이 있는 것인지에 관해 조금 더 내용을 추가할 필요가 있을 것 같아 AWS에 포스팅된 내용을 함께 정리하였습니다.
1) 1밀리초 미만의 응답시간
위 그림은 https://architecturenotes.co/redis/가 출처임을 밝힙니다.
- 위 그림에서 알 수 있듯, 캐시를 이용한다는 것은 데이터 요청 시 응답 속도 측면에서 엄청난 빠르기를 가진다는 것을 알 수 있다.
- Redis는 캐시메모리를 주 저장소로 이용하기 때문에 1밀리초 미만의 응답시간을 보장한다고 알려져 있다. 데이터를 쓸 때도 1 밀리초 미만이 걸린다고 한다.
데이터의 양에 따라 이 속도는 달라지므로, 위 그림은 데이터 양을 고려하여 시간을 측정한 것이라 이해하고, 캐시가 속도가 현저히 빠르다 정도로 받아들이면 될듯하다.
- 아마존에서는 Amazon MemoryDB for Redis와 Amazon ElastiCache for Redis를 통해 Redis를 지원하고 있다.
2) 유연한 데이터 구조
- Redis에서 지원하는 데이터 구조는 문자열, 목록, Sets, Sorted Sets 등 다양하다.
3) 단순성 및 사용 편의성
- 짧고 단순한 코드로 기존의 복잡한 코드를 작성할 수 있다.
- 짧은 코드를 작성할 수 있도록 지원하고 다수의 언어를 지원한다.
4) 복제 및 지속성
- 다음 포스팅(https://velog.io/@jungedlin/Redis%EB%9E%80-%EB%AD%98%EA%B9%8C-2)에서 다룰 내용이다.
5) 고가용성 및 확장성
- 단일 노드 기본 또는 클러스터링된 토폴로지에서 기본-복제 아키텍처를 제공한다.
- 클러스터링 시, 스케일업, 스케일 아웃 등 다양한 옵션을 선택할 수 있다.
6) 오픈소스
- Redis는 AWS를 포함한 커뮤니티를 통해 지원되는 오픈 소스 프로젝트이다.
- 다양한 클라이언트 세트를 지원하기 때문에 기술 종속이 없다는 것이 장점이다.
📣 Redis는 2009년 이후 성숙해졌고 다음포스팅에서는 Redis에 대해 좀 더 차근차근 알아보도록 하겠습니다!
만나본 질문
- 랭킹 구현시, 굳이 Redis를 쓰지않았어도 되었을 것 같은데 왜 Redis를 썼나요?
📣 실제 제가 받은 질문은 아니지만, 옆의 어떤 분이 프로젝트를 설명하시며 현업 개발자님께 받은 질문입니다. Redis를 사용하셨다면 왜 Redis 여야만 했는지에 관해 자신만의 근거를 가져야 한다고 생각했습니다. :) 위 정리된 Redis의 장점과 이어지는 포스팅에서 Redis의 특징을 이해하고 Redis를 선택한 근거를 명확히 선택해봅시다!
챙겨볼 영어 단어 👀
- mission-critical: 필수불가결한
- full-fledged: 만반의
e.g. full-fledged primary database: 기본적으로 쓰일 수 있는 DB
- de facto: 공식적이진 않으나 기정 사실로 받아들여지는
- de jure: 법적으로 받아들여지는
- eviction: 퇴거, DB에서는 데이터를 지우는 것을 의미
오 Redis 가 이런거였군여 ㅋㅋ 덕분에 하나 더 배워갑니다~