Redis Replication Performance

Asynchronous Replication 비동기 복제 내부 흐름

• redis.io에 복제에 대한 설명이 있는데 대게 복제 시작시 처음 발생하는 전체 동기화(Full sync)나 네트웍 일시적 다운 후 발생하는 부분 동기화(Partial sync)에 대한 설명이고 정상 상황에서 지속적으로 이루어지는 명령 단위의 동기화에 대해서는 비동기(asynchronous)라는 설명밖에 없다.
  여기서는 비동기 방식 복제는 어떻게 이루어지고 있는지, 모니터링은 가능한지, 성능은 어떤지에 대한 설명을 소스 코드와 테스트 결과로 설명합니다.
• 레디스는 쓰기(write) 명령이 입력되면 실행하고 슬레이브가 있으면 슬레이브 fd(file descriptor)로 명령을 memcpy()로 복사한다. 그러면 epoll 이벤트가 발생해서 epoll_wait()에서 알아차리고 이어서 복사된 명령을 슬레이브 노드에 전달한다.   아래는 소스에 주요 흐름을 따라 호출 순서대로 표시한 것이다.
server.c
processCommand() -> call() -> propagate() -> replicationFeedSlaves() -->
replication.c
replicationFeedSlaves() -> addReplyBulk() ->
networking.c
addReply() -> _addReplyToBuffer() -> memcpy()

복제 모니터링

• 비동기 복제의 처리시간이나 지연시간을 직접 모니터링 하는 방법은 제공되지 않습니다.
• 일반 모니터링 명령인 MONITOR를 이용해서 명령 실행 시간을 볼 수 있습니다.   MONITOR 명령은 복제 노드에서 실행해야 합니다.   이 방법은 레디스 서버의 성능을 반 정보 떨어뜨리므로 주의해서 수행해야 하고, 명령 실행 시간도 이를 감안해서 보아야 합니다.

복제 성능 테스트 1

• 테스트 방법: 마스터 1 -> 10개 복제
• 구성: 마스터 1대에 복제 10대를 연결했고, 같은 머신안에서 수행했다.

• set key1 111111 명령 하나를 실행했다. 빠른것은 0.7밀리초, 가장 느린것은 4.8밀리초이고, 평균 2.2밀리초가 걸렸다.

포트       명령 모니터                                                                              전달처리시간(밀리초)    
5011> 1444440781.007235 [0 127.0.0.1:34180] "set" "key1" "111111"	 
5012> 1444440781.007939 [0 127.0.0.1:5011] "set" "key1" "111111"	 0.7
5013> 1444440781.008035 [0 127.0.0.1:5011] "set" "key1" "111111"	 0.8
5014> 1444440781.012080 [0 127.0.0.1:5011] "set" "key1" "111111"	 4.8
5015> 1444440781.008124 [0 127.0.0.1:5011] "set" "key1" "111111"	 0.9
5016> 1444440781.011227 [0 127.0.0.1:5011] "set" "key1" "111111"	 3.9
5017> 1444440781.008214 [0 127.0.0.1:5011] "set" "key1" "111111"	 0.9
5018> 1444440781.008303 [0 127.0.0.1:5011] "set" "key1" "111111"	 1.1
5019> 1444440781.009281 [0 127.0.0.1:5011] "set" "key1" "111111"	 2.0
5020> 1444440781.009604 [0 127.0.0.1:5011] "set" "key1" "111111"	 2.4
5021> 1444440781.011917 [0 127.0.0.1:5011] "set" "key1" "111111"	 4.7

• 다음은 레디스 서버에 부하를 주었을때 전달처리시간을 알아보기위해 redis-benchmark를 디폴트로 실행해서 밴치마크의 마지막 명령인 mset이 수행된 후 나온 시간이다.
  빠른것은 5.1밀리초, 가장 느린것은 65.8밀리초이고, 평균 22.1밀리초가 걸렸다.

포트       명령 모니터                                                                              전달처리시간(밀리초)    
5011> 1444441860.645160 [0 127.0.0.1:34891] "MSET" "key:__rand_int__"	
5012> 1444441860.650335 [0 127.0.0.1:5011] "MSET" "key:__rand_int__"	  5.1
5013> 1444441860.653299 [0 127.0.0.1:5011] "MSET" "key:__rand_int__" 	  8.1
5014> 1444441860.656081 [0 127.0.0.1:5011] "MSET" "key:__rand_int__" 	10.9
5015> 1444441860.659390 [0 127.0.0.1:5011] "MSET" "key:__rand_int__" 	14.2
5016> 1444441860.663042 [0 127.0.0.1:5011] "MSET" "key:__rand_int__"	17.9
5017> 1444441860.665981 [0 127.0.0.1:5011] "MSET" "key:__rand_int__"	20.8
5018> 1444441860.709919 [0 127.0.0.1:5011] "MSET" "key:__rand_int__" 	64.8
5019> 1444441860.668844 [0 127.0.0.1:5011] "MSET" "key:__rand_int__" 	23.7
5020> 1444441860.671692 [0 127.0.0.1:5011] "MSET" "key:__rand_int__" 	26.5
5021> 1444441860.674378 [0 127.0.0.1:5011] "MSET" "key:__rand_int__" 	29.2

복제 성능 테스트 2

• 테스트 방법: 마스터 1 -> 10개 복제
• 구성: 마스터 1대에 복제서버 10대를 줄줄이 사탕처럼 연결했다. 같은 머신안에서 수행했다.

• set key1 111111 명령 하나를 실행했다. 이 경우 노드간 전달처리시간이 평균 0.3밀리초로 거의 균일했다.
• 레디스 벤치마크를 실행하고 마지막 명령의 전달처리시간은 빠른 것이 0.7밀리초, 느린 것이 15.3밀리초, 평균 5.3밀리초가 걸렸다.

정리와 주의해서 볼 사항

• 시간 측정을 MONITOR 명령으로 했고 이 명령은 성능을 반 이하로 떨어뜨립니다. 그러므로 앞에 제시한 수치를 반으로 줄여서 봐도 좋을 것입니다.
• 위 테스트는 노드간에 네트웍 환경이 아니므로 네트웍 환경을 고려해서 보면 수치가 늘어날 것입니다.
• 테스트 환경에 따라 다를 수 있습니다만,   비동기 복제 전달처리 시간은 느린 환경이라고 해도 100밀리초, 즉 0.1초 이내에 슬레이브로 전달처리 될 것입니다.
• 슬레이브 노드를 조회용으로 사용할 경우 약간의 시간 간격을 두고 조회야 한다.