Redis는 클라이언트-서버 모델을 따르는 TCP 서버로 요청/응답 프로토콜을 사용하고 있다. 이는 요청의 처리를 완료하기 위해서 아래의 과정을 따른다는 것을 의미한다.
클라이언트가 서버로 요청을 보낸다. 서버는 소켓으로 부터 요청 데이터를 읽는다. 서버는 데이터를 처리해서 응답을 보낼 준비를 한다. 일반적으로 이 과정은 blocking이 된다.
서버 프로세스는 응답을 보낸다. 그리고 다음 요청을 받는다.
예를 들어 4개의 명령을 보낸다면, 아래와 같은 순서로 처리된다.
Client : INCR X
Server : 1
Client : INCR X
Server : 2
Client : INCR X
Server : 3
Client : INCR X
Server : 4
클라이언트와 서버는 네트워크로 연결돼 있다. 따라서 연결 거리와 환경에 따라서 데이터가 왕복하는데 시간이 걸린다. 루프백 인터페이스로 연결된 경우에는 매우 빠를테고, 인터넷으로 연결된 경우에는 매우 느릴 거다. 네트워크로 연결된 서버와 클라이언트간에 데이터를 보내고 그에 대한 응답을 받는데 걸리는 시간을 RTT(Rount Trip Time)이라고 부른다.
RTT가 서비스 성능에 어떤 영향을 주는지는 쉽게 계산할 수 있다. RTT가 250msec인 환경이 있다고 가정해보자. 만약 초당 10만번의 요청이 들어올 경우 프로세스는 고작 4개의 요청만 처리할 수 있을 거다. 서비스가 거의 불가능한 수준일건데, 다행이 이 문제를 처리할 방법이 있다.
REDIS 2.6 이상 버전에서는 Redis scripting기능을 이용할 수 있다. 서버에 스크립트를 밀어넣어서 실행하는 것으로, 파이프라이닝 보다 더 효과적인 데이터 운용이 가능하다. 이 방식의 가장 큰 장점은 네트워크 레이턴시의 영향을 최소한 받으면서, 데이터를 읽고 쓸수 있다는데 있다.
Contents
1. Request/Response Protocols과 RTT
2. Redis Pipelining
3. 벤치마크
3.1. Local 테스트
3.2. Remote 테스트
4. Pipelining VS Scripting
1. Request/Response Protocols과 RTT
2. Redis Pipelining
3. 벤치마크
3.1. Local 테스트
3.2. Remote 테스트
4. Pipelining VS Scripting
Recent Posts
Archive Posts
Tags