일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- go
- Go언어
- 튜토리얼
- 파이썬
- DP
- HBase
- Linux
- 자바
- 코드워
- 동적프로그래밍
- 알고리즘
- gradle
- dynamic programming
- 문제풀이
- docker
- leetcode
- golang
- 주키퍼
- scala
- redis
- boj
- zookeeper
- 리눅스
- Java
- 스칼라
- programmers
- 프로그래머스
- Python
- codewars
- OOM
- Today
- Total
파이문
[Zookeeper] 주키퍼를 통한 리더 선출 본문
주키퍼를 통한 리더 선출
HBase 를 비롯한 많은 분산 시스템에서는 주키퍼를 통해 일관성, 가용성 (CAP 이론중 CA) 을 보장 받고 있다.
Leader Election (리더 선출)
다양한 다른 분산 시스템과 같이 주키퍼를 이용해 고 가용성 어플리케이션을 설계할 일이 생겨서, 리더 선출 방법들을 살펴 보았다.
이 방법은 최선이 아닐 수 있다.
리더 선출 준비
우선 임의의 path 를 지정한다. 여기서는 /election
이라고 하겠다.
/election
하위에, 가용하는 서버 목록의 정보들을 Ephemeral-sequential 모드로 생성하는 것이 핵심이다.
만약 서버가 1번부터 10번까지 총 10개 있다고 해보자. (혹은 10개의 프로세스라고 볼 수도 있다.)
1번 서버(혹은 프로세스) 가 /election
의 자식으로 아래와 같이 Ephemeral-sequential 노드를 생성한다.
create -es /election server-n
결과는 아마 server-n-00000
과 같은 형태가 될 것이다. (sequential number 는 다를 수 있다.)
그리고 그 다음 2번 프로세스가 같은 방식으로 노드를 생성한다고 해 보자. 다른 설정을 하지 않았다면 결과 노드는 server-n-00001
처럼 최초에 만들어졌던 노드보다 더 큰 숫자가 할당 될 것이다.
물론 수는 1씩 증가하지 않을 수 있다. 중요한 건 sequential 하다는 것이다.
여기까지만 보면 어떻게 이렇게 리더 선출을 하나 싶기도 할지 모른다.
그렇다면 이렇게 생성된 자식 노드들 중에 어떤것이 리더가 되어야 할까?
보통 가장 작은 수를 갖는 노드가 리더로 한다. 즉 아래와 같은 노드 들이 있을때
/electopn/server-n-00000
/election/server-n-00001
/election/server-n-00009
/election/server-n-00012
...
리더는 server-n-00000
이 된다. 이를 primary node 라 부른다.
리더 장애 복구
이제는 리더가 죽거나, 장애가 발생 시 나머지 노드들 중 어떤것이 리더가 되어야 하고, 어떻게 리더가 장애가 났는지를 알 수 있냐는 문제가 남았다.
리더 server-n-00000
의 대용품 backup node 는 어떤것이 되어야할까?
가장 쉬운 방법은 이미 노드들을 sequential 하게 만들었기 때문에 server-n-00000
의 다음 노드 (다음 숫자) server-n-00001
이 backup node 가 되면 될 것이다.
리더가 죽을 시, 선출될 다음 노드도 이제 선택했다면 이제 리더가 죽었음을 해당 backup node 가 감지하는 것이다.
이 때, 사용하는 것이 바로 Watcher
이다. 주키퍼는 Watcher
라는, 특정 노드에 생기는 이벤트를 감지하고, 액션을 취할 수 있는 인터페이스가 존재한다.
server-n-00001
은 server-n-00000
에게 exists watcher 를 등록하면 된다. 그러면 노드 server-n-00000
가 삭제 된다면 (Ephemeral 이기 때문에 프로세스가 중지 되면 노드도 날라간다.) server-n-00001
을 등록한 프로세스는 워쳐로 알람을 받을 수 있다.
삭제 알람을 받게되면 server-n-00001
를 등록한 프로세스는 server-n-00001
를 마스터로 승격 시키면 된다. (마스터가 해야할 역할을 위임하면 된다.) 그러면 server-n-00001
가 죽게 된다면?
역시 마찬가지로 server-n-00001
의 다음 노드 server-n-00009
가 server-n-00001
의 backup node 로써 exists watcher 를 등록하면 된다.
워쳐를 등록하는 로직은 최초에 /election
하위에 노드를 생성할 때 미리 진행해주면 될 것이다.
이 방법을 사용하면 하나의 노드에 대해선 하나의 워쳐만 등록하게 된다.
(실제로 주키퍼에선 하나의 노드엔 하나의 워쳐를 지향하고 있다.)
정리
- 서버 (혹은 프로세스) 정보를 Ephemeral sequential 모드로 zNode 를 생성한다.
- 생성된 zNode 들 중에 리더는 항상 가장 작은 sequential 을 갖는 zNode 이다.
- 각각의 sequential zNode 들은 바로 그 다음 수의 zNode 를 backup node 로 갖고 있는다.
- 각각의 backup node 들은 바로 이전의 sequential zNode 에
Watcher
를 등록한다.
참고
'컴퓨터 과학 > 분산 시스템 및 빅데이터' 카테고리의 다른 글
HBase TTL (0) | 2020.10.20 |
---|---|
consensus algorithms (0) | 2020.01.31 |
주키퍼 (Zookeeper) 살펴보기 (0) | 2019.09.22 |
Split Brain 이란? (0) | 2019.09.22 |
복제(replication)와 샤딩(sharding) (0) | 2019.06.16 |