엔지니어링

새로운 시대를 맞이하는 Elasticsearch의 클러스터 조정

By
David Turner
•
Yannick Welsch

Elasticsearch가 널리 인기를 얻고 있는 이유 중 하나는 몇 개의 노드가 있는 소규모 클러스터에서 수백 개의 노드가 있는 대규모 클러스터까지 원활하게 확장할 수 있다는 점입니다. 그 중심에는 클러스터 조정 하위 시스템이 있습니다. Elasticsearch 버전 7에는 이전 버전에 비해 많은 이점을 제공하는 새로운 클러스터 조정 하위 시스템이 포함되어 있습니다. 이 문서에서는 이 하위 시스템이 버전 7에서 어떻게 개선되었는지를 다룹니다. 새로운 하위 시스템을 사용하는 방법, 변경 사항이 버전 6의 업그레이드에 미치는 영향, 이러한 개선 사항이 어떻게 실수로 인해 데이터가 위험에 빠지는 상황을 방지하는지 설명합니다. 그리고 새로운 하위 시스템의 작동 방식에 대한 간략한 설명으로 마무리합니다.

클러스터 조정이란 무엇인가요?

Elasticsearch 클러스터는 여러 노드가 연동되어야 처리가 가능한 많은 작업을 수행할 수 있습니다. 예를 들어 정확한 결과를 얻기 위해서는 모든 검색이 적절한 샤드로 라우팅되어야 합니다. 모든 복제본은 일부 문서를 색인하거나 삭제할 때 업데이트되어야 합니다. 모든 클라이언트 요청은 이를 수신하는 노드에서 이를 처리할 수 있는 노드로 전달되어야 합니다. 각 노드에는 클러스터에 대한 자체 개요가 있으므로 검색, 색인 및 기타 조정 활동을 수행할 수 있습니다. 이러한 개요를 클러스터 상태라고 합니다. 클러스터 상태는 각 인덱스의 매핑 및 설정, 각 노드에 할당되는 샤드, 동기화 중인 샤드 복사본 등을 결정합니다. 이러한 정보를 클러스터 전체에 걸쳐 일관되게 유지하는 것이 매우 중요합니다. 시퀀스 번호 기반 복제 및 교차 클러스터 복제를 비롯한 많은 최신 기능이 올바르게 작동하려면 클러스터 상태의 일관성을 신뢰할 수 있어야 합니다.

조정 하위 시스템은 클러스터의 마스터로 사용할 특정 노드를 선택하는 방식으로 작동합니다. 이렇게 선출된 마스터 노드는 클러스터의 모든 노드가 클러스터 상태에 대한 업데이트를 수신하도록 합니다. 이는 생각보다 어렵습니다. Elasticsearch와 같은 분산 시스템이 여러 이상 상황에 대처할 수 있게 준비해야 하기 때문입니다. 노드는 때때로 느리게 실행되거나, 가비지 수집을 위해 일시 중단되거나, 갑자기 동력을 잃기도 합니다. 네트워크는 파티션, 패킷 손실, 지연 시간이 긴 기간으로 인해 성능이 저하되거나, 메시지를 발송 순서와 다른 순서로 전송할 수도 있습니다. 이러한 문제가 한 번에 여러 개가 발생할 수도 있고 간헐적으로 발생할 수도 있습니다. 이 모든 어려움에도 불구하고 클러스터 조정 하위 시스템은 모든 노드가 클러스터 상태를 일관되게 파악하도록 보장할 수 있어야 합니다.

Elasticsearch가 개별 노드 장애에 대한 복원력을 갖추고 있어야 한다는 것도 중요합니다. Elasticsearch는 노드의 쿼럼이 클러스터 상태 업데이트를 수락한 후에 업데이트가 성공한 것으로 간주하는 방식으로 이러한 복원력을 달성합니다. 쿼럼은 클러스터의 마스터 적격 노드에서 신중하게 선택된 하위 집합입니다. 노드의 하위 집합만 응답하도록 하면 일부 노드에 장애가 발생해도 클러스터의 가용성에 영향을 미치지 않는다는 이점이 있습니다. 클러스터가 2개의 독립적인 마스터를 선택하면 일관성 없는 의사 결정을 내리고 이는 궁극적으로 데이터 손실로 이어지기 때문에 마스터를 2개 선택할 수는 없습니다. 따라서 쿼럼은 신중하게 선택해야 합니다.

일반적으로 클러스터에는 3개의 마스터 적격 노드가 있는 것이 좋습니다. 그러면 노드 중 하나에 장애가 발생하더라도 여전히 나머지 두 개로 안전하게 쿼럼을 형성하고 계속 진행할 수 있습니다. 클러스터에 마스터 적격 노드가 3개 미만인 경우, 이 중 하나의 손실도 허용될 수 없습니다. 이와 반대로 클러스터에 마스터 적격 노드가 3개보다 훨씬 많은 경우, 선출과 클러스터 상태 업데이트에 시간이 더 걸릴 수 있습니다.

진화 또는 혁명?

Elasticsearch 버전 6.x 및 이전 버전에서는 Zen Discovery라고 하는 클러스터 조정 하위 시스템을 사용합니다. 이 하위 시스템은 수년 동안 진화되고 성숙되었으며, 모든 규모의 클러스터를 성공적으로 지원합니다. 그러나 몇 가지 개선하고자 하는 부분이 있었으며 이를 위해서는 작동 방식에 보다 근본적인 변화가 필요했습니다.

Zen Discovery를 사용하면 사용자는 discovery.zen.minimum_master_nodes 설정을 통해 쿼럼을 구성하는 마스터 적격 노드 수를 선택할 수 있습니다. 모든 노드에 이 설정을 올바르게 구성하고, 클러스터가 동적으로 확장될 때 이를 올바르게 업데이트하는 것이 매우 중요합니다. 시스템에서 사용자가 이 설정을 잘못 구성했는지 여부를 감지하는 것은 불가능하며, 사실상 노드를 추가하거나 제거한 후에 설정을 변경하는 것을 잊어버리기가 매우 쉽습니다. Zen Discovery는 각 마스터 선출 후 몇 초를 기다림으로써 이러한 종류의 잘못된 구성으로부터 보호하며, 일반적으로 다른 시간 제한에도 상당히 보수적입니다. 즉, 선택된 마스터 노드에 장애가 발생하면 교체 노드를 선택하기 전에 최소한 몇 초 동안 클러스터를 사용할 수 없습니다. 클러스터가 마스터를 선택할 수 없는 경우에는 그 이유를 이해하기 매우 어려울 때가 있습니다.

Elasticsearch 7.0에서는 클러스터 조정 하위 시스템을 다음과 같이 재검토 및 재구축했습니다.

  • minimum_master_nodes 설정 기능을 없애고 Elasticsearch 자체에서 쿼럼을 구성할 노드를 선택할 수 있도록 했습니다. 
  • 일반적인 마스터 선출은 이제 완료하는 데 1초도 걸리지 않습니다. 
  • 클러스터 확장 및 축소가 더 안전하고 쉬워졌으며 데이터 손실 위험이 있는 방식으로 시스템을 구성할 여지가 훨씬 줄어들었습니다. 
  • 노드가 자신의 상태를 훨씬 명확하게 기록하므로 클러스터에 조인할 수 없는 이유 또는 마스터로 선출될 수 없는 이유를 진단하는 데 도움이 됩니다.

노드가 추가되거나 제거될 때 Elasticsearch는 클러스터의 투표 구성을 업데이트하여 최적의 내결함성 수준을 자동으로 유지 관리합니다. 투표 구성은 마스터 적격 노드의 집합으로, 의사 결정을 내릴 때 해당 표가 계산에 포함됩니다. 일반적으로 투표 구성에는 클러스터의 모든 마스터 적격 노드가 포함됩니다. 쿼럼은 투표 구성의 단순 과수입니다. 모든 클러스터 상태 업데이트에는 투표 구성의 노드 중 과반수 이상의 동의가 필요합니다. 시스템에서 투표 구성을 관리하고 따라서 쿼럼도 관리하므로, 노드가 추가되거나 제거되더라도 데이터 손실로 이어질 수 있는 잘못된 구성이 발생할 가능성이 없습니다.

노드가 마스터 노드를 발견할 수 없고 자신이 마스터로 선출되지 못하는 경우, Elasticsearch 7.0부터는 많은 일반적인 문제를 진단하는 데 도움이 될 만큼 상세하게 현재 상태를 설명하는 경고 메시지를 주기적으로 기록합니다.

또한, Zen Discovery에는 Elasticsearch 복원력 상태 페이지에 “Repeated network partitions can cause cluster state updates to be lost(네트워크 파티션이 반복되면 클러스터 상태 업데이트가 손실될 수 있습니다)”로 기록된 매우 드문 장애 모드가 있었으며, 이 장애 모드는 더 이상 발생하지 않습니다. 이 항목은 이제 해결된 것으로 표시됩니다.

어떻게 사용하나요?

완전히 기본 구성으로 새로 설치된 Elasticsearch 노드를 시작하는 경우, 해당 노드는 자동으로 동일한 호스트에서 실행 중인 다른 노드를 찾아 클러스터를 형성합니다. 동일한 호스트에서 추가 노드를 시작하면, 기본적으로 추가 노드 역시 이 클러스터를 찾아 조인합니다. 따라서 Elasticsearch 버전 7.0에서도 이전 버전과 마찬가지로 다중 노드 개발 클러스터를 쉽게 시작할 수 있습니다.

이러한 완전 자동 클러스터 형성 메커니즘은 단일 호스트에서는 잘 작동하지만 프로덕션 또는 다른 분산 환경에 사용할 수 있을 정도는 아닙니다. 노드가 제때 서로를 발견하지 못하고 둘 이상의 독립적인 클러스터를 형성할 위험이 있습니다. 버전 7.0부터는 노드가 있는 새로운 클러스터를 둘 이상의 호스트에서 시작하려는 경우, 클러스터에서 첫 번째 선출의 투표 구성으로 사용할 마스터 적격 노드의 초기 집합을 지정해야 합니다. 이를 클러스터 부트스트래핑이라고 하며, 클러스터가 처음 형성될 때만 필요합니다. 클러스터에 이미 조인된 노드는 데이터 폴더에 투표 구성을 저장하고 다시 시작한 후 이를 재사용하며, 기존 클러스터에 조인하는 새로 시작된 노드는 클러스터의 선택된 마스터로부터 이 정보를 수신할 수 있습니다.

cluster.initial_master_nodes 설정을 마스터 적격 노드 초기 세트의 이름 또는 IP 주소로 설정하여 클러스터를 부트스트래핑합니다. 이 설정은 명령줄 또는 하나 이상의 마스터 적격 노드의 elasticsearch.yml 파일로 제공할 수 있습니다. 또한, 노드가 서로를 찾는 방법을 알도록 검색 하위 시스템을 구성해야 합니다.

initial_master_nodes가 설정되어 있지 않은 경우 새로운 노드는 기존 클러스터를 찾을 수 있을 것으로 예상하고 시작합니다. 노드가 조인할 클러스터를 찾지 못하면 다음과 같은 경고 메시지를 주기적으로 로깅합니다.

마스터가 아직 발견되지 않았고, 이 노드는 부트스트래핑된(v7+) 클러스터에 미리 조인되어 있지 않으며,
이 노드의 [cluster.initial_master_nodes]가 비어 있습니다

클러스터에 새로운 마스터 적격 노드를 추가하는 데 더는 특별한 절차가 필요하지 않습니다. 새로운 노드가 기존 클러스터를 찾도록 구성하고, 이를 시작하기만 하면, 새 노드가 조인될 때 클러스터가 투표 구성을 자동으로 안전하게 채택합니다. 또한, 절반 이상의 마스터 적격 노드를 한꺼번에 중지하지 않는 한 노드를 중지하는 방식으로 노드를 제거하는 것이 안전합니다. 마스터 적격 노드의 절반 이상을 중지해야 하거나 더 복잡한 확장 및 오케스트레이션 요구 사항이 있는 경우, API를 사용하여 직접 투표 구성을 조정하는 좀 더 타게팅된 확장 절차를 사용할 수 있습니다.

업그레이드하려면 어떻게 해야 하나요?

롤링 업그레이드 또는 전체 클러스터 재시작을 통해 Elasticsearch 클러스터를 버전 6에서 버전 7로 업그레이드할 수 있습니다. 업그레이드 동안 클러스터의 가용성을 유지하면서 노드별로 업그레이드를 수행할 수 있는 롤링 업그레이드를 권장합니다. 버전 7로 롤링 업그레이드를 수행하기 전에 버전 6 클러스터를 버전 6.7로 업그레이드해야 합니다. 전체 클러스터 재시작을 사용하면 모든 6.x 버전을 버전 7로 업그레이드할 수 있지만, 전체 클러스터를 종료한 후 다시 시작해야 합니다. 어떤 방법을 사용하든 Elasticsearch의 버전 6과 7 사이에는 여기에서 설명한 클러스터 조정 기능보다 훨씬 더 많은 부분이 개선되었습니다. 원활한 업그레이드를 보장하려면 항상 상세한 업그레이드 지침을 주의 깊게 따라야 합니다.

롤링 업그레이드를 수행하면 클러스터의 노드 수와 기존 minimum_master_nodes 설정에 따라 클러스터 부트스트래핑이 자동으로 진행됩니다. 즉, 업그레이드를 시작하기 전에 이 설정이 올바르게 구성되어 있는지 확인하는 것이 중요합니다. 클러스터 부트스트래핑은 이 롤링 업그레이드를 수행할 때 자동으로 진행되므로 여기에서 initial_master_nodes를 설정할 필요는 없습니다. 버전 7 마스터 적격 노드는 마스터 선출 시 버전 6.7 노드에 투표하는 것을 선호하므로, 모든 마스터 적격 노드가 업그레이드될 때까지 업그레이드 중에는 일반적으로 버전 6.7 노드가 마스터로 선출될 것입니다.

전체 클러스터 재시작 업그레이드를 수행하는 경우 위에 설명된 대로 업그레이드된 클러스터를 부트스트래핑해야 합니다. 새로 업그레이드된 클러스터를 시작하기 전에 먼저 initial_master_nodes를 마스터 적격 노드의 이름 또는 IP 주소로 설정해야 합니다.

버전 6 및 이전 버전에서는 Zen Discovery의 동작을 discovery.zen.* 네임스페이스에 구성할 수 있는 몇 가지 다른 설정이 있습니다. 이러한 설정 중 일부는 더는 적용되지 않으며 제거되었습니다. 나머지 설정은 이름이 바뀌었습니다. 설정의 이름이 바뀐 경우, 이전 이름은 버전 7에서 사용되지 않으며 사용자는 새 이름을 사용하도록 다음과 같이 구성을 변경해야 합니다.

| 이전 이름 | 새 이름 | | --- | --- | | discovery.zen.ping.unicast.hosts | discovery.seed_hosts | | discovery.zen.hosts_provider | discovery.seed_providers | | discovery.zen.no_master_block | cluster.no_master_block |

새로운 클러스터 조정 하위 시스템에는 새로운 결함 감지 메커니즘이 포함되어 있습니다. 즉, discovery.zen.fd.* 네임스페이스의 Zen Discovery 결함 감지 설정은 더는 적용되지 않습니다. 대부분의 사용자는 버전 7 이상의 기본 결함 감지 구성을 사용해야 하지만, 구성을 변경해야 하는 경우에는 cluster.fault_detection.* 설정을 사용할 수 있습니다.

안전제일

Elasticsearch 7.0 이전 버전에서는 의도치 않게 클러스터의 일관성을 위태롭게 하는 일련의 단계를 수행하는 것이 허용되었습니다. 반면에 버전 7.0 이상에서는 안전하지 않은 작업을 수행하고 있다는 것을 분명히 인지하게 만들고 계속 진행하기를 원하는지 확인하는 단계를 거칩니다.

예를 들어 Elasticsearch 7.0 클러스터는 마스터 적격 노드의 절반 이상이 영구적으로 손실되는 경우 자동 복구를 수행하지 않습니다. 일반적으로 클러스터에는 3개의 마스터 적격 노드가 있어 이 중 하나가 손실되더라도 Elasticsearch가 가동 중단되지는 않습니다. 이 중 두 개가 영구적으로 손실되면 나머지 노드가 안전하게 진행할 수 없습니다.

Elasticsearch 7.0 이전 버전에서는 클러스터가 이러한 상황을 복구할 수 있도록 허용되었습니다. 사용자는 비어 있는 새로운 마스터 적격 노드를 시작해 손실된 노드를 모두 대체하여 클러스터를 다시 온라인 상태로 전환할 수 있습니다. 절반 이상이 영구 손실된 마스터 적격 노드를 자동 복구하는 것은 안전하지 않습니다. 나머지 노드 중에서 최신 클러스터 상태의 복사본을 가지고 있는 노드가 있다는 보장이 없기 때문입니다. 이는 데이터 손실로 이어질 수 있습니다. 예를 들어 샤드 복사본이 동기화 집합에서 제거되었을 수 있습니다. 나머지 노드 중에 이를 아는 노드가 없다면 오래된 샤드 복사본이 기본으로 할당될 수 있습니다. 여기에서 가장 위험한 것은 사용자가 자신의 클러스터를 위태롭게 하는 일련의 단계를 전혀 인지하지 못한다는 것입니다. 사용자가 일관되지 않은 무언가를 발견할 때까지 수주 또는 수개월이 걸릴 수 있습니다.

Elasticsearch 7.0 이후 버전에서는 안전하지 않은 이러한 동작이 훨씬 더 제한됩니다. 클러스터는 이러한 위험을 감수하기보다는 사용할 수 없는 상태를 유지하는 것을 선호하게 됩니다. 드물지만 백업이 없는 상황에서 절대적으로 필요한 경우에는 이러한 안전하지 않은 작업을 수행할 수 있습니다. 위험을 인지하고 있는지 확인하고 실수로 안전하지 않은 작업을 수행하는 것을 방지하기 위해 몇 가지 추가 단계가 필요합니다.

마스터 적격 노드의 절반 이상이 손실된 경우 먼저 손실된 마스터 적격 노드를 다시 온라인 상태로 전환해야 합니다. 노드의 데이터 디렉터리가 손상되지 않았다면 이러한 데이터 디렉터리를 사용하여 새 노드를 시작하는 것이 가장 좋습니다. 이것이 가능한 경우 클러스터는 최신 클러스터 상태를 사용하여 다시 안전하게 형성됩니다.

다음으로 시도해볼 수 있는 작업은 최근 스냅샷에서 클러스터를 복원하는 것입니다. 이렇게 하면 알고 있는 정상 상태로 클러스터를 복원할 수 있지만 스냅샷을 생성한 후에 기록된 데이터는 손실됩니다. 누락된 기간을 알고 있기 때문에 누락된 데이터를 다시 색인할 수 있습니다. 스냅샷은 증분식이므로 매우 자주 생성할 수 있습니다. 30분마다 스냅샷을 생성하여 이러한 복구에서 손실되는 데이터의 양을 제한하는 것은 드문 일이 아닙니다.

이러한 복구 작업 중 어느 것도 가능하지 않은 경우 최후의 수단은 elasticsearch-node라는 안전하지 않은 복구 도구를 사용하는 것입니다. 이는 시스템 관리자가 실행할 수 있는 명령줄 도구로, 소수 노드에서 오래된 마스터를 선택하는 등 안전하지 않은 작업을 수행할 수 있습니다. 일관성을 깨트릴 수 있는 단계를 명시적으로 수행하도록 함으로써 Elasticsearch 7.0은 일련의 안전하지 않은 작업을 통해 의도치 않게 데이터 손실이 발생할 위험을 제거합니다.

어떻게 작동하나요?

분산 시스템 이론에 익숙하다면 클러스터 조정을 분산 합의를 사용해 해결할 수 있는 문제의 하나로 이해할 수 있습니다.  Elasticsearch 개발이 시작되었을 때는 분산 합의가 널리 알려진 기술이 아니었지만 최근 몇 년 동안 놀라운 발전을 이루었습니다.

Zen Discovery는 분산 합의 알고리즘에서 많은 아이디어를 채택했지만, 이론이 규정하는 모델을 그대로 따르기보다는 유기적으로 적용했습니다. 또한, 시간 제한이 매우 보수적으로 설정되어 있어 때로는 장애 후 복구에 오랜 시간이 걸리기도 합니다. 7.0에서 새로운 클러스터 조정 하위 시스템을 도입함에 따라 이론적 모델을 훨씬 더 충실히 따를 수 있게 되었습니다.

분산 조정은 제대로 해결하기 어려운 문제로 알려져 있습니다. Elastic에서는 정확성과 안전성 측면에서 강력한 보증을 제공하는 자동화된 도구를 통해 정형 방법을 중점적으로 사용하여 디자인을 검증했습니다. Elasticsearch의 새로운 클러스터 조정 알고리즘의 공식 사양은 당사의 퍼블릭 Elasticsearch 정형 모델 리포지토리에서 확인할 수 있습니다. 알고리즘의 핵심 안전 모듈은 간단하고 간결하며, Elasticsearch 리포지토리의 정형 모델과 프로덕션 코드 간에는 직접적인 일대일 대응 관계가 있습니다.

Paxos, Raft, Zab, Viewstamped Replication(VR) 등 분산 합의 알고리즘 제품군을 잘 알고 있다면 핵심 안전 모듈이 친숙해 보일 것입니다. 재작성 가능한 단일 레지스터를 모델링하고 Paxos의 ballot, Raft의 용어, VR의 뷰와 유사한 마스터 용어 개념을 사용합니다. 핵심 안전 모듈 및 관련 정형 모델에는 클러스터 부트스트래핑, 노드 재시작에 걸친 지속성, 동적 재구성이 포함됩니다. 이 모든 기능은 시스템이 모든 환경에서 올바르게 작동하도록 하는 데 중요합니다.

이론적으로 강력한 이 핵심 기술을 기반으로 하여, 클러스터에 어떤 장애가 발생하더라도 네트워크가 복원되고 충분한 노드가 온라인으로 전환되면 마스터가 선출되고 클러스터 상태 업데이트를 게시할 수 있도록 활동성 계층을 구축했습니다. 활동성 계층은 몇 가지 최신 기술을 사용하여 많은 일반적인 문제를 피합니다. 선출 스케줄러는 적응형으로, 과도한 선출 경쟁을 피하기 위해 네트워크 상태에 따라 동작을 변경합니다. Raft 방식의 사전 투표는 선출될 가능성이 없는 투표를 시작되기 전에 억제하여 악성 노드로 인한 중단을 방지합니다. 지연 감지는 노드가 마스터보다 너무 뒤처질 경우 노드가 클러스터를 방해하지 못하게 합니다. 활성 양방향 결함 감지는 클러스터의 노드가 항상 상호 통신할 수 있도록 합니다. 대부분의 클러스터 상태 업데이트는 작은 diffs로 효율적으로 게시되므로 노드에서 노드로 전체 클러스터 상태를 복사할 필요가 없습니다. 원활하게 종료된 리더는 선택된 후임자에게 명시적으로 자리를 물려주어 전체 선출의 필요성을 제거함으로써 의도적인 장애 조치 동안 가동 중단 시간을 줄입니다. Elastic에서는 몇 초, 몇 분 또는 몇 시간 동안 지속될 수 있는 걷잡을 수 없는 중단의 영향을 효율적으로 시뮬레이션하기 위해 테스트 인프라를 개발했습니다. 따라서 중단이 해결되면 클러스터가 항상 신속하게 복구되는지 확인할 수 있습니다.

Raft를 사용하지 않는 이유는?

우리가 흔히 받는 질문은 왜 간단하게 Raft와 같은 표준 분산 합의 알고리즘을 ‘연결’하지 않았냐는 것입니다. 잘 알려진 알고리즘이 여러 개 있으며 각각 장단점이 있습니다. 우리는 찾을 수 있는 모든 문헌을 통해 신중하게 평가하고 영감을 얻었습니다. 초기에 진행했던 개념 증명 중 하나에서는 Raft와 매우 유사한 프로토콜을 사용했습니다. 우리는 이 경험을 통해 Elasticsearch와 완벽하게 통합하는 데 필요한 변경 사항이 상당히 많다는 것을 알게 되었습니다. 많은 표준 알고리즘에서 규정하는 일부 디자인 의사 결정 또한 Elasticsearch에는 최적이 아닙니다. 예를 들어 다음과 같습니다.

  • 표준 알고리즘은 작업 로그를 중심으로 구성되는 경우가 많은 반면, Elasticsearch의 클러스터 조정은 클러스터 상태 자체에 직접적인 기반을 두고 있습니다. 따라서 작업 기반일 때보다 훨씬 간단하게 배치 처리(관련 작업을 단일 브로드캐스트로 결합)와 같은 중요한 최적화가 가능합니다.
  • 표준 알고리즘은 클러스터를 확장하거나 축소할 수 있는 기능이 상당히 제한적인 경우가 많아 여러 유지 관리 작업을 수행하려면 일련의 단계가 필요한 반면, Elasticsearch의 클러스터 조정은 한 번에 안전하게 임의 재구성을 수행할 수 있습니다. 따라서 문제를 일으킬 수 있는 중간 상태를 피함으로써 주변 시스템을 간소화합니다.
  • 표준 알고리즘은 안전에 중점을 두고, 활동성을 보장하는 방법에 대한 세부 사항이 결정되어 있지 않으며, 비정상 노드를 발견한 경우 클러스터가 어떻게 대응해야 하는지를 설명하지 않습니다. Elasticsearch의 상태 확인은 수년간 현장에서 사용되고 다듬어져 왔기 때문에 복잡합니다. 그리고 우리에게는 기존 동작을 유지하는 것이 중요했습니다. 사실, 시스템의 안전 속성을 구현하는 것보다 활동성을 보장하는 데 훨씬 더 많은 노력이 들었습니다. 구현 작업 대부분이 시스템의 활동성 속성에 집중되었습니다.
  • 프로젝트의 목표 중 하나는 Zen Discovery를 실행하는 6.7 클러스터에서 새로운 조정 하위 시스템을 실행하는 버전 7 클러스터로 가동 중단 없는 롤링 업그레이드를 지원하는 것이었습니다. 표준 알고리즘을 채택해서는 이러한 롤링 업그레이드를 지원하는 것이 불가능해 보였습니다.

분산 합의 알고리즘 전체를 아주 높은 수준으로 구현하려면 개발에 상당한 노력이 필요하며 학술 문헌에 설명된 것 그 이상이 필요합니다. 실제로 사용자 지정 작업은 불가피하지만, 조정 프로토콜은 복잡하고 모든 사용자 지정 작업에는 오류가 발생할 위험이 있습니다. 엔지니어링 관점에서는 이러한 사용자 지정 작업을 새로운 프로토콜 개발과 동일하게 보는 것이 가장 타당했습니다.

요약

Elasticsearch 7.0에는 더 빠르고 더 안전하며 사용이 더 간편한 새로운 클러스터 조정 하위 시스템이 함께 제공됩니다. 버전 6.7에서부터 가동 중단 없는 롤링 업그레이드를 지원하며 복원력이 뛰어난 데이터 복제의 기반을 제공합니다. 새로운 클러스터 조정 하위 시스템을 사용해 보려면 최신 7.0 베타 릴리즈를 다운로드하고, 설명서를 참조하여 테스트해 본 후, 피드백을 보내주십시오.