В 마지막 기사 내결함성과 고가용성을 위해 RabbitMQ 클러스터링을 살펴보았습니다. 이제 Apache Kafka에 대해 자세히 살펴보겠습니다.

여기서 복제 단위는 파티션입니다. 각 주제에는 하나 이상의 섹션이 있습니다. 각 섹션에는 추종자가 있거나 없는 리더가 있습니다. 주제를 생성할 때 파티션 수와 복제 계수를 지정합니다. 일반적인 값은 3입니다. 이는 XNUMX개의 복제본(리더 XNUMX개와 팔로어 XNUMX개)을 의미합니다.

쌀. 1. XNUMX개의 섹션이 XNUMX개의 브로커에 분산됩니다.

모든 읽기 및 쓰기 요청은 리더에게 전달됩니다. 팔로어는 정기적으로 리더에게 최신 메시지 수신 요청을 보냅니다. 소비자는 추종자에게 결코 의지하지 않으며 후자는 중복성과 내결함성을 위해서만 존재합니다.

파티션 실패

브로커가 실패하면 여러 섹션의 리더가 실패하는 경우가 많습니다. 각각에서 다른 노드의 팔로어가 리더가 됩니다. 실제로 동기화 요소도 영향을 미치기 때문에 항상 그런 것은 아닙니다. 동기화된 팔로어가 있는지 여부, 그렇지 않은 경우 동기화되지 않은 복제본으로의 전환이 허용되는지 여부. 하지만 지금은 상황을 복잡하게 만들지 마세요.

브로커 3이 네트워크를 떠나고 브로커 2의 섹션 2에 대한 새로운 리더가 선출됩니다.

쌀. 2. 브로커 3이 사망하고 브로커 2의 추종자가 파티션 2의 새로운 리더로 선출됩니다.

그런 다음 브로커 1이 떠나고 섹션 1도 리더를 잃습니다. 리더의 역할은 브로커 2에게 전달됩니다.

쌀. 3. 브로커가 한 명 남았습니다. 모든 리더는 중복성이 전혀 없는 하나의 브로커에 있습니다.

브로커 1이 다시 온라인 상태가 되면 2개의 팔로어를 추가하여 각 파티션에 약간의 중복성을 제공합니다. 그러나 모든 리더는 여전히 브로커 XNUMX에 남아 있었습니다.

쌀. 4. 리더는 브로커 2에 남아 있습니다.

브로커 3이 나타나면 파티션당 2개의 복제본으로 돌아갑니다. 그러나 모든 리더는 여전히 브로커 XNUMX에 있습니다.

쌀. 5. 브로커 1, 3 복원 후 리더의 불균형 배치

Kafka에는 RabbitMQ보다 더 나은 리더 재조정을 위한 도구가 있습니다. 여기서는 마이그레이션 중 중복성을 줄여 마스터 노드 마이그레이션 정책을 변경하는 타사 플러그인 또는 스크립트를 사용해야 했습니다. 또한 대규모 대기열의 경우 동기화 중에 비가용성을 허용해야 했습니다.

Kafka에는 리더 역할에 대해 "선호 복제본"이라는 개념이 있습니다. 토픽 파티션이 생성되면 Kafka는 노드 전체에 리더를 균등하게 배포하려고 시도하고 첫 번째 리더를 선호하는 리더로 표시합니다. 시간이 지남에 따라 서버 재부팅, 오류 및 연결 끊김으로 인해 위에서 설명한 극단적인 경우처럼 리더가 다른 노드에 위치할 수 있습니다.

이 문제를 해결하기 위해 Kafka는 두 가지 옵션을 제공합니다.

• 옵션 auto.leader.rebalance.enable=true 컨트롤러 노드가 자동으로 리더를 기본 복제본에 다시 할당하여 균일한 배포를 복원할 수 있습니다.
• 관리자는 스크립트를 실행할 수 있습니다 카프카-선호-복제본-election.sh 수동 재할당용.

쌀. 6. 재조정 후 복제본

이것은 실패의 단순화된 버전이지만 현실은 더 복잡합니다. 여기에는 너무 복잡한 것이 없습니다. 이 모든 것은 동기화된 복제본(In-Sync Replicas, ISR)으로 귀결됩니다.

동기화된 복제본(ISR)

ISR은 "동기화"(동기화)된 것으로 간주되는 파티션의 복제본 세트입니다. 리더는 있지만 추종자는 없을 수도 있다. 간격이 만료되기 전에 모든 리더 메시지의 정확한 복사본을 만든 경우 팔로어는 동기화된 것으로 간주됩니다. 복제.지연.시간.최대.ms.

다음과 같은 경우 팔로어가 ISR 세트에서 제거됩니다.

• 간격 선택을 요청하지 않았습니다. 복제.지연.시간.최대.ms (죽은 것으로 추정)
• 간격 동안 업데이트를 관리하지 못했습니다. 복제.지연.시간.최대.ms (느린 것으로 간주)

팔로워는 일정 간격으로 샘플링 요청을 합니다. 복제본.fetch.wait.max.ms, 기본값은 500ms입니다.

ISR의 목적을 명확하게 설명하려면 생산자의 확인과 일부 실패 시나리오를 살펴봐야 합니다. 생산자는 브로커가 확인을 보내는 시기를 선택할 수 있습니다.

• acks=0, 확인이 전송되지 않음
• acks=1, 리더가 로컬 로그에 메시지를 작성한 후 확인이 전송됩니다.
• acks=all, ISR의 모든 복제본이 메시지를 로컬 로그에 기록한 후 확인이 전송됩니다.

Kafka 용어에서는 ISR이 메시지를 저장한 경우 해당 메시지가 "커밋"됩니다. Acks=all은 가장 안전한 옵션이지만 지연이 추가됩니다. 실패의 두 가지 예와 다양한 'acks' 옵션이 ISR 개념과 어떻게 상호 작용하는지 살펴보겠습니다.

Ack=1 및 ISR

이 예에서는 리더가 모든 팔로어의 모든 메시지가 저장될 때까지 기다리지 않으면 리더가 실패할 경우 데이터가 손실될 수 있음을 알 수 있습니다. 동기화되지 않은 팔로어 탐색은 설정을 통해 활성화하거나 비활성화할 수 있습니다. 부정한.리더.선거.활성화.

이 예에서 제조업체의 값은 acks=1입니다. 섹션은 세 브로커 모두에 분산됩니다. 브로커 3이 뒤쳐져 있으며 7456초 전에 리더와 동기화되었으며 현재 1개의 메시지가 뒤쳐져 있습니다. 브로커 XNUMX은 단 XNUMX초 뒤쳐졌습니다. 우리의 프로듀서는 리더가 기다리지 않는 느리거나 죽은 추종자의 오버헤드 없이 메시지를 보내고 신속하게 응답을 받습니다.

쌀. 7. 세 개의 복제본이 있는 ISR

브로커 2가 실패하고 생산자에게 연결 오류가 발생합니다. 리더십이 브로커 1로 전달된 후 123개의 메시지가 손실됩니다. 브로커 1의 팔로어는 ISR의 일부였지만 떨어졌을 때 리더와 완전히 동기화되지 않았습니다.

쌀. 8. 충돌이 발생하면 메시지가 손실됩니다.

구성 중 bootstrap.서버 제조업체에는 여러 브로커가 나열되어 있으며 새로운 섹션 리더인 다른 브로커에게 요청할 수 있습니다. 그런 다음 브로커 1에 대한 연결을 설정하고 계속해서 메시지를 보냅니다.

쌀. 9. 잠시 휴식 후 메시지 보내기가 재개됩니다.

브로커 3은 훨씬 뒤쳐져 있습니다. 가져오기 요청을 하지만 동기화할 수 없습니다. 이는 브로커 간 네트워크 연결 속도 저하, 저장 문제 등으로 인해 발생할 수 있습니다. ISR에서 제거됩니다. 이제 ISR은 하나의 복제본, 즉 리더로 구성됩니다! 제조업체는 계속해서 메시지를 보내고 확인 메시지를 받습니다.

쌀. 10. 브로커 3의 팔로어가 ISR에서 제거됩니다.

브로커 1이 중단되고 3개의 메시지가 손실되면서 리더십 역할이 브로커 15286으로 넘어갑니다! 제조업체는 연결 오류 메시지를 받습니다. ISR 외부의 리더로의 전환은 다음 설정으로 인해 가능했습니다. unclean.leader.election.enable=true. 에 설치되어 있는 경우 그릇된이면 전환이 발생하지 않고 모든 읽기 및 쓰기 요청이 거부됩니다. 이 경우, 브로커 1이 복제본에 그대로 데이터를 가지고 돌아올 때까지 기다립니다. 그러면 브로커 XNUMX이 다시 리더십을 맡게 됩니다.

쌀. 11. 브로커 1이 넘어집니다. 오류가 발생하면 많은 수의 메시지가 손실됩니다.

생산자는 마지막 브로커와 연결을 설정하고 이제 그가 섹션의 리더임을 확인합니다. 그는 브로커 3에 메시지를 보내기 시작합니다.

쌀. 12. 잠시 휴식 후 다시 0번 구역으로 메시지가 전송됩니다.

우리는 새로운 연결을 구축하고 새로운 리더를 찾기 위한 짧은 중단 외에도 제조업체가 지속적으로 메시지를 보내는 것을 확인했습니다. 이 구성은 일관성(데이터 보안)을 희생하여 가용성을 보장합니다. Kafka는 수천 개의 메시지를 잃었지만 계속해서 새로운 쓰기를 허용했습니다.

Acks=all 및 ISR

이 시나리오를 다시 반복해 보겠습니다. 승인=모두. 브로커 3의 평균 대기 시간은 XNUMX초입니다. 제조업체는 다음과 같은 메시지를 보냅니다. 승인=모두, 이제 빠른 응답을 받지 못합니다. 리더는 ISR의 모든 복제본에 메시지가 저장될 때까지 기다립니다.

쌀. 13. 세 개의 복제본이 있는 ISR. 하나는 속도가 느려 녹음이 지연됩니다.

2초의 추가 지연 후 브로커 XNUMX는 ack를 보냅니다. 이제 모든 복제본이 완전히 업데이트되었습니다.

쌀. 14. 모든 복제본은 메시지를 저장하고 ack를 보냅니다.

이제 브로커 3은 더욱 뒤쳐져 ISR에서 제거됩니다. ISR에 느린 복제본이 남아 있지 않기 때문에 지연 시간이 크게 줄어듭니다. 이제 브로커 2는 브로커 1만 기다리며 평균 지연 시간은 500ms입니다.

쌀. 15. 브로커 3의 복제본이 ISR에서 제거됩니다.

그런 다음 브로커 2가 실패하고 리더십이 메시지 손실 없이 브로커 1로 전달됩니다.

쌀. 16. 브로커 2 하락

제조업체는 새로운 리더를 찾아 그에게 메시지를 보내기 시작합니다. 이제 ISR이 하나의 복제본으로 구성되므로 대기 시간이 더욱 단축됩니다! 그러므로 옵션은 승인=모두 중복성을 추가하지 않습니다.

쌀. 17. 브로커 1의 복제본이 메시지 손실 없이 선두를 차지합니다.

그런 다음 브로커 1이 충돌하고 리드가 3개의 메시지 손실과 함께 브로커 14238으로 이동합니다!

쌀. 18. 브로커 1의 사망 및 불결한 설정으로 인한 리더십 전환으로 인해 광범위한 데이터 손실 발생

옵션을 설치할 수 없습니다 부정한.리더.선거.활성화 의미상 참된. 기본적으로는 동일합니다. 그릇된. 설정 승인=모두 с unclean.leader.election.enable=true 일부 추가된 데이터 보안과 함께 접근성을 제공합니다. 하지만 보시다시피 메시지는 여전히 손실될 수 있습니다.

하지만 데이터 보안을 강화하고 싶다면 어떻게 해야 할까요? 당신은 넣을 수 있습니다 unclean.leader.election.enable = 거짓, 그러나 이것이 반드시 데이터 손실로부터 우리를 보호하지는 않습니다. 리더가 쓰러져 데이터를 가져간 경우 메시지는 여전히 손실되며 관리자가 상황을 복원할 때까지 가용성도 손실됩니다.

모든 메시지가 중복되는지 확인하고 그렇지 않으면 녹음을 삭제하는 것이 좋습니다. 그러면 적어도 브로커 입장에서는 두 개 이상의 동시 장애가 발생하는 경우에만 데이터 손실이 가능합니다.

Acks=all, min.insync.replicas 및 ISR

주제 구성 포함 min.insync.replicas 데이터 보안 수준을 높이고 있습니다. 이전 시나리오의 마지막 부분을 다시 살펴보겠습니다. min.insync.replicas=2.

따라서 브로커 2에는 복제본 리더가 있고 브로커 3의 팔로어는 ISR에서 제거됩니다.

쌀. 19. 두 복제본의 ISR

브로커 2가 실패하고 리더십이 메시지 손실 없이 브로커 1로 전달됩니다. 그러나 이제 ISR은 단 하나의 복제본으로 구성됩니다. 이는 레코드를 수신할 수 있는 최소 개수를 충족하지 못하므로 브로커는 쓰기 시도에 오류로 응답합니다. 충분하지 않은 복제본.

쌀. 20. ISR 수가 min.insync.replicas에 지정된 것보다 XNUMX개 적습니다.

이 구성은 일관성을 위해 가용성을 희생합니다. 메시지를 승인하기 전에 메시지가 최소한 두 개의 복제본에 기록되었는지 확인합니다. 이는 제조업체에게 훨씬 더 많은 신뢰를 줍니다. 여기서 메시지 손실은 메시지가 추가 팔로어에 복제될 때까지 짧은 간격으로 두 개의 복제본이 동시에 실패하는 경우에만 가능하며 그럴 가능성은 없습니다. 하지만 편집증이 심한 사람이라면 복제 인자를 5로 설정할 수 있습니다. min.insync.replicas by 3. 여기서 세 명의 브로커가 동시에 떨어져야 기록을 잃게 됩니다! 물론 이러한 안정성에 대한 대가는 추가 대기 시간으로 발생합니다.

데이터 보안을 위해 접근성이 필요한 경우

에서와 같이 RabbitMQ의 경우, 때로는 데이터 보안을 위해 접근성이 필요할 수도 있습니다. 당신이 생각해야 할 사항은 다음과 같습니다.

• 게시자가 단순히 오류를 반환하고 업스트림 서비스나 사용자가 나중에 다시 시도하도록 할 수 있습니까?
• 게시자가 나중에 다시 시도하기 위해 메시지를 로컬이나 데이터베이스에 저장할 수 있습니까?

대답이 '아니요'인 경우 가용성을 최적화하면 데이터 보안이 향상됩니다. 기록하지 않는 대신 사용 가능 여부를 선택하면 데이터 손실이 줄어듭니다. 따라서 모든 것은 균형을 찾는 것으로 귀결되며 결정은 특정 상황에 따라 달라집니다.

ISR의 의미

ISR 제품군을 사용하면 데이터 보안과 대기 시간 간의 최적의 균형을 선택할 수 있습니다. 예를 들어, 대부분의 복제본에 오류가 발생하는 경우 가용성을 보장하여 지연 시간 측면에서 작동하지 않거나 느린 복제본의 영향을 최소화합니다.

우리는 의미를 스스로 선택합니다 복제.지연.시간.최대.ms 귀하의 필요에 따라. 기본적으로 이 매개변수는 다음과 같은 경우에 허용할 지연 시간을 의미합니다. 승인=모두. 기본값은 XNUMX초입니다. 너무 길다면 줄여도 됩니다. 그러면 팔로어가 더 자주 제거되고 추가되므로 ISR의 변경 빈도가 증가합니다.

RabbitMQ는 단순히 복제가 필요한 미러 세트입니다. 느린 미러는 추가 대기 시간을 발생시키고, 데드 미러는 각 노드의 가용성(넷 틱)을 확인하는 패킷이 응답할 때까지 기다릴 수 있습니다. ISR은 이러한 대기 시간 문제를 방지하는 흥미로운 방법입니다. 그러나 ISR은 리더로만 축소될 수 있으므로 중복성을 잃을 위험이 있습니다. 이러한 위험을 피하려면 다음 설정을 사용하십시오. min.insync.replicas.

클라이언트 연결 보장

설정에서 bootstrap.서버 생산자와 소비자는 클라이언트 연결을 위해 여러 브로커를 지정할 수 있습니다. 한 노드가 다운되면 클라이언트가 연결을 열 수 있는 여분의 노드가 여러 개 남게 된다는 아이디어입니다. 이는 반드시 섹션 리더일 필요는 없으며 단순히 초기 로딩을 위한 발판일 뿐입니다. 클라이언트는 읽기/쓰기 파티션 리더를 호스팅하는 노드를 물어볼 수 있습니다.

RabbitMQ에서 클라이언트는 모든 노드에 연결할 수 있으며 내부 라우팅은 필요한 곳으로 요청을 보냅니다. 이는 RabbitMQ 앞에 로드 밸런서를 설치할 수 있음을 의미합니다. Kafka에서는 클라이언트가 해당 파티션 리더를 호스팅하는 노드에 연결해야 합니다. 이러한 상황에서는 로드 밸런서를 설치할 수 없습니다. 목록 bootstrap.서버 장애 발생 후 클라이언트가 올바른 노드에 액세스하고 찾을 수 있는 것이 중요합니다.

Kafka 합의 아키텍처

지금까지 우리는 클러스터가 브로커의 몰락을 어떻게 학습하고 새로운 리더가 선출되는지 고려하지 않았습니다. Kafka가 네트워크 파티션에서 작동하는 방식을 이해하려면 먼저 합의 아키텍처를 이해해야 합니다.

각 Kafka 클러스터는 시스템이 특정 상태에 대한 합의에 도달할 수 있도록 하는 분산 합의 서비스인 Zookeeper 클러스터와 함께 배포되어 가용성보다 일관성을 우선시합니다. 읽기 및 쓰기 작업을 승인하려면 Zookeeper 노드 대다수의 동의가 필요합니다.

Zookeeper는 클러스터 상태를 저장합니다.

• 주제, 섹션, 구성, 현재 리더 복제본, 기본 복제본 목록입니다.
• 클러스터 구성원. 각 브로커는 Zookeeper 클러스터를 ping합니다. 지정된 시간 내에 핑을 받지 못하면 Zookeeper는 브로커를 사용할 수 없는 것으로 기록합니다.
• 컨트롤러의 기본 노드와 예비 노드를 선택합니다.

컨트롤러 노드는 복제본 리더 선택을 담당하는 Kafka 브로커 중 하나입니다. Zookeeper는 클러스터 멤버십 및 주제 변경에 대한 알림을 컨트롤러에 보내고 컨트롤러는 이러한 변경 사항에 대해 조치를 취해야 합니다.

예를 들어, 3개의 파티션과 XNUMX의 복제 팩터가 있는 새 주제를 가정해 보겠습니다. 컨트롤러는 브로커 간에 리더를 최적으로 배포하기 위해 각 파티션에 대한 리더를 선택해야 합니다.

각 섹션 컨트롤러에 대해 다음을 수행합니다.

• ISR 및 리더에 대한 Zookeeper의 정보를 업데이트합니다.
• 이 파티션의 복제본을 호스팅하는 각 브로커에 LeaderAndISRCommand를 전송하여 브로커에게 ISR 및 리더에 대해 알립니다.

리더가 있는 브로커가 떨어지면 Zookeeper는 컨트롤러에 알림을 보내고 새 리더를 선택합니다. 이번에도 컨트롤러는 먼저 Zookeeper를 업데이트한 다음 각 브로커에 리더십 변경을 알리는 명령을 보냅니다.

각 리더는 ISR 모집을 담당합니다. 설정 복제.지연.시간.최대.ms 거기에 들어갈 사람을 결정합니다. ISR이 변경되면 리더는 새로운 정보를 Zookeeper로 전송합니다.

Zookeeper는 장애 발생 시 경영진이 원활하게 새로운 리더로 전환될 수 있도록 모든 변경 사항에 대한 정보를 항상 받습니다.

쌀. 21. 카프카 합의

복제 프로토콜

복제의 세부 사항을 이해하면 잠재적인 데이터 손실 시나리오를 더 잘 이해하는 데 도움이 됩니다.

샘플링 쿼리, LEO(로그 끝 오프셋) 및 HW(하이워터 마크)

우리는 팔로어가 주기적으로 리더에게 가져오기 요청을 보내는 것을 고려했습니다. 기본 간격은 500ms입니다. 이는 RabbitMQ 복제가 큐 미러가 아닌 마스터에 의해 시작된다는 점에서 RabbitMQ와 다릅니다. 마스터는 변경 사항을 미러에 푸시합니다.

리더와 모든 팔로어는 LEO(Log End Offset) 및 HW(Highwater) 레이블을 저장합니다. LEO 마크는 로컬 복제본의 마지막 메시지 오프셋을 저장하고, HW는 마지막 커밋의 오프셋을 보유합니다. 커밋 상태의 경우 메시지는 모든 ISR 복제본에서 지속되어야 합니다. 이는 LEO가 일반적으로 HW보다 약간 앞서 있음을 의미합니다.

리더는 메시지를 받으면 이를 로컬에 저장합니다. 팔로어는 자신의 LEO를 전송하여 가져오기 요청을 합니다. 그런 다음 리더는 이 LEO에서 시작하여 일괄 메시지를 보내고 현재 HW도 전송합니다. 리더는 모든 복제본이 지정된 오프셋에 메시지를 저장했다는 정보를 받으면 HW 마크를 이동합니다. 리더만이 HW를 이동할 수 있으므로 모든 팔로어는 요청에 대한 응답의 현재 값을 알 수 있습니다. 이는 팔로어가 메시지와 HW 지식 모두에서 리더보다 뒤처질 수 있음을 의미합니다. 소비자는 현재 HW까지만 메시지를 받습니다.

"지속형"은 디스크가 아닌 메모리에 기록된다는 의미입니다. 성능을 위해 Kafka는 특정 간격으로 디스크와 동기화합니다. RabbitMQ에도 이러한 간격이 있지만 마스터와 모든 미러가 디스크에 메시지를 쓴 후에만 게시자에게 승인을 보냅니다. Kafka 개발자는 성능상의 이유로 메시지가 메모리에 기록되자마자 ack를 보내기로 결정했습니다. Kafka는 중복성이 확인된 메시지를 메모리에만 잠시 저장하는 위험을 상쇄한다고 확신합니다.

리더 실패

리더가 떨어지면 Zookeeper는 컨트롤러에 이를 알리고 새 리더 복제본을 선택합니다. 새로운 리더는 LEO에 따라 새로운 HW 마크를 설정합니다. 그러면 추종자들은 새로운 리더에 대한 정보를 받습니다. Kafka 버전에 따라 추종자는 두 가지 시나리오 중 하나를 선택합니다.

1. 로컬 로그를 알려진 HW로 자르고 이 표시 이후의 메시지에 대한 요청을 새 리더에게 보냅니다.
2. 리더로 선출된 당시의 HW를 알아내기 위해 리더에게 요청을 보낸 다음 로그를 이 오프셋으로 자릅니다. 그런 다음 이 오프셋에서 시작하여 주기적인 가져오기 요청을 만들기 시작합니다.

팔로어는 다음과 같은 이유로 로그를 잘라야 할 수 있습니다.

• 리더가 실패하면 Zookeeper에 등록된 ISR 세트의 첫 번째 팔로어가 선거에서 승리하고 리더가 됩니다. ISR의 모든 팔로워는 "동기화"된 것으로 간주되지만 이전 리더로부터 모든 메시지의 사본을 받지 못했을 수도 있습니다. 추천 팔로워가 최신 사본을 갖고 있지 않을 수도 있습니다. Kafka는 복제본 간에 차이가 없는지 확인합니다. 따라서 불일치를 피하기 위해 각 팔로어는 자신의 로그를 선출 당시 새로운 리더의 HW 값으로 줄여야 합니다. 이것이 설정하는 또 다른 이유입니다. 승인=모두 일관성을 위해 매우 중요합니다.
• 메시지는 주기적으로 디스크에 기록됩니다. 모든 클러스터 노드가 동시에 실패하면 서로 다른 오프셋을 가진 복제본이 디스크에 저장됩니다. 브로커가 다시 온라인 상태가 되면 선출된 새 리더는 다른 리더보다 먼저 디스크에 저장되었기 때문에 추종자 뒤에 있을 가능성이 있습니다.

클러스터와의 재결합

클러스터에 다시 참가할 때 복제본은 리더가 실패할 때와 동일한 작업을 수행합니다. 즉, 리더의 복제본을 확인하고 해당 로그를 해당 HW(선택 시)로 자릅니다. 이에 비해 RabbitMQ는 재결합된 노드를 완전히 새로운 노드로 동일하게 취급합니다. 두 경우 모두 브로커는 기존 상태를 모두 삭제합니다. 자동 동기화가 사용되는 경우 마스터는 "전 세계를 기다리게 하는" 방법으로 현재 컨텐츠를 완전히 새 미러에 복제해야 합니다. 마스터는 이 작업 중에 읽기 또는 쓰기 작업을 허용하지 않습니다. 이 접근 방식은 대규모 대기열에 문제를 일으킵니다.

Kafka는 분산 로그이며 일반적으로 데이터를 읽은 후 큐에서 제거되는 RabbitMQ 큐보다 더 많은 메시지를 저장합니다. 활성 대기열은 상대적으로 작게 유지되어야 합니다. 그러나 Kafka는 며칠 또는 몇 주 기간을 설정할 수 있는 자체 보존 정책이 있는 로그입니다. 대기열 차단 및 전체 동기화 접근 방식은 분산 로그에는 절대 허용되지 않습니다. 대신 Kafka 팔로어는 자신의 복사본이 리더보다 앞에 있는 경우 리더의 HW(선출 당시)에 대한 로그를 잘라냅니다. 더 가능성 있는 경우, 팔로어가 뒤쳐지면 현재 LEO부터 시작하여 가져오기 요청을 시작하기 시작합니다.

신규 또는 재가입된 팔로워는 ISR 외부에서 시작하며 커밋에 참여하지 않습니다. 그들은 단순히 그룹과 함께 일하면서 리더를 따라잡고 ISR에 들어갈 때까지 가능한 한 빨리 메시지를 받습니다. 종속성이 없으며 모든 데이터를 버릴 필요가 없습니다.

연결 끊김

Kafka에는 RabbitMQ보다 더 많은 구성 요소가 있으므로 클러스터 연결이 끊어질 때 더 복잡한 동작 집합을 갖습니다. 그러나 Kafka는 원래 클러스터용으로 설계되었으므로 솔루션이 매우 잘 고려되었습니다.

다음은 몇 가지 연결 실패 시나리오입니다.

• 시나리오 1: 추종자는 리더를 보지 못하지만 여전히 Zookeeper를 봅니다.
• 시나리오 2: 리더는 추종자를 볼 수 없지만 여전히 Zookeeper를 볼 수 있습니다.
• 시나리오 3: 추종자는 리더를 볼 수 있지만 사육사는 볼 수 없습니다.
• 시나리오 4: 리더는 추종자를 볼 수 있지만 사육사는 볼 수 없습니다.
• 시나리오 5: Follower는 다른 Kafka 노드 및 Zookeeper와 완전히 분리되어 있습니다.
• 시나리오 6: 리더는 다른 Kafka 노드 및 Zookeeper와 완전히 분리되어 있습니다.
• 시나리오 7: Kafka 컨트롤러 노드는 다른 Kafka 노드를 볼 수 없습니다.
• 시나리오 8: Kafka 컨트롤러에 Zookeeper가 표시되지 않습니다.

각 시나리오에는 고유한 동작이 있습니다.

시나리오 1: 팔로어는 리더를 볼 수 없지만 여전히 Zookeeper를 볼 수 있습니다.

쌀. 22. 시나리오 1: XNUMX개 복제본의 ISR

연결 실패로 인해 브로커 3이 브로커 1 및 2에서 분리되지만 Zookeeper에서는 분리되지 않습니다. 브로커 3은 더 이상 가져오기 요청을 보낼 수 없습니다. 시간이 지나고 나면 복제.지연.시간.최대.ms ISR에서 제거되며 메시지 커밋에 참여하지 않습니다. 연결이 복원되면 가져오기 요청을 재개하고 리더를 따라잡을 때 ISR에 참여합니다. Zookeeper는 계속해서 핑을 수신하고 브로커가 살아 있고 건강하다고 가정합니다.

쌀. 23. 시나리오 1: Replica.lag.time.max.ms 간격 내에 가져오기 요청이 수신되지 않으면 브로커가 ISR에서 제거됩니다.

RabbitMQ와 같이 분할 브레인이나 노드 정지가 없습니다. 대신 중복성이 줄어듭니다.

시나리오 2: 리더는 팔로어를 볼 수 없지만 여전히 Zookeeper를 볼 수 있습니다.

쌀. 24. 시나리오 2. 리더와 두 명의 추종자

네트워크 연결이 끊어지면 리더와 팔로워가 분리되지만 브로커는 여전히 Zookeeper를 볼 수 있습니다. 첫 번째 시나리오와 마찬가지로 ISR은 축소되지만 이번에는 모든 팔로어가 가져오기 요청 전송을 중단하므로 리더만 축소됩니다. 다시 말하지만, 논리적인 구분은 없습니다. 대신 연결이 복원될 때까지 새 메시지에 대한 중복성이 손실됩니다. Zookeeper는 계속해서 핑을 수신하며 브로커가 살아 있고 건강하다고 믿습니다.

쌀. 25. 시나리오 2. ISR은 리더로만 축소되었습니다.

시나리오 3. 팔로워는 리더를 볼 수 있지만 사육사는 볼 수 없습니다.

Follower는 Zookeeper와 분리되어 있지만 Leader가 있는 Broker와는 분리되어 있지 않습니다. 결과적으로 팔로어는 계속해서 가져오기 요청을 하며 ISR의 회원이 됩니다. Zookeeper는 더 이상 핑을 수신하지 않고 브로커 충돌을 등록하지만 팔로어일 뿐이므로 복구 후 결과가 없습니다.

쌀. 26. 시나리오 3: 팔로어가 계속해서 리더에게 가져오기 요청을 보냅니다.

시나리오 4. 리더는 추종자를 볼 수 있지만 사육사는 볼 수 없습니다.

쌀. 27. 시나리오 4. 리더와 두 명의 추종자

리더는 Zookeeper와 분리되지만 추종자가 있는 브로커와는 분리되지 않습니다.

쌀. 28. 시나리오 4: 사육사로부터 분리된 리더

얼마 후 Zookeeper는 브로커 실패를 등록하고 이에 대해 컨트롤러에 알립니다. 그는 추종자들 중에서 새로운 지도자를 선택할 것입니다. 하지만 원래 리더는 계속해서 자신이 리더라고 생각하고 다음 항목을 계속 수락하게 됩니다. 승인=1. 추종자들은 더 이상 그에게 가져오기 요청을 보내지 않으므로 그는 해당 요청이 죽은 것으로 간주하고 ISR을 자체적으로 축소하려고 시도할 것입니다. 하지만 Zookeeper와 연결되어 있지 않기 때문에 이 작업을 수행할 수 없으며 그 시점에서는 더 이상의 항목 수락을 거부합니다.

Сообщения 승인=모두 ISR이 먼저 모든 복제본을 켜고 메시지가 도달하지 않기 때문에 승인을 받지 못합니다. 원래 리더가 ISR에서 해당 메시지를 제거하려고 시도하면 그렇게 할 수 없으며 메시지 수신이 전혀 중단됩니다.

클라이언트는 곧 리더의 변경을 확인하고 레코드를 새 서버로 보내기 시작합니다. 네트워크가 복원되면 원래 리더는 자신이 더 이상 리더가 아니라는 것을 확인하고 로그 분기를 피하기 위해 실패 당시 새 리더가 가졌던 HW 값으로 로그를 자릅니다. 그런 다음 새 리더에게 가져오기 요청을 보내기 시작합니다. 새 리더에 복제되지 않은 원래 리더의 모든 레코드는 손실됩니다. 즉, 두 리더가 작업 중일 때 원래 리더가 몇 초 동안 승인하지 않은 메시지는 손실됩니다.

쌀. 29. 시나리오 4. 브로커 1의 리더는 네트워크가 복원된 후 팔로어가 됩니다.

시나리오 5: Follower는 다른 Kafka 노드 및 Zookeeper와 완전히 분리되어 있습니다.

Follower는 다른 Kafka 노드와 Zookeeper로부터 완전히 격리됩니다. 그는 네트워크가 복원될 때까지 ISR에서 자신을 제거한 다음 다른 사람들을 따라잡습니다.

쌀. 30. 시나리오 5: ISR에서 격리된 팔로워가 제거됨

시나리오 6: 리더는 다른 Kafka 노드 및 Zookeeper와 완전히 분리되어 있습니다.

쌀. 31. 시나리오 6. 리더와 두 명의 추종자

리더는 추종자, 컨트롤러, 사육사로부터 완전히 격리됩니다. 짧은 기간 동안은 계속해서 다음의 출품작을 접수할 예정입니다. 승인=1.

쌀. 32. 시나리오 6: 다른 Kafka 및 Zookeeper 노드에서 리더 격리

만료 후 요청을 받지 못한 경우 복제.지연.시간.최대.ms, ISR을 자체적으로 축소하려고 시도하지만 Zookeeper와의 통신이 없기 때문에 그렇게 할 수 없으며 이후 쓰기 허용이 중지됩니다.

한편 Zookeeper는 격리된 브로커를 죽은 것으로 표시하고 컨트롤러는 새로운 리더를 선출합니다.

쌀. 33. 시나리오 6. 두 명의 리더

원래 리더는 몇 초 동안 항목을 수락할 수 있지만 그런 다음 메시지 수락을 중지합니다. 클라이언트는 60초마다 최신 메타데이터로 업데이트됩니다. 그들은 리더 변경에 대한 정보를 받고 새 리더에게 항목을 보내기 시작합니다.

쌀. 34. 시나리오 6: 제조업체가 새로운 리더로 전환

연결이 끊어진 이후 원래 리더가 확인한 모든 항목은 손실됩니다. 네트워크가 복원되면 원래 리더는 Zookeeper를 통해 자신이 더 이상 리더가 아님을 알게 됩니다. 그런 다음 선출 시 새 리더의 HW에 대한 로그를 자르고 팔로어로서 요청을 보내기 시작합니다.

쌀. 35. 시나리오 6: 네트워크 연결이 복원된 후 원래 리더가 팔로어가 됩니다.

이러한 상황에서는 짧은 기간 동안 논리적 분리가 발생할 수 있지만, 승인=1 и min.insync.replicas 또한 1. 네트워크가 복원된 후 원래 리더가 자신이 더 이상 리더가 아니라는 것을 인식하거나 모든 클라이언트가 리더가 변경되었음을 인식하고 새 리더에 쓰기 시작하는 경우 중 먼저 발생하는 경우 논리적 분리가 자동으로 종료됩니다. 어떤 경우든 일부 메시지는 손실되지만 승인=1.

이 시나리오의 또 다른 변형은 네트워크 분할 직전에 추종자들이 뒤쳐지고 리더가 ISR을 자신에게만 압축하는 경우입니다. 그런 다음 연결 끊김으로 인해 격리됩니다. 새로운 리더가 선출되지만 원래 리더는 계속해서 참가를 수락합니다. 승인=모두, ISR에는 그 외에는 아무도 없기 때문입니다. 네트워크가 복원되면 이러한 기록은 손실됩니다. 이 옵션을 피하는 유일한 방법은 다음과 같습니다. min.insync.replicas = 2.

시나리오 7: Kafka 컨트롤러 노드가 다른 Kafka 노드를 볼 수 없음

일반적으로 Kafka 노드와의 연결이 끊어지면 컨트롤러는 리더 변경 정보를 해당 노드로 전송할 수 없습니다. 최악의 경우 이는 시나리오 6에서와 같이 단기적인 논리적 분리로 이어질 것입니다. 대개 후자가 실패할 경우 브로커는 단순히 리더십 후보가 되지 않습니다.

시나리오 8: Kafka 컨트롤러에 Zookeeper가 표시되지 않습니다.

Zookeeper는 타락한 컨트롤러로부터 핑을 받지 않고 새 Kafka 노드를 컨트롤러로 선택합니다. 원래 컨트롤러는 계속해서 그 자체로 표시될 수 있지만 Zookeeper로부터 알림을 받지 않으므로 수행할 작업이 없습니다. 네트워크가 복원되면 그는 자신이 더 이상 컨트롤러가 아니라 일반 Kafka 노드가 되었음을 깨닫게 됩니다.

시나리오의 결론

팔로어 연결이 끊어져도 메시지가 손실되지는 않지만 네트워크가 복원될 때까지 일시적으로 중복성이 줄어드는 것을 알 수 있습니다. 물론, 하나 이상의 노드가 손실되면 데이터 손실이 발생할 수 있습니다.

연결 끊김으로 인해 리더가 Zookeeper에서 분리되면 메시지가 손실될 수 있습니다. 승인=1. Zookeeper와의 의사 소통 부족으로 인해 두 리더와의 짧은 논리적 분열이 발생합니다. 이 문제는 매개변수로 해결됩니다. 승인=모두.

매개 변수 min.insync.replicas 두 개 이상의 복제본으로 분할하면 이러한 단기 시나리오에서 시나리오 6과 같이 메시지가 손실되지 않는다는 추가적인 보증을 제공합니다.

손실된 메시지 요약

Kafka에서 데이터가 손실될 수 있는 모든 방법을 나열해 보겠습니다.

• 메시지가 다음을 사용하여 확인된 경우 모든 리더 실패 승인=1
• 리더십이 ISR 외부의 추종자로 불결하게 이전되는 경우에도 마찬가지입니다. 승인=모두
• 다음을 사용하여 메시지가 확인된 경우 Zookeeper에서 리더를 격리합니다. 승인=1
• 이미 ISR 그룹을 자신으로 축소시킨 리더의 완전한 고립. 모든 메시지가 손실됩니다. 승인=모두. 이는 다음 경우에만 해당됩니다. min.insync.replicas=1.
• 모든 파티션 노드에 동시 오류가 발생합니다. 메시지는 메모리에서 확인되기 때문에 일부는 아직 디스크에 기록되지 않을 수 있습니다. 서버를 재부팅한 후 일부 메시지가 누락될 수 있습니다.

불순한 리더십 전환은 이를 금지하거나 최소한 두 번의 중복을 보장함으로써 방지할 수 있습니다. 가장 내구성이 뛰어난 구성은 조합입니다. 승인=모두 и min.insync.replicas 더 많은 1.

RabbitMQ와 Kafka의 신뢰성 직접 비교

안정성과 고가용성을 보장하기 위해 두 플랫폼 모두 기본 및 보조 복제 시스템을 구현합니다. 그러나 RabbitMQ에는 아킬레스건이 있습니다. 장애 후 재접속 시 노드는 데이터를 폐기하고 동기화가 차단됩니다. 이 이중 문제는 RabbitMQ에서 대규모 대기열의 수명에 의문을 제기합니다. 중복성이 줄어들거나 차단 시간이 길어지는 것을 받아들여야 합니다. 중복성을 줄이면 대규모 데이터 손실 위험이 높아집니다. 그러나 대기열이 작을 경우 중복성을 위해 반복적인 연결 시도를 통해 짧은 기간(몇 초) 동안 사용할 수 없는 상황을 처리할 수 있습니다.

카프카에는 이런 문제가 없습니다. 리더와 팔로어 사이의 분기점에서만 데이터를 버립니다. 공유된 데이터는 모두 저장됩니다. 또한 복제는 시스템을 차단하지 않습니다. 리더는 새로운 팔로어가 따라잡는 동안 계속해서 게시물을 수락하므로 데브옵스의 경우 클러스터에 가입하거나 다시 가입하는 것이 간단한 작업이 됩니다. 물론 복제 중 네트워크 대역폭 등의 문제는 여전히 존재합니다. 동시에 여러 팔로어를 추가하면 대역폭 제한이 발생할 수 있습니다.

RabbitMQ는 클러스터의 여러 서버가 동시에 실패할 때 안정성이 Kafka보다 우수합니다. 이미 말했듯이 RabbitMQ는 마스터와 모든 미러가 메시지를 디스크에 기록한 후에만 게시자에게 확인을 보냅니다. 하지만 이로 인해 다음 두 가지 이유로 대기 시간이 추가됩니다.

• 수백 밀리초마다 fsync
• 미러 오류는 각 노드의 가용성(net Tick)을 확인하는 패킷의 수명이 만료된 후에만 알 수 있습니다. 미러가 느려지거나 떨어지면 지연이 추가됩니다.

Kafka의 주장은 메시지가 여러 노드에 걸쳐 저장되면 메시지가 메모리에 도달하자마자 메시지를 확인할 수 있다는 것입니다. 이로 인해 모든 유형의 메시지가 손실될 위험이 있습니다(심지어 승인=모두, min.insync.replicas=2) 동시 고장인 경우.

전반적으로 Kafka는 더 나은 소프트웨어 성능을 보여주며 처음부터 클러스터용으로 설계되었습니다. 신뢰성을 위해 필요한 경우 팔로어 수를 11명으로 늘릴 수 있습니다. 복제 인자 5 및 동기화 시 최소 복제본 수 min.insync.replicas=3 메시지 손실이 매우 드물게 발생합니다. 인프라가 이 복제 비율과 중복성 수준을 지원할 수 있는 경우 이 옵션을 선택할 수 있습니다.

RabbitMQ 클러스터링은 작은 대기열에 적합합니다. 그러나 트래픽이 많으면 작은 대기열이라도 빠르게 늘어날 수 있습니다. 대기열이 커지면 가용성과 안정성 사이에서 어려운 선택을 해야 합니다. RabbitMQ 클러스터링은 RabbitMQ 유연성의 이점이 클러스터링의 단점보다 더 큰 비일반적인 상황에 가장 적합합니다.

대규모 대기열에 대한 RabbitMQ의 취약성에 대한 한 가지 해결책은 대기열을 여러 개의 작은 대기열로 나누는 것입니다. 전체 대기열의 완전한 순서가 필요하지 않고 관련 메시지(예: 특정 클라이언트의 메시지)만 필요하거나 아무것도 주문하지 않는 경우 이 옵션이 허용됩니다. 내 프로젝트 보기 리밸런서 대기열을 분할합니다(프로젝트는 아직 초기 단계입니다).

마지막으로 RabbitMQ와 Kafka의 클러스터링 및 복제 메커니즘에 있는 여러 버그를 잊지 마십시오. 시간이 지남에 따라 시스템은 더욱 성숙해지고 안정해졌지만 어떤 메시지도 손실로부터 100% 안전할 수는 없습니다. 게다가 데이터센터에서도 대규모 사고가 발생한다!

제가 놓친 부분, 실수한 부분, 또는 내용에 동의하지 않는 부분이 있으면 언제든지 댓글을 쓰거나 저에게 연락해 주세요.

저는 종종 "Kafka와 RabbitMQ 중 무엇을 선택해야 합니까?", "어떤 플랫폼이 더 좋습니까?"라는 질문을 받습니다. 사실 이는 귀하의 상황, 현재 경험 등에 따라 달라집니다. 모든 사용 사례와 가능한 제한 사항에 대해 하나의 플랫폼을 권장하는 것은 너무 단순화하기 때문에 제 의견을 제시하는 것을 주저합니다. 나는 당신이 자신의 의견을 형성할 수 있도록 이 일련의 기사를 썼습니다.

두 시스템 모두 이 분야의 리더라고 말하고 싶습니다. 나는 프로젝트 경험으로 볼 때 보장된 메시지 순서 및 신뢰성과 같은 것을 중요하게 생각하는 경향이 있기 때문에 약간 편견이 있을 수 있습니다.

이러한 신뢰성과 보장된 순서가 부족한 다른 기술을 본 다음 RabbitMQ와 Kafka를 살펴보고 이 두 시스템의 놀라운 가치를 깨달았습니다.

출처 : habr.com