Redis Overview
Upcoming SlideShare
Loading in...5

Redis Overview






Total Views
Views on SlideShare
Embed Views



1 Embed 3 3



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Redis Overview Redis Overview Presentation Transcript

  • Redis (Remote Dictionary Server)
  • Today’s topic
    • Redis( 현재 version 2.4.6) 에서 지원하는 기능 및 특징
      • 무엇이 가능하고 , 무엇이 불가능한가 ?
      • 데이터 연산보다는 운영 상의 특징들을 정리
      • 간단한 기능 및 성능 시험
  • Redis Overview
    • Replication
      • Non-blocking 으로 동작
        • Master 는 replication 하는 동시에 client 의 query 에 응답할 수 있음
      • Master 는 server, slave 는 client 로 동작
      • Master 에 기록하는 정보는 공유 되지만 , slave 에 기록하는 정보는 공유되지 않음
    Master Slave Slave server client client replication replication X
  • Redis Overview
    • Replication
      • How Redis replication works (see below fig)
      • Reconnection
        • Slaves are able to automatically reconnect when the master <-> slave link goes down for some reason. When a master and a slave reconnects after the link went down, a full resync is performed .
    Master Slave SYNC DB file - saves DB file on disk - loads DB file into memory All accumulated commands modify the dataset
    • background saving
    • collects all new commands
    • received that will modify the dataset
    Fig. Replication procedure
    • set up
  • Redis Overview
    • Replication
      • Slave 가 Master 와 연결이 끊기거나 replication 이 진행 중일 때 동작은 configuration 에 따라 달라짐
        • 1. slave-serve-stale 을 yes 로 지정한 경우
          • 자신이 현재 가지고 있는 data 를 기반으로 client 에 응답
          • Data 가 최신이라는 보장은 없다 .
        • 2. slave-serve-stale 을 no 로 지정한 경우
          • Client 에 error 응답 (“SYNC with master in progress”), 단 INFO, SLAVEOF command 는 제외
    Issue: replication 이 진행 중일 때 , slave 는 client request 에 갱신된 값을 줄 수 있을까 ? 성능에 영향은 ..?
  • Redis Overview
    • Publish/Subscribe 기능 지원
      • System decoupling 에 유용함
    Slave Master Client 1 Client 2 1. Subscribe foo 2. Publish foo (key) bar (value) 3. Message foo bar Fig. Pub/Sub procedure
  • Redis Overview
    • Redis Persistence
      • RDB persistence
        • Performs point-in-time snapshots of your dataset at specified intervals.
      • AOF (Append Only File) persistence
        • Logs every write operation received by the server, that will be played again at server startup, reconstructing the original dataset. 
      • Server 가 동작하는 동안만 data 를 유지하고 싶으면 RDB, AOF 기능을 사용하지 않을 수 있음
      • RDB, AOF 조합해서 사용 가능
      • RDB persistence
        • Snapshotting 정책 설정
          • Ex) save 60 1000
          • Redis automatically dump the dataset to disk every 60 seconds if at least 1000 keys changed
          • 여러 개 지정 가능
            • save 900 1
            • save 300 10
            • save 60 10000
  • Redis Overview
    • Redis Persistence
      • RDB persistence
        • Snapshotting 동작과정
    Redis Parent child 1. fork() 2. The child starts to write the dataset to a temporary RDB file 3. When the child is done writing the new RDB file, it replaces the old one.
  • Redis Overview
    • Redis Persistence
      • Append-only file
        • Snapshotting is not very durable.
          • If your computer running Redis stops, your power line fails, or you accidentally kill -9 your instance, the latest data written on Redis will get lost.
        • The  append-only file  is an alternative, fully-durable strategy for Redis.
        • You can turn on the AOF in your configuration file:
          • appendonly yes
          • From now on, every time Redis receives a command that changes the dataset (e.g. SET) it will append it to the AOF. When you restart Redis it will re-play the AOF to rebuild the state.
  • Redis Overview
    • Pipelining
      • 한 번에 다수의 command 를 보내고 , 나중에 그 결과를 수신하는 기술
      • RTT(Round Trip Time) 을 줄이기 위함
    • Redis Administration
      • Upgrading or restarting a Redis instance without downtime
        • CONFIG SET 명령을 이용해서 실행 도중 설정 값을 변경할 수 있음
        • 단 , Redis 를 upgrade 하거나 기능이 변경되어 바꿔야 하는 경우에는 불가피하게 down 시켜야 함
  • Redis Overview
    • Redis cluster specification (Redis-trib)
      • 다수의 node 를 cluster 단위로 관리
      • 제공 기능
        • Redirection (MOVED, ASK)
          • 자신이 key 에 대한 데이터를 가지고 있지 않은 경우 실제 데이터를 가지고 있는 node 를 알려줌
        • Cluster live reconfiguration
          • 운영 중에 새로운 node 를 추가하거나 제거하는 기능
        • Fault Tolerance
          • Node failure detection
          • Cluster state detection (only partially implemented)
          • Slave election (not implemented)
            • Master node 가 중지된 경우 새로운 Master 를 선발하는 기능
      • 현재 release 된 Redis(v.2.4.6) 자체에는 cluster 기능이 구현되어있지 않음
        • 현재 개발중인 것으로 보임
  • Client library
    • Client 의 기능
      • Redis server 로 command 를 송신
        • 데이터 관련 연산 뿐 아니라 , server 의 동작도 제어 가능함  기능 분리 필요
          • 데이터 관련연산
          • Redis server 동작 제어
  • Client library
    • 현재 제공되는 C/C++ library
      • C
        • hiredis : recommended !!
        • credis
        • libredis
      • C++
        • C++ Client
          • Multi-server 로 command 송신 지원
          • Experimental state….
    “… Generally the current api is not stable and not well documented. Please have a look at the provided test cases (test_client.cpp) to see what is currently possible.” “ This is the official C client. Support for the whole command set, pipelining, event driven programming.” “ Support for executing commands on multiple servers in parallel via poll(2), ketama hashing. Includes PHP bindings.” “ Credis aims to be fast and minimalistic with respect to memory usage . It supports connections to multiple Redis servers. ... Current status is &quot;almost complete“…”  찾을 수 없음
  • Functional test
    • Master / Slave node 구성
      • 아래와 같이 구성하면 모두 같은 data 를 공유할 수 있음
    Node1 Node2 Master Slave
    • => 처음부터 모두 slave 로 구동 시키면 불가능 . 다음 순서로 실행하면 가능
    • Node1 을 Master 로 구동
    • Node2 를 Node1 의 Slave 로 구동
    • Client command 로 Node1 을 Node2 의 slave 로 설정
    Slave Master Node1 Node2 Node3 Master Slave Master Slave => POSSIBLE Node1 Node2 Node3 Master Slave Master Slave Master Slave => POSSIBLE
  • Functional test
    • Data update 문제
      • Master / Slave 관계가 순환 구조를 갖는 경우 발생
        • GET 은 무조건 된다 .
        • Update 가 되지 않는 경우가 발생 . Update 기능에 대해 신뢰성이 없다 .
          • Update: 특정 key A 에 대해 value 를 SET 하고 , 같은 key 에 대해 다시 value SET 을 시도
    Node1 Node2 Node3 Master Slave Master Slave Master Slave Node1 Node2 Node3 Node4 Node5 * 이상적인 구조 * Master/Slave 순환 구조
  • Performance test
    • 시험결과
      • SET, GET 연산 결과는 거의 유사함
      • Local : 약 10,000 TPS
      • Remote: 약 2,000 TPS
    • Data size: 1024 byte
    • Client num: 1
    • Request num: SET/GET 각각 10,000
    • Operation: SET  GET
    VM-Client 1 - Redis client
    • VM-Client 1 (local)
    • Redis server
    • 10,000 개 request 처리시간 약 1 초
    • VM-Client 2 (remote)
    • Redis server
    • 10,000 개 request 처리시간 약 5 초
    Issue: local 연산이 확연히 빠름 . 성능 향상을 위해 Redis server 측에 data 연산용 process 가 필요할까 ..?
  • Performance test
    • 시험결과
      • Data size 와 처리시간 관계
      • Redis server 는 client 와 물리적으로 다른 server 에 존재
    Data size (byte) SET time (sec) GET time (sec) 32 3.08 2.7 64 2.62 2.33 128 2.66 2.31 256 3.13 2.4 512 3.38 2.88 1024 4.41 4.38
  • Cluster 구성
    • 방안 1
      • Master/Slave 순환 구조로 구성
      • Client 는 최초 하나의 Redis server 에만 wirte
      • 장애 발생 시 client 에서 다른 server 로 연결하고 , 이후 연결된 server 에 write
    Node1 Node2 Node3 Master Slave Master Slave Master Slave Client Node1 Node2 Node3 Master Slave Master Slave Master Slave X Client X X Command] > Slaveof no one > Slaveof node3_ip port - 장점 : replication 기능을 최대한 활용할 수 있음 - 단점 : Value update 가 안될 가능성이 존재
  • Cluster 구성
    • 방안 2
      • 모든 Redis server 를 Master 로 구성
      • Client 에서 현재 연결된 모든 server 에 write
    Node1 Node2 Node3 Client Master Master Master - 장점 : 안전함 , master 하나에 장애가 발생해도 데이터 유지 , replication traffic 없음 - 단점 : Client 에서 다수의 connection 유지해야 함
  • Cluster 구성
    • 방안 3
      • 모든 client 는 하나의 Master server 에 write
      • Master server 에 장애 발생 시 Slave 중 하나를 Master 로 교체
    Node1 Node2 Node3 Client Slave Master Slave Client Client Node1 Node2 Node3 Client Slave Master Slave Client Client X X - 장점 : 방안 2 에 비해 connection 수가 적음 , Master/Slave 구조가 이상적임 - 단점 : 하나의 server 에 트래픽 집중 , slave 가 master 되기 전까지 서비스 불가
  • Summary
    • Cluster 구성을 어떤 방식으로 해야 할까 ?
    • Cluster 관리용 process 가 필요할 듯
      • Cluster 관리 process 역할 예시
        • 처음 구동 시 , 구동 순서 조정 및 Master / Slave 지정
        • Master node 가 죽으면 연결되어있던 slave 는 계속해서 re-connection 시도 . Command( slaveof no one ) 를 보내서 connection 시도 중지 .