Redis
레디스(Redis)란?
REDIS(REmote Dictionary Server)는 메모리 기반의 “키-값” 구조 데이터 관리 시스템이며,
모든 데이터를 메모리에 저장하고 조회하기에 빠른 Read, Write 속도를 보장하는 비 관계형 데이터베이스
레디스는 크게 5가지< String, Set, Sorted Set, Hash, List >의 데이터 형식을 지원합니다.
Redis는 빠른 오픈 소스 인 메모리 키-값 데이터 구조 스토어이며, 다양한 인 메모리 데이터 구조 집합을 제공하므로 사용자 정의 애플리케이션을 손쉽게 생성할 수 있습니다.
레디스(Redis) 특징
영속성을 지원하는 인메모리 데이터 저장소
읽기 성능 증대를 위한 서버 측 복제를 지원
Redis가 실행중인 서버가 충돌하는 경우 장애 조치 처리와 함께 더 높은 읽기 성능을 지원하기 위해 슬레이브가
마스터에 연결하고 전체 데이터베이스의 초기 복사본을 받는 마스터 / 슬레이브 복제를 지원함.
마스터에서 쓰기가 수행되면 슬레이브 데이터 세트를 실시간으로 업데이트하기 위해 연결된 모든 슬레이브로 전송
- 쓰기 성능 증대를 위한 클라이언트 측 샤딩(Sharding)을 지원
샤딩 : 같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스에 분산하여 저장하는 방법을 의미
- 문자열, 리스트, 해시, 셋, 정렬된 셋과 같은 다양한 데이터형을 지원한다.
레디스(Redis)의 장점
-
리스트, 배열과 같은 데이터를 처리하는데 유용
-
리스트형 데이터 입력과 삭제가 MySQL에 비해서 10배정도 빠름
여러 프로세스에서 동시에 같은 key에 대한 갱신을 요청할 경우,
Atomic 처리로 데이터 부정합 방지 Atomic처리 함수를 제공한다.(원자성)
-
메모리를 활용하면서 영속적인 데이터 보존
-
Redis Server는 1개의 싱글 쓰레드로 수행되며, 따라서 서버 하나에 여러개의 서버를 띄우는 것이 가능
Master — Slave 형식으로 구성이 가능함, 데이터 분실 위험을 없애주는 것이 바로 Master — Slave 방식
레디스에서 주의해야할 점
- 저장된 모든 키를 보여주는 명령어(keys)나 모든 데이터를 소거하는 명령어(flushall)
모든 키를 보여주거나 플러싱하는 명령어는 테스트 환경이나 소량의 데이터를 관리하는 시스템에서
모니터링하는 용도로만 써야 하며 실행 대상을 전수처리하기 때문에 점차 데이터를 쌓아가는 환경에서는 운영에 차질을 빚을 정도로 속도가 느려 짐
- 멤캐시드 때문에 사람들이 레디스에서도 이 명령어가 금방 처리될 거라 기대하기도 하는데 실제 작동하는 방식이 완전히 다름
명령어 수행 시간을 재 보면 멤캐시드는 항상 일정하게 1~2ms가 나오는데 레디스는 데이터 100만건 정도 기준으로 1초(1천ms)로 이미 훨씬 느리다, 이건 실패한 사용법
- 레디스는 인메모리DB라 빠른 속도가 강점이지만 큰 용량의 데이터를 담기엔 공간 제약
그래서 실시간 처리는 인메모리에서, 보관은 디스크 기반 스토리지로 하는 구조가 성능과 효율을 함께 달성할 수 있음
트위터, 인스타그램, 페이스북처럼 대규모 사용자 기반을 갖춘 인터넷 서비스 업체들도 이런 식으로 서비스를 설계
- 용량 측면에서의 주의점
레디스는 32비트 환경에선 최대 3GB 메모리만 사용 가능하고 64비트 시스템에서는 그런 제약이 없어 운영체제(OS)의 가상메모리(스왑)까지 사용함
하지만 이 경우 시스템의 메모리 한계를 인식하지 못해 더 많은 메모리를 요구하다가 문제를 일으킬 수 있어 관리자가 따로 설정을 더해줘야 함
- 레디스는 멤캐시드에서 지원 안 하는 명령어 ‘콜렉션’을 지원하지만 앞서 ‘플러시올’이나 ‘키즈’같이 싱글쓰레드 방식에서 쓰지 말아야 하는 기능
콜렉션에 데이터 100만건을 넣으면 처리시간이 10초, 1천만건 넣으면 100초씩 걸리는 식으로 늘어나기 때문에 굳이 쓰려면 일단 데이터를 1만건 미만으로 관리해야함
- 레디스에서 디스크에 메모리 상태를 그대로 받아 저장하는(메모리스냅숏) RDB 기능이 레디스 서버 장애요인 99.9%를 차지, 원한다면 이 기능을 그냥 꺼야함
아마존 웹서비스 서버 기준으로 60GB짜리 메모리 서버 테스트시 RDB 작업에 10분 정도가 걸림
싱글쓰레드 문제를 겪지 않기 위해 'Fork()'라는 분기 기능을 쓸 수 있지만 이 경우 메모리를 2배로 잡아먹어, 용량부족에 따른 오류와 원인을 알수 없는 장애를 낼 수있음
이어지는 효과로, RDB 작업이 실패하면 '쓰기 거부' 상태가 돼 추가 장애를 낼 수있음
- AOF와 그로 인한 문제 사례
메모리상의 정보를 디스크에 저장한다는 점은 RDB와 비슷하나,
AOF는 레디스 프로토콜로 통신한 내용들을 명령어, 키, 이름 등 형식 그대로 저장한다는 점이 다름
다만 RDB 사용시 주의사항은 AOF에도 동일하게 적용
- 레디스의 ‘마스터’와 ‘슬레이브’라는 개념과 관리 요령을 숙지
레디스 시스템에서 슬레이브는 이름처럼 마스터의 데이터 저장을 보조함.
마스터가 죽었다가 되살아날 때 자신의 정보를 모두 없애고 그 데이터를 그대로 베낌.
별도 조치 없이 아무 데이터가 없는 마스터를 시스템에 연결하면 슬레이브에 남은 데이터를 마스터에 되살릴 수 없다는 점이 포인트.
이를 피하려면 복구할 데이터를 가진 시스템에 '슬레이브오브노원'이라는 명령어를 줘서 그걸 마스터로 승격
Reference
https://medium.com/@jyejye9201/%EB%A0%88%EB%94%94%EC%8A%A4-redis-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-2b7af75fa818
https://zdnet.co.kr/view/?no=20131119174125