zetcd는 ZooKeeper에 대한 애플리케이션의 의존성을 제거하는 방법을 해결합니다.-리눅스-php.cn

분산 시스템은 일반적으로 중재 시스템을 사용하여 함께 작동합니다. 일반적으로 이러한 시스템은 분할 브레인을 방지하기 위해 정보의 정확한 전송을 보장하기 위해 중재를 사용합니다. 이러한 시스템은 충분한 설계 여유를 제공하는 대신 다양성을 희생합니다. 이는 구현의 확산으로 분명히 입증된 관행입니다. chubby, ZooKeeper, etcd 및 consul 등과 같은 시스템이 많이 있습니다. 이러한 시스템의 개념과 프로토콜은 다르지만 모두 유사한 키-값 기반 분산 중재를 제공합니다. etcd를 분산 시스템의 가장 주목받는 기본 구성 요소로 만들려는 계획의 일환으로 etcd 팀은 etcd 클러스터가 변경 없이 ZooKeeper 서비스 요청을 사용할 수 있도록 하는 새로운 에이전트인 zetcd를 개발했습니다.

ZooKeeper는 중재 소프트웨어의 최초 오픈 소스 구현으로 많은 분산 시스템에서 선호되는 백엔드가 되었습니다. 이론적으로 이러한 시스템은 etcd와 호환되어야 하지만 역사적 이유로 인해 etcd 클러스터는 ZooKeeper를 대체할 수 없으며 해당 데이터 모델 및 클라이언트 프로토콜은 ZooKeeper 애플리케이션과 호환되지 않습니다. 시스템이 이미 생산 중인 경우 이를 새로운 백엔드에 연결하고 새로운 복잡성을 도입할 인센티브가 거의 없습니다.

다행히도 etcd v3 API는 표준 프록시 zetcd를 통해 ZooKeeper 데이터 모델에 대한 시뮬레이션 지원을 구현할 준비를 하고 있습니다. zetcd는 etcd 팀이 개발한 새로운 오픈 소스 프로젝트로 오늘 zetcd의 첫 번째 베타 버전인 v0.0.1이 출시되었습니다. 출시되었습니다. 목표는 프로덕션 시스템에서 zetcd 시스템을 관리하고 배포하는 것입니다.

zetcd 에이전트는 etcd 클러스터 앞에 배포되고 시뮬레이션된 ZooKeeper 클라이언트 포트를 제공하므로 ZooKeeper 애플리케이션이 상위 계층에서 기본적으로 etcd를 호출할 수 있습니다. 일반적으로 zetcd는 ZooKeeper 클라이언트 요청을 수락하고 이를 etcd의 데이터 모델 및 API로 변환하고 요청을 etcd로 전달한 다음 클라이언트가 이해할 수 있는 방식으로 반환 정보를 다시 전달합니다. zetcd의 성능은 ZooKeeper와 비슷하며 ZooKeeper 클러스터와 etcd 간의 관리 및 운영 복잡성을 단순화합니다. 이 기사에서는 zetcd 사용 방법, zetcd 작동 방법 및 성능 벤치마크를 설명합니다.

zetcd 시작하기

zetcd가 실행되기 위해 필요한 것은 go 컴파일러와 인터넷에서 얻은 소스 코드, 그리고 etcd를 실행할 수 있는 시스템입니다. 다음 예에서는 zetcd 소스 코드를 얻고 zetcd에서 ZooKeeper 명령을 실행하는 방법을 보여줍니다. etcd와 zetcd는 모두 개발 브랜치를 기반으로 구축되므로 프로덕션 환경에서는 권장하지 않습니다. 이는 단지 사용 방법을 설명하기 위한 간단한 예일 뿐입니다.

먼저 etcd 및 zetcd 소스 코드를 구하여 바이너리 코드로 컴파일합니다.

으아악

두 번째로, etcd를 실행하고 zetcd를 etcd 클라이언트 서버에 연결하십시오:

으아악

구독을 추가하고 키를 생성하여 zetd를 사용해 보세요.

으아악

개념적으로 위의 예는 단일 etcd 인스턴스에 zetcd 계층을 추가하는 것을 완료합니다.
zetcd는 ZooKeeper에 대한 애플리케이션의 의존성을 제거하는 방법을 해결합니다.

etcd3

에서 ZooKeeper 지원

심층적으로 zetcd는 ZooKeeper의 데이터 모델을 적합한 etcd API로 변환합니다. 키 조회를 위해 zetcd는 ZooKeeper 계층적 디렉토리를 etcd의 플랫 바이너리 키스페이스로 변환합니다. 메타데이터를 관리하기 위해 etcd 백엔드에 쓸 때 zetcd는 메모리 수준 트랜잭션을 활용하여 정보를 ZooKeeper znode 정보로 안전하고 원자적으로 업데이트합니다.

ZooKeeper는 키를 디렉터리 형식(getChildren)으로 나열하고, etcd는 키를 간격(Range) 형식으로 나열합니다. 다음 그림에서는 zetcd가 etcd 아래의 키를 인코딩하여 디렉토리 형식의 목록을 효과적으로 지원하는 방법을 설명합니다. etcd의 모든 zetcd 키에는 전체 디렉터리 이름을 포함하는 접두사가 있습니다(예: "/" 및 "/abc"는 각각 깊이 0과 1을 나타냄). 디렉토리를 나열하기 위해 zetcd는 접두사가 붙은 범위 요청(예: ["/zk/key/002/abc/", "/zk/key/002/abc0")을 발행하여 디렉토리 깊이와 경로를 만족하는 디렉토리를 나열합니다. . /abc/ 아래의 모든 키. 깊이 제한은 디렉토리 자체에만 적용됩니다. zetcd가 경로만 사용하고 깊이를 사용하지 않는 경우 etcd는 이 디렉토리의 모든 키를 반환하고 zetcd는 결과를 삭제합니다. 그렇지 않으면 이 디렉토리의 키만 반환됩니다.

zetcd는 ZooKeeper에 대한 애플리케이션의 의존성을 제거하는 방법을 해결합니다.

각 ZooKeeper 키는 ZNode에 일부 메타데이터, 즉 키 조정, 버전, 권한 등을 전달합니다. etcd에도 각 키에 대한 메타데이터가 있지만 ZNode보다 훨씬 간단합니다. 예를 들어, etcd는 역할 기반 인증 메커니즘을 사용하므로 ACL이 없고 실제 시계가 없기 때문에 전복이 없습니다. 범위를 벗어났습니다. 타임스탬프가 없습니다. 이러한 추가 메타데이터는 완전한 ZNode를 설명하기 위해 해당 키에 매핑됩니다. 메타데이터를 수정할 때 zetcd는 메모리 수준 소프트 트랜잭션을 사용하여 키 하위 집합을 자동으로 업데이트하므로 값비싼 잠금 메커니즘 없이도 ZNode가 일관성을 유지할 수 있습니다.

또한 zetcd는 인증된 ZooKeeper 서버를 통해 동적 검증을 수행할 수 있습니다. 비교를 위해 zetcd는 etcd와 외부 ZooKeeper 서버 모두에 연결할 수 있습니다. 클라이언트가 이 모드에서 zetcd에 대한 요청을 시작하면 해당 요청은 zetcd와 ZooKeeper 서버 모두로 전달됩니다. 두 서버의 응답 데이터가 일치하지 않으면 zetcd는 이 응답에 대한 경고 플래그를 지정합니다.

성능 벤치마크

由于数据的转换以及额外的网络开销，也许很容易觉得这样的模拟不切实际。尽管对于ZooKeeper或者etcd集群来说，zetcd有额外的花销，但是它仍然有一个优势，即某些etcd应用安装完毕后仍然需要ZooKeeper来协调的场景。例如，早期用户报告称在zetcd里通过etcd的TLS加密流量比一个类似的经典ZooKeeper配置更简单。在这些场景中，支持同一种ZooKeeper协议所带来的简单可靠性比性能更重要一些。跟etcd性能工具的接口及报告形式类似，zetcd命令行工具zkboom可以用来判断一个zetcd的性能基准是否满足要求。其它ZooKeeper性能工具应该也可以用在zetcd；zkboom为用户提供了便利，我们不妨试试用它来做下创建key的测试：

go get github.com/coreos/zetcd/cmd/zkboom 
zkboom --conns=50 --total=10000 --endpoints=localhost:2181 create

로그인 후 복사

zetcd应当可以为小负载提供充分的性能保障。一个简单两节点配置的延迟基准表明zetcd是可以承受大量请求的。具体配置为两台Linux服务器通过一个千兆交换机互联，其中一台设备在RAID磁盘配置上运行代理和和服务端，另外一台设备用于产生客户请求。zkbook通过创建一个空的key存储，然后从中读取128Kbytes的键值对来进行测量。用户请求被限制在每秒2500个请求，然后逐渐增加并发客户端数量。ZooKeeper 3.4.10和etcd结果对比见下图。

下图揭示了zetcd客户端并发数与创建key的平均延迟之间的关系。由于etcd在延迟上比ZooKeeper要有5-35ms的优势，zetcd有足够余地处理由于额外负载和网络跳转造成的延迟。比起ZooKeeper，zetcd代理始终还是存在20ms左右的差距，但是从处理2500请求的吞吐量数据来看，并没有出现队列堵塞。一种对zetcd写比较慢的解释是，与读不一样，由于数据模型上存在差异，所以在每个ZooKeeper key写时需要写多个key。

zetcd는 ZooKeeper에 대한 애플리케이션의 의존성을 제거하는 방법을 해결합니다.

下图揭示了zetcd客户端并发数与key取值的平均延迟之间的关系。由于ZooKeeper的取值延迟比etcd要快那么2ms左右，想要zetcd提供数据的速度快过ZooKeeper的话恐怕还得依赖于etcd本身性能的进一步提升。然而，尽管zetcd需要从etcd请求额外的key来模拟Zookeeper znode的元数据，zetcd的命中延迟在等待etcd key提取数据方面只增加了大概1.5ms。zetcd在key的数据提取操作方面仅需一次往返，因为读请求会被打包到一个etcd事务中。

zetcd는 ZooKeeper에 대한 애플리케이션의 의존성을 제거하는 방법을 해결합니다.
zetcd承诺上述性能基准测试的结果是合理的，在可接受的延迟情况下，可以轻松支撑每秒上千个操作。以上模拟对于Mesos，Kafka和Drill替代ZooKeeper提供了一个替代选择。但是对于zetcd本身来说性能方面仍有不少的提升空间。与此同时测试更多的ZooKeeper应用也会进一步推动zetcd成为ZooKeeper服务器的替代品。