Redis Sentinel로 고가용성 유지하기 (with Slack)

기존 ver.2에서 Redis를 도입해 RDBMS의 부하를 30퍼센트 줄여 문제점을 개선하였습니다. 하지만 읽기 요청이 많아지면 Redis에 큰 무리가 가게 되고 Redis가 standalone 상태에서 다운되면 뒤에 있는 RDBMS도 다운될 가능성이 있습니다. 

 

때문에 Redis의 고가용성을 유지하는 것이 새로운 과제가 되었고 이번 ver.6에서 Redis Sentinel을 이용해 문제를 해결하게 되었습니다. 

 

왜 Sentinel이었나?

Redis에 고가용성을 위한 옵션으로 Sentinel과 Cluster가 존재합니다. 둘 중 Sharding이 지원되는 Cluster가 상위호환이지만 Sentinel을 선택하게 되었습니다. 

 

Sentinel을 선택한 이유는 우선 첫번째로 프로젝트에 Sharding이 필요할지 감이 안잡혔기 때문입니다. MongoDB 공식 문서에서 NoSQL의 특징 중 수평확장의 대표주자인 Sharding에 대해서 설명할 때 다음과 같이 언급한 바 있습니다. 

 

"Sharding은 최후의 최후까지 선택하지 않았으면 좋겠다"

 

그 이유로 MongoDB에선 Sharding으로 분산된 데이터를 관리하는 비용이 기존 방식에 비해 어마어마하게 높아지기 때문이라고 하였습니다. 

 

제 프로젝트의 컨셉이 이용자가 100만명, 1000만명이 되면 어떤 문제가 발생할까에 대한 사고실험에 가까운 프로젝트이지만 실제로 제가 100만명, 1000만명의 트래픽을 받아본 적이 없기 때문에 Sharding이 필요할 정도가 어느정도인지 감을 잡지 못해서 Sentinel을 선택했습니다. 

 

 

Sentinel로 얻은 것

Sentinel에서 기본적으로 마스터-슬레이브 구조에서 replica를 둘 수 있다는 점에서 읽기 연산에 대한 부하를 분산할 수 있다는 점에서 기존 프로젝트에 비해 높은 안정성을 보여줄 것으로 기대하고 있습니다. 

 

또한, 마스터노드가 다운되었을 때 데이터가 유실될 수 있는 상황에서 Sentinel의 모니터링 시스템과 슬레이브에서 마스터로 승격하는 시스템덕분에 데이터 유실을 최대한 방지할 수 있게 되었습니다. 

 

이뿐아니라 Sentinel에서 기본적으로 제공하는 Notification을 이용해 슬랙과 연동하여 마스터노드의 장애 상황을 실시간으로 알람을 받을 수 있는 환경을 구축했습니다. 

 

아쉬운 점

조금 아쉬운 점은 마스터노드의 장애 이후 슬레이브가 마스터로 승격되는 시간이 금방 되는 경우도 있었지만 오래 걸릴땐 5분이상 걸리는 것이 조금 아쉬운 점으로 남았습니다. 

 

이를 해결하기 위해 슬레이브 노드를 지정해 대기시켜 Sentinel이 sdown에 대한 알람이 오면 바로 설정을 변경하여 마스터 노드로 승격시키는 방법을 고려해봤습니다만 슬레이브 노드의 장애 상황에는 상황이 더 복잡해질 것을 우려해 해당 방식을 폐기되었습니다.