Redis Single Thread 모델에 대해서.

다음글은 페이스북 서버사이드 아키텍트 그룹 세미나에서 강대명씨가 발표한 내용을 정리한 글입니다.

Redis acc from Dae Myung Kang

Redis는 Single Thread Model이다. (중요)

이로 인해서 긴 Transaction이 들어 오면, 그 Tx를 처리하기 위해서 다른 request를 처리 못하는 현상이 발생한다.

대표적으로

• Flushall이나 Keys는 List 전체를 Scan하는 구조로, 100만개 처리시 1초, 1000만개 10초,1억개 100초가 소요된다.
• 이를 예방하기 위해서, 데이타를 전체 하나의 Collection에 넣는 것이 아니라 여러개의 Collection에 나눠서 처리하는 방안이 좋다. 각 Collection당 보통 10,000개 정도의 데이타를 저장하는 것이 좋다

다른 문제로, Redis의 경우 메모리의 내용을 파일로 저장할 수 있다. 두 가지 방식이 있는데,

• RDB (메모리 덤프 방식) -:순간적으로 메모리의 내용을 덤프 떠서 디스크에 저장한다. 이때 Fork (& copy on write)방식으로, Fork 된 프로세스에서 full scan을 해서 디스크에 저장한다. 이때 문제점은 fork가 되기 때문에, 순간적으로 메모리 사용량이 증가한다. 예를 들어 4G짜리 redis 프로세스가 돌고 있으면 fork되는 순간 worst case 똑같이 4G 메모리를 차지하는 Child Process가 생성된다. 그래서, 시스템 메모리가 넉넉하지 않은 경우, Swap이 발생하고 전체적인 box의 성능을 떨어뜨려서, parent process에도 성능 영향을 줄 수 있다. 이를 해결하기 위해서는 하나의 box에 큰 redis instance 하나를 띄우는게 아니라 여러개로 잘게 나눠서 띄우는게 좋다. 예를 들어 시스템 메모리가 8G일때, 6G짜리 하나를 띄우는 것보다 1G짜리 6개, 또는 1.5G 짜리 4개를 띄우면, RDB로 덤프할때도 추가로 사용되는 메모리는 worst case 1.5이기 때문에 시스템 메모리 내에서 커버가 
• AOF(Append on File - 일종의 DB Commit Log와 같은 개념) - AOF는 write tx를 매번 파일에 저장하는 방식이다. 그래서, 매번 write 시마다 disk io가 발생한다. 대신, 매 tx를 logging하기 때문에, 최신 데이타를 항상 디스크에 백업할 수 있다. AOF 파일이 무제한으로 커지는 것을 막기 위해서 AOF 파일이 일정 크기 이상이 되면, 현재 메모리를 RDB처럼 DUMP하고, AOF 파일을 지우고 새로 쓰기를 시작한다. (마찬가지로 이 과정에서 fork 방식을 사용한다.)

이런 성능 저하나 문제를 막기 위해서는 master node에서 rdb나 aof를 사용하지 않고, slave 노드를 만들어서 slave 노드에서 qordjqdmf wlsgodgksms rjtdl whgek.

Master/Slave 구조시 Master 노드 장애

• Master 노드가 장애가 나면 클라이언트는 Slave로 붙어서 write를 하는데, redis는 특성상, master 노드가 다시 살아나면, master 노드의 데이타를 최신 데이타로 생각하고, slave 의 데이타를 지우고, master 노드의 데이타를 복제한다. 이 구조 때문에, master노드가 장애시 slave 노드에 쓰여진 데이타는 유실 될 수 있다.
• 이런 현상을 막기 위해서 "Slave of no one" 이라는 옵션을 지정하면,, Slave가 master로 격상되고, 원래 master가 올라오더라도 데이타를 복제 받지 않는다.

Master/Slave 구조에서 또 주의해야할점 중 하나는, Slave를 새로 만들면, Slave는 Master로 부터 데이타를 복제해와야 하는데, 이 과정이 RDB dump를 떠서 이뤄진다. (성능에 영향을 줄 수 있다.)

이렇게 HA 쪽에 문제가 있어서 여러가지 Configuration 방법이 있다. Pub/Sub을 사용하지 않는다면, TwemProxy 를 사용하는 것이 좋다.

※ 결론적으로 이야기 하자면, memcached에 비해서 많은 기능을 제공하지만, 대단히 sensitive한 솔루션으로 보이고, 특히 복제나 HA Replication에서 장애 유발할 수 있는 가능성이 있으니, 대용량 데이타 저장시에는 반드시, 맞는 구조로 데이타 모델 및 파티셔닝 그리고 ㅗ드 분산을 해야 한다. (이게 아마 대명씨가 이야기 하는 cell architecture 인듯)