[Redis] Redis Master-Slave 사용하기 (Sentinel, HAProxy)

What is Redis Master-slave?

Redis Master-slave는 Redis에서 제공하는 가장 기본적인 Replication 기법입니다. Redis Master-Slave 구성시 위와 같은 구조를 가지는데 이는 MySQL의 Master-slave Replication 기법과 유사한 점이 많습니다.

• 하나의 master에 다수의 slave가 붙을 수 있습니다.
• Master는 Read-Write mode로 동작합니다.
• Slave는 Read-Only mode로 동작합니다.

따라서, Client는 필요에 따라 Master에 붙어 Write 동작을 수행하거나 Master 혹은 Slave에 붙어 Read 동작을 수행할 수 있습니다.

Master-slave Replication Process

Master-slave 사이의 replication은 Async(비동기)방식을 이용합니다.

1. Master는 Data 변경 시 변경 내용을 backlog에 기록
2. Slave는 master에 접속하여 backlog의 내용을 바탕으로 replication 작업을 수행

이 때, Async 방식의 특성상 Master에 저장된 Data가 Slave에 잠깐동안 저장되지 않을 수 있기 때문에 Client(App)는 Slave에서 Data를 Read 할 때 Async 특징을 반드시 고려해야 합니다.

Master의 동작이 멈췄을 경우

1. Master가 죽을 경우 Slave는 Master에게 주기적으로 Connection을 요청하며 Master가 되살아날때까지 대기합니다.
2. Master가 살아나면 Slave는 Replication을 수행하여 Master와 동기화를 맞춥니다.
3. Master의 복구가 힘든 경우 Redis 관리자는 Slave 중에서 하나를 수동으로 Master로 승격시키고, 나머지 Slave들을 새로운 Master로부터 Replication 하도록 설정해야합니다. Master가 바뀐뒤에는 죽었던 Master는 새로운 Master의 Slave로 설정하여 이용해야합니다.

위에서 Master의 동작이 멈췄을 경우 어떻게 해야하는지 알아보았습니다. 하지만 이를 Redis 관리자가 복구시키기에는 번거롭기 때문에 우리는 Sentinel을 이용하여 이러한 문제를 해결하도록 합니다.

Sentinel

Master의 동작이 멈출 경우 Client는 Slave를 통해서 Read 동작을 수행 할 수 있지만, Write 동작을 수행 할 수 없습니다. 따라서 Master의 Downtime은 Redis Cluster의 가용성을 떨어트립니다. 이러한 가용성 문제를 도와주는 App이 Sentinel입니다.

Sentinel은 Master가 죽는지 감지하고 Master가 죽었을 경우 Slave 중 하나를 Master로 승격시키고, 기존의 Master는 Slave로 강등시킵니다. Redis 관리자의 간섭 없이 자동으로 이루어지기 때문에 Master의 Downtime을 최소화하여 HA(High Availabilty)를 가능하게 만듭니다.

Sentinel은 일반적으로 홀수개로 구성하여 Split-brain을 방지합니다.(Fail over를 위해 과반수 이상의 vote가 필요하기 때문입니다.)그림에서는 Sentinal을 Redis와 별도의 Node에 구성하여 이용하는 모습을 나타내고 있지만, Sentinel을 Redis와 동일한 Node에 구성하여 이용하여도 문제없습니다. Sentinel 설정에는 Quorum이란 설정값이 존재합니다. Quorum은 특정 Redis에 장애 발생시 몇개의 Sentinel이 특정 Redis의 장애 발생을 감지해야 장애라고 판별하는지를 결정하는 기준값입니다. 예를들어 Quorum 값을 2로 설정하였을 경우, 2개 이상의 Sentienl이 특정 Redis에 장애가 발생하였다고 판별해야 Sentinel은 해당 Redis에 대한 장애 대응을 수행합니다.

• redis process가 실행되는 각 서버마다 각각 sentinal process를 띄워놓는 방법
• redis process가 실행되는 서버와 별개로 redis에 액세스를 하는 application server들에 sentinel process를 띄워놓는 방법

HAProxy

Redis Master-slave 구성시 Master는 RW Mode로 동작하고 Slave는 RO Mode로 동작하기 때문에 Client는 Master의 IP/Port, Slave의 IP/Port를 각각 알고, 필요에 따라 적절한 Master 또는 Slave에 붙어 동작을 수행해야 합니다. 따라서 Master의 장애 발생시 Master가 교체되면 그에 따라 Client Redis 설정도 바뀌어야합니다. 하지만 Master가 교체될때마다 Redis를 이용하는 모든 Client의 설정을 바꾸는 일은 쉬운일이 아닙니다. 이러한 문제를 해결하기 위해서 일반적으로 HAProxy를 이용합니다.

HAProxy는 Client에게 Redis의 Master, Slave에 일정하게 접근 할 수 있는 End-point를 제공합니다. 그림에서 Port X는 Master에게 접근 할 수 있는 Port를 나타내고 Port Y는 Slave에게 접근 할 수 있는 Port를 나타냅니다. HAProxy는 tcp-check를 이용하여 주기적으로 각 Redis가 Master로 동작하는지 또는 Slave 동작하는지 파악하고 그에따라 동적으로 Routing Rule을 설정합니다. 따라서 Master가 교체되어도 HAProxy는 일정한 End-point를 Client에게 제공 할 수 있다. HAProxy를 하나만 구성하면 HAProxy로 HAProxy가 죽을경우 SPOF(Single Point of Failure)가 발생하여 Redis의 HA를 방해한다. 따라서 L4 Load Balancer 및 VRRP를 이용하여 다수의 HAProxy를 하나의 HAProxy 처럼 보이도록 Client에게 제공해야 합니다.

---

References

• https://ssup2.github.io/theory_analysis/Redis_Master_Slave_Cluster/