RabbitMQ 네트워크 파티션 발생으로 인한 데이터 큐잉 중단 이슈

개요

팀에서 RabbitMQ에 추가된 데이터를 컨슘하여 레디스에 캐싱하는 scdf 프로젝트가 있었다.

설정된대로 데이터가 노출되지 않는다는 CS가 발생하여 원인을 분석하던 중

rabbitMQ 쪽을 확인해봤고, 데이터 큐잉이 중단되어 있었다.

큐잉이 중단되었기 때문에, 설정된대로 데이터가 노출되지 않았을 것이다.

아래의 명령어를 통해 확인해봤더니,

$ rabbitmqctl cluster_status

기존에는 RabbitMQ에 구성된 노드는 3개였는데

rabbitMQ 클러스터를 구성하던 노드 중 하나에서 네트워크 파티션이 발생했다는 것을 확인했다.

그리고, 또 다른 노드는 rabbitMQ 클러스터 구성에서 탈퇴되었음을 확인했다.

이것이 데이터 큐잉 중단과 관련이 있을 거 같아서 추적해봤다.

이슈 1: split-brain

네트워크 파티셔닝 장애로 인해 클러스터가 서브 클러스터로 분할되어 모든 노드들이 자신이 리더라고 인식하게 되는 상황

즉, 서로 리더로써 데이터를 저장하고 있어, 노드들이 가진 데이터가 서로 다를 수 있다.

따라서 데이터 손실 및 정합성 깨질 수 있다고 한다.

확인해보니 네트워크 파티션 처리 전략은 autoheal로 설정되어있었다.

autoheal은 가장 많은 클라이언트가 연결된 파티션에 있지 않은 모든 노드를 재시작 하는 것이다.

따라서, 데이터 무결성보다는 서비스의 연속성을 신경쓰는 설정이다. 이로 인해 데이터 누락이 발생했다.

이슈 2: 미러링 전략

split-brain을 autoheal방식으로 처리한 후, 설정된 미러링 전략에 의해 연쇄적으로 데이터 큐잉이 중단된 것이었다.

좀 더 자세히 설명하자면.. 미러링 전략은 다음과 같았다.

ha-promote-on-failure:	when-synced
ha-promote-on-shutdown:	when-synced

리더 큐가 포함된 서버가 중단될 경우, 전체 동기화 된 팔로워 큐가 없다면, 메시지 유실 방지를 위해 전체 큐를 중단시키는 방식이다.

따라서  rabbitMQ 서버 하나가 재시작되어, 리더 큐 rabbitMQ 02번 서버에 동기화된 팔로워 큐가 없어
메시지 큐잉이 중단되어서 데이터가 정체되었던 것으로 보여진다.

따라서 캐싱도 정체되었을 것이고, 설정된대로 데이터가 노출되지 않았을 것이다.

결론

클러스터링을 이루고 있는 노드 중 하나가 탈퇴했음을 인지했거나,

미러링 전략이 when-synced가 아닌 서비스의 연속성을 위해 always로 설정했다면

비동기화된 미러에 대해서도 승격이 허용되었을 거 같다.

사실 이렇게 반실시간 스트림 프로젝트에 대한 이슈를 고려하여 운영 중인 배치가 있기 때문에

always를 설정하는 것이 좋아보인다.