해시넷
레디스
레디스(Redis)는 Remote Dictionary Server의 약자로서 '키-값'(key-value) 구조의 비 관계형 데이터를 저장하고 관리하기 위한 노에스큐엘(NoSQL)의 일종이다. 2009년 살바토르 산필리포(Salvatore Sanfilippo)가 처음 개발했다. 2015년부터 레디스랩스(Redis Labs)가 지원하고 있다. 모든 데이터를 메모리로 불러와서 처리하는 메모리 기반 데이터베이스 관리 시스템(DBMS)이다. BSD 라이선스를 따른다.
목차
개요
레디스는 빠른 오픈 소스인 메모리 키 값 데이터 구조 스토어이다. 레디스는 다양한 인 메모리 데이터 구조 집합을 제공하므로 다양한 사용자 정의 애플리케이션을 손쉽게 생성할 수 있다. 주요 레디스 사용 사례로는 캐싱, 세션 관리, pub/sub 및 순위표를 들 수 있다. 레디스는 현재 가장 인기 있는 키값 스토어로서, BSD 라이선스가 있고, 최적화된 C 코드로 작성되었으며, 다양한 개발 언어를 지원한다. 레디스는 REmote DIctionary Server의 약어이다.
레디스는 속도가 빠르고 사용이 간편하여 최고의 성능이 필요한 웹, 모바일, 게임, 광고 기술 및 IoT 애플리케이션에서 널리 사용되고 있다. AWS는 레디스용 Amazon ElastiCache라는 최적화된 완전관리형 데이터베이스 서비스를 통해 레디스를 지원하며, 고객은 원하는 경우 AWS EC2에서 자체 관리형 레디스를 실행할 수도 있다.[1]
역사
레디스 프로젝트는 레디스의 최초 개발자인 antirez라는 별명을 가진 살바토르 산필리포(Salvatore Sanfilippo)가 이탈리아 웹사이트의 확장성을 향상시키고 실시간 웹 로그 분석기를 개발하려고 할 때 시작되었다. 기존 데이터베이스 시스템을 사용하여 일부 유형의 작업 부하를 조정하는 데 심각한 문제가 발생한 후 산필리포는 Tcl에서 레디스의 개념증명 버전을 프로토타입 화하기 시작했다. 나중에 산필리포는 프로토 타입을 C 언어로 번역하고 첫 번째 데이터 유형인목록을 구현했다. 내부적으로 성공을 거둔 프로젝트를 몇 주 동안 사용한 후 산필리포는 소스를 공개하고 Hacker News에서 프로젝트를 발표하기로 했다. 프로젝트는 깃허브(GitHub)와 인스타그램(Instagram)을 채택한 최초의 회사 중 하나인 루비(Ruby) 커뮤니티에서 더욱 주목받기 시작했다. 산필리포는 2010년 03월 브이엠웨어(VMware)에 고용되었다. 2013년 05월 레디스는 Pivotal Software (VMware 분사)의 후원을 받았다. 2015년 06월에 레디스 Las가 후원했다. 2018년 10월에 레디스 5.0이 출시되었다. Redis Stream은 단일 키에서 자동 시간 기준 시퀀스(Sequence)를 사용하여 여러 필드와 문자열 값을 저장할 수 있는 새로운 데이터 구조이다.[2]
특징
레디스는 오픈 소스 소프트웨어이며 디스크가 아닌 메모리 기반의 데이터 저장소이다. NoSQL & Cache 솔루션이며 메모리 기반으로 구성된다. 명시적으로 삭제를 설정하지 않으면 데이터는 삭제되지 않는 영구적 보존이다. 여러 대의 서버 구성이 가능하며 데이터베이스로 사용될 수 있고 캐시로도 사용될 수 있는 기술이다. 성능은 서버에 따라 다르나 초당 2만 ~ 10만 회 정도 수행한다. 메모리 위에서 동작하는 레디스는 NoSQL DBMS로 분류되며 동시에 Memcached와 같은 인메모리(In-memory) 솔루션으로 분리된다. NoSQL 중에서도 레디스가 주목을 받는 이유는 데이터 저장소로 입력/출력이 가장 빠른 메모리를 채택하고 단순한 구조의 데이터 모델을 사용하여 속도가 빠르다. 그리고 캐시 및 데이터 스토어에 유리하고 다양한 API를 지원한다. 레디스는 대형 서비스 업체들이 사용자들의 대규모 메시지를 실시간으로 처리하기 위해서 사용하고 있다.[3]레디스와 멤캐시드(Memcashed)는 특징이 유사하다.[4]
멤캐시드 특징
데이터가 메모리에만 저장되어 속도가 느린 디스크(Disk)를 거치지 않음으로 처리 속도가 빠르다. 데이터가 메모리에만 저장되어 프로세스가 죽거나 장비가 셧다운(Shutdown) 되면 데이터가 사라진다. 캐시이기 때문에 만료일을 지정하여 만료되면 자동으로 데이터가 사라진다. 만료가 되지 않았더라도 더 이상 데이터를 넣을 메모리가 없으면 LRU(Least recently used) 알고리즘에 의해 데이터가 사라져 저장소 메모리를 재사용한다. 그래서, 보통 대형 포털들에서 검색 결과 등을 캐시 하는 데 많이 사용한다.[4]
멤캐시드와 레디스 비교
[4]차이 Memcached Redis 처리 속도 처리 속도가 빠르다. 당연히 데이터가 메모리에만 저장되니 빠를 수 밖에 없다. 디스크 거치지 않음 처리 속도가 빠르다. 디스크와 메모리에 저장되는데도 멤캐시드랑 차이가 없다. 데이터 저장 데이터가 메모리에만 저장된다. 프로세스가 죽거나 끄는 즉시 데이터와는 이별해야 한다. 데이터는 메모리와 디스크에 저장되서 불의의 경우에도 데이터 복구가 가능하다. 만료일 지정 만료일을 지정해서 만료시 데이터는 캐시처럼 영원히 사라진다. 동일하다. 메모리 재사용 저장소 메모리를 재사용한다. 만료전에도 더 이상 데이터를 넣을 메모리가 없으면 데이터는 사라져 버린다. 저장소 메모리 재사용 없다. 명시적으로만 데이터 제거 가능하다. 데이터 타입 문자열만 지원한다. 문자열, Set, Sorted Set, Hash, List 데이터 타입을 지원한다.
장점
- 데이터 대부분을 디스크 또는 SSD에 저장하는 다른 데이터베이스와는 달리 모든 레디스 데이터는 서버의 주 메모리에 상주한다. 작업을 위해 대부분 디스크까지 왕복해야 하는 전통적인 디스크 기반 데이터베이스와 대조적으로, 레디스와 같은 인 메모리 데이터 스토어는 이와 같은 단점이 없다. 따라서 더 많은 작업을 처리하고 더 빠른 응답 시간을 지원할 수 있다. 그래서 평균 읽기 또는 쓰기 작업 속도 1밀리초 미만이라는 빠른 성능으로 초당 수백만 건의 작업을 할 수 있다.[5]
- 레디스에서는 더 짧은 코드 작성으로도 애플리케이션(Application)의 데이터를 저장, 액세스 및 사용할 수 있음으로 코드가 간소화된다. 예를 들어 애플리케이션의 데이터가 해시맵에 저장되어 있는데 이를 데이터 스토어에 저장하려는 경우, 레디스 해시 데이터 구조를 사용하면 간단하게 데이터를 저장할 수 있다. 해시 데이터 구조가 없는 데이터 스토어에서 유사한 작업을 수행하려면 형식을 변환하기 위해 더 긴 코드가 필요하다.[5]
- 레디스는 기본-복제 아키텍처(architecture)를 사용하며 비동기식 복제를 지원하므로 데이터가 여러 복제 서버에 복제될 수 있다. 따라서 주 서버에 장애가 발생하는 경우 요청이 여러 서버로 분산될 수 있음으로 향상된 읽기 성능과 더 빠른 복구 기능을 사용할 수 있다.[5]
- 레디스는 단일 노드 또는 클러스터링(clustering)된 토폴로지(topology)에서 기본-복제 아키텍처를 제공한다. 따라서 가용성이 뛰어난 솔루션을 구축하여 일관된 성능과 안정성을 사용할 수 있다. 클러스터 크기를 조정해야 하는 경우, 스케일업(scale-up), 스케일인(scale-in) 또는 스케일아웃(scale-out)할 수 있는 다양한 옵션이 있다. 따라서 수요에 맞춰 클러스터를 확장할 수 있다.[5]
- 리스트, 배열과 같은 데이터를 처리하는 데 유용하다. 밸류(value) 값으로 문자열, 리스트, Set, Sorted set, Hash 등 여러 데이터 형식을 지원한다. 따라서 다양한 방식으로 데이터를 활용할 수 있다. 리스트형 데이터 입력과 삭제가 MySQL에 비해서 10배 정도 빠르다고 한다.[6]
- 여러 프로세스에서 동시에 같은 key에 대한 갱신을 요청할 경우, 오토믹(Atomic) 처리로 데이터 부정합 방지 오토믹처리 함수를 제공한다.[6]
- 메모리를 활용하면서 영속적인 데이터를 보존한다. 명령어로 명식적으로 삭제, 만료(expires)를 설정하지 않으면 데이터가 삭제되지 않는다. 스냅샷(기억장치) 기능을 제공하여 메모리의 내용을 *.rdb파일로 저장하여 해당 시점으로 복구할 수 있다.[6]
- 레디스 서버(Redis Server)는 1개의 싱글 스레드로 수행되며, 따라서 서버 하나에 여러 개의 서버를 띄우는 것이 가능하다. Master - Slave 형식으로 구성이 가능하다. Master-Slave 방식으로 데이터 분실 위험을 없애준다.[6]
- 레디스에는 String, Lists, Sets, Sorted sets, Hashes의 5가지 데이터형을 사용할 수 있다.[6]
레디스 데이터 타입 종류
레디스 데이터 타입(Redis Data Type)에는 Strings, Lists, Sets, Hashes, Sorted sets, Bitmaps 등이 있다. Strings는 값에 문자, 숫자 등을 저장하고 저장 시에 별도로 숫자, 문자 구분이 없다. 숫자도 저장이 가능하며 숫자에 incr(특정 수를 더할 때), incrby(특정 수를 뺄 때) 같은 연산이 가능하다. Lists는 값에 리스트(list)를 저장한다. Sets는 값을 셋(set) 형태로 가지고 있는다. 리스트는 중복이 가능하지만 셋은 중복이 안된다. Hashes는 Hashs key/value 목록을 값으로 가진다. Sorted sets는 값을 셋 형태로 가지고 있는다. Sets와 마찬가지로 중복은 안 되고 리스트처럼 사용이 될거 같으나 정렬된다는 장점이 있는 것 같다. Bitmaps는 비트(bit)값을 저장해준다. 512MB(메가바이트)의 용량으로 2^32(42억)개의 비트값들을 저장할 수 있다.[5]
단점
- 메모리를 2배로 사용한다.
- 레디스는 싱글 스레드이기 때문에 스냅샷을 뜰 때 자식 프로세스를 하나 만들어낸 후 새로 변경된 메모리 페이지를 복사해서 사용한다.
- copy-on-write 방식을 사용한다. 보통 레디스를 사용할 때는 데이터 변경이 자주 있기 때문에 실제 메모리 크기만큼 자식 프로세스가 복사하게 된다. 그로 인해 실제로 필요한 메모리양보다 더 많은 메모리를 사용하게 된다.
- 대규모 트래픽으로 인해 많은 데이터가 업데이트되면 레디스는 Memcached에 비해서 속도가 불안정하다. 이것은 레디스와 Memcached 의 메모리 할당 구조가 다르기 때문에 발생하는 현상이다.
- jemalloc을 사용하기 때문에 매번 malloc과 free를 통해서 메모리 할당이 이루어진다. 반면 Memcached는 slab 할당자를 이용하여 내부적으로는 메모리 재할당을 하지 않고 관리하는 형태를 취한다. 이로 인해 레디스는 메모리 파편화가 발생하여 이 할당 비용 때문에 응답 속도가 느려진다. 다만 이는 극단적으로 봤을 때 발생하는 일이다. 대규모 서비스에서도 레디스를 많이 도입하는 것을 보면 일반적으로 스타트업 등에서 사용하여도 무방하다 볼 수 있다.[3]
사용시 주의할 점
레디스는 인메모리 데이터 저장소로서 서버에 장애가 났을 경우 데이터 유실이 발생한다. 따라서 스냅샷(Snapshot)과 에이오에프(AOF) 기능을 통한 복구 시나리오가 제대로 세워져 있어야 데이터 유실에 대비한 사고에 대처할 수 있다. 그리고 캐시 솔루션으로 사용할 시 잘못된 데이터가 캐시 되는 것을 방지, 예방해야 한다. 회사에서 레디스를 운영 중 전 개발자의 실수로 작성된 로직(logic)으로 캐시 데이터가 잘못 캐싱(caching)되어 올바르지 않은 데이터가 꺼내져 한동안 데이터가 꼬이는 일이 있었다. 레디스와 캐싱하고자 하는 데이터 저장소의 데이터가 서로 일치하는지 주기적인 모니터링과 이를 방지하기 위한 사내 솔루션을 개발하는 것이 좋다.[7]
활용
- 캐싱 :레디스는 데이터 액세스(Access) 지연 시간을 줄이고, 처리량을 늘리며, 관계형 또는 NoSQL 데이터베이스와 애플리케이션(Application)의 로드를 줄일 수 있는 가용성이 뛰어난 인 메모리 캐시(In Memory Cache) 구현에 적합하다. 레디스를 사용하면 빈번하게 요청되는 항목을 1밀리초(ms) 미만의 응답 시간으로 지원할 수 있고, 고가의 백 엔드를 추가하지 않고도 손쉽게 확장하여 더 많은 로드를 처리할 수 있다.[8]
- 채팅, 메시징 및 대기열:레디스는 패턴 매칭과 다양한 데이터 구조옵션으로 게시/구독을 사용할 수 있다. 따라서 레디스에서는 고성능 채팅방, 실시간 코멘트 스트림, 소셜 미디어 피드 및 서버 상호 통신을 지원한다. 레디스 목록 데이터 구조를 사용하면 간단한 대기열을 손쉽게 구현할 수 있다. 목록은 자동 작업 및 차단 기능을 제공하므로 신뢰할 수 있는 메시지 브로커 또는 순환 목록이 필요한 다양한 애플리케이션에 적합하다.[8]
- 다양한 미디어 스트리밍:레디스는 라이브 스트리밍 사용 사례를 지원할 수 있는 빠른 인 메모리 데이터 스토어를 제공한다. 레디스는 CDN(Contents Delivery Network)이 동시에 수백만 명의 모바일 및 데스크톱 사용자에게 비디오를 스트리밍할 수 있도록 사용자 프로필 및 열람 기록에 대한 메타데이터, 수백만 사용자의 인증 정보/토큰, 매니페스트 파일을 저장하는 데 사용할 수 있다.[8]
- 지리 공간:레디스는 대규모의 실시간 지리 공간 데이터를 빠르게 관리할 수 있도록 특별히 구축된 인 메모리 데이터 구조 및 연산자를 제공한다. 지리 공간 데이터를 실시간으로 저장, 처리 및 분석하는 명령을 사용하면 레디스에서 쉽고 빠르게 지리 공간을 처리할 수 있다. 레디스를 사용하여 주행 시간, 주행 거리, 안내 표시와 같은 위치 기반 기능을 애플리케이션에 추가할 수 있다.[8]
- 실시간 분석:레디스는 스트리밍 솔루션에 인 메모리 데이터 스토어로 사용하여 1밀리초 미만의 지연 시간으로 실시간 데이터를 수집, 처리 및 분석할 수 있다. 레디스는 소셜 미디어 분석, 광고 타게팅(Targeting), 개인화 및 IoT와 같은 실시간 분석 사용 사례에 적합하다.[8]
레디스 활용 사례
- 좋아요 처리하기: 좋아요 처리에서 가장 중요한 것은 한 사용자가 하나의 댓글에 좋아요를 한 번씩만 할 수 있다는 것이다. RDBMS(관계형 데이터베이스 관리 시스템, Relational DataBase Management System)에서 유니크 조건을 걸어서 구현할 수 있지만, 인서트(insert)와 업데이트(update)가 자주 발생하는 경우 RDBMS 성능 저하가 필연적으로 발생하게 된다. 레디스의 셋을 이용하면 간단하게 구현할 수 있으며, 빠른 시간 안에 처리할 수 있다. 댓글의 번호를 key로 하고, 해당 댓글에 좋아요를 누른 회원 ID를 아이템으로 추가하면 조건을 만족할 수 있다.[9]
- 게임 서비스에서 일일 순 방문자 수 구하기: 순 방문자 수는 서비스에 사용자가 하루에 여러 번 방문했더라도 한 번만 카운팅 되는 값이다. 이를 구현하기 위해서는 구글 애널리틱스(Analytics)와 같은 외부 서비스를 이용하거나 접속 정보를 로그 파일로 작성하여 배치 프로그램을 작성하는 방법들이 있다. 레디스의 비트 연산을 활용하면 간단하게 실시간 순 방문자를 저장하고 조회하는 방법을 구현할 수 있다.[9]
- 출석 이벤트 구현하기: 일일 순 방문자 수 구하기를 이용해 매일 방문자를 구현하였고, 구해놓은 String 간의 비트를 비교하는 BITOP 커맨드를 사용하면 이 서비스를 구현할 수 있다.[9]
평가 및 전망
망설임 없이 새로운 프로젝트 또는 멤캐시드를 사용하지 않는 기존 프로젝트의 경우 멤캐시드보다 레디스를 권장한다. 레디스는 멤캐시드가 수행하는 모든 작업을 더 잘 수행한다. 멤캐시드의 성능 이점은 작고 작업 부하에 따라 다르다. 레디스가 더 빨라질 워크로드(work load)와 레디스가 수행할 수 있는 더 많은 워크로드가 있다. 두 도구가 빠르고 효율적이라는 사실은 확장에 대해 염려해야 할 인프라(infrastructure)의 마지막 부분일 수 있다. 멤캐시드가 더 적합한 시나리오는 멤캐시드가 이미 캐시로 사용 중인 경우다. 이미 멤캐시드로 캐싱하는 경우 필요에 따라 계속 사용한다. 레디스로 옮기는 노력은 가치가 없으며 아마도 캐싱을 위해 레디스를 사용하려는 경우 시간 가치가 충분하지 않을 수 있다. 멤캐시드가 요구 사항을 충족하지 못하면 아마도 레디스로 이동해야 한다. [10]
각주
- ↑ 레디스란 무엇입니까? 아마존 웹서비스 - https://aws.amazon.com/ko/elasticache/what-is-redis/
- ↑ Redis Wikipedia - https://en.wikipedia.org/wiki/Redis
- ↑ 3.0 3.1 goodGid , 〈레디스 개념과 특징 〉, 《깃허브 》, 2018-10-28
- ↑ 4.0 4.1 4.2 JIHYE KANG, 〈레디스란 무엇인가? 〉 , 《 미디엄》, 2019-01-05
- ↑ 5.0 5.1 5.2 5.3 5.4 레디스 아마존 웹 서비스 - https://aws.amazon.com/ko/redis
- ↑ 6.0 6.1 6.2 6.3 6.4 〈레디스 개념 및 특징 〉, 《티스토리》, 2016-06-10
- ↑ 새로비, 〈레디스 소개 및 아키텍처, 주의할점 〉, 《티스토리》, 2019-06-01
- ↑ 8.0 8.1 8.2 8.3 8.4 레디스란 무엇입니까? 아마존 웹서비스 - https://aws.amazon.com/ko/redis
- ↑ 9.0 9.1 9.2 taehyun_kim, 〈레디스(Redis)의 다양한 활용 사례 〉, 《티스토리》, 2020-03-17
- ↑ Memcached vs Redis it-swarm - https://www.it-swarm.dev/ko/caching/memcached-%EB%8C%80-redis/1067241005/
참고 자료
- 레디스란 무엇입니까? 아마존 웹서비스 - https://aws.amazon.com/ko/elasticache/what-is-redis/
- Redis Wikipedia - https://en.wikipedia.org/wiki/Redis
- goodGid , 〈레디스 개념과 특징 〉, 《깃허브 》, 2018-10-2
- JIHYE KANG, 〈레디스란 무엇인가? 〉 , 《 미디엄》, 2019-01-05
- 레디스 아마존 웹 서비스 - https://aws.amazon.com/ko/redis
- 〈레디스 개념 및 특징 〉, 《티스토리》, 2016-06-10
- 새로비, 〈레디스 소개 및 아키텍처, 주의할점 〉, 《티스토리》, 2019-06-01
- 레디스란 무엇입니까? 아마존 웹서비스 - https://aws.amazon.com/ko/redis
- taehyun_kim, 〈레디스(Redis)의 다양한 활용 사례 〉, 《티스토리》, 2020-03-17
- Memcached vs Redis it-swarm - https://www.it-swarm.dev/ko/caching/memcached-%EB%8C%80-redis/1067241005/
같이 보기
