내결함성과 고가용성은 큰 주제이므로 RabbitMQ와 Kafka에 대해서는 별도의 기사를 다루겠습니다. 이번 글은 RabbitMQ에 대한 글이고 다음 글은 Kafka에 대한 RabbitMQ 비교 글입니다. 긴 글이니까 편안하게 읽어보세요.

내결함성, 일관성, 고가용성(HA) 전략과 각 전략의 장단점을 살펴보겠습니다. RabbitMQ는 노드 클러스터에서 실행될 수 있으며 분산 시스템으로 분류됩니다. 분산 시스템의 경우 일관성과 가용성에 대해 자주 이야기합니다.

이러한 개념은 시스템이 실패할 때 시스템이 어떻게 작동하는지 설명합니다. 네트워크 연결 오류, 서버 오류, 하드 드라이브 오류, 가비지 수집으로 인한 서버 일시적 사용 불가, 패킷 손실 또는 네트워크 연결 속도 저하. 이 모든 것이 데이터 손실이나 충돌로 이어질 수 있습니다. 모든 장애 시나리오에 대해 완전히 일관되고(데이터 손실 없음, 데이터 분기 없음) 사용 가능(읽기 및 쓰기 허용)되는 시스템을 구축하는 것은 거의 불가능하다는 것이 밝혀졌습니다.

일관성과 가용성은 스펙트럼의 정반대에 있다는 것을 알게 될 것이며, 최적화할 방법을 선택해야 합니다. 좋은 소식은 RabbitMQ를 사용하면 이러한 선택이 가능하다는 것입니다. 균형을 더 큰 일관성이나 더 큰 접근성으로 전환할 수 있는 이러한 종류의 "괴상한" 레버가 있습니다.

확인된 기록으로 인해 어떤 구성이 데이터 손실로 이어지는지 특별히 주의하겠습니다. 출판사, 브로커, 소비자 사이에는 일련의 책임이 있습니다. 메시지가 브로커에게 전송되면 메시지를 잃지 않는 것이 그의 임무입니다. 브로커가 게시자의 메시지 수신을 승인하면 해당 메시지가 손실될 것으로 예상하지 않습니다. 그러나 브로커 및 게시자 구성에 따라 실제로 이러한 일이 발생할 수 있음을 살펴보겠습니다.

단일 노드 복원력 기본 요소

탄력적인 큐/라우팅

RabbitMQ에는 내구성과 비지속성이라는 두 가지 유형의 대기열이 있습니다. 모든 대기열은 Mnesia 데이터베이스에 저장됩니다. 내구성 있는 대기열은 노드 시작 시 다시 광고되므로 다시 시작, 시스템 충돌 또는 서버 충돌(데이터가 지속되는 한)에도 살아남습니다. 즉, 라우팅(교환) 및 대기열을 탄력적으로 선언하면 대기열/라우팅 인프라가 다시 온라인 상태가 됩니다.

노드가 다시 시작되면 휘발성 큐와 라우팅이 제거됩니다.

지속적인 메시지

큐가 내구성이 있다고 해서 모든 메시지가 노드를 다시 시작해도 유지된다는 의미는 아닙니다. 게시자가 다음과 같이 설정한 메시지만 지속 가능한 (지속성 있는). 지속성 메시지는 브로커에 추가 로드를 생성하지만 메시지 손실이 허용되지 않는 경우에는 다른 옵션이 없습니다.

쌀. 1. 지속가능성 매트릭스

큐 미러링을 사용한 클러스터링

브로커의 손실에서 살아남으려면 중복성이 필요합니다. 여러 RabbitMQ 노드를 클러스터로 결합한 다음 여러 노드 간에 대기열을 복제하여 추가 중복성을 추가할 수 있습니다. 이렇게 하면 한 노드에 장애가 발생하더라도 데이터가 손실되지 않고 계속 사용 가능한 상태로 유지됩니다.

대기열 미러링:

• 모든 쓰기 및 읽기 명령을 수신하는 하나의 기본 대기열(마스터)
• 기본 대기열에서 모든 메시지와 메타데이터를 수신하는 하나 이상의 미러. 이러한 미러는 확장을 위해 존재하는 것이 아니라 순전히 중복성을 위해 존재합니다.

쌀. 2. 대기열 미러링

미러링은 적절한 정책에 의해 설정됩니다. 여기에서 복제 계수와 큐가 위치해야 하는 노드까지 선택할 수 있습니다. 예:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (마스터 XNUMX개와 미러 XNUMX개)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

출판사 확인

일관된 녹화를 위해서는 게시자 확인이 필요합니다. 그렇지 않으면 메시지가 유실될 위험이 있습니다. 메시지가 디스크에 기록되면 게시자에게 확인 메시지가 전송됩니다. RabbitMQ는 메시지를 수신하는 즉시 디스크에 기록하는 것이 아니라 수백 밀리초 단위로 주기적으로 디스크에 기록합니다. 큐가 미러링되면 모든 미러가 메시지 복사본을 디스크에 쓴 후에만 승인이 전송됩니다. 즉, 확인을 사용하면 대기 시간이 추가되지만 데이터 보안이 중요하다면 반드시 필요합니다.

장애 조치 대기열

브로커가 종료되거나 충돌하면 해당 노드의 모든 대기열 리더(마스터)도 함께 충돌합니다. 그런 다음 클러스터는 각 마스터의 가장 오래된 미러를 선택하고 이를 새 마스터로 승격시킵니다.

쌀. 3. 여러 미러링된 대기열 및 해당 정책

브로커 3이 다운됩니다. 브로커 2의 대기열 C 미러가 마스터로 승격되고 있습니다. 또한 Broker 1의 대기열 C에 대해 새 미러가 생성되었습니다. RabbitMQ는 항상 정책에 지정된 복제 요소를 유지하려고 시도합니다.

쌀. 4. 브로커 3이 실패하여 큐 C가 실패하게 됩니다.

다음 브로커 1이 무너졌습니다! 이제 브로커가 한 명 남았습니다. 대기열 B 미러가 마스터로 승격됩니다.

그림. 5

브로커 1을 반환했습니다. 브로커 손실 및 복구 후에도 데이터가 얼마나 잘 유지되는지에 관계없이 미러링된 모든 대기열 메시지는 다시 시작 시 삭제됩니다. 결과가 따르기 때문에 주의하는 것이 중요합니다. 우리는 곧 이러한 의미를 살펴보겠습니다. 따라서 브로커 1은 이제 다시 클러스터의 구성원이 되고 클러스터는 정책을 준수하려고 시도하므로 브로커 1에 미러가 생성됩니다.

이 경우 데이터와 마찬가지로 Broker 1의 손실이 완료되었으므로 미러링되지 않은 대기열 B가 완전히 손실되었습니다.

쌀. 6. 브로커 1이 서비스로 복귀합니다.

브로커 3이 다시 온라인 상태가 되므로 대기열 A와 B는 HA 정책을 충족하기 위해 생성된 미러를 다시 가져옵니다. 하지만 이제 모든 기본 대기열이 하나의 노드에 있습니다! 이는 이상적이지 않습니다. 노드 간에 균등한 분포가 더 좋습니다. 불행하게도 여기에는 마스터 재조정을 위한 옵션이 많지 않습니다. 먼저 대기열 동기화를 살펴봐야 하므로 이 문제는 나중에 다시 다루겠습니다.

쌀. 7. 브로커 3이 서비스로 돌아갑니다. 하나의 노드에 모든 기본 대기열이 있습니다!

이제 미러가 중복성과 내결함성을 제공하는 방법에 대해 이해해야 합니다. 이는 단일 노드 장애 시 가용성을 보장하고 데이터 손실을 방지합니다. 하지만 아직 끝나지 않았습니다. 실제로는 훨씬 더 복잡하기 때문입니다.

동기화 중

새 미러를 생성할 때 모든 새 메시지는 항상 이 미러와 다른 미러에 복제됩니다. 마스터 큐에 있는 기존 데이터의 경우 이를 새 미러에 복제할 수 있으며 이는 마스터의 전체 복사본이 됩니다. 또한 기존 메시지를 복제하지 않고 기본 대기열과 새 미러가 시간에 맞춰 수렴하도록 선택할 수도 있습니다. 이때 새 메시지는 테일에 도착하고 기존 메시지는 기본 대기열의 헤드를 떠납니다.

이 동기화는 자동 또는 수동으로 수행되며 대기열 정책을 사용하여 관리됩니다. 예를 살펴보겠습니다.

두 개의 미러링된 대기열이 있습니다. 대기열 A는 자동으로 동기화되고 대기열 B는 수동으로 동기화됩니다. 두 대기열 모두 XNUMX개의 메시지를 포함합니다.

쌀. 8. 동기화 모드가 다른 두 개의 대기열

이제 우리는 Broker 3을 잃고 있습니다.

쌀. 9. 브로커 3이 떨어졌다

브로커 3이 서비스로 돌아갑니다. 클러스터는 새 노드의 각 대기열에 대한 미러를 생성하고 새 대기열 A를 마스터와 자동으로 동기화합니다. 그러나 새 대기열 B의 미러는 비어 있습니다. 이러한 방식으로 대기열 A에 대한 전체 중복성이 있고 기존 대기열 B 메시지에 대한 미러는 하나만 있습니다.

쌀. 10. 대기열 A의 새 미러는 기존 메시지를 모두 수신하지만 대기열 B의 새 미러는 그렇지 않습니다.

두 대기열 모두에 2개의 추가 메시지가 도착합니다. 그런 다음 브로커 1가 충돌하고 대기열 A가 브로커 XNUMX에 있는 가장 오래된 미러로 롤백됩니다. 실패해도 데이터 손실은 없습니다. 큐 B에는 마스터에 XNUMX개의 메시지가 있고 미러에는 XNUMX개의 메시지만 있습니다. 이 큐는 원래 XNUMX개의 메시지를 복제하지 않았기 때문입니다.

쌀. 11. 대기열 A는 메시지 손실 없이 Broker 1로 롤백됩니다.

두 대기열 모두에 1개의 추가 메시지가 도착합니다. 이제 브로커 XNUMX이 충돌하고 대기열 A는 메시지 손실 없이 미러로 쉽게 전환됩니다. 그러나 대기열 B에 문제가 있습니다. 이 시점에서 가용성이나 일관성을 최적화할 수 있습니다.

접근성을 최적화하려면 정책이 필요합니다. 하-실패 시 승격 에 설치해야합니다 항상. 이는 기본값이므로 단순히 정책을 전혀 지정할 수 없습니다. 이 경우 기본적으로 동기화되지 않은 미러에서 오류가 허용됩니다. 이로 인해 메시지가 손실되지만 대기열은 읽기 및 쓰기가 가능한 상태로 유지됩니다.

쌀. 12. 대기열 A는 메시지 손실 없이 Broker 3으로 롤백됩니다. 대기열 B는 3개의 메시지가 손실된 상태로 Broker XNUMX으로 롤백됩니다.

우리는 또한 설치할 수 있습니다 ha-promote-on-failure 의미상 when-synced. 이 경우 큐는 미러로 롤백하는 대신 데이터가 있는 브로커 1이 온라인 모드로 돌아올 때까지 기다립니다. 반환된 후 기본 대기열은 데이터 손실 없이 Broker 1로 돌아갑니다. 데이터 보안을 위해 가용성이 희생됩니다. 그러나 이는 완전한 데이터 손실로 이어질 수도 있는 위험한 모드입니다. 이에 대해서는 곧 살펴보겠습니다.

쌀. 13. 브로커 1을 잃은 후 대기열 B를 계속 사용할 수 없습니다.

“자동 동기화를 절대 사용하지 않는 것이 낫나요?”라고 물을 수도 있습니다. 대답은 동기화가 차단 작업이라는 것입니다. 동기화 중에는 기본 대기열에서 읽기 또는 쓰기 작업을 수행할 수 없습니다!

예를 살펴보겠습니다. 이제 대기열이 매우 깁니다. 어떻게 그런 크기로 자랄 수 있습니까? 여러 가지 이유:

• 대기열이 적극적으로 사용되지 않습니다.
• 이것은 고속 대기열이며 현재 소비자는 느립니다.
• 대기열이 너무 빨라서 결함이 있었고 소비자가 따라잡고 있습니다.

쌀. 14. 동기화 모드가 다른 두 개의 큰 대기열

이제 브로커 3이 무너졌습니다.

쌀. 15. 브로커 3이 중단되어 각 대기열에 하나의 마스터와 미러가 남습니다.

브로커 3이 다시 온라인 상태가 되고 새 미러가 생성됩니다. 기본 대기열 A는 기존 메시지를 새 미러로 복제하기 시작하며 이 시간 동안 대기열을 사용할 수 없습니다. 데이터를 복제하는 데 XNUMX시간이 걸리므로 이 대기열에 XNUMX시간의 가동 중지 시간이 발생합니다!

그러나 대기열 B는 전체 기간 동안 계속 사용 가능합니다. 그녀는 접근성을 위해 일부 중복성을 희생했습니다.

쌀. 16. 동기화 중에 대기열을 사용할 수 없습니다.

XNUMX시간 후에는 큐 A도 사용할 수 있게 되어 읽기 및 쓰기 허용을 다시 시작할 수 있습니다.

업데이트

동기화 중 이러한 차단 동작으로 인해 대기열이 매우 큰 클러스터를 업데이트하기가 어렵습니다. 어떤 시점에서는 마스터 노드를 다시 시작해야 합니다. 이는 서버가 업그레이드되는 동안 미러로 전환하거나 대기열을 비활성화하는 것을 의미합니다. 전환을 선택하면 미러가 동기화되지 않으면 메시지가 손실됩니다. 기본적으로 브로커 가동 중단 중에는 비동기화된 미러로의 장애 조치가 수행되지 않습니다. 즉, 브로커가 반환되자마자 메시지가 손실되지 않으며 유일한 피해는 단순한 대기열뿐이었습니다. 브로커 연결이 끊어졌을 때의 행동 규칙은 정책에 따라 설정됩니다. ha-promote-on-shutdown. 다음 두 값 중 하나를 설정할 수 있습니다.

• always= 비동기화된 미러로의 전환이 활성화되었습니다.
• when-synced= 동기화된 미러로만 전환됩니다. 그렇지 않으면 대기열을 읽을 수 없고 쓸 수 없게 됩니다. 브로커가 반환되자마자 대기열이 서비스로 돌아갑니다.

어떤 식으로든 대기열이 크면 데이터 손실과 가용성 중 하나를 선택해야 합니다.

가용성으로 인해 데이터 보안이 향상되는 경우

결정을 내리기 전에 고려해야 할 문제가 하나 더 있습니다. 중복성을 위해서는 자동 동기화가 더 좋지만 데이터 보안에는 어떤 영향을 줍니까? 물론 중복성이 향상되면 RabbitMQ는 기존 메시지를 잃을 가능성이 적습니다. 하지만 게시자의 새 메시지는 어떻습니까?

여기에서는 다음 사항을 고려해야 합니다.

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

게시자가 메시지를 삭제할 수만 있다면 실제로 접근성을 향상시키면 데이터 보안도 향상됩니다.

따라서 균형을 찾아야 하며, 해결책은 특정 상황에 따라 달라집니다.

ha-promote-on-failure=when-synced 관련 문제

생각 하-실패 시 승격= 동기화 시 비동기화된 미러로의 전환을 방지하여 데이터 손실을 방지한다는 것입니다. 대기열은 읽거나 쓸 수 없는 상태로 유지됩니다. 대신, 데이터 손실 없이 마스터 기능을 재개할 수 있도록 충돌이 발생한 브로커를 데이터를 그대로 복구하려고 합니다.

그러나 (그리고 이것은 큰 일이지만) 브로커가 데이터를 잃어버린 경우 큰 문제가 발생합니다. 대기열이 손실됩니다! 모든 데이터가 사라졌습니다! 기본 대기열을 대부분 따라잡는 미러가 있더라도 해당 미러도 삭제됩니다.

같은 이름의 노드를 다시 추가하려면 클러스터에 손실된 노드를 잊어버리라고 지시합니다(명령어 사용). Rabbitmqctl 잊어버리다_cluster_node) 동일한 호스트 이름으로 새 브로커를 시작합니다. 클러스터는 손실된 노드를 기억하는 동시에 이전 대기열과 동기화되지 않은 미러도 기억합니다. 클러스터에 고아 노드를 삭제하라는 메시지가 표시되면 해당 대기열도 삭제됩니다. 이제 다시 선언해야 합니다. 일부 데이터 세트가 포함된 미러가 있었지만 모든 데이터가 손실되었습니다. 비동기 미러로 전환하는 것이 더 좋을 것 같습니다!

따라서 수동 동기화(및 동기화 실패)는 ha-promote-on-failure=when-synced, 제 생각에는 꽤 위험합니다. 문서에는 데이터 보안을 위해 이 옵션이 존재한다고 나와 있지만 이는 양날의 칼입니다.

마스터 재조정

약속한 대로 하나 또는 여러 노드에 모든 마스터가 축적되는 문제로 돌아갑니다. 이는 롤링 클러스터 업데이트의 결과로 발생할 수도 있습니다. XNUMX노드 클러스터에서는 모든 마스터 큐가 XNUMX개 또는 XNUMX개의 노드에 누적됩니다.

마스터 재조정은 다음 두 가지 이유로 문제가 될 수 있습니다.

• 재조정을 수행할 수 있는 좋은 도구가 없습니다.
• 대기열 동기화

재조정을 위한 제XNUMX자가 있습니다. 플러그인, 이는 공식적으로 지원되지 않습니다. RabbitMQ 매뉴얼의 타사 플러그인 관련 그것이라고: “플러그인은 몇 가지 추가 구성 및 보고 도구를 제공하지만 RabbitMQ 팀에서는 지원하거나 확인하지 않습니다. 사용에 따른 책임은 본인에게 있습니다."

HA 정책을 통해 기본 대기열을 이동하는 또 다른 트릭이 있습니다. 매뉴얼에는 언급되어 있습니다. 스크립트 이를 위해. 다음과 같이 작동합니다.

• 기존 HA 정책보다 우선순위가 높은 임시 정책을 사용하여 모든 미러를 제거합니다.
• 마스터 큐가 전송되어야 하는 노드를 지정하여 노드 모드를 사용하도록 HA 임시 정책을 변경합니다.
• 푸시 마이그레이션을 위해 큐를 동기화합니다.
• 마이그레이션이 완료된 후 임시 정책을 삭제합니다. 초기 HA 정책이 적용되고 필요한 수의 미러가 생성됩니다.

단점은 대기열이 크거나 중복성 요구 사항이 엄격한 경우 이 접근 방식이 작동하지 않을 수 있다는 것입니다.

이제 RabbitMQ 클러스터가 네트워크 파티션에서 어떻게 작동하는지 살펴보겠습니다.

연결 끊김

분산 시스템의 노드는 네트워크 링크로 연결되어 있으며 네트워크 링크는 연결이 끊어질 수 있으며 연결이 끊어질 수 있습니다. 중단 빈도는 로컬 인프라 또는 선택한 클라우드의 안정성에 따라 다릅니다. 어떤 경우에도 분산 시스템은 이에 대처할 수 있어야 합니다. 다시 한 번 가용성과 일관성 사이에서 선택할 수 있게 되었으며, 다시 한 번 좋은 소식은 RabbitMQ가 두 옵션을 모두 제공한다는 것입니다(단, 동시에는 아님).

RabbitMQ에는 두 가지 주요 옵션이 있습니다.

• 논리적 분할(분할 브레인)을 허용합니다. 이렇게 하면 가용성이 보장되지만 데이터가 손실될 수 있습니다.
• 논리적 분리를 비활성화합니다. 클라이언트가 클러스터에 연결하는 방식에 따라 단기적인 가용성 손실이 발생할 수 있습니다. 또한 XNUMX노드 클러스터에서 완전한 가용성이 불가능해질 수도 있습니다.

그런데 논리적 분리란 무엇인가? 이는 네트워크 연결이 끊어져 클러스터가 둘로 분할되는 경우입니다. 각 측면에서 미러는 마스터로 승격되므로 결국 대기열당 여러 마스터가 있게 됩니다.

쌀. 17. 각각 별도의 노드에 있는 기본 대기열과 두 개의 미러. 그런 다음 네트워크 오류가 발생하고 미러 하나가 분리됩니다. 분리된 노드는 다른 두 노드가 떨어진 것을 확인하고 자신의 미러를 마스터로 승격시킵니다. 이제 쓰기 가능하고 읽기 가능한 두 개의 기본 대기열이 있습니다.

게시자가 두 마스터 모두에 데이터를 보내는 경우 대기열의 서로 다른 두 복사본이 생성됩니다.

RabbitMQ의 다양한 모드는 가용성 또는 일관성을 제공합니다.

무시 모드(기본값)

이 모드는 접근성을 보장합니다. 연결이 끊어지면 논리적 분리가 발생합니다. 연결이 복원된 후 관리자는 우선 순위를 부여할 파티션을 결정해야 합니다. 패배한 쪽은 다시 시작되고 해당 쪽의 축적된 데이터는 모두 손실됩니다.

쌀. 18. 세 명의 게시자가 세 명의 브로커와 연결되어 있습니다. 내부적으로 클러스터는 모든 요청을 브로커 2의 기본 대기열로 라우팅합니다.

이제 우리는 브로커 3을 잃고 있습니다. 그는 다른 브로커가 탈락한 것을 보고 자신의 미러를 마스터로 승격시킵니다. 이것이 논리적 분리가 발생하는 방식입니다.

쌀. 19. 논리적 분할(분할 브레인). 레코드는 두 개의 기본 대기열로 들어가고 두 개의 복사본이 분기됩니다.

연결은 복원되지만 논리적 분리는 유지됩니다. 관리자는 패배한 쪽을 수동으로 선택해야 합니다. 아래의 경우 관리자는 Broker 3을 재부팅합니다. 전송하지 못한 메시지는 모두 손실됩니다.

쌀. 20. 관리자가 브로커 3을 비활성화합니다.

쌀. 21. 관리자가 Broker 3을 시작하고 클러스터에 합류하면 그곳에 남아 있던 모든 메시지가 손실됩니다.

연결이 끊어지는 동안과 복원 후에는 클러스터와 이 큐를 읽고 쓸 수 있었습니다.

자동 복구 모드

연결을 분할하고 복원한 후 클러스터 자체가 손실된 쪽을 자동으로 선택한다는 점을 제외하면 무시 모드와 유사하게 작동합니다. 패배한 쪽은 빈 클러스터로 돌아가고 대기열은 해당 쪽으로만 전송된 모든 메시지를 잃게 됩니다.

소수 모드 일시 중지

논리적 분할을 허용하지 않으려면 유일한 옵션은 클러스터 분할 후 더 작은 쪽에서 읽기 및 쓰기를 삭제하는 것입니다. 브로커는 자신이 더 작은 쪽에 있음을 확인하면 작업을 일시 중지합니다. 즉, 기존 연결을 모두 닫고 새 연결을 거부합니다. 초당 한 번씩 연결 복원을 확인합니다. 연결이 복원되면 작업이 재개되고 클러스터에 연결됩니다.

쌀. 22. 세 명의 게시자가 세 명의 브로커와 연결되어 있습니다. 내부적으로 클러스터는 모든 요청을 브로커 2의 기본 대기열로 라우팅합니다.

그런 다음 브로커 1과 2가 브로커 3에서 분할됩니다. 미러를 마스터로 승격하는 대신 브로커 3이 일시 중지되어 사용할 수 없게 됩니다.

쌀. 23. 브로커 3은 일시 중지되고 모든 클라이언트의 연결을 끊고 연결 요청을 거부합니다.

연결이 복원되면 클러스터로 돌아갑니다.

메인 큐가 브로커 3에 있는 또 다른 예를 살펴보겠습니다.

쌀. 24. 브로커 3의 메인 큐.

그러면 동일한 연결 끊김이 발생합니다. 브로커 3은 더 작은 쪽에 있기 때문에 일시 중지됩니다. 반면에 노드는 브로커 3이 중단되었음을 확인하므로 브로커 1과 2의 이전 미러가 마스터로 승격됩니다.

쌀. 25. 브로커 2을 사용할 수 없는 경우 브로커 3로 전환합니다.

연결이 복원되면 Broker 3이 클러스터에 합류합니다.

쌀. 26. 클러스터가 정상 작동으로 돌아왔습니다.

여기서 이해해야 할 중요한 점은 일관성을 얻을 수도 있지만 가용성도 얻을 수 있다는 것입니다. 면 우리는 고객을 대부분의 섹션으로 성공적으로 이전할 것입니다. 대부분의 상황에서는 개인적으로 Pause Minority 모드를 선택하지만 실제로는 개별 사례에 따라 다릅니다.

가용성을 보장하려면 클라이언트가 호스트에 성공적으로 연결되는지 확인하는 것이 중요합니다. 옵션을 살펴보겠습니다.

고객 연결 보장

연결이 끊어진 후 클라이언트를 클러스터의 주요 부분이나 작업 노드(한 노드가 실패한 후)로 보내는 방법에 대한 몇 가지 옵션이 있습니다. 먼저, 특정 대기열은 특정 노드에서 호스팅되지만 라우팅 및 정책은 모든 노드에 복제된다는 점을 기억하세요. 클라이언트는 모든 노드에 연결할 수 있으며 내부 라우팅은 클라이언트가 가야 할 곳으로 안내합니다. 그러나 노드가 일시 중단되면 연결이 거부되므로 클라이언트는 다른 노드에 연결해야 합니다. 노드가 떨어지면 그가 할 수 있는 일은 거의 없습니다.

우리의 옵션:

• 클러스터는 단순히 노드를 순환하는 로드 밸런서를 사용하여 액세스되며 클라이언트는 성공할 때까지 연결을 다시 시도합니다. 노드가 다운되거나 일시 중단된 경우 해당 노드에 대한 연결 시도는 실패하지만 후속 시도는 라운드 로빈 방식으로 다른 서버로 이동합니다. 이는 단기적인 연결 끊김 또는 신속하게 복구할 수 있는 다운된 서버에 적합합니다.
• 로드 밸런서를 통해 클러스터에 액세스하고 일시 중지/실패한 노드가 감지되는 즉시 목록에서 제거합니다. 이 작업을 신속하게 수행하고 클라이언트가 연결을 다시 시도할 수 있다면 지속적인 가용성을 얻을 수 있습니다.
• 각 클라이언트에 모든 노드 목록을 제공하고 클라이언트는 연결할 때 그 중 하나를 무작위로 선택합니다. 연결을 시도할 때 오류가 발생하면 연결될 때까지 목록의 다음 노드로 이동합니다.
• DNS를 사용하여 실패/일시 중지된 노드에서 트래픽을 제거합니다. 이는 작은 TTL을 사용하여 수행됩니다.

조사 결과

RabbitMQ 클러스터링에는 장점과 단점이 있습니다. 가장 심각한 단점은 다음과 같습니다.

• 클러스터에 합류할 때 노드는 데이터를 버립니다.
• 동기화를 차단하면 대기열을 사용할 수 없게 됩니다.

모든 어려운 결정은 이 두 가지 아키텍처 기능에서 비롯됩니다. 클러스터가 다시 결합될 때 RabbitMQ가 데이터를 저장할 수 있다면 동기화가 더 빨라질 것입니다. 비차단 동기화가 가능하다면 대규모 대기열을 더 잘 지원할 것입니다. 이 두 가지 문제를 해결하면 내결함성 및 고가용성 메시징 기술로서 RabbitMQ의 성능이 크게 향상됩니다. 다음과 같은 상황에서는 클러스터링이 포함된 RabbitMQ를 권장하기가 꺼려집니다.

• 신뢰할 수 없는 네트워크.
• 신뢰할 수 없는 스토리지.
• 매우 긴 대기열.

고가용성 설정에 관해서는 다음을 고려하십시오.

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (또는 autoheal)
• 지속적인 메시지
• 일부 노드에 장애가 발생하면 클라이언트가 활성 노드에 연결되도록 보장

일관성(데이터 보안)을 위해 다음 설정을 고려하십시오.

• 게시자 확인 및 소비자 측 수동 승인
• ha-promote-on-failure=when-synced, 게시자가 나중에 다시 시도할 수 있고 매우 안정적인 저장 공간이 있다면! 그렇지 않으면 넣어 =always.
• ha-sync-mode=automatic (그러나 큰 비활성 대기열의 경우 수동 모드가 필요할 수 있습니다. 또한 사용 불가능으로 인해 메시지가 손실되는지 여부도 고려하십시오.)
• 소수 모드 일시 중지
• 지속적인 메시지

아직 내결함성 및 고가용성 문제를 모두 다루지는 않았습니다. 예를 들어 관리 절차(예: 롤링 업데이트)를 안전하게 수행하는 방법 등이 있습니다. 또한 페더레이션과 Shovel 플러그인에 대해서도 이야기해야 합니다.

제가 놓친 다른 사항이 있으면 알려주시기 바랍니다.

내 것도 참조하세요 게시여기서는 Docker와 Blockade를 사용하여 RabbitMQ 클러스터에 큰 피해를 입히고 이 기사에 설명된 메시지 손실 시나리오 중 일부를 테스트했습니다.

시리즈의 이전 기사 :
1번 - habr.com/ru/company/itsumma/blog/416629
2번 - habr.com/ru/company/itsumma/blog/418389
3번 - habr.com/ru/company/itsumma/blog/437446

출처 : habr.com