분류

데이터베이스 변경 프로토콜: 카우치베이스 서버 3.0 복제를 연결하는 슈퍼 컨덕터

DCP(데이터베이스 변경 프로토콜)는 버전 3.0의 핵심 복제 프로토콜로, 지리적으로 분산된 데이터센터의 노드와 클러스터를 연결하는 데 사용됩니다. 이 게시물에서는 이 프로토콜의 작동 방식과 Couchbase Server 3.0을 통해 가용성, 성능 및 확장성을 높이는 방법에 대해 자세히 살펴보겠습니다.  

복제가 모든 데이터베이스에서 중요한 부분인 이유부터 시작하겠습니다: "이유"는 다음과 같습니다: 

  • 데이터 보호: 복제는 로컬 및 교차 데이터 센터 복제 피드를 유지하여 장애로부터 보호하는 데 사용됩니다. 데이터베이스가 복제본에 데이터를 얼마나 빨리 복제할 수 있는지에 따라 데이터 손실 기간이 결정됩니다. 데이터베이스의 복제 효율이 낮을수록 데이터 손실 기간도 커집니다!
  • 더 신선한 인덱스 제공: 복제는 Couchbase에서 뷰를 업데이트하는 수단이기도 합니다. 쿼리에 응답하는 데 사용되는 증분 맵/축소 인덱스는 최신 상태로 유지하려면 빠른 피드가 필요합니다. 특히 데이터의 일관된 보기가 필요한 쿼리의 경우, 복제 피드가 놀라울 정도로 빠르고 효율적이지 않으면 답변할 수 없습니다!

그렇다면 DCP가 경쟁 복제 프로토콜과 다른 특별한 점은 무엇일까요? 4가지 주요 특성이 있습니다: 

  • 주문하기: DCP는 돌연변이를 주문합니다. 이는 중단된 부분을 기록하는 데 중요합니다. 
  • 다시 시작할 수 있습니다: DCP는 짧거나 오래 지속되는 장애 후 재시작을 최적화합니다. 
  • 일관성: DCP는 일관된 스냅샷을 효율적으로 생성할 수 있습니다.
  • 고성능: DCP는 메모리 기반입니다. 클라이언트가 따라잡을 수 있는 한 열심히 변경 사항을 스트리밍합니다.

아키텍처

DCP의 마법의 대부분을 구성하는 세 가지 요소, 즉 vbucket UUID, 시퀀스 번호 및 장애 조치 로그가 있습니다. vbuckets와 같은 몇 가지 개념은 이미 알고 계시리라 가정하겠습니다. (자세한 내용은 여기 에 대해). 그것이 무엇인지 살펴보겠습니다:

vbucket UUID와 변이 시퀀스 번호는 CouchBase Server의 각 변이를 고유하게 식별합니다. 이러한 개념에 대해 설명해드리자면, vbucket은 Couchbase Server 내의 샤드를 나타냅니다.  vbucket에는 고유한 UUID가 있습니다. 를 할당합니다. 각 돌연변이에는 시퀀스 번호가 할당됩니다.. 시퀀스 번호는 단조롭게 증가하는 숫자이며 각 v버킷으로 범위가 지정됩니다. 일관성과 세분화된 재개 기능의 마법은 장애 조치 로그를 통해 이루어집니다. 각 vbucket은 장애 조치 로그도 유지합니다. 장애 조치 로그에는 여러 쌍의 vbucket UUID 및 시퀀스 번호가 기록됩니다. 첫 번째 항목은 시간의 시작을 표시하고 각각의 새 항목은 장애 조치를 표시합니다. 시스템의 마스터 및 복제 v버킷은 동일한 장애 조치 로그를 유지합니다. 장애가 발생하면, 예를 들어 마스터 v버킷에 장애가 발생하면 복제 v버킷이 마스터 v버킷으로 업데이트됩니다. 새 마스터 v버킷 장애 조치 로그 항목에는 새 마스터 v버킷의 UUID와 마지막 시퀀스 번호가 기록되고 이를 복제 v버킷에 복제하여 해당 상황을 표시합니다. 이러한 기본적인 메커니즘을 통해 많은 마법이 가능합니다. 다음 섹션에서는 DCP 3.0에서 개선된 주요 작업 몇 가지를 살펴보고 이러한 메커니즘이 어떻게 작동하는지 설명해 보겠습니다.

증분 백업

3.0을 사용하면 백업 저장 효율을 100배 높일 수 있습니다. 방법은 다음과 같습니다: 3.0에서는 전체 백업을 증분 백업으로 보완하여 스토리지 효율성을 높일 수 있습니다. 증분 백업은 마지막 전체 백업, 누적 백업 또는 증분 백업 이후 변경된 데이터만 백업합니다. 매번 전체 스냅샷을 찍는 대신 전체 스냅샷을 찍고 증분 또는 누적 백업 체인을 만들 수 있습니다. Vbucket UUID, 시퀀스 번호 및 장애 조치 로그는 모두 백업 체인 간에 일관성을 유지하는 데 필요한 메타데이터를 제공합니다.

뷰 및 증분 맵/축소 처리

지연 시간이 짧은 뷰 쿼리는 신속한 애플리케이션의 핵심이며, 3.0에서는 뷰 쿼리 지연 시간이 50배 개선되었습니다. 맵/축소는 Hadoop 세계에서 한동안 사용되어 왔지만, Couchbase는 뷰에서 쿼리를 미리 계산할 수 있도록 맵/축소의 증분 처리 기능을 제공합니다. 이것이 바로 카우치베이스 서버가 지연 시간이 짧은 쿼리를 제공하는 방식입니다. 증분 처리 엔진은 DCP 스트림에 의해 공급됩니다. 변이가 메모리에 도착하면 디자인 문서와 그 안에 있는 뷰로 처리하기 위해 스트리밍됩니다. 스트리밍은 이전 버전에 비해 인덱스의 최신성을 50배 이상 향상시킵니다. 많은 쿼리에는 일관성이 필요합니다. 카우치베이스 개발자는 뷰의 일관성에 대한 옵션이 있습니다. 인덱스가 어느 시점에서 처리한 것을 쿼리하거나(stale=ok), 쿼리 시점까지의 모든 변이가 포함된 뷰를 쿼리하도록 요청할 수 있습니다(stale=false). DCP는 변경 사항을 매우 빠르게 뷰 프로세서로 스트리밍할 수 있기 때문에 특히 후자의 쿼리 유형에서 빛을 발합니다. 

빠른 리밸런싱을 위한 델타 복구

문제로 인해 장애 조치된 노드를 클러스터로 다시 가져오는 경우, 더 이상 몇 시간 또는 며칠을 되돌려서 노드에 변경 사항을 다시 전송할 필요가 없습니다. vbucket UUID, 시퀀스 번호 및 장애 조치 로그를 통해 DCP는 중단된 지점부터 매우 세밀하게 다시 시작할 수 있습니다. 수신 노드가 클러스터에서 몇 분 동안 부재한 경우, 델타 노드 복구 옵션을 사용하여 최근 몇 분 동안의 누락된 변이를 수신하는 것만으로 간단히 복구할 수 있습니다. 특히 노드당 데이터 크기가 방대한 경우, 델타 노드 복구를 통해 리밸런싱 시간이 100배 이상 개선되었습니다.

"ReplicateTo"를 통한 내구성 보장 

카우치베이스 서버에는 일관성이 내장되어 있어 메모리에 변형을 쓰더라도 문제 없이 "자체 쓰기"가 가능합니다. 그러나 많은 개발자는 데이터 손실 없이 노드 장애를 견딜 수 있도록 애플리케이션에 대한 내구성 보장이 필요합니다. 일부는 전통적인 디스크 지속성에 의존하지만, 더 나은 가용성과 복구 가능성을 위해 Couchbase의 많은 개발자들은 데이터의 내구성을 보장하기 위해 복제를 선택합니다. 이는 기본 couchbase SDK의 ReplicateTo 메서드를 통해 수행됩니다. ReplicateTo는 변이가 하나 이상의 다른 복제본에 복제된 후에 반환되는 것을 확인합니다. DCP의 고성능 스트리밍 복제를 사용하면 변이를 최대 180배 빠르게 복제본에 복제할 수 있습니다. 클라우드에서 테스트한 결과 'ReplicateTo'를 사용하면 1~2ms 이내의 지연 시간을 보았습니다. 그러나 이러한 절대적인 수치는 실행 중인 인프라와 HW의 품질에 따라 달라질 수 있으므로 신중하게 고려해야 합니다. 

데이터 센터 간 복제

데이터 센터 간 복제인 XDCR도 DCP에 의존합니다. 메모리에서 다른 데이터센터로 직접 스트리밍 복제를 하면 데이터를 더 잘 보호할 수 있습니다! 두 클러스터 간의 양방향 복제를 상상해 보세요. 클러스터 #1에 장애가 발생하면 복제 지연 시간이 가장 긴 클러스터에 의해 손실되는 돌연변이의 양이 결정됩니다. 빠른 복제는 이번과 같은 지역적 재난 상황에서 데이터 손실 노출이 최소화된다는 것을 의미합니다! 우리는 복제 지연 시간 4배 개선 카우치베이스 서버 3.0에서 XDCR을 사용하세요. 

XDCR은 또한 네트워크 오류와 딸꾹질이 발생하기 쉬우므로 이러한 문제에서 빠르게 복구하고 정상화할 수 있는 것이 중요합니다! DCP 메타데이터를 사용하면 통신 장애 시 중단된 부분부터 빠르게 복구할 수 있습니다. 

이는 DCP가 Couchbase Server의 기능을 확장하는 방법의 몇 가지 예에 불과합니다. 그 외에도 많은 기능이 있습니다... 실제로 Couchbase Server 3.0에는 200개 이상의 기능이 있으며, 대부분 DCP가 제공하는 강력한 기반 덕분에 가능한 기능입니다. 

DCP의 장애 처리 및 메커니즘에 대해 더 자세히 알아보고 싶으시다면, Couchbase Connect에서 DCP를 다루는 자세한 강연을 보실 수 있습니다.또는 구현에 대한 자세한 내용은 깃허브 사이트.

즐거운 테스트 되세요.

이 문서 공유하기
받은 편지함에서 카우치베이스 블로그 업데이트 받기
이 필드는 필수 입력 사항입니다.

작성자

게시자 Cihan Biyikoglu, 제품 관리 이사, Couchbase

Cihan Biyikoglu는 Couchbase의 제품 관리 디렉터로, Couchbase Server 제품을 담당하고 있습니다. Cihan은 빅 데이터 애호가로서 20년 이상의 경험을 Redis Labs의 제품 팀에 제공하고 있습니다. Cihan은 C/C++ 개발자로 경력을 시작했습니다.

댓글 하나

  1. Chian,

    좋은 글입니다. 간단한 질문: 장애 조치 로그는 어디에 저장되나요?

    thx,
    Dani

    1. 시한 비이코글루 1월 27, 2015에서 12:47 오전

      안녕하세요 장애 조치 로그는 v버킷마다 v버킷에 저장됩니다.

댓글 남기기

카우치베이스 카펠라를 시작할 준비가 되셨나요?

구축 시작

개발자 포털에서 NoSQL을 살펴보고, 리소스를 찾아보고, 튜토리얼을 시작하세요.

카펠라 무료 사용

클릭 몇 번으로 Couchbase를 직접 체험해 보세요. Capella DBaaS는 가장 쉽고 빠르게 시작할 수 있는 방법입니다.

연락하기

카우치베이스 제품에 대해 자세히 알고 싶으신가요? 저희가 도와드리겠습니다.