승하연서빠의 작업 메모

아래 링크 사이트에 redis의 모든 사용법/명령어/교육/유지보수/ 이런내용들이 다 있습니다.

http://redisgate.kr/redisgate/ent/ent_intro.php

▶︎▶︎▶︎레디스 클러스터, 센티넬 구성 및 레디스 동작 방식

RDBMS만큼의 정합성과 영속성을 보장할 필요가 없는 데이터들을 빠르게 처리하거나 일정 기간동안만 보관하고 있기 위한 용도로 레디스(Redis), memcached 등의 in-memory 기반 저장소가 많이 사용된다. 그중에서도 Redis는 빠른 성능을 유지하면서도 일정 수준 이상의 persistence를 제공하고, 다양한 native 데이터 구조들을 제공하여 효율적이고 편리한 사용이 가능하게 해주기 때문에 다양한 use-case들이 존재한다.

이 글은 실제 명령어를 날려서 레디스를 직접 사용해보는 것을 배우기 보다는 어떤 in-memory 저장소를 선택할지 고민하는 분들을 위해서 주요 운영 방식, 레디스의 내부 동작 방식 및 특징, 주요 클라이언트들에 대한 정보를 제공하는 쪽에 초점이 맞춰져 있다.

운영 모드 (Operation Modes)

레디스는 단일 인스턴스만으로도 충분히 운영이 가능하지만, 물리 머신이 가진 메모리의 한계를 초과하는 데이터를 저장하고 싶거나, failover에 대한 처리를 통해 HA를 보장하려면 센티넬이나 클러스터 등의 운영 모드를 선택해서 사용해야 한다. 각 모드들이 어떤 특성을 갖는지 좀더 자세히 알아보도록 하자.

• 단일 인스턴스(Single instance)
  • HA(High availibilty) 지원 안됨.
• 센티넬(Sentinel)
  • HA 지원
  • master/slave replication
  • sentinel process
    • redis와 별도의 process
    • 여러개의 독립적인 sentinel process들이 서로 협동하여 운영된다 (SPOF 아님)
    • 안정적 운영을 위해서는 최소 3개 이상의 sentinel instance 필요 (fail over를 위해 과반수 이상 vote 필요)
      • redis process가 실행되는 각 서버마다 각각 sentinel process를 띄워놓는 방법
      • redis process가 실행되는 서버와 별개로 redis에 액세스를 하는 application server들에 sentinel process를 띄워놓는것도 가능
      • 등등 다양한 구성이 가능
    • 지속적으로 master/slave 가 제대로 동작을 하고있는지 모니터링
    • master에 문제가 감지되면 자동으로 failover 수행
  • 클라이언트는 어떻게 redis server에 연결해서 데이터를 조회하나?
    • 먼저 sentinel에 연결해서 현재 master를 조회해야 한다.
• 클러스터(Cluster)
  • HA, sharding 지원
    • Sentinel과 동시에 사용하는 것이 아님! 완전히 별도의 솔루션.
    • dataset을 자동으로 여러 노드들에 나눠서 저장해준다.
    • Redis Cluster 기능을 지원하는 client를 써야만 데이터 액세스 시에 올바른 노드로 redirect가 가능하다.
  • Cluster node들의 동작 방식
    • serve clients 6379 (data port)
    • cluster bus 16379 (data port + 10000)
      • 자체적인 바이너리 프로토콜을 통해 node-to-node 통신을 한다.
      • failure detection, configuration update, failover authorization 등을 수행
    • 각 노드들은 클러스터에 속한 다른 노드들에 대한 정보를 모두 갖고있다.
  • Sharding 방식
    • 최대 1000개의 노드로 샤딩해서 사용. 그 이상은 추천하지 않음
    • consistent hashing을 사용하지 않는대신 hashslot이라는 개념을 도입
    • hashslot
      • 결정방법 CRC16(key) mod 16384를
        • CRC16을 이용하면 16384개의 슬롯에 균일하게 잘 분배됨
      • 노드별로 자유롭게 hash slot을 할당 가능
      • 예)
        • Node A contains hash slots from 0 to 5500.
        • Node B contains hash slots from 5501 to 11000.
        • Node C contains hash slots from 11001 to 16383.
    • 운영 중단 없이 hash slots을 다른 노드로 이동시키는 것이 가능
      • add/remove nodes
      • 노드별 hashslot 할당량 조정
    • multiple key operations 을 수행하려면 모든 키값이 같은 hashslot에 들어와야 한다.
      • 이를 보장하기위해 hashtag 라는 개념 도입
        • {} 안에있는 값으로만 hash 계산
        • {foo}_my_key
        • {foo}_your_key
  • Replication & failover
    • failover를 위해 클러스터의 각 노드를 N대로 구성가능 
    • master(1대) / slave(N-1대)
    • async replication (master → slave replication 과정에서 ack을 받지 않음)
      • 데이터 손실 가능성 존재
      • master가 client요청을 받아서 ack을 완료한 후, 해당 요청에 대한 replication이 slave로 전파되기 전에 master가 죽는 경우 존재
  • 클라이언트는 클러스터에 어떻게 연결해서 데이터를 조회하나?
    • redis client는 클러스터 내의 어떤 노드에 쿼리를 날려도 된다(슬레이브에도 가능).
      • ex) GET my_key
    • 쿼리를 받은 노드가 해당 쿼리를 분석
      • 해당 키를 자기 자신이 갖고있다면 바로 찾아서 값을 리턴
      • 그렇지 않은경우 해당 키를 저장하고 있는 노드의 정보를 리턴 (클라이언트는 이 정보를 토대로 쿼리를 다시 보내야함)
      • ex) MOVED 3999 127.0.0.1:6381

메모리 동작 방식

• key가 만료되거나 삭제되어 redis가 메모리를 해제하더라도, OS에서 해당 분량만큼 바로 메모리가 확보되진 않음
  • 꼭 redis에만 해당되는 이야기는 아님
  • 5GB중 3GB의 데이터를 메모리에서 해제 -> OS 메모리 사용량은 여전히 5GB
  • 하지만 다시 데이터를 add하면 logically freed된 영역에 잡히므로 실제 메모리 5GB를 넘지는 않는다.
• 따라서 peak memory usage 기준으로 잡아야 한다.
• 대부분 5GB 정도 사용하고 가끔 10GB 가 필요하더라도, 10GB 메모리를 이상의 머신이 필요.
• maxmemory 설정을 해두는게 좋음 (하지 않으면 무한히 메모리 사용하다가 머신 전체가 죽을 가능성)
  • maxmemory 설정시의 eviction policy
    • no-eviction (추가 memory를 사용하는 write command에 대해 에러 리턴)
    • allkeys-lru (전체 아이템 중에서 LRU)
    • volatile-lru (expire 되는 아이템 중에서 LRU)
    • volatile-ttl (expire 되는 아이템 중 TTL이 얼마 안남은 녀석 순으로)
  • RDB persistence를 사용한다면 maxmemory를 실제 가용 메모리의 45%정도로 설정하는것을 추천. 스냅샷을 찍을때 현재 사용중인 메모리의 양만큼 필요하다. (5%는 오버헤드에 대비한 마진)
  • 사용하고 있지 않다면 가용 메모리의 95%정도로
• 동일 key-value 데이터를 저장한다고 가정했을 때, Cluster Mode를 사용할 경우 Single instance 보다 1.5~2배 정도 메모리를 더 사용하는것에 주의해야 한다.
  • Redis cluster의 경우 내부적으로 cluster안에 저장된 key를 hashslot으로 맵핑하기 위한 테이블을 가지고 있기 때문에 추가적인 memory overhead가 발생한다.
  • 이때문에 key의 숫자가 많아질수록 이러한 현상이 더 두드러진다
  • 4.x 버전에 이와 관련한 메모리 최적화 기능이 들어가서 3.x 버전보다는 더 적게 메모리를 사용하지만, 여전히 Single instance보다는 많은 메모리를 필요로 한다.

데이터 영속성 (Data Persistence)

memcached의 경우 데이터가 메모리에만 저장되기 때문에 프로세스가 재기동되면 메모리상의 데이터는 모두 유실된다. 하지만 redis의 경우 기본적으로 disk persistence가 설정되어있기 때문에, 프로세스를 재시작 하더라도 셧다운 되기 전의 마지막 상태와 거의 동일한 (약간의 손실은 있을 수 있다) 상태로 돌려 놓을 수 있다.

• RDB persistence
  • 일정 인터벌로 point-in-time snapshots을 생성
  • compact한 단일 파일로 저장됨 백업하기 좋음
  • 부모 프로세스는 자식 프로세스를 fork. fork된 프로세스에서 모든 persist I/O처리
  • restart 시간이 빠르다
    • H/W 사양에 따라 다르겠지만 보통 메모리 사용량 1GB당 10~20 초정도 로드타임
  • 멈췄을때 데이터 유실 가능성이 더 높다.
  • 몇 분 정도의 데이터 유실 가능성을 감내 할 수 있다면 RDB를 쓰는것을 추천
• AOF (append only file)
  • 모든 write operation 을 log로 남기고 서버 재시작 시점에 replay
  • 데이터 양이 많아지면 해당 시점의 데이터셋을 만들어낼 수 있도록하는 minimum log들만 남기는 compaction을 진행
  • 읽기 쉬운 포멧이지만 RDB보다 용량이 크다
  • write 리퀘스트가 많을때 RDB보다 반응성이 느리다
• 참고: http://oldblog.antirez.com/post/redis-persistence-demystified.html

라인 메신저의 메시징 시스템에서는 RDB또는 AOF 사용으로 인해

트랜잭션 모델(Transaction model)

• Redis는 single threaded model이고 요청이 들어온 순서대로 처리한다
• MULTI → commands → EXEC/DISCARD
• MULTI 이후의 명령들은 queue에 넣어뒀다가 EXEC가 불린순간 순차적으로 진행
  • EXEC를 통해서 실행중일때는 다른 connection에서 중간에 끼어들지 못한다
• command 실행중에 에러가 발생해도 롤백하지 않고 계속 진행한다.
  • command에 잘못된 명령어나, 잘못된 타입의 인자를 넣었을때 에러 발생 -> 거의 개발자의 실수
  • 롤백기능을 없앤 덕분에 훨씬 빠른 성능 제공 가능
• optimistic locking (using CAS operation) 사용
  • 값의 변경을 모니터링하다가, 값이 변경되었다면 현재 트랜잭션을 취소하고 다시 처음부터 실행
  • WATCH
    • 특정 키값이 변경되지 않은 경우에만 EXEC를 수행, 변경된경우 transaction자체를 수행하지 않음
    • EXEC가 불리는 시점에 모든 key에 대한 WATCH가 자동으로 UNWATCH됨
    • client의 연결이 끝나는 시점에도 모든 key에 대해 UNWATCH됨
  • 예시)
    • WATCH mykey
    • val = GET mykey
    • val = val + 1
    • MULTI
    • SET mykey $val
    • EXEC

주요 특수 기능

• 다양한 데이터 구조 지원
  • 단순히 key – value 문자열만 저장하는 것이 아니라 고수준의 데이터 구조를 사용 가능하다
  • ex) Hash, Set, List, SortedSet, etc.
  • Hash
    • HSET(key, fields, value), HGET(key, field)
    • web application에서 특정 유저 userId를 key로 두고 해당 유저의 세부 정보들(name, email 등)을 field로 둔다
    • 이렇게하면 특정 유저와 관련된 정보들을 한번에 삭제하는 등의 namespace처럼 사용하는것도 가능하다.
    • hash key당 1000개 정도의 field까지는 레디스가 zipmap을 이용해 압축해서 저장한다
      • 동일한 value 1000개를 저장할때 방식에 따른 메모리 사용량을 비교
        • “1000개의 키에 저장” > “1개의 키 안에 100개의 field로 저장”
      • 대신 CPU사용량이 증가하므로 어플리케이션 특성에 맞게 적정 갯수를 잘 선택해야한다.
      • 참고: https://instagram-engineering.com/storing-hundreds-of-millions-of-simple-key-value-pairs-in-redis-1091ae80f74c
      • 참고: https://redis.io/topics/memory-optimization
• Expiration 지정
  • key별로 TTL(Time-To-Live)을 정해두면 레디스가 알아서 해당 시점이 지날때 key 삭제
  • 설정된 max memory에 도달하면 expire되지 않은 key들도 eviction policy에 따라 삭제될 수 있다.
• Pipelining
  • 여러 커맨드들을 한번에 모아서 보낸후, 실행 결과도 한번에 모아서 받는다.
  • 레이턴시가 큰 네트워크 환경이라면 명령어 하나당 한번의 request/response를 할 때보다 스루풋을 올릴 수 있음.
• Pub/Sub (출판/구독 모델)
  • 하나의 클라이언트가 같은 채널에 연결된 다른 클라이언트들에게 메시지들을 보내는 것이 가능
  • 이를 이용하여 속도가 빠른 메시지 브로드캐스터 혹은 메시지 큐 처럼 사용하는것이 가능하다.
• Lua scripting
  • 여러 명령어들이 사용되는 복잡한 작업을 할 때 (특히 트랜잭션이 사용되는 경우) 이를 하나의 lua script로 만들어서 사용할 수있다.
  • 스크립트는 atomic하게 실행되기 때문에 optimistic locking transactions 를 사용할 필요가 없다.

지표 모니터링 (Monitoring Metrics)

• used_memory
• total_commands_processed
  • 이 지표와 요청/응답 latency 로깅해두면 명령어 처리량 대비 latency를 알 수 있다.
  • redis-cli -h {host} -p {port} —latency
• slow command
  • slowlog get 명령으로 확인
• client connections
  • info clients 명령으로 확인
  • 대략 5000개 이상의 커넥션들이 존재한다면 응답 시간이 느려지고 있을 가능성이 있으니 주의깊게 모니터링
  • maxclients 값을 대략 예상되는 connection 숫자의 1.1배~1.5배정도로 설정해 두면 안전함
• mem_fragmentation_ratio
  • 정의 = 실제 물리 메모리 사용량 / 레디스의 메모리 사용량
  • 1 이면 이상적인 상태, 커질수록 파편화 심화
  • 1.5가 넘는다면 서버 재시작 추천
  • 1보다 작은 경우
    • 레디스의 메모리 사용량이 실제 물리 메모리 사용량보다 큰 경우는 OS에 의해 메모리의 일부가 swap되어 디스크로 이동되었을때 나타남
    • 디스크 사용으로 인해 성능 저하 발생
    • 메모리 사용량을 줄이거나 램 용량 증설 필요
• 참고: https://www.datadoghq.com/pdf/Understanding-the-Top-5-Redis-Performance-Metrics.pdf

클라이언트 핸들링(Client Handling)

• maxclients 설정 가능
  • 설정된 maxclient 도달시에 
• timeout default = forever
• Redis 3.2 이상부터 TCP keep-alive 디폴트로 켜져있음(약 300초)

Redis Client library for Java

언어별로 레디스 클라이언트 라이브러리들이 다양하게 존재하고 있다. 그중에서 자바언어로 만들어진 가장 많이 사용되는 3가지를 뽑아서 비교해 보았다.
async style API를 사용하는 경우 처리량(throughput)을 높일 수 있지만 오히려 개별 요청에 대한 응답 지연(latency)은 sync API 보다 더 느려질 수 있으니 상황에 맞게 선택해서 사용하는 것이 좋다.

• jedis
  • https://github.com/xetorthio/jedis
  • light & simple (sync API only)
  • low level 명령을 직접 실행
  • connection pool
  • master에만 명령 실행 가능 (slave 선택 불가)
  • http://www.baeldung.com/jedis-java-redis-client-library
• redisson
  • https://github.com/redisson/redisson
  • async & sync API (netty기반이라 좀 헤비하다)
  • high-level abstraction 명령어가 아닌 객체를 조작
    • 예) Map이나 Set 객체를 생성해서 사용하면 해당 객체가 Redis서버에 자동으로 싱크가됨 (데이터 마샬링 필요 없음)
    • jedis 방식: redis get → java model object → redis put
    • redisson 방식: get RObject → modify RObject (modification sync to redis internally by redisson)
  • https://stackoverflow.com/questions/42250951/redisson-vs-jedis-for-redis
• lettuce
  • https://lettuce.io/
  • async & sync API (netty기반이라 좀 헤비하다)
  • read only 명령어에 대해서는 master/slave에 선택적으로 실행 가능

본문 출처 : 코딩스타트 :: Springboot,Redis - Springboot Redis Nodes Cluster !(레디스 클러스터) (tistory.com)

이전 포스팅에서는 Redis Server들의 고가용성을 위해 Redis Sentinel을 구성하여 Master-Slave 관계의 구성을 해보았습니다. 

▶︎▶︎▶︎Redis Sentinel 구성

Sentinel을 구성하여 Redis Server들의 고가용성을 키워주는 방법 이외에도 사실 Redis는 Cluster라는 좋은 기능을 지원해줍니다.

그럼 Sentinel은 무엇이고 Redis Cluster는 다른 것인가? 대답은 엄연히 다른 기능입니다. 

간단히 비교하면 Sentinel는 Master-Slave관계를 구성합니다.(Redis Server 끼리 구성을 갖춤).

하지만 Redis Server 이외에 Sentinel 인스턴스를 띄워주어야합니다. 그런 Sentinel 인스턴스들은 Redis Server들을 모니터링하고 고가용성을 위한 적당한 처리를 해줍니다. 그리고 Redis Server끼리의 데이터 동기화도 마춰줍니다. 이말은,

모든 Redis Server는 모두 같은 데이터들을 가지고 있는 것이죠.

하지만 Cluster를 이용하면 각 Redis Server들은 자신만의 HashSlot을 할당 받게 됩니다. 그리고 Cluster도 Master-Slave 관계를 구성하게 됩니다.

이말은 무엇이냐? 대략 16000개의 데이터 바구니를 나누어가지는 Redis Server들은 Master가 됩니다.

Sentinel과는 다르게 하나의 마스터만 갖는 것이 아닙니다. 그리고 각 마스터에 대한 Slave 서버를 가지게 되는 것입니다. 더 자세한 사항은 아래 링크를 참조해주세요.

▶︎▶︎▶︎Cluster&Sentinel 그리고 Redis

이제는 Redis Cluster 구성을 해보겠습니다. 오늘 구성해볼 아키텍쳐입니다.

혹시나 Redis를 설치와 간단한 사용법에 대해 모르신다면 아래링크를 참조해주세요.

▶︎▶︎▶︎Redis 설치와 사용법

3개의 Master와 3개의 Slave 입니다.(편의상 Redis 폴더의 루트 == $REDIS)

$REDIS 위치에 cluster라는 폴더를 하나 구성해줍니다. 

그리고 해당 $REDIS/redis.conf를 cluster 폴더에 6개를 복사해줍니다.(redis-cluster1~6.conf)

이제 각 redis-cluster 설정파일을 수정할 것입니다. 이번에 할 설정은 간단한 설정입니다. 프러덕환경에서는

더 세부적인 설정이 필요할 수 있습니다.

이번예제는 동일한 서버에 6개의 port를 나누어 진행합니다. 만약 서로 다른 서버에 구성을 하시기 위해서는

적절히 인스턴스들을 나누어주시고 각 서버에 대해 포트 개방이 필요합니다.

redis-cluster1.conf - port:6379

설정은 직관적으로 어떠한 설정에 대한 것인지 알수 있습니다. 해당 인스턴스의 포트는 6379를 사용하고

클러스터를 사용하겠다. 그리고 해당 인스턴스가 클러스터에 대한 정보를 남기기위해 nodes.conf를 사용한다.

또한 타임아웃은 5초로 하고 모든 데이터는 영속하기 위해 항상 write마다 기록한다 라는 설정입니다.(데이터 유실방지)

나머지 인스턴스들의 설정도 port와 cluster-config-file의 설정만 구분하고 동일하게 작성합니다.

ex) port 6380, cluster-config-file nodes2.conf

설정 파일작성이 끝나셨으면 6개의 터미널을 띄워줍니다.

>cd src

>./redis-server ../cluster/redis-clusterN.conf 

총 6개의 레디스 인스턴스를 실행시킵니다.

그리고 하나 추가적으로 작업을 해주어야할 것이 있습니다. 실행되고 있는 인스턴스에 대해

명시적으로 클러스터 구성을 생성해주는 작업입니다. 이 과정은 버젼에 따라 총 2가지의 방법이 있습니다.

$REDIS/src 의 redis-cli를 이용한 방법입니다. 클러스터 구성에 참여하는 인스턴스 정보를 모두 입력하고 마지막에 replicas 속성을

명시해줍니다. 마지막 속성은 마스터에 대한 슬레이브를 몇개를 둘것인가 라는 설정입니다.

동일한 속성에 대한 redis-trib.rb를 이용한 클러스터 구성방법입니다.

저는 첫번째 방법을 이용하였습니다. 명령어를 탁 치는 순간 3개는 마스터 3개는 슬레이브 노드를 임의로 

선택해 이렇게 클러스터를 구성하겠습니까? 라는 질문에 yes||no로 답변해주어야합니다. yes를 입력합니다.

이제는 클러스터 구성이 잘 되었는지 확인해볼까요?

잘 구성이 되었습니다 ! 여기서 한가지 집고 넘어가야 할 것이 있습니다. Redis Cluster 사용을 위해서는 그에 맞는 클라이언트가 필요합니다. 저는

그 클라이언트를 Springboot를 이용하여 구성해보았습니다. springboot의 Spring Redis 프로젝트를 생성해줍니다!

application.propeties 파일입니다. 클러스터에 참여하는 노드들을 나열해줍니다.

properties에 나열한 노드들의 정보를 얻기위한 빈을 하나 띄워줍니다. 물론 @Value로 직접 주입시켜주어도 상관없습니다. 해당 방법은 Spring Redis Document에 나온데로 진행하고 있는 중입니다.

/**
 * Redis Configuration
 * @author yun-yeoseong
 *
 */
@Configuration
public class RedisConfig {
    
    
    /**
     * Redis Cluster 구성 설정
     */
    @Autowired
    private RedisClusterConfigurationProperties clusterProperties;
    
    /**
     * JedisPool관련 설정
     * @return
     */
    @Bean
    public JedisPoolConfig jedisPoolConfig() {
        return new JedisPoolConfig();
    }
    
    
    /**
     * Redis Cluster 구성 설정
     */
    @Bean
    public RedisConnectionFactory jedisConnectionFactory(JedisPoolConfig jedisPoolConfig) {
        return new JedisConnectionFactory(new RedisClusterConfiguration(clusterProperties.getNodes()),jedisPoolConfig);
    }
    
    /**
     * RedisTemplate관련 설정
     * 
     * -Thread-safety Bean
     * @param jedisConnectionConfig - RedisTemplate에 설정할 JedisConnectionConfig
     * @return
     */
    @Bean(name="redisTemplate")
    public RedisTemplate redisTemplateConfig(JedisConnectionFactory jedisConnectionConfig) {
        
        RedisTemplate redisTemplate = new RedisTemplate<>();

        redisTemplate.setKeySerializer(new StringRedisSerializer());
        redisTemplate.setValueSerializer(new StringRedisSerializer());
        redisTemplate.setConnectionFactory(jedisConnectionConfig);
        
        return redisTemplate;
        
    }
    
    /**
     * 문자열 중심 편의 RedisTemplate
     * 
     * @param jedisConnectionConfig
     * @return
     */
    @Bean(name="stringRedisTemplate")
    public StringRedisTemplate stringRedisTemplate(JedisConnectionFactory jedisConnectionConfig) {
        StringRedisTemplate stringRedisTemplate = new StringRedisTemplate(jedisConnectionConfig);
        
        return stringRedisTemplate;
    }
    
}

Redis Config를 위한 자바클래스입니다. 이제 정말로 잘되는지 확인해볼까요?

결과값으로 "yoon"이라는 값을 얻어옵니다. 그러면 진짜로 클러스터된 노드들에서 얻어왔는지 확인해봐야겠습니다.

6379 포트의 인스턴스로 해당 값을 얻어오려고 하니 실제로는 6381에 해당 데이터가 있어 리다이렉트 됬다라는 로그와 함께 결과 데이터를 얻어왔습니다.

여기까지 Redis Cluster 구성이었습니다. 

본문 출처 : 코딩스타트 :: Redis - Redis 설치 및 설정, 간단한 사용방법 (tistory.com)

Redis란? 정말 단순하게 표현하면 key-value 형태의 값을 저장할 수 있는 하나의 In-Memory DB라고 생각하시면 됩니다. 

사용용도는 정말 많습니다. Springboot에서는 세션클러스터링을 위해 Redis를 사용하기도 하고, Cache를 위해서 사용하기도 하며, 여러 서버에서 공통으로 공유해야하는 정보를 담는 용도로 사용하기도 합니다. 필자는 챗봇을 개발중인데, 이중화된 서버에서 세션값을 공유하기위한 용도로 Redis를 사용하려고 합니다. 우선 이번 포스팅에서는 Redis 설치 및 설정, 그리고 간단한 사용법에 대한 포스팅입니다.

▶︎▶︎▶︎Redis Homepage

우선 위에서 Redis를 다운로드 받아줍니다.

그리고 다운로드 받아진 Redis Root 폴더로 들어가서

>make 

명령으로 컴파일을 해줍니다.

준비끝 !

첫번째 예제는 Redis Server를 Standard Alone으로 구성하는 예제입니다.

(편의상 Redis 폴더의 root를 $REDIS로 표현합니다.)

>$REDIS/src/redis-server 

위처럼 실행시켜줍니다. 그러면 Redis Server은 모든 기본설정으로 구동이됩니다.

localhost:6379

이런 화면이 보인다면 지금까지는 잘 따라오신겁니다. 다음은 cli를 이용하여 간단하게 데이터를 삽입,조회 해보겠습니다.

직관적으로 key-value 형태의 데이터를 삽입하고 조회하는 예제입니다.

현재까지의 구성으로 dev환경에서는 충분히 활용가치가 있습니다. 하지만 prod환경에서는 하나의 Redis Server로

운영한다는 것은 아주 위험한 선택일 것 같습니다. 그래서 다음 예제는 Zookeeper와 같은 소프트웨어에서도 이용하는

구성인 Master-Slave 관계를 구축해보겠습니다. Redis Server 구성은 하나의 로컬에서 구성한다는 가정입니다.

위의 구성으로 진행해보도록 하겠습니다. 진행하기에 앞서 우리가 이번 포스팅에서 건들게되는 설정파일이 있습니다.

그것은 바로 redis.conf입니다. 해당 파일을 들어가보면 주석으로 친절하게 설정정보 설명이 되어있습니다.

이번에는 모든 설정정보를 다루기보다는 우리가 많이 다루고, 꼭 필요한 정보들에 대한 설명만 할 예정입니다.

우선 다중 Redis Server 구성을 위하여 $REDIS에 있는 redis.conf를 2개 복사해둡니다.(Slave 2개 설정파일)

>cp redis.conf ./redis-slave1.conf

>cp redis.conf ./redis-slave2.conf

여기까지 몇가지 설정들을 다루어봤다. 실제 위에 설정들 일부를 사용하여 Master-Slave 관계를 구성해볼 것이다.

우선 MasterNode의 설정파일로 사용할 redis.conf이다.

>bind 127.0.0.1

>port 6379

>requirepass yourpassword

>daemonize  yes

이정도 설정으로 나머지는 기본설정을 사용한다.

이제는 나머지 SlaveNode의 설정파일 2개이다.

>bind 127.0.0.1

>port 6380(slave -1) / port 6381(slave-2)

>replicaof 127.0.0.1 6379

>masterauth yourpassword

>daemonize yes

로 구성한다.

이제 순차적으로 실행시켜본다

>$REDIS/src/redis-server ../redis.conf

>$REDIS/src/redis-server ../redis-slave1.conf

>$REDIS/src/redis-server ../redis-slave2.conf

Master&Slave를 순차적으로 실행 시킨 로그이다. Connection이 맺어지고 있는 것이 보인다.

그리고 실제로 데이터의 복제가 잘 이루어지는지 보기 위해 몇개의 창을 더 띄워서

cli로 데이터를 삽입,조회해본다.

복사가 잘된것을 확인할 수 있다. 그렇다면 혹시나 Master와의 관계를 끊기 위해

Master 노드를 중지시켰다면 어떻게 될까?

SlaveNode들의 로그를 보면 connection refused 로그가 계속해서 떨어진다.

하지만 아까 보았던 설정에서 replica-server-stale-data의 설정에 따라 Slave들의 행동이 

달라질것이다.

마지막으로 다시 MasterNode를 띄워보면

Slave들이 다시 Master에 connection 된것을 볼수있다.

여기까지는 좋다. 데이터 복제를 위해 replica도 구성했고, 근데 하나찜찜한 것이있다. Master가 죽으면 알아서 Slave중에서 Master를 선출하면 좋을 텐데.... 방법이 있다!

바로 sentinel을 이용하여 클러스터를 구성해주는 것이다. sentinel은 아쉽게도 다음 포스팅에서 다뤄볼 예정이다.

본문 출처 : 코딩스타트 :: Redis - Sentinel 이란? 설정방법! Redis 고가용성을 위한 방법 (tistory.com)

이전 포스팅에서 Redis Server Replication 구성방법에 대해 알아봤습니다. 이번 포스팅은

Redis 고가용성을 위한 Sentinel 기능에 대해 알아보려고 합니다. 어떻게 보면 조금더 완벽한 클러스터링을

구성한다고 생각하시면 됩니다. 

만약 Redis 설치 및 설정 방법을 모르신다면 아래 링크를 통해 참조하시고 오셔도 좋을 것같습니다.

▶︎▶︎▶︎Redis 설치 및 설정, 간단한 사용법!

우선 Sentinel에 대한 기능에 대해 알아보겠습니다.

1) 모니터링

2) 알림기능

3) 페일오버

4) 환경 구성 프로바이더

이러한 기능을 제공해줍니다.

오늘 예제로 구성해볼 이미지입니다.

구성이 이해가 가십니까? 간단하게 설명을 하면 Master&Slave는 이전 포스팅과 동일하게 3개의 노드를 띄웁니다.

그리고 Sentinel도 동일하게 3개의 노드를 띄웁니다(3개의 의미가 있음). 이런 구성에서 Sentinel은 마스터를 지속적으로 

모니터링합니다. 그리고 장애가 있을시에 적당한 프로세스를 거칩니다. 여기서 Sentinel의 노드를 3개를 띄웠는데요. 이것은

의미가 있는 숫자입니다. 이전에 포스팅 중 Zookeeper관련된 글에서도 동일한 정책을 따랐는데요. 

"바로 홀수단위로 띄운다"

입니다. 이것은 만약 네트워크의 잠깐의 오버타임때문에 마스터가 죽었다고 생각하는 하나의 Sentinel이 있을 수 있습니다.

그럼 이것이 진짜로 죽은 거라고 판단을 해야할까요? 우리는 보통 선거를 하게되면 과반수의 원칙에 따르게 됩니다. 여기서도

동일하게 과반수의 원칙을 따르게 되는 겁니다. 과반수 이상의 Sentinel이 "OK" 해야 비로소 그 마스터 노드는

죽은 것이고, 그때서야 Slave 노드에서 마스터 노드를 선출하게 되는 것입니다. 그렇기 때문에 Sentinel은

3개이상의 홀수 인스턴스를 띄운다 원칙을 지켜주셔야합니다.

우리가 구성할 실제 구성도입니다.

진행하기 앞서, $REDIS(Redis 폴더 root)에 있는 sentinel.conf 파일을 2개 복사해줍니다.(총 3개의 Sentinel 설정파일 구성)

그리고 아래 설정을 port만 각기 분리해주고 나머지 설정을 동일하게 작성해줍니다.

여기서 하나 설명할 것이 있다면 설정중 quorum 입니다. 이것은 의사결정에 필요한 최소 Sentinel 노드수라고 생각하시면 됩니다.

즉, 지금 구성에서는 딱 과반수가되는 2개의 Sentinel이 동의하면 의사결정이 진행이 되는 것입니다.

SDOWN vs ODOWN

More advanced concepts이라는 페이지에서 SDOWN과 ODOWN이라는 단어가 나옵니다. SDOWN은 Subjectively Down condition의 축약어이고 ODOWN은 Objectively Down condition의 축약어입니다.

SDOWN은 센티널 인스턴스가 Master와 접속이 끊긴 경우 주관적인 다운 상태로 바뀝니다. 이것은 잠시 네트워크 순단 등으로 인해 일시적인 현상일 수 있으므로 우선 SDOWN 상태가 됩니다.

그러나 SDOWN 상태인 센티널들이 많아진다면 이는 ODOWN 상태(quorum), 즉 객관적인 다운 상태로 바뀝니다. 이때부터 실질적인 페일오버(failover) 작업이 시작됩니다.

위의 설정을 모두 완료하셨다면 이전 포스팅에서 진행한 redis.conf를 조금 변경해야합니다.

Redis Server 설정 파일에 마스터,슬래이브 관계없이 모두

masterauth yourpassword

requirepass yourpassword

두개의 설정을 3개의 redis conf에 설정해줍니다. 이유는 슬래이브 노드가 마스터 노드로 선출될 수도 있기에

모든 슬래이브는 require pass 설정을 가져야하고 마스터 노드도 슬래이브 노드가 될수 있기 때문에

masterauth설정을 해주어야합니다.

이제 실행을 해봅니다. Redis Server들은 이전 포스팅에서 진행한 데로 실행해주시면 됩니다.

>$REDIS/src/redis-sentinel ../sentinel.conf

>$REDIS/src/redis-sentinel ../sentinel2.conf

>$REDIS/src/redis-sentinel ../sentinel3.conf

명령으로 모든 센티널들을 실행시킵니다.

로그를 하나하나 설명안해도 읽어보시면 어떠한 로그인지 직관적으로 이해가갑니다.

여기에서 마스터 노드를 shutdown 시켜봅니다. 그리고 마스터 선출에 시간이 걸리니 대략

30초 정도 기다려봅니다. 아니? 슬래이브 노드가 마스터노드로 선출됬습니다.

기존에 마스터였던 6379는 슬래이브로, 기존에 슬래이브였던 6381이 마스터로 선출되었습니다.

위의 정보를 출력하기 위해서는 

>./redis-cli -p port -a password

>info

로 접속하셔야합니다. 패스워드를 작성안하시면 해당 명령어를 사용하실수 없습니다.

여기까지 Redis Server 고가용성을 위한 Sentinel 구성이었습니다. production 환경에서는 반드시

위와같이 장애에 대응할 수 있는 서버 구성을 가져야합니다. 

다음 포스팅은 실제 Redis를 Springboot에서 추상화된 객체로 사용해보는 예제를 진행 해볼 것입니다.