Bioyino - 분산되고 확장 가능한 측정항목 수집기

따라서 측정항목을 수집합니다. 우리처럼. 우리는 또한 지표를 수집합니다. 물론 사업상 필요합니다. 오늘 우리는 모니터링 시스템의 첫 번째 링크인 statsd 호환 집계 서버에 대해 이야기하겠습니다. 비오이노, 우리가 그것을 쓴 이유와 Brubeck을 포기한 이유.

이전 기사에서 (1, 2) 얼마 전까지 우리는 다음을 사용하여 점수를 수집했다는 것을 알 수 있습니다. 브루벡. C로 작성되었습니다. 코드 관점에서 볼 때 이는 플러그만큼 간단하며(기여하려는 경우 중요함) 가장 중요한 것은 최대 2만 MPS(초당 메트릭) 볼륨을 처리한다는 것입니다. 아무 문제 없이. 설명서에는 별표가 표시된 4만 MPS 지원이 명시되어 있습니다. 이는 Linux에서 네트워크를 올바르게 구성하면 명시된 수치를 얻을 수 있음을 의미합니다. (네트워크를 그대로 두면 얼마나 많은 MPS를 얻을 수 있는지 알 수 없습니다). 이러한 장점에도 불구하고 우리는 브루벡에 대해 몇 가지 심각한 불만을 제기했습니다.

주장 1. 프로젝트 개발자인 Github는 패치 및 수정 사항 게시, 우리와 (우리뿐만 아니라) PR을 수락하는 등 지원을 중단했습니다. 지난 몇 달 동안(2018년 2월~XNUMX월경) 활동이 재개되었지만 그 전에는 거의 XNUMX년 동안 완전히 평온했습니다. 또한 프로젝트가 개발 중입니다. 내부 Gihub 요구 사항에 맞게, 이는 새로운 기능 도입에 심각한 장애물이 될 수 있습니다.

주장 2. 계산의 정확성. Brubeck은 집계를 위해 총 65536개의 값을 수집합니다. 우리의 경우 일부 지표의 경우 집계 기간(30초) 동안 훨씬 더 많은 값이 도착할 수 있습니다(최고 1개). 이 샘플링 결과 최대값과 최소값은 쓸모없어 보입니다. 예를 들어 다음과 같습니다.

그대로

어땠어야 했는데?

같은 이유로 금액은 일반적으로 잘못 계산됩니다. 여기에 32비트 부동 오버플로 버그를 추가하면 일반적으로 겉보기에 무해한 측정항목을 수신할 때 서버를 세그폴트로 보내 모든 것이 훌륭해집니다. 그런데 버그는 수정되지 않았습니다.

그리고 마지막으로, 클레임 X. 이 글을 쓰는 시점에서 우리가 찾을 수 있었던 대략 14개의 작동하는 statsd 구현 모두에 이를 제공할 준비가 되었습니다. 일부 단일 인프라가 너무 많이 성장하여 4만 MPS를 수용하는 것만으로는 더 이상 충분하지 않다고 가정해 보겠습니다. 또는 아직 성장하지 않았더라도 측정항목이 이미 너무 중요해서 차트가 2~3분 정도만 하락해도 이미 중요해져서 관리자들 사이에 극복할 수 없는 우울증을 유발할 수 있습니다. 우울증 치료는 고마운 일이기 때문에 기술적 해결책이 필요합니다.

첫째, 서버에 갑작스러운 문제가 발생해도 사무실에 정신병적인 좀비 대재앙이 발생하지 않도록 내결함성입니다. 둘째, Linux 네트워크 스택을 깊이 파고들지 않고 필요한 크기로 "폭"을 조용히 확장하지 않고도 4만 MPS 이상을 수용할 수 있도록 확장할 수 있습니다.

확장할 여지가 있었기 때문에 내결함성부터 시작하기로 결정했습니다. "에 대한! 결함 허용! 간단해요. 할 수 있어요.”라고 생각하고 서버 2대를 시작하여 각각에 brubeck 사본을 올렸습니다. 이를 위해 우리는 메트릭이 포함된 트래픽을 두 서버 모두에 복사하고 이에 대해 작성해야 했습니다. 작은 유틸리티. 우리는 이것으로 내결함성 문제를 해결했지만... 별로 좋지는 않았습니다. 처음에는 모든 것이 훌륭해 보였습니다. 각 brubeck은 자체 집계 버전을 수집하고 30초마다 한 번씩 Graphite에 데이터를 쓰고 이전 간격을 덮어씁니다(이 작업은 Graphite 측에서 수행됨). 한 서버가 갑자기 실패하면 항상 집계된 데이터의 자체 복사본이 있는 두 번째 서버가 있습니다. 하지만 여기에 문제가 있습니다. 서버가 실패하면 그래프에 "톱"이 나타납니다. 이는 brubeck의 30초 간격이 동기화되지 않고 충돌이 발생하는 순간 그 중 하나가 덮어쓰여지지 않기 때문입니다. 두 번째 서버가 시작되면 동일한 일이 발생합니다. 꽤 견딜만하지만 더 나은 것을 원합니다! 확장성 문제도 사라지지 않았습니다. 모든 지표는 여전히 단일 서버로 "이동"하므로 네트워크 수준에 따라 동일한 2만~4만 MPS로 제한됩니다.

문제에 대해 조금 생각하고 동시에 삽으로 눈을 파면 다음과 같은 분명한 아이디어가 떠오를 수 있습니다. 분산 모드에서 작동할 수 있는 통계가 필요하다는 것입니다. 즉, 시간과 메트릭의 노드 간 동기화를 구현하는 것입니다. “물론 그러한 솔루션은 이미 존재할 것입니다.”라고 말하고 Google을 방문했습니다… 그리고 그들은 아무것도 발견하지 못했습니다. 다양한 통계에 대한 문서를 살펴본 후(https://github.com/etsy/statsd/wiki#server-implementations 11.12.2017년 XNUMX월 XNUMX일 현재) 전혀 발견된 바가 없습니다. 분명히 이러한 솔루션의 개발자나 사용자 모두 아직까지 많은 측정 항목을 접하지 못했습니다. 그렇지 않으면 분명히 뭔가를 생각해 낼 것입니다.

그런 다음 우리는 재미를 위해 해커톤(프로젝트 이름은 해커톤 시작 전에 스크립트에 의해 생성됨)에서 작성된 "장난감" 통계인 bioyino에 대해 기억하고 우리 자신의 통계가 시급히 필요하다는 것을 깨달았습니다. 무엇을 위해?

• 세상에는 statsd 클론이 너무 적기 때문에
• 원하는 또는 원하는 수준에 가까운 내결함성 및 확장성을 제공할 수 있기 때문입니다(서버 간에 집계된 메트릭 동기화 및 전송 충돌 문제 해결 포함).
• Brubeck보다 더 정확하게 지표를 계산할 수 있기 때문입니다.
• brubeck이 실제로 제공하지 못한 더 자세한 통계를 직접 수집할 수 있기 때문에,
• 다른 유사한 하이퍼포의 아키텍처를 완전히 반복하지 않는 나만의 하이퍼퍼포먼스 분산 규모 랩 애플리케이션을 프로그래밍할 기회가 있었기 때문입니다... 음, 그게 전부입니다.

무엇을 쓸까? 물론 러스트에서요. 왜?

• 이미 프로토타입 솔루션이 있었기 때문에
• 그 기사의 저자는 그 당시 이미 Rust를 알고 있었고 그것을 오픈 소스에 넣을 기회와 함께 생산을 위해 그 안에 무언가를 쓰고 싶어했기 때문입니다.
• GC가 있는 언어는 수신되는 트래픽의 특성(거의 실시간)으로 인해 우리에게 적합하지 않으며 GC 일시 중지는 사실상 허용되지 않기 때문입니다.
• C에 필적하는 최대 성능이 필요하기 때문에
• Rust는 우리에게 두려움 없는 동시성을 제공하기 때문에 C/C++로 작성하기 시작했다면 brubeck보다 훨씬 더 많은 취약점, 버퍼 오버플로, 경쟁 조건 및 기타 무서운 단어를 긁어모았을 것입니다.

Rust에 대한 논쟁도있었습니다. 회사는 Rust로 프로젝트를 생성한 경험이 없었으며 이제 이를 메인 프로젝트에서도 사용할 계획이 없습니다. 따라서 아무것도 해결되지 않을 것이라는 심각한 두려움이 있었지만 우리는 기회를 잡기로 결정하고 시도했습니다.

시간이 지났다...

마침내 몇 번의 시도 실패 끝에 첫 번째 작업 버전이 준비되었습니다. 무슨 일이에요? 이것이 일어난 일입니다.

각 노드는 자체 측정항목 세트를 수신하여 누적하며, 최종 집계에 전체 세트가 필요한 유형에 대해서는 측정항목을 집계하지 않습니다. 노드는 일종의 분산 잠금 프로토콜에 의해 서로 연결되어 있으며, 이를 통해 Great One에 메트릭을 보낼 가치가 있는 유일한 노드(여기서 우리는 울었습니다)를 선택할 수 있습니다. 이 문제는 현재 해결 중입니다. 영사하지만 앞으로 저자의 야망은 다음과 같이 확장됩니다. 자신의 구현 물론 가장 가치 있는 노드가 합의 리더 노드가 되는 Raft입니다. 합의 외에도 노드는 매우 자주(기본적으로 초당 한 번) 해당 초에 수집할 수 있었던 사전 집계된 지표의 일부를 이웃에게 보냅니다. 확장성과 내결함성은 유지되는 것으로 나타났습니다. 각 노드는 여전히 전체 메트릭 세트를 보유하지만 메트릭은 이미 TCP를 통해 집계되어 바이너리 프로토콜로 인코딩되어 전송되므로 UDP에 비해 복제 비용이 크게 줄어듭니다. 상당히 많은 수의 수신 메트릭에도 불구하고 축적에는 매우 적은 메모리와 CPU가 필요합니다. 압축률이 높은 측정 항목의 경우 이는 수십 메가바이트에 불과한 데이터입니다. 추가 보너스로 Burbeck의 경우처럼 Graphite에서는 불필요한 데이터 다시 쓰기가 발생하지 않습니다.

메트릭이 포함된 UDP 패킷은 간단한 라운드 로빈을 통해 네트워크 장비의 노드 간에 불균형이 발생합니다. 물론 네트워크 하드웨어는 패킷의 내용을 구문 분석하지 않으므로 전혀 알지 못하는 측정 항목은 말할 것도 없고 초당 4만 개가 넘는 패킷을 가져올 수 있습니다. 메트릭이 각 패킷에서 한 번에 하나씩 제공되지 않는다는 점을 고려하면 여기서 성능 문제가 발생하지 않을 것으로 예상됩니다. 서버가 충돌하면 네트워크 장치는 신속하게(1~2초 이내) 이 사실을 감지하고 충돌한 서버를 교체에서 제거합니다. 결과적으로 패시브(즉, 리더가 아닌) 노드는 실제로 차트의 하락을 인지하지 않고도 켜고 끌 수 있습니다. 우리가 잃는 최대값은 마지막 순간에 들어온 측정항목의 일부입니다. 리더의 갑작스러운 손실/종료/전환은 여전히 ​​사소한 이상 현상을 발생시키지만(30초 간격은 여전히 ​​동기화되지 않음) 노드 간 통신이 있는 경우 동기화 패킷을 전송하는 등의 방법으로 이러한 문제를 최소화할 수 있습니다. .

내부 구조에 대해 조금. 물론 이 애플리케이션은 멀티스레드이지만 스레딩 아키텍처는 brubeck에서 사용되는 것과 다릅니다. brubeck의 스레드는 동일합니다. 각각은 정보 수집과 집계를 모두 담당합니다. bioyino에서 작업자는 네트워크를 담당하는 그룹과 집계를 담당하는 그룹의 두 그룹으로 나뉩니다. 이러한 분할을 통해 메트릭 유형에 따라 애플리케이션을 보다 유연하게 관리할 수 있습니다. 집중적인 집계가 필요한 경우 집계자를 추가할 수 있고, 네트워크 트래픽이 많은 경우 네트워크 흐름 수를 추가할 수 있습니다. 현재 우리 서버에서는 8개의 네트워크와 4개의 집계 흐름에서 작업하고 있습니다.

계산(집계를 담당) 부분은 꽤 지루합니다. 네트워크 흐름으로 채워진 버퍼는 계산 흐름에 분산되어 이후에 구문 분석되고 집계됩니다. 요청 시 다른 노드로 전송하기 위한 메트릭이 제공됩니다. 노드 간 데이터 전송 및 Consul 작업을 포함한 이 모든 작업은 프레임워크에서 실행되어 비동기식으로 수행됩니다. 도쿄.

개발 중에 메트릭 수신을 담당하는 네트워크 부분으로 인해 훨씬 ​​더 많은 문제가 발생했습니다. 네트워크 흐름을 별도의 엔터티로 분리하는 주요 목표는 흐름이 소비하는 시간을 줄이기 위한 것이었습니다. 아니 소켓에서 데이터를 읽습니다. 비동기 UDP 및 일반 recvmsg를 사용하는 옵션은 빠르게 사라졌습니다. 첫 번째는 이벤트 처리를 위해 너무 많은 사용자 공간 CPU를 소비하고 두 번째는 너무 많은 컨텍스트 스위치가 필요합니다. 그러므로 지금은 사용된다 Recvmmsg 큰 버퍼가 있습니다 (그리고 버퍼, 장교 여러분, 당신에게는 아무것도 아닙니다!). 일반 UDP에 대한 지원은 recvmmsg가 필요하지 않은 가벼운 경우를 위해 예약되어 있습니다. 다중 메시지 모드에서는 중요한 것을 달성할 수 있습니다. 대부분의 시간 동안 네트워크 스레드는 OS 대기열을 긁어모습니다. 즉, 소켓에서 데이터를 읽고 이를 사용자 공간 버퍼로 전송하며 가끔 채워진 버퍼를 제공하도록 전환합니다. 수집자. 소켓의 큐는 실제로 누적되지 않으며 삭제된 패킷의 수도 실제로 증가하지 않습니다.

주의

기본 설정에서는 버퍼 크기가 상당히 크게 설정되어 있습니다. 갑자기 서버를 직접 사용해 보기로 결정한 경우 소수의 메트릭을 보낸 후 해당 메트릭이 Graphite에 도착하지 않고 네트워크 스트림 버퍼에 남아 있다는 사실을 접할 수 있습니다. 적은 수의 메트릭으로 작업하려면 구성에서 bufsize 및 task-queue-size를 더 작은 값으로 설정해야 합니다.

마지막으로 차트 애호가를 위한 몇 가지 차트입니다.

각 서버의 수신 메트릭 수에 대한 통계: 2만 MPS 이상.

노드 중 하나를 비활성화하고 수신 측정항목을 재배포합니다.

나가는 측정항목에 대한 통계: 항상 하나의 노드(레이드 보스)만 보냅니다.

다양한 시스템 모듈의 오류를 고려한 각 노드의 작동 통계입니다.

수신 측정항목의 세부정보(측정항목 이름은 숨겨짐)

이 모든 것을 다음에 무엇을 할 계획입니까? 물론 코드도 작성하고, 젠장...! 이 프로젝트는 원래 오픈 소스로 계획되었으며 평생 동안 그대로 유지될 것입니다. 우리의 즉각적인 계획에는 자체 버전의 Raft로 전환, 피어 프로토콜을 보다 이식 가능한 프로토콜로 변경, 추가 내부 통계 도입, 새로운 유형의 측정항목, 버그 수정 및 기타 개선 사항이 포함됩니다.

물론 누구나 프로젝트 개발에 도움을 줄 수 있습니다. PR 작성, 이슈 작성, 가능하다면 대응, 개선 등을 해드립니다.

그렇게 말하면 그게 전부입니다. 우리 코끼리를 사세요!

출처 : habr.com