비교

Zookeeper

장점

가장 오래 된 프로젝트
가장 신뢰성 높음
기술적으로 완성도 높음
많은 큰 회사들이 이미 사용하고 있음 (우리 회사, 특히 우리 팀 포함)
파일 시스템과 비슷해서 이해하기 쉬운 데이터 저장 구조
풍부한 기능 보유

단점

자바 기반으로 경쟁자들에 비해 무겁고 많은 자원을 필요로 함
복잡함
- 사용 용도에 따라 필요한 기능보다 불필요한 기능이 더 많은 경우가 존재
- 서비스 및 클라이언트 모두에게 무거운 dependency가 얹어짐
동적으로 노드를 확장하기 어려움
- 구버전에서는 무조건 주키퍼를 재시작해야만 했음
- 3.5.0 이후 버전부터는 동적 확장 가능
- 그러나 2016년 11월 기준으로 3.5.0이 아직 stable 버전이 아님
primitive 값만 저장 가능

Etcd

장점

설치, 배포 및 사용이 쉬움
신뢰성 있는 데이터 저장, 제공
훌륭한 문서를 가짐
가볍고 간단함
- 꼭 필요한 서드파티들의 조합으로 작게 시스템 구축 가능
Raft 알고리즘

단점

주키퍼에 비해서 상대적으로 짧은 기간동안 검증됨
- 첫 릴리즈가 2014년
primitive 값만 저장 가능

Consul

장점

gossip + Raft 알고리즘
Service discovery 시스템을 자체적으로 내장
- DNS, HTTP 인터페이스 선택 사용
multiple datacenters 지원
손 쉬운 노드 추가
자체적인 UI 제공
서비스 단위로 데이터 저장 가능

단점

etcd보다도 짧은 역사를 가짐

Eureka

고민거리

CP vs AP (CAP 이론)

Eureka 문서를 보다보면 Service discovery 측면에서는 CP보단 AP가 낫다는 말을 여러 번 찾아볼 수 있다. service discovery는 잘못된 정보가 섞여있을 수 있더라도 어쨌든 데이터를 받는게 아예 못받는 것 보다는 낫다는 주장인데... 예를 들어 Zookeeper의 경우 Split brain 이 발생하면 나눠진 partition 중 quorum 만큼의 갯수를 충족하지 못한 partition에 속한 node의 client들은 모두 zookeeper connection을 잃어버리고 당연히 service discovery도 불가능하게 되는건 사실이다. 그렇게 되면 그 클라이언트들은 모두 서비스를 정상적으로 이용할 수 없게 되는 셈이다.

한편 좀 더 고민해보면 client에선 connection이 끊어지면 설정에 있는 다른 zookeeper 주소로 연결을 시도할 것이고 그 중에 정상 partition에 속한 서버가 있다면 정상적으로 서비스 이용이 가능할 것이라는 생각도 든다. 이 상황에서 문제점은 클라이언트가 살아있는 서버를 찾아서 접속하는데 걸리는 시간만큼 시간이 더 소요될 수 있다는 것과 config에 다른 주소가 저장되어있지 않은 상황이라면 클라이언트가 서비스를 정상적으로 이용할 수 없다는 것이고, 장점은 언제나 정확한 현재 서비스 상태를 제공받을 수 있다는 것이다.

양쪽 다 일장일단이 있어 어느 것이 정답이라고 딱 잘라 말하기가 쉽지 않다.

비교

비교