티스토리 뷰
앞서 작성한 Kafka 클러스터 구축 내용을 정리하면서, (https://c-diary.tistory.com/3)
아무 생각없이 따라한 ZooKeeper (3 Node)에 대해 다시 찾아본 내용을 정리했다.
일단 기본적인 정보는 아래 두 블로그에 잘 나와 있다.
https://engkimbs.tistory.com/660
https://paulsmooth.tistory.com/156
가장 먼저 확인하려고 했던 왜 3 node인지는 확인했다.
일단, ZooKeeper는 전체 node의 과반수가 살아있는 시점까지는 Fault Tolerance를 보장한다.
과반수를 정한다는 점에서 Falut Tolerance를 보장하는 최소 수는 3node이다.
3 node에서는 1개 server의 Fault에 대해서 Fault Tolerance를 보장한다.
4 node 역시 과반수 서버가 살아 있어야 정상 작동하므로 1개 node의 Fault에 대해서만
Fault Tolerance를 보장한다.
이래서 권장사항이 홀수 구성인 것이었다.
n개의 node의 Fault에 대해 Fault Tolerance를 보장받기 위해서는 2n+1개의 node를 구성해야 한다.
그런데 두번 째 블로그 글을 읽으면서 내용 중에
2곳의 데이터 센터에 각각 3 server로 zookeeper 앙상블이 구성되어 있는 케이스의 예제는 잘 이해가 되지 않았다.
대략 내용은 데이터 센터간에 Switch등으로 단절이 일어나면, 각 데이터 센터는 개별적인 zookeeper가 3 server 앙상블로 정상 운영되어 데이터 정합성이 문제가 된다는 내용이다.
이 부분은 아래 블로그를 통해 일정 부분은 좀 더 쉽게 이해했다.
https://engkimbs.tistory.com/561
대략 내용은 Zookeeper에는 과반수(majority)로 이루어진 quorum(쿼럼)이라는 그룹을 구성하는 기능이 있고
이 기능은 ZooKeeper에서 장애 또는 불일치가 발생했는데, 서비스가 정상적으로 도는 것처럼 보이는 것을 방지하는 것이 목적으로 보인다.
결국 2곳의 데이터 센터에 분할해서 node를 구성할 때에는 각각 n , n+1 의 숫자로 node를 분할해야한다.
똑같이 n, n으로 분할 구성하는 경우
데이터 센터간 연결이 끊기는 장애에 대해서는 majority를 구성을 못하게 되면서
양 데이터 센터 모두 ZooKeeper 서비스가 작동을 하지 않을 것이고
majority qourum을 사용하지 않는다면,
양 데이터 센터에 각각의 ZooKeeper 그룹이 생기면서 동일성 보장도 되지 않고
운영자는 서비스에 이상이 생겼는지 감지를 할 수 없게 된다.
n, n+1의 구성인 경우 데이터 센터간 연결이 끊어지면 n쪽의 구성을 가진 데이터 센터 쪽은 서비스가 되지 않을것이다. (quorum 구성을 위한 majority (과반수) 확보 불가)
P.S. 나중에 확인한 내용으로
Leader Election시에 짝수 Node구성으로는, 투표가 동일값이 나면서 문제가 될 수 있다는 내용을 들었다.
관련 상세 내용은 추가로 파악 예정 (6/16)
- 끝 -
'프로그래밍 > 빅데이터 관련' 카테고리의 다른 글
Telegraf + Influx DB + Grafana on AWS EC2 (0) | 2020.06.25 |
---|---|
Kafka Partition Assignment Strategy (0) | 2020.06.25 |
AWS EC2에 Kafka 클러스터(3 node) 구축하기 (기초) (0) | 2020.06.10 |