Elasticsearch 클러스터 200TB 이상

많은 사람들이 Elasticsearch로 어려움을 겪고 있습니다. 하지만 이를 사용하여 "특히 큰 볼륨"에 로그를 저장하려는 경우 어떻게 될까요? 그리고 여러 데이터 센터 중 어느 하나의 장애를 경험하는 것도 고통스럽지 않습니까? 어떤 종류의 건축물을 만들어야 하며, 어떤 함정에 빠지게 될까요?

Odnoklassniki에서는 로그 관리 문제를 해결하기 위해 Elasticsearch를 사용하기로 결정했으며 이제 아키텍처와 함정에 관한 경험을 Habr과 공유합니다.

저는 Pyotr Zaitsev이고 Odnoklassniki에서 시스템 관리자로 일하고 있습니다. 그 전에는 Manticore Search, Sphinx 검색, Elasticsearch를 다루는 관리자이기도 했습니다. 아마도 또 다른 검색이 나타나면 나도 그 검색을 할 것입니다. 저는 또한 자발적으로 여러 오픈 소스 프로젝트에 참여하고 있습니다.

Odnoklassniki에 왔을 때 인터뷰에서 Elasticsearch로 일할 수 있다고 무모하게 말했습니다. 요령을 터득하고 몇 가지 간단한 작업을 마친 후, 당시 존재하던 로그 관리 시스템을 개편하는 큰 임무가 주어졌습니다.

요구 사항

시스템 요구 사항은 다음과 같이 공식화되었습니다.

• Graylog를 프런트엔드로 사용하기로 했습니다. 회사에서는 이미 이 제품을 사용해 본 경험이 있기 때문에 프로그래머와 테스터들은 이 제품을 알고 있었고 익숙하고 편리했습니다.
• 데이터 볼륨: 초당 평균 50~80개의 메시지이지만 문제가 발생하면 트래픽은 어떤 제한도 받지 않으며 초당 2~3백만 줄이 될 수 있습니다.
• 고객과 검색 쿼리 처리 속도에 대한 요구 사항을 논의한 결과 이러한 시스템을 사용하는 일반적인 패턴은 다음과 같다는 것을 깨달았습니다. 사람들은 지난 이틀 동안 애플리케이션 로그를 찾고 있으며 XNUMX시간 이상 기다리기를 원하지 않습니다. 두 번째는 공식화된 쿼리 결과입니다.
• 관리자들은 시스템 작동 방식을 자세히 알아볼 필요 없이 필요한 경우 시스템을 쉽게 확장할 수 있어야 한다고 주장했습니다.
• 따라서 이러한 시스템에 주기적으로 필요한 유일한 유지 관리 작업은 일부 하드웨어를 변경하는 것입니다.
• 또한 Odnoklassniki는 뛰어난 기술적 전통을 가지고 있습니다. 우리가 출시하는 모든 서비스는 데이터 센터 장애(갑작스럽고, 계획되지 않았으며, 언제든지)에도 살아남아야 합니다.

이 프로젝트를 구현할 때 마지막 요구 사항에 가장 많은 비용이 들었습니다. 이에 대해 더 자세히 설명하겠습니다.

수요일

우리는 XNUMX개의 데이터 센터에서 일하고 있지만 Elasticsearch 데이터 노드는 (기술적이지 않은 여러 가지 이유로) XNUMX개에만 위치할 수 있습니다.

이들 18개의 데이터 센터에는 하드웨어, 컨테이너, 가상 머신 등 약 XNUMX개의 다양한 로그 소스가 포함되어 있습니다.

중요한 기능: 클러스터가 컨테이너에서 시작됩니다. 포드 맨 실제 머신이 아니라 자체 클라우드 제품 one-cloud. 컨테이너는 2Ghz v2.0와 유사한 4개의 코어를 보장하며 유휴 상태인 경우 나머지 코어를 재활용할 수 있습니다.

다른 말로하면 :

토폴로지

처음에는 솔루션의 일반적인 형태를 다음과 같이 보았습니다.

• 3~4개의 VIP는 Graylog 도메인의 A 레코드 뒤에 있으며, 이는 로그가 전송되는 주소입니다.
• 각 VIP는 LVS 밸런서입니다.
• 그 후 로그는 Graylog 배터리로 이동하고 일부 데이터는 GELF 형식이고 일부는 syslog 형식입니다.
• 그런 다음 이 모든 내용이 Elasticsearch 코디네이터 배터리에 대규모 배치로 기록됩니다.
• 그리고 관련 데이터 노드에 쓰기 및 읽기 요청을 보냅니다.

전문 용어

아마도 모든 사람이 용어를 자세히 이해하는 것은 아니므로 조금 더 자세히 설명하고 싶습니다.

Elasticsearch에는 마스터, 코디네이터, 데이터 노드 등 여러 유형의 노드가 있습니다. 서로 다른 로그 변환 및 서로 다른 클러스터 간의 통신을 위한 두 가지 다른 유형이 있지만 우리는 나열된 유형만 사용했습니다.

마스터
클러스터에 있는 모든 노드를 ping하고, 최신 클러스터 맵을 유지 관리하고, 이를 노드 간에 배포하고, 이벤트 로직을 처리하고, 다양한 종류의 클러스터 전체 관리를 수행합니다.

조정자
단일 작업을 수행합니다. 클라이언트의 읽기 또는 쓰기 요청을 수락하고 이 트래픽을 라우팅합니다. 쓰기 요청이 있는 경우 마스터에게 관련 인덱스의 어떤 샤드를 넣어야 하는지 묻고 요청을 추가로 리디렉션할 것입니다.

데이터 노드
데이터를 저장하고, 외부에서 들어오는 검색 쿼리를 수행하며, 해당 데이터에 있는 샤드에 대한 작업을 수행합니다.

그레이로그
이는 ELK 스택에서 Kibana와 Logstash를 융합한 것과 같습니다. Graylog는 UI와 로그 처리 파이프라인을 모두 결합합니다. 내부적으로 Graylog는 Kafka 및 Zookeeper를 실행하여 Graylog에 대한 연결을 클러스터로 제공합니다. Graylog는 Elasticsearch를 사용할 수 없는 경우 로그(Kafka)를 캐시하고 실패한 읽기 및 쓰기 요청을 반복하고 지정된 규칙에 따라 로그를 그룹화하고 표시할 수 있습니다. Logstash와 마찬가지로 Graylog에는 행을 Elasticsearch에 쓰기 전에 수정하는 기능이 있습니다.

또한 Graylog에는 사용 가능한 하나의 Elasticsearch 노드를 기반으로 전체 클러스터 맵을 얻고 이를 특정 태그로 필터링할 수 있는 내장 서비스 검색 기능이 있어 특정 컨테이너에 요청을 전달할 수 있습니다.

시각적으로 다음과 같습니다.

특정 인스턴스의 스크린샷입니다. 여기에서는 검색어를 기반으로 히스토그램을 작성하고 관련 행을 표시합니다.

지수

시스템 아키텍처로 돌아가서 모든 것이 올바르게 작동하도록 인덱스 모델을 구축한 방법에 대해 더 자세히 설명하고 싶습니다.

위 다이어그램에서 이는 가장 낮은 수준인 Elasticsearch 데이터 노드입니다.

인덱스는 Elasticsearch 샤드로 구성된 대규모 가상 엔터티입니다. 그 자체로 각 샤드는 Lucene 인덱스에 지나지 않습니다. 그리고 각 Lucene 인덱스는 하나 이상의 세그먼트로 구성됩니다.

설계할 때 우리는 대량의 데이터에 대한 읽기 속도 요구 사항을 충족하려면 이 데이터를 데이터 노드 전체에 고르게 "분산"해야 한다고 생각했습니다.

이로 인해 인덱스당 샤드(복제본 포함) 수가 데이터 노드 수와 엄격하게 동일해야 한다는 사실이 나타났습니다. 첫째, 복제 인수가 XNUMX가 되도록 보장하기 위해(즉, 클러스터의 절반을 잃을 수 있음) 둘째, 클러스터의 절반 이상에서 읽기 및 쓰기 요청을 처리합니다.

먼저 보관 기간을 30일로 결정했습니다.

샤드의 분포는 다음과 같이 그래픽으로 표현될 수 있습니다.

어두운 회색 직사각형 전체가 색인입니다. 왼쪽 빨간색 사각형은 인덱스의 첫 번째 샤드인 기본 샤드입니다. 그리고 파란색 사각형은 복제 파편입니다. 서로 다른 데이터 센터에 위치해 있습니다.

다른 샤드를 추가하면 세 번째 데이터 센터로 이동됩니다. 그리고 결국 우리는 데이터 일관성을 잃지 않고 DC를 잃을 수 있는 다음 구조를 얻습니다.

인덱스 회전, 즉 새 인덱스를 생성하고 가장 오래된 인덱스를 삭제하여 48시간으로 설정했습니다(인덱스 사용 패턴에 따라 최근 48시간이 가장 자주 검색됩니다).

이 인덱스 회전 간격은 다음과 같은 이유로 인해 발생합니다.

특정 데이터 노드에 검색 요청이 도착하면 성능 관점에서 볼 때 그 크기가 노드의 엉덩이 크기와 비슷할 경우 하나의 샤드를 쿼리하는 것이 더 유리합니다. 이를 통해 인덱스의 "핫" 부분을 힙에 유지하고 빠르게 액세스할 수 있습니다. "핫파트"가 많으면 인덱스 검색 속도가 저하됩니다.

노드가 하나의 샤드에서 검색 쿼리를 실행하기 시작하면 물리적 시스템의 하이퍼스레딩 코어 수와 동일한 수의 스레드를 할당합니다. 검색 쿼리가 다수의 샤드에 영향을 미치는 경우 스레드 수가 비례적으로 늘어납니다. 이는 검색 속도에 부정적인 영향을 미치고 새 데이터의 인덱싱에 부정적인 영향을 미칩니다.

필요한 검색 대기 시간을 제공하기 위해 SSD를 사용하기로 결정했습니다. 요청을 신속하게 처리하려면 이러한 컨테이너를 호스팅하는 시스템에 코어가 56개 이상 있어야 했습니다. 56이라는 숫자는 Elasticsearch가 작업 중에 생성할 스레드 수를 결정하는 조건부 충분 값으로 선택되었습니다. Elasitcsearch에서 많은 스레드 풀 매개변수는 사용 가능한 코어 수에 직접적으로 의존하며, 이는 "더 적은 코어 - 더 많은 노드" 원칙에 따라 클러스터에 필요한 노드 수에 직접적인 영향을 미칩니다.

그 결과, 평균적으로 샤드 하나의 무게는 약 20GB이고, 인덱스당 샤드 수는 1개라는 것을 알아냈습니다. 따라서 360시간마다 한 번씩 교체하면 48개가 됩니다. 각 인덱스에는 15일 동안의 데이터가 포함됩니다.

데이터 쓰기 및 읽기 회로

이 시스템에서 데이터가 어떻게 기록되는지 알아 보겠습니다.

Graylog에서 코디네이터에게 일부 요청이 도착했다고 가정해 보겠습니다. 예를 들어 2~3개의 행을 색인화하려고 합니다.

Graylog로부터 요청을 받은 코디네이터는 마스터에게 "인덱싱 요청에서 인덱스를 구체적으로 지정했지만 이를 작성할 샤드가 지정되지 않았습니다."라고 질문합니다.

마스터는 "이 정보를 샤드 번호 71에 기록하세요"라고 응답한 후 기본 샤드 번호 71이 있는 관련 데이터 노드로 직접 전송됩니다.

그런 다음 트랜잭션 로그는 다른 데이터 센터에 있는 복제본 샤드로 복제됩니다.

Graylog에서 코디네이터에게 검색 요청이 도착합니다. 코디네이터는 인덱스에 따라 이를 리디렉션하는 반면 Elasticsearch는 라운드 로빈 원칙을 사용하여 기본 샤드와 복제본 샤드 간에 요청을 분산합니다.

180개의 노드는 고르지 않게 응답하며, 응답하는 동안 코디네이터는 더 빠른 데이터 노드에 의해 이미 "뱉어낸" 정보를 축적하고 있습니다. 그 후 모든 정보가 도착하거나 요청이 시간 초과에 도달하면 모든 정보가 클라이언트에 직접 제공됩니다.

이 전체 시스템은 평균적으로 지난 48시간 동안의 검색 쿼리를 300-400ms 내에 처리합니다. 단, 앞에 와일드카드가 있는 쿼리는 제외됩니다.

Elasticsearch를 사용한 꽃: Java 설정

모든 것이 원래 원했던 방식으로 작동하도록 하기 위해 클러스터의 다양한 항목을 디버깅하는 데 매우 오랜 시간을 보냈습니다.

발견된 문제의 첫 번째 부분은 Elasticsearch에서 Java가 기본적으로 사전 구성되는 방식과 관련이 있었습니다.

첫 번째 문제
Lucene 수준에서 백그라운드 작업이 실행 중일 때 Lucene 세그먼트 병합이 오류와 함께 실패한다는 보고가 매우 많이 관찰되었습니다. 동시에 로그에는 이것이 OutOfMemoryError 오류라는 것이 분명했습니다. 우리는 원격 측정을 통해 엉덩이가 자유로운 것을 보았으며 이 작업이 실패한 이유는 명확하지 않았습니다.

Lucene 지수 병합은 엉덩이 외부에서 발생하는 것으로 나타났습니다. 그리고 컨테이너는 소비되는 리소스 측면에서 매우 엄격하게 제한됩니다. 힙만 이러한 리소스에 들어갈 수 있으며(heap.size 값은 대략 RAM과 동일함) 일부 오프 힙 작업은 어떤 이유로 제한 이전에 남아 있는 ~500MB에 맞지 않으면 메모리 할당 오류로 인해 충돌이 발생했습니다.

수정 사항은 매우 간단했습니다. 컨테이너에 사용할 수 있는 RAM의 양이 증가한 후 우리는 그러한 문제가 있다는 사실조차 잊어버렸습니다.

문제 XNUMX
클러스터 시작 후 4~5일 후에 데이터 노드가 주기적으로 클러스터에서 빠져나오고 10~20초 후에 클러스터에 들어가기 시작하는 것을 확인했습니다.

우리가 그것을 알아내기 시작했을 때 Elasticsearch의 이 오프 힙 메모리는 어떤 방식으로도 제어되지 않는다는 것이 밝혀졌습니다. 컨테이너에 더 많은 메모리를 할당했을 때 직접 버퍼 풀을 다양한 정보로 채울 수 있었고 Elasticsearch에서 명시적 GC가 시작된 후에야 메모리가 지워졌습니다.

어떤 경우에는 이 작업에 꽤 오랜 시간이 걸렸으며 이 시간 동안 클러스터는 이 노드를 이미 종료된 것으로 표시했습니다. 이 문제는 잘 설명되어 있습니다. 여기에.

해결책은 다음과 같습니다. 이러한 작업을 위해 힙 외부의 대량 메모리를 사용하는 Java의 기능을 제한했습니다. 이를 16GB(-XX:MaxDirectMemorySize=16g)로 제한하여 명시적 GC가 훨씬 더 자주 호출되고 훨씬 빠르게 처리되어 더 이상 클러스터가 불안정해지지 않도록 했습니다.

문제 XNUMX
“가장 예상치 못한 순간에 노드가 클러스터를 떠나는” 문제가 끝났다고 생각한다면 착각입니다.

인덱스로 작업을 구성할 때 mmapfs를 선택했습니다. 검색 시간을 줄이다 훌륭한 세분화를 갖춘 신선한 샤드에 있습니다. 이는 mmapfs를 사용할 때 파일이 RAM에 매핑된 다음 매핑된 파일로 작업하기 때문에 큰 실수였습니다. 이로 인해 GC가 애플리케이션의 스레드를 중지하려고 하면 매우 오랜 시간 동안 safepoint로 이동하고 그곳으로 가는 도중에 애플리케이션이 마스터의 살아 있는지 여부에 대한 요청에 대한 응답을 중지하는 것으로 나타났습니다. . 따라서 마스터는 해당 노드가 더 이상 클러스터에 존재하지 않는다고 믿습니다. 그 후 5~10초 후에 가비지 수집기가 작동하고 노드가 활성화되어 다시 클러스터에 들어가 샤드 초기화를 시작합니다. 그것은 모두 "우리가 마땅히 받아야 할 제작물"처럼 느껴졌고 진지한 것에는 적합하지 않았습니다.

이 동작을 없애기 위해 먼저 표준 niofs로 전환한 다음 Elastic의 다섯 번째 버전에서 여섯 번째 버전으로 마이그레이션할 때 hybridfs를 시도했지만 이 문제는 재현되지 않았습니다. 저장소 유형에 대해 자세히 알아볼 수 있습니다. 여기에.

문제 XNUMX
그리고 우리가 기록적인 시간 동안 다루었던 또 다른 매우 흥미로운 문제가 있었습니다. 패턴이 전혀 이해가 안 되기 때문에 2~3개월 동안 잡았습니다.

때때로 우리 코디네이터는 보통 점심 식사 후에 Full GC에 갔다가 다시는 돌아오지 않았습니다. 동시에 GC 지연을 기록할 때 다음과 같이 보였습니다. 모든 것이 잘 진행되고 있었는데 갑자기 모든 것이 매우 나빠졌습니다.

처음에 우리는 코디네이터를 작업 모드에서 종료시키는 일종의 요청을 실행하는 사악한 사용자가 있다고 생각했습니다. 우리는 무슨 일이 일어나고 있는지 파악하기 위해 매우 오랫동안 요청을 기록했습니다.

그 결과, 사용자가 대규모 요청을 시작하고 특정 Elasticsearch 코디네이터에 도달하는 순간 일부 노드는 다른 노드보다 더 오래 응답하는 것으로 나타났습니다.

그리고 코디네이터는 모든 노드의 응답을 기다리는 동안 이미 응답한 노드들로부터 전송된 결과를 누적한다. GC의 경우 이는 힙 사용 패턴이 매우 빠르게 변한다는 것을 의미합니다. 그리고 우리가 사용한 GC는 이 작업을 처리할 수 없었습니다.

이 상황에서 클러스터의 동작을 변경하기 위해 찾은 유일한 수정 사항은 JDK13으로 마이그레이션하고 Shenandoah 가비지 수집기를 사용하는 것입니다. 이로 인해 문제가 해결되었고 코디네이터가 넘어지는 것을 멈췄습니다.

여기서 Java 문제가 끝나고 대역폭 문제가 시작되었습니다.

Elasticsearch를 사용한 "베리": 처리량

처리량 문제는 클러스터가 안정적으로 작동한다는 것을 의미하지만, 색인된 문서 수가 최고조에 달하고 조작 중에는 성능이 부족합니다.

첫 번째 증상: 프로덕션 중 일부 "폭발" 중에 매우 많은 수의 로그가 갑자기 생성되면 인덱싱 오류 es_rejected_execution이 Graylog에서 자주 깜박이기 시작합니다.

이는 Elasticsearch가 인덱싱 요청을 처리하고 정보를 디스크의 샤드에 업로드할 수 있을 때까지 하나의 데이터 노드에 있는 thread_pool.write.queue가 기본적으로 200개의 요청만 캐시할 수 있다는 사실 때문이었습니다. 그리고 Elasticsearch 문서 이 매개변수에 대해서는 알려진 바가 거의 없습니다. 최대 스레드 수와 기본 크기만 표시됩니다.

물론 우리는 이 값을 비틀어 다음과 같은 사실을 발견했습니다. 특히 우리 설정에서는 최대 300개의 요청이 상당히 잘 캐시되고 더 높은 값은 다시 Full GC로 이동한다는 사실로 가득 차 있습니다.

또한 이는 하나의 요청 내에 도착하는 메시지 배치이기 때문에 자주, 작은 배치로 쓰지 않고 대규모 배치로 쓰거나 배치가 아직 완료되지 않은 경우 3초에 한 번씩 쓰도록 Graylog를 조정해야 했습니다. 이 경우 Elasticsearch에 작성한 정보는 XNUMX초가 아니라 XNUMX초(우리에게 매우 적합함)에 사용할 수 있게 되지만, 대규모 프로세스를 통과하기 위해 만들어야 하는 재트레이 횟수가 많은 것으로 나타났습니다. 정보의 스택이 줄어듭니다.

이는 어딘가에서 충돌이 발생하여 이에 대해 격렬하게 보고하는 순간에 특히 중요합니다. 이렇게 하면 완전히 스팸 처리된 Elastic을 얻지 못하고 일정 시간이 지나면 막힌 버퍼로 인해 작동할 수 없는 Graylog 노드를 방지할 수 있습니다.

또한 생산이 이와 같이 폭발적으로 증가했을 때 프로그래머와 테스터로부터 불만을 접수했습니다. 실제로 이러한 로그가 필요한 순간에 로그가 매우 느리게 제공되었습니다.

그들은 그것을 알아내기 시작했습니다. 한편으로는 검색 쿼리와 인덱싱 쿼리가 본질적으로 동일한 물리적 시스템에서 처리되었으며 어떤 식으로든 특정 단점이 있을 것이 분명했습니다.

그러나 이는 Elasticsearch의 여섯 번째 버전에서 무작위 라운드 로빈 원칙(인덱싱을 수행하고 기본 데이터를 보관하는 컨테이너)에 따르지 않고 관련 데이터 노드 간에 쿼리를 배포할 수 있는 알고리즘이 등장했기 때문에 부분적으로 우회될 수 있습니다. 샤드는 매우 바쁠 수 있으므로 빠르게 응답할 방법이 없습니다. 하지만 이 요청을 복제본 샤드를 사용하여 로드가 적은 컨테이너에 전달하면 훨씬 빠르게 응답합니다. 즉, use_adaptive_replica_selection: true에 도달했습니다.

독서 그림은 다음과 같이 보이기 시작합니다.

이 알고리즘으로 전환하면 작성할 로그 흐름이 많을 때 쿼리 시간이 크게 향상될 수 있었습니다.

마지막으로, 가장 큰 문제는 데이터 센터를 쉽게 제거하는 것이었습니다.

하나의 DC와의 연결이 끊어진 직후 클러스터에서 원하는 것:

• 실패한 데이터 센터에 현재 마스터가 있는 경우 다시 선택되어 다른 DC의 다른 노드로 역할로 이동됩니다.
• 마스터는 클러스터에서 액세스할 수 없는 모든 노드를 신속하게 제거합니다.
• 나머지 데이터 센터를 기반으로 그는 손실된 데이터 센터에 이러한 주요 샤드가 있었고 나머지 데이터 센터에서 보완적인 복제본 샤드를 신속하게 승격하고 데이터 인덱싱을 계속할 것이라는 점을 이해할 것입니다.
• 결과적으로 클러스터의 쓰기 및 읽기 처리량은 점차 저하되지만 일반적으로 모든 것이 느리지만 안정적으로 작동합니다.

결과적으로 우리는 다음과 같은 것을 원했습니다.

그리고 우리는 다음을 얻었습니다:

어떻게 된거야?

데이터 센터가 무너지자 우리 마스터가 병목 현상을 겪었습니다.

이유는 무엇입니까?

사실 마스터에는 클러스터의 특정 작업 및 이벤트 배포를 담당하는 TaskBatcher가 있습니다. 모든 노드 종료, 복제본에서 기본으로의 샤드 승격, 어딘가에 샤드를 생성하는 모든 작업 등이 모두 먼저 TaskBatcher로 이동하여 하나의 스레드에서 순차적으로 처리됩니다.

하나의 데이터 센터가 철수될 당시, 남아 있는 데이터 센터의 모든 데이터 노드는 마스터에게 "우리는 이런 샤드와 저런 데이터 노드를 잃었습니다"라고 알리는 것을 자신의 의무로 간주한 것으로 나타났습니다.

동시에, 살아남은 데이터 노드는 이 모든 정보를 현재 마스터에게 보내고 그가 이를 수락했다는 확인을 기다리려고 했습니다. 주인이 대답할 수 있는 것보다 더 빨리 작업을 받았기 때문에 그들은 이것을 기다리지 않았습니다. 노드는 반복되는 요청 시간을 초과했으며 이때 마스터는 응답을 시도조차하지 않고 우선 순위에 따라 요청을 정렬하는 작업에 완전히 몰두했습니다.

터미널 형태에서는 데이터 노드가 전체 GC로 이동하는 지점까지 마스터에 스팸을 보낸 것으로 나타났습니다. 그 후 우리의 마스터 역할은 다음 노드로 이동했고 완전히 동일한 일이 발생했으며 결과적으로 클러스터가 완전히 붕괴되었습니다.

측정 결과, 이 문제가 수정된 버전 6.4.0 이전에는 클러스터를 완전히 종료하려면 10개 중 360개의 데이터 노드만 동시에 출력하는 것으로 충분했습니다.

그것은 다음과 같이 보였습니다:

이 끔찍한 버그가 수정된 버전 6.4.0 이후에는 데이터 노드가 마스터 종료를 중단했습니다. 하지만 그것이 그를 "더 똑똑하게" 만들지는 못했습니다. 즉, 2개, 3개 또는 10개(XNUMX개 이외의 모든 수)의 데이터 노드를 출력하면 마스터는 노드 A가 떠났다는 첫 번째 메시지를 수신하고 노드 B, 노드 C, 노드 D에 이에 대해 알리려고 합니다.

그리고 현재 이 문제는 누군가에게 무언가를 알리려는 시도에 대해 약 20-30초의 시간 초과를 설정하여 클러스터 밖으로 이동하는 데이터 센터의 속도를 제어함으로써만 처리될 수 있습니다.

원칙적으로 이는 프로젝트의 일부로 최종 제품에 처음 제시된 요구 사항에 부합하지만 "순수 과학"의 관점에서 보면 이는 버그입니다. 그건 그렇고, 버전 7.2에서 개발자가 성공적으로 수정했습니다.

더욱이, 특정 데이터 노드가 나가면, 그 출구에 대한 정보를 전파하는 것이 전체 클러스터에 그러한 기본 샤드가 있다고 알리는 것보다 더 중요하다는 것이 밝혀졌습니다(다른 데이터에서 복제본 샤드를 승격시키기 위해). 기본 센터에 정보가 기록될 수 있습니다).

따라서 모든 것이 이미 중단된 경우 릴리스된 데이터 노드는 즉시 오래된 것으로 표시되지 않습니다. 따라서 우리는 해제된 데이터 노드에 대한 모든 핑 시간이 초과될 때까지 기다려야 하며, 그 후에야 클러스터가 정보 기록을 계속해야 한다고 알려주기 시작합니다. 이에 대해 더 자세히 읽을 수 있습니다. 여기에.

그 결과 오늘 데이터센터 철수 작업은 출퇴근 시간에 5분 정도 소요된다. 그렇게 크고 서투른 거상에게는 이것은 꽤 좋은 결과입니다.

그 결과, 우리는 다음과 같은 결정을 내렸습니다.

• 우리는 360GB 디스크를 갖춘 700개의 데이터 노드를 보유하고 있습니다.
• 동일한 데이터 노드를 통해 트래픽을 라우팅하기 위한 60개의 코디네이터.
• 40 이전 버전부터 일종의 유산으로 남겨둔 마스터 6.4.0개 - 데이터센터 철수에도 살아남기 위해, 마스터 정족수 확보를 위해 몇 대의 머신을 잃을 수도 있다는 정신적 준비가 되어 있었다. 최악의 시나리오
• 하나의 컨테이너에서 역할을 결합하려는 모든 시도는 조만간 노드가 부하로 인해 중단된다는 사실에 직면했습니다.
• 전체 클러스터는 31GB의 heap.size를 사용합니다. 크기를 줄이려는 모든 시도는 앞에 와일드카드를 사용한 과도한 검색 쿼리에서 일부 노드를 종료하거나 Elasticsearch 자체에서 회로 차단기를 가져오는 결과를 가져왔습니다.
• 또한 검색 성능을 보장하기 위해 마스터에서 발생하는 병목 현상에서 가능한 적은 이벤트를 처리하기 위해 클러스터의 개체 수를 가능한 한 적게 유지하려고 노력했습니다.

마지막으로 모니터링에 대해

이 모든 것이 의도한 대로 작동하는지 확인하기 위해 우리는 다음을 모니터링합니다.

• 각 데이터 노드는 클라우드에 자신이 존재하며 그러한 샤드가 있음을 보고합니다. 우리가 어딘가에서 무언가를 끄면 클러스터는 2~3초 후에 센터 A에서 노드 2, 3, 4를 끄었다고 보고합니다. 이는 다른 데이터 센터에서는 어떤 상황에서도 샤드가 하나만 있는 노드를 끌 수 없다는 것을 의미합니다. 왼쪽.
• 마스터 행동의 성격을 알면서 우리는 대기 중인 작업의 수를 매우 주의 깊게 살펴봅니다. 하나의 멈춘 작업이라도 시간 초과가 발생하지 않으면 이론적으로 일부 긴급 상황에서는 예를 들어 기본 복제본의 복제본 샤드 승격이 작동하지 않아 인덱싱 작동이 중지될 수 있습니다.
• 또한 최적화 과정에서 이미 큰 어려움을 겪었기 때문에 가비지 수집기 지연도 매우 자세히 살펴봅니다.
• 병목 현상이 발생하는 위치를 미리 파악하기 위해 스레드별로 거부합니다.
• 힙, RAM, I/O와 같은 표준 메트릭입니다.

모니터링을 구축할 때 Elasticsearch의 스레드 풀 기능을 고려해야 합니다. Elasticsearch 문서 검색 및 인덱싱을 위한 구성 옵션 및 기본값을 설명하지만 thread_pool.management에 대해서는 전혀 설명하지 않습니다. 이러한 스레드는 특히 _cat/shards 및 기타 유사한 쿼리를 처리하므로 모니터링 작성 시 사용하기 편리합니다. 클러스터가 클수록 단위 시간당 더 많은 요청이 실행되며 앞서 언급한 thread_pool.management는 공식 문서에 표시되지 않을 뿐만 아니라 기본적으로 5개의 스레드로 제한되어 있으며 이후 매우 빠르게 폐기됩니다. 어떤 모니터링이 제대로 작동하지 않는지.

결론적으로 말하고 싶은 것은: 우리가 해냈다! 우리는 프로그래머와 개발자에게 거의 모든 상황에서 프로덕션에서 일어나는 일에 대한 정보를 빠르고 안정적으로 제공할 수 있는 도구를 제공할 수 있었습니다.

예, 꽤 복잡한 것으로 판명되었지만 그럼에도 불구하고 우리는 우리가 원하는 것을 기존 제품에 적용할 수 있었기 때문에 패치하고 다시 작성할 필요가 없었습니다.

출처 : habr.com