XNUMX명의 학생과 XNUMX개의 분산 키-값 저장소

또는 ZooKeeper, etcd 및 Consul KV용 클라이언트 C++ 라이브러리를 작성한 방법

분산 시스템의 세계에는 클러스터 구성에 대한 정보 저장, 노드 구성 관리, 결함이 있는 노드 감지, 리더 선택 등 여러 가지 일반적인 작업이 있습니다. 다른. 이러한 문제를 해결하기 위해 조정 서비스라는 특수 분산 시스템이 만들어졌습니다. 이제 우리는 ZooKeeper, etcd 및 Consul이라는 세 가지에 관심을 가질 것입니다. Consul의 풍부한 기능 중에서 Consul KV에 중점을 둘 것입니다.

본질적으로 이러한 모든 시스템은 내결함성이 있고 선형화 가능한 키-값 저장소입니다. 나중에 논의할 데이터 모델에는 상당한 차이가 있지만 동일한 실제 문제를 해결합니다. 분명히 조정 서비스를 사용하는 각 애플리케이션은 그 중 하나에 연결되어 있으며, 이는 서로 다른 애플리케이션의 동일한 문제를 해결하는 하나의 데이터 센터에서 여러 시스템을 지원해야 할 필요성으로 이어질 수 있습니다.

이 문제를 해결하려는 아이디어는 호주의 한 컨설팅 에이전시에서 시작되었고, 이를 구현하는 것은 소규모 학생들로 구성된 우리 팀의 몫이 되었습니다. 이에 대해 제가 이야기하겠습니다.

우리는 ZooKeeper, etcd 및 Consul KV 작업을 위한 공통 인터페이스를 제공하는 라이브러리를 만들었습니다. 라이브러리는 C++로 작성되었지만 다른 언어로 이식할 계획이 있습니다.

데이터 모델

세 가지 서로 다른 시스템에 대한 공통 인터페이스를 개발하려면 이들 시스템의 공통점과 차이점을 이해해야 합니다. 그것을 알아 봅시다.

주 키퍼

키는 트리로 구성되며 노드라고 합니다. 따라서 노드에 대해 해당 하위 항목 목록을 얻을 수 있습니다. znode 생성(create) 및 값 변경(setData) 작업은 분리되어 있습니다. 기존 키만 읽고 변경할 수 있습니다. 노드의 존재를 확인하고, 값을 읽고, 자식을 가져오는 작업에 Watch를 연결할 수 있습니다. Watch는 서버의 해당 데이터 버전이 변경될 때 실행되는 일회성 트리거입니다. 임시 노드는 오류를 감지하는 데 사용됩니다. 이를 생성한 클라이언트의 세션에 연결되어 있습니다. 클라이언트가 세션을 닫거나 ZooKeeper에 세션 존재 알림을 중지하면 해당 노드가 자동으로 삭제됩니다. 간단한 트랜잭션이 지원됩니다. 즉, 최소한 하나라도 불가능할 경우 모두 성공하거나 실패하는 일련의 작업입니다.

등

이 시스템의 개발자는 분명히 ZooKeeper에서 영감을 얻었으므로 모든 것을 다르게 수행했습니다. 키의 계층 구조는 없지만 사전순으로 정렬된 세트를 형성합니다. 특정 범위에 속하는 모든 키를 가져오거나 삭제할 수 있습니다. 이 구조는 이상하게 보일 수도 있지만 실제로는 매우 표현력이 뛰어나며 이를 통해 계층적 뷰를 쉽게 모방할 수 있습니다.

etcd에는 표준 비교 및 ​​설정 작업이 없지만 더 나은 기능인 트랜잭션이 있습니다. 물론 세 시스템 모두에 존재하지만 etcd 트랜잭션이 특히 좋습니다. 확인, 성공, 실패의 세 가지 블록으로 구성됩니다. 첫 번째 블록에는 일련의 조건, 두 번째 및 세 번째 작업이 포함되어 있습니다. 트랜잭션은 원자적으로 실행됩니다. 모든 조건이 true이면 성공 블록이 실행되고, 그렇지 않으면 실패 블록이 실행됩니다. API 3.3에서는 성공 및 실패 블록에 중첩된 트랜잭션이 포함될 수 있습니다. 즉, 거의 임의의 중첩 수준의 조건부 구성을 원자적으로 실행할 수 있습니다. 어떤 검사와 ​​작업이 있는지 자세히 알아볼 수 있습니다. 선적 서류 비치.

시계도 여기에 존재하지만 조금 더 복잡하고 재사용이 가능합니다. 즉, 특정 키 범위에 시계를 설치한 후 시계를 취소할 때까지 첫 번째 업데이트뿐만 아니라 이 범위의 모든 업데이트를 받게 됩니다. etcd에서 ZooKeeper 클라이언트 세션과 유사한 것은 임대입니다.

K.V. 영사

여기에는 엄격한 계층 구조도 없지만 Consul은 존재하는 것처럼 보이게 만들 수 있습니다. 즉, 지정된 접두사가 있는 모든 키를 가져오고 삭제할 수 있습니다. 즉, 키의 "하위 트리"로 작업할 수 있습니다. 이러한 쿼리를 재귀 쿼리라고 합니다. 또한 Consul은 접두사 뒤에 지정된 문자를 포함하지 않는 키만 선택할 수 있으며 이는 직계 "자식"을 얻는 것에 해당합니다. 그러나 이것이 바로 계층 구조의 모습이라는 점을 기억할 가치가 있습니다. 부모가 존재하지 않는 경우 키를 생성하거나 자식이 있는 키를 삭제할 수 있지만 자식은 시스템에 계속 저장됩니다.

시계 대신 Consul은 HTTP 요청을 차단했습니다. 본질적으로 이는 데이터 읽기 방법에 대한 일반적인 호출이며, 다른 매개변수와 함께 마지막으로 알려진 데이터 버전이 표시됩니다. 서버에 있는 해당 데이터의 현재 버전이 지정된 버전보다 크면 응답이 즉시 반환되고, 그렇지 않으면 값이 변경될 때 응답이 반환됩니다. 언제든지 키에 연결할 수 있는 세션도 있습니다. 세션을 삭제하면 관련 키도 삭제되는 etcd 및 ZooKeeper와 달리 세션이 단순히 연결 해제되는 모드가 있다는 점은 주목할 가치가 있습니다. 사용 가능 업무, 가지가 없지만 모든 종류의 수표가 있습니다.

함께 모아서

ZooKeeper는 가장 엄격한 데이터 모델을 가지고 있습니다. etcd에서 사용할 수 있는 표현 범위 쿼리는 ZooKeeper 또는 Consul에서 효과적으로 에뮬레이션될 수 없습니다. 모든 서비스에서 최선을 다하려고 노력한 결과 다음과 같은 중요한 예외를 제외하고 ZooKeeper 인터페이스와 거의 동일한 인터페이스를 갖게 되었습니다.

• 시퀀스, 컨테이너 및 TTL 노드 지원되지 않음
• ACL은 지원되지 않습니다.
• set 메소드는 키가 존재하지 않는 경우 키를 생성합니다(ZK에서는 setData가 이 경우 오류를 반환함).
• set 및 cas 메소드는 분리되어 있습니다(ZK에서는 본질적으로 동일합니다).
• 삭제 메소드는 하위 트리와 함께 노드를 삭제합니다(ZK에서 삭제는 노드에 자식이 있는 경우 오류를 반환합니다).
• 각 키에는 하나의 버전, 즉 값 버전(ZK)만 있습니다. 그들 중 XNUMX 명이있다)

순차 노드를 거부하는 이유는 etcd와 Consul이 이를 기본적으로 지원하지 않고 결과 라이브러리 인터페이스 위에 사용자가 쉽게 구현할 수 있기 때문입니다.

정점을 삭제할 때 ZooKeeper와 유사한 동작을 구현하려면 etcd 및 Consul의 각 키에 대해 별도의 하위 카운터를 유지해야 합니다. 메타 정보 저장을 피하려고 했기 때문에 전체 하위 트리를 삭제하기로 결정했습니다.

구현의 미묘함

다양한 시스템에서 라이브러리 인터페이스를 구현하는 몇 가지 측면을 자세히 살펴보겠습니다.

etcd의 계층 구조

etcd에서 계층적 보기를 유지하는 것은 가장 흥미로운 작업 중 하나였습니다. 범위 쿼리를 사용하면 지정된 접두사가 있는 키 목록을 쉽게 검색할 수 있습니다. 예를 들어 다음으로 시작하는 모든 항목이 필요한 경우 "/foo", 당신은 범위를 요구하고 있습니다 ["/foo", "/fop"). 그러나 이렇게 하면 키의 전체 하위 트리가 반환되므로 하위 트리가 큰 경우 허용되지 않을 수 있습니다. 처음에는 주요 번역 메커니즘을 사용할 계획이었습니다. zetcd에서 구현됨. 여기에는 트리의 노드 깊이와 동일한 키 시작 부분에 XNUMX바이트를 추가하는 작업이 포함됩니다. 예를 들어 보겠습니다.

"/foo" -> "u01/foo"
"/foo/bar" -> "u02/foo/bar"

그런 다음 키의 모든 직계 자식을 가져옵니다. "/foo" 범위를 요청하여 가능 ["u02/foo/", "u02/foo0"). 예, ASCII로 "0" 바로 뒤에 서 있다 "/".

하지만 이 경우 정점 제거를 어떻게 구현합니까? 유형의 모든 범위를 삭제해야 하는 것으로 나타났습니다. ["uXX/foo/", "uXX/foo0") XX의 경우 01부터 FF까지입니다. 그러다가 우리는 우연히 만났어요 작업 횟수 제한 한 번의 거래 내에서.

그 결과 간단한 키 변환 시스템이 개발되어 키 삭제와 하위 목록 가져오기를 모두 효과적으로 구현할 수 있었습니다. 마지막 토큰 앞에 특수 문자를 추가하면 충분합니다. 예를 들어:

"/very" -> "/u00very"
"/very/long" -> "/very/u00long"
"/very/long/path" -> "/very/long/u00path"

그런 다음 키를 삭제합니다. "/very" 삭제로 바뀐다 "/u00very" 및 범위 ["/very/", "/very0"), 모든 하위 항목 가져오기 - 범위에서 키 요청 시 ["/very/u00", "/very/u01").

ZooKeeper에서 키 제거

이미 언급했듯이 ZooKeeper에서는 하위 노드가 있는 노드를 삭제할 수 없습니다. 하위 트리와 함께 키를 삭제하고 싶습니다. 어떻게 해야 하나요? 우리는 낙관적인 태도로 이를 수행합니다. 먼저, 하위 트리를 재귀적으로 탐색하여 별도의 쿼리를 통해 각 정점의 하위 항목을 얻습니다. 그런 다음 올바른 순서로 하위 트리의 모든 노드를 삭제하려고 시도하는 트랜잭션을 구축합니다. 물론 하위 트리를 읽는 것과 삭제하는 사이에 변경이 발생할 수 있습니다. 이 경우 트랜잭션이 실패합니다. 또한 읽기 프로세스 중에 하위 트리가 변경될 수 있습니다. 예를 들어, 이 노드가 이미 삭제된 경우 다음 노드의 하위 노드에 대한 요청은 오류를 반환할 수 있습니다. 두 경우 모두 전체 프로세스를 다시 반복합니다.

이 접근 방식은 하위 항목이 있는 경우 키 삭제를 매우 비효율적으로 만들고, 애플리케이션이 하위 트리를 계속 사용하여 키를 삭제하고 생성하는 경우에는 더욱 그렇습니다. 그러나 이를 통해 etcd 및 Consul에서 다른 메소드 구현이 복잡해지는 것을 피할 수 있었습니다.

ZooKeeper에 설정

ZooKeeper에는 트리 구조(create, delete, getChildren)와 노드의 데이터(setData, getData)로 작업하는 별도의 메소드가 있습니다. 또한 모든 메소드에는 엄격한 전제 조건이 있습니다. 노드가 이미 있으면 오류를 반환합니다. 생성, 삭제 또는 setData – 아직 존재하지 않는 경우. 키의 존재 여부를 생각하지 않고 호출할 수 있는 set 메서드가 필요했습니다.

한 가지 옵션은 삭제와 마찬가지로 낙관적인 접근 방식을 취하는 것입니다. 노드가 존재하는지 확인하세요. 존재하는 경우 setData를 호출하고, 그렇지 않으면 생성합니다. 마지막 메서드에서 오류가 반환되면 다시 반복하세요. 가장 먼저 주목해야 할 점은 존재 테스트가 무의미하다는 것입니다. 즉시 create를 호출할 수 있습니다. 성공적으로 완료되면 노드가 존재하지 않고 생성되었음을 의미합니다. 그렇지 않으면 create가 적절한 오류를 반환한 후 setData를 호출해야 합니다. 물론 호출 사이에 경쟁 호출에 의해 정점이 삭제될 수 있으며 setData도 오류를 반환합니다. 이 경우 다시 모든 작업을 수행할 수 있지만 그만한 가치가 있습니까?

두 메서드 모두 오류를 반환하면 경쟁 삭제가 발생했음을 확실히 알 수 있습니다. 이 삭제가 set을 호출한 후에 발생했다고 가정해 보겠습니다. 그렇다면 우리가 확립하려는 의미는 이미 지워졌습니다. 이는 실제로 아무것도 작성되지 않았더라도 set이 성공적으로 실행되었다고 가정할 수 있음을 의미합니다.

더 많은 기술적인 세부사항

이번 섹션에서는 분산 시스템에서 벗어나 코딩에 대해 이야기하겠습니다.
고객의 주요 요구 사항 중 하나는 크로스 플랫폼이었습니다. 즉, 서비스 중 하나 이상이 Linux, MacOS 및 Windows에서 지원되어야 합니다. 처음에는 Linux용으로만 개발했고 나중에 다른 시스템에서도 테스트를 시작했습니다. 이로 인해 많은 문제가 발생했으며 한동안 접근 방법이 완전히 불분명했습니다. 결과적으로 이제 세 가지 조정 서비스가 모두 Linux 및 MacOS에서 지원되는 반면 Consul KV만 Windows에서 지원됩니다.

우리는 처음부터 기성 라이브러리를 사용하여 서비스에 접근하려고 노력했습니다. ZooKeeper의 경우 선택이 떨어졌습니다. 주키퍼 C++, 결국 Windows에서 컴파일하지 못했습니다. 그러나 이것은 놀라운 일이 아닙니다. 라이브러리는 Linux 전용으로 배치되어 있습니다. Consul의 유일한 선택은 PP콘술. 지원이 추가되어야했습니다. 세션 и 업무. etcd의 경우 최신 버전의 프로토콜을 지원하는 본격적인 라이브러리를 찾을 수 없으므로 간단히 생성된 grpc 클라이언트.

ZooKeeper C++ 라이브러리의 비동기 인터페이스에서 영감을 받아 비동기 인터페이스도 구현하기로 결정했습니다. ZooKeeper C++에서는 이를 위해 future/promise 프리미티브를 사용합니다. 불행히도 STL에서는 매우 적절하게 구현됩니다. 예를 들어, 아니오 그런 다음 방법, 전달된 함수가 사용 가능해지면 future 결과에 적용됩니다. 우리의 경우 결과를 우리 라이브러리의 형식으로 변환하려면 이러한 방법이 필요합니다. 이 문제를 해결하기 위해 우리는 고객의 요청에 따라 Boost와 같은 무거운 타사 라이브러리를 사용할 수 없었기 때문에 자체적으로 간단한 스레드 풀을 구현해야 했습니다.

우리의 구현은 다음과 같이 작동합니다. 호출되면 추가 약속/미래 쌍이 생성됩니다. 새로운 future가 반환되고, 전달된 future는 해당 함수 및 추가 Promise와 함께 대기열에 배치됩니다. 풀의 스레드는 대기열에서 여러 미래를 선택하고 wait_for를 사용하여 폴링합니다. 결과를 사용할 수 있게 되면 해당 함수가 호출되고 해당 함수의 반환 값이 Promise에 전달됩니다.

동일한 스레드 풀을 사용하여 etcd 및 Consul에 대한 쿼리를 실행했습니다. 이는 기본 라이브러리가 여러 다른 스레드에서 액세스될 수 있음을 의미합니다. ppconsul은 스레드로부터 안전하지 않으므로 이에 대한 호출은 잠금으로 보호됩니다.
여러 스레드에서 grpc로 작업할 수 있지만 미묘한 부분이 있습니다. etcd에서 watch는 grpc 스트림을 통해 구현됩니다. 이는 특정 유형의 메시지에 대한 양방향 채널입니다. 라이브러리는 모든 감시에 대한 단일 스레드와 수신 메시지를 처리하는 단일 스레드를 생성합니다. 따라서 grpc는 스트리밍에 대한 병렬 쓰기를 금지합니다. 이는 시계를 초기화하거나 삭제할 때 다음 요청을 보내기 전에 이전 요청의 전송이 완료될 때까지 기다려야 함을 의미합니다. 동기화에 사용한다 조건부 변수.

합계

자신에 대한 참조 : liboffkv.

우리 팀: 라에드 로마노프, 이반 글루셴코프, 드미트리 카말디노프, 빅터 크라피벤스키, 비탈리 이바닌.

출처 : habr.com