[REDIS] Sentinel + Haproxy + Keepalived를 이용한 Redis HA LoadBalance 구축 (1)

기 구축 Redis 시스템 구조

---

• RDB(no save) + Replication 총 3대 구성
• Slave 2(REDIS-2,3)대가 각각 Master(REDIS-1)에 Repl 동기화를 하는 구조
• Master → RW, Slave(REDIS-2) → RO 로 클라이언트에서 RIP로 직접 접근

• 문제점
  • Master Down 시 Role change 되지 않음. → 쓰기 실패하고 수동 Role Change 지연 발생
  • Redis의 Role이 변경 된 경우 클라이언트에서 RW, RO Redis의 IP, Port의 Sync 필요.
  • RDB만 사용하고 SAVE 하지 않아 Data 유실 위험

 

Redis + Sentinel + Haproxy + Keepalived 를 이용한 변경 구성

---

•  Keepalived
  • VRRP를 이용한 VIP 구성으로 Redis가 Role Change 되더라도 Bind IP 유지
  • No Failback : 기존 Master(Haproxy)가 회복되더라도 VIP가 다시 넘어가 서비스에 순단이 발생하지 않게 설정
  • Haproxy를 트랙킹

• Haproxy
  • Master(redis), Slave(redis) Load Balancer로 Down, 변경 시 흐름 유지
  • Active-Active 설정으로 서비스 트래픽의 흐름은 Keepalived VIP에 좌우됨.
  • backend(Redis) 는 Redis 모두를 RR(RoundRobin) 으로 구성하고 tcp-check을 통해 Master. Slave Redis로 프록싱함.
  • Bind Write Port → Master Redis
  • Bind Read Port → Slave Redis
• Sentinel
  • Redis Role Changer로 Master Redis를 트랙킹하고 Down 시 Slave 중 하나를 Master로 선출하여 Role Change.
  • No Failback : Master Redis가 회복되더라고 다시 Role Change로 인한 순단을 방지
  • Sentinel 간의 의사 정확도(다수결)를 위해 3개(홀수)의 Sentinel 구성
• Redis
  • Replication
  • AOF+RDB로 DATA 유실 방지

 

Normal Flow

---

 

• Keepalived
  • VRRP : 멀티캐스트를 통한 Keepalived 간 interval 2초간격 Master에서 광고
  • Haproxy 트랙킹
• Haproxy
  • Redis Role checker(tcp-check)를 통한 backend master, slave 흐름 제어
• Sentinel
  • Redis Master 트랙킹
  • 정족수(quorum) 동의를 통한 Redis role change 담당
• Redis
  • 주 AOF everysec + 부 RDB key 변환 시 save를 통한 DATA 유실 방지

 

Failover 

---

 

• Redis Role Change
  • Haproxy tcp-check에 의해 Master로 선출된 Redis로 프록싱
  • Haproxy backend health check interval + Redis Master 선출 시간 까지의 데이터 유실이 발생
    
    • Sentinal : Sdown(응답이 없음을 알리는 Subjective Down) → Odown(장애로 판단하는 Objective Down) 5s
    • Haproxy backend tcp-check interval 5s
    • 약 10초의 순단
  • Keepalived VIP, Haproxy는 변화 없이 유지됨.
• Keepalived Down
  • Master Keepalived의 멀티캐스트 VRRP 광고가 끊기고 Slave로 VIP가 넘어감
    • No Failback설정의 경우 Keepalived state가 EQUAL(priority)로 설정되고 다음 VIP를 가지고 있을 Master 선출은 RIP 내림차순이나 오름차순에 의해 결정 됨
    • Failover 시 advert_int 시간 만큼의 순단 발생
  • No Failback으로 Master 복구 시 State Change 변화 없음.
  • Haproxy, Redis, Sentinel는 변화없이 유지 됨.
•  Haproxy Down
  • Keepalived Tracking이 실패하고 Slave로 VIP를 넘김
    • Failover 시 Tracking interval, fall 값에 의한 Down 확정 + advert_int 시간 만큼의 순단이 일어남
    • interval 2, fall 3 의 경우 약 6~7초동안의 Down 확정 시간 + advert_int 2 의 광고 시간까지 약 10초 내외의 순단
    • No Failback으로 Master 복구 시 State Change 변화 없음.