지난 시간에는 Couchbase Kafka 커넥터가 다음에 대해 지원하는 것에 대해 이야기했습니다. 압축 및 IPv6. 이후 수신 문서의 유효 기간 값 설정을 지원하도록 싱크 커넥터를 개선하고 문서에서 여러 필드로 구성된 문서 ID를 할당하는 기능을 추가했습니다.
최근 저희는 Kafka 커넥터의 내결함성을 최대한 확보하는 데 주력해 왔습니다. 오늘은 Kafka 커넥터의 베타 버전 3.4를 소개하고 장애 조치 후 롤백이 처리되는 방식에 대한 주요 개선 사항에 대해 말씀드리고자 합니다. 베타 버전 출시의 목표는 이 기능을 가능한 한 빨리 여러분께 제공하여 여러분의 피드백을 최종 버전에 반영하는 것입니다.
비관론자는 분산된 시스템을 유지하는 현실주의자입니다.
하드웨어는 항상 고장납니다. 지금 이 순간에도 전 세계 어딘가에서 고장 난 I/O 컨트롤러가 연기 신호를 보내고 있을 것입니다. 카우치베이스 노드는 실패할 수 있고 실제로 실패하지만, 카우치베이스에서 앱을 빌드하는 가장 좋은 이유 중 하나는 피할 수 없는 하드웨어 장애가 발생해도 복구가 순식간이라는 점입니다.
각 카우치베이스 버킷은 여러 개의 "가상 버킷"으로 분할되며, 각 파티션은 클러스터의 노드에 걸쳐 복제됩니다. 주어진 시간에 복사본 중 하나는 "활성"이며, 이는 클라이언트가 통신할 복사본이라는 의미입니다. (클라이언트도 복제본에서 읽을 수 있지만 그렇게 하려면 사용자가 직접 해야 합니다.) 복제본은 활성 인스턴스의 실시간 백업이라고 생각하면 됩니다.
그렇다면 Couchbase 클러스터의 노드에서 스모크 신호가 발생하면 어떻게 될까요? 어느 시점에서 토스티 노드를 장애 조치(클러스터에서 제거)하고 리밸런싱(장애 노드의 임무를 나머지 노드에 재할당)해야 할 것입니다. 장애가 발생한 노드에서 활성 상태였던 각 파티션에 대해 복제본 중 하나가 '활성' 상태로 승격됩니다. 나머지 노드도 여유가 생기면 장애가 발생한 노드에 있던 복제본을 대체하기 위해 추가 복제본을 호스팅하기 시작합니다.
배포의 필요에 따라 전체 장애 조치 및 재조정 프로세스는 사람이 버튼을 누르거나 자동 장애 감지 알고리즘에 의해 시작될 수 있습니다. 꽤 멋지지 않나요?
이제 단계가 설정되었으므로 중요한 질문을 고려해 보겠습니다. 활성 인스턴스가 실패했을 때 복제본이 완전히 최신 상태가 아닌 경우 어떻게 될까요?
(아무도 놀라지 않기를 바라지만) 정답은 아직 복제본에 저장되지 않은 변경 사항은 모두 손실된다는 것입니다. 공상 과학 소설 용어로 말하면, 이러한 변경 사항은 존재하지 않는 대체 타임라인에 있었습니다. "롤백"된 것입니다.
난 큰 센세이션을 일으키려는 게 아니야 / 그냥 롤백 완화에 대해 이야기하는 거야.
이 모든 것이 카프카 커넥터와 어떤 관련이 있나요? 커넥터는 데이터베이스 변경 프로토콜(DCP)을 사용해 변경 알림을 수신합니다. DCP 프로토콜 구현은 속도를 위해 구축되었으며, 변경 사항이 디스크에 기록되기도 전에 변경 사항을 알립니다. 이러한 낙관론을 보완하기 위해 프로토콜에는 "죄송합니다, 제가 너무 빨리 말씀드렸습니다. 지난번에 말씀드린 몇 가지 변경 사항 기억하시죠? 실제로는 그런 일이 일어나지 않았어요."라고 말합니다. 이 기능은 이러한 파티셔닝 세부 사항을 알고 있고 새로운 현실이 발생하면 이에 적응할 수 있는 Couchbase Server에서 매우 잘 작동합니다. 복제, 전체 텍스트 업데이트, 인덱스 업데이트 등이 바로 이러한 작업입니다.
이전 버전의 Kafka 커넥터에서는 이벤트를 Kafka 토픽에 즉시 게시했습니다. DCP 서버가 변경 사항을 발표하자마자 해당 변경 사항이 토픽에 게시되었습니다. 롤백이 발생해도 토픽은 추가 전용이기 때문에 일단 게시된 카프카 메시지는 되돌릴 수 없었기 때문에 할 수 있는 일이 많지 않았습니다. 소비자는 앞서 설명한 대체 타임라인에서 비현실적인 메시지를 받게 됩니다.
애플리케이션에 따라 차원 호핑 메시지는 무해할 수도 있고, 패닉을 일으킬 수도 있습니다. Kafka 주제에 실제, 지속적이고 복제된 데이터베이스 변경 사항만 포함하기를 원한다면 좋은 소식을 준비하세요.
방향 감각 상실자를 위한 세부 정보
충분히 쌓였습니다. 베타 버전에 포함된 기능과 롤백 완화 기능의 작동 방식에 대해 설명하겠습니다.
롤백 완화 기능이 활성화되면(기본값으로 설정되어 있음) 커넥터는 Couchbase Server를 자동으로 확인하여 어떤 변경 사항이 실제로 디스크에 지속되었는지 확인합니다. 커넥터는 모든 복제본에서 지속성이 관찰될 때까지 변경 사항을 버퍼링합니다. 이 시점에서 변경 사항이 롤백될 가능성은 거의 없습니다(여러 번의 장애가 발생하는 일부 시나리오에서는 여전히 가능하지만). 그런 다음에야 커넥터가 Kafka 토픽에 메시지를 게시합니다.
물론 이 방식에는 약간의 지연 시간과 약간의 오버헤드가 있습니다. 변경 사항을 즉시 게시하는 이전 동작으로 되돌리려면 롤백 완화 기능을 쉽게 비활성화할 수 있습니다. 자세한 내용은 문서를 참조하세요.
흐름을 따라가기
흐름 제어는 생산자가 소비자를 앞지르는 것을 방지하기 위한 기술입니다. 이 경우, Kafka 커넥터는 DCP 서버에 승인 메시지를 보내 처리된 데이터의 양을 보고합니다. 서버는 승인되지 않은 데이터의 양이 "흐름 제어 버퍼 크기"라고 하는 임계값을 초과하면 스트림을 일시 중지합니다.
롤백 완화에는 잠재적으로 많은 수의 메시지를 버퍼링하는 작업이 포함되므로 흐름 제어 버퍼 크기를 조정할 수 있는 것이 중요합니다.
이전 버전의 커넥터는 20메가바이트의 하드코딩된 버퍼 크기를 사용했습니다. 새로운 기본값은 128메가바이트로, 보다 공격적인 버퍼링을 허용합니다. 이 값을 자유롭게 조정하여 워크로드에 가장 적합한 값을 찾아보세요. 버퍼 크기를 크게 늘리고 싶다면 커넥터에 더 많은 메모리를 할당하려면 카프카_힙_옵트 환경 변수입니다.
모든 좋은 스트림은 반드시 EOF에 도달해야 합니다.
롤백 완화 기능이 포함된 3.4 베타 버전을 사용해 보시기 바랍니다. 상단의 링크에서 다운로드하세요. 빠른 시작 가이드. 에 소감을 게시해 주세요. 카우치베이스 포럼 최종 릴리스에 여러분의 피드백을 반영할 수 있도록 최선을 다하겠습니다. 감사합니다, 다음에 또 뵙겠습니다!
