Qrator 필터링 네트워크 구성 관리 시스템

TL; DR: 내부 네트워크 구성 관리 시스템인 QControl의 클라이언트-서버 아키텍처에 대한 설명입니다. 이는 엔드포인트 간 압축을 풀지 않고 gzip으로 압축된 메시지와 작동하는 XNUMX계층 전송 프로토콜을 기반으로 합니다. 분산 라우터와 엔드포인트는 구성 업데이트를 수신하고 프로토콜 자체를 통해 지역화된 중간 릴레이를 설치할 수 있습니다. 시스템은 원칙에 따라 구축됩니다. 차등 백업 (“최근 안정”, 아래 설명) Jinja 템플릿 엔진과 함께 JMESpath 쿼리 언어를 사용하여 구성 파일을 렌더링합니다.

Qrator Labs는 전 세계적으로 분산된 공격 완화 네트워크를 운영합니다. 당사 네트워크는 애니캐스트 원칙에 따라 작동하며 서브넷은 BGP를 통해 광고됩니다. 지구상의 여러 지역에 물리적으로 위치한 BGP 애니캐스트 네트워크이기 때문에 인터넷의 핵심인 Tier-1 사업자에 더 가까운 불법 트래픽을 처리하고 필터링할 수 있습니다.

반면, 지리적으로 분산된 네트워크가 되는 것은 쉽지 않습니다. 보안 서비스 제공업체가 모든 네트워크 노드를 일관되게 구성하고 적시에 업데이트하려면 네트워크 PoP(Point of Presence) 간의 통신이 중요합니다. 따라서 소비자에게 최고 수준의 핵심 서비스를 제공하기 위해 대륙 전체에 걸쳐 구성 데이터를 안정적으로 동기화할 수 있는 방법을 찾아야 했습니다.

태초에 말씀이 있었다. 이는 빠르게 업데이트가 필요한 통신 프로토콜이 되었습니다.

QControl 존재의 초석이자 동시에 이러한 종류의 프로토콜을 구축하는 데 상당한 시간과 자원을 소비하는 주된 이유는 신뢰할 수 있는 단일 구성 소스를 확보하고 궁극적으로 존재 지점을 동기화해야 한다는 것입니다. 그것으로. 스토리지 자체는 QControl 개발 중 여러 요구 사항 중 하나에 불과했습니다. 또한 POP(Point of Presence)에서 기존 및 계획된 서비스와의 통합, 데이터 검증을 위한 스마트하고 사용자 정의 가능한 방법, 액세스 제어도 필요했습니다. 이 외에도 파일을 수정하는 대신 명령을 사용하여 이러한 시스템을 제어하고 싶었습니다. QControl 이전에는 데이터가 거의 수동으로 접속 지점으로 전송되었습니다. PoP 중 하나를 사용할 수 없고 나중에 업데이트하는 것을 잊어버린 경우 구성이 동기화되지 않아 다시 시작하고 실행하는 데 시간을 낭비해야 합니다.

결과적으로 우리는 다음과 같은 계획을 생각해 냈습니다.

구성 서버는 데이터 유효성 검사 및 저장을 담당하며, 라우터에는 클라이언트 및 지원 팀에서 서버로, 서버에서 접속 지점으로 구성 업데이트를 수신하고 브로드캐스팅하는 여러 엔드포인트가 있습니다.

인터넷 연결 품질은 여전히 ​​전 세계적으로 다양합니다. 이 점을 설명하기 위해 체코 프라하에서 싱가포르 및 홍콩까지의 간단한 MTR을 살펴보겠습니다.

프라하에서 싱가포르까지 MTR

홍콩도 마찬가지

대기 시간이 길다는 것은 속도가 낮다는 것을 의미합니다. 게다가 패킷 손실도 있습니다. 채널 폭은 이 문제를 보상하지 않으므로 분산 시스템을 구축할 때 항상 고려해야 합니다.

PoP의 전체 구성은 신뢰할 수 없는 연결을 통해 많은 수신자에게 전송되어야 하는 상당한 양의 데이터입니다. 다행스럽게도 구성은 지속적으로 변경되지만 조금씩 변경됩니다.

최근 안정된 디자인

증분 업데이트 원칙을 기반으로 분산 네트워크를 구축하는 것은 상당히 확실한 솔루션이라고 말할 수 있습니다. 하지만 diff에는 문제가 많습니다. 참조 지점 간의 모든 차이점을 저장해야 하며, 누군가가 데이터의 일부를 놓친 경우를 대비하여 다시 보낼 수도 있어야 합니다. 각 대상은 엄격하게 지정된 순서에 따라 이를 적용해야 합니다. 일반적으로 대상이 여러 개인 경우 이러한 작업에 오랜 시간이 걸릴 수 있습니다. 수신자는 또한 누락된 부분을 요청할 수 있어야 하며, 물론 중앙 부분은 이러한 요청에 올바르게 응답하여 누락된 데이터만 보내야 합니다.

결과적으로 우리는 다소 흥미로운 솔루션에 도달했습니다. 참조 레이어가 하나만 있고 고정되어 있고 안정적이라고 부르며 최근에는 단 하나의 차이점만 있습니다. 각각의 최근 항목은 마지막으로 생성된 안정 항목을 기반으로 하며 구성 데이터를 다시 작성하는 데 충분합니다. 새로운 최신 항목이 목적지에 도달하자마자 이전 항목은 더 이상 필요하지 않습니다.

예를 들어 최근 구성이 너무 커졌기 때문에 때때로 새롭고 안정적인 구성을 보내는 것만 남아 있습니다. 여기서 중요한 점은 개별 수신자 및 데이터 조각을 통합하는 능력에 대해 걱정하지 않고 이러한 모든 업데이트를 브로드캐스트/멀티캐스트 모드로 보낸다는 것입니다. 모든 사람이 올바른 마구간을 갖고 있다고 확신하면 최신의 새 마구간만 보냅니다. 이것이 작동한다는 것을 명확히 할 가치가 있습니까? 공장. 안정 버전은 구성 서버와 수신자에 캐시되며, 필요에 따라 최근 버전이 생성됩니다.

XNUMX단계 전송 아키텍처

왜 우리는 두 가지 수준으로 운송 수단을 구축했을까요? 대답은 매우 간단합니다. 우리는 OSI 모델의 전송 및 애플리케이션 계층에서 영감을 받아 상위 수준 로직에서 라우팅을 분리하고 싶었습니다. 전송 프로토콜의 역할에는 Thrift를 사용하고 제어 메시지의 상위 수준 형식에는 msgpack 직렬화 형식을 사용했습니다. 멀티캐스트/브로드캐스트/릴레이를 수행하는 라우터가 msgpack 내부를 살펴보지 않고, 내용을 언팩하거나 다시 팩하지 않고, 데이터만 전달하는 이유가 여기에 있습니다.

Thrift(영어 - "thrift", [θrift]로 발음)는 다양한 프로그래밍 언어에 대한 서비스를 정의하고 생성하는 데 사용되는 인터페이스 설명 언어입니다. RPC(원격 프로시저 호출)를 위한 프레임워크입니다. 소프트웨어 파이프라인을 코드 생성 엔진과 결합하여 언어 간에 어느 정도 효율적이고 쉽게 작동하는 서비스를 개발합니다.

우리는 RPC와 다양한 언어 지원 때문에 Thrift 프레임워크를 선택했습니다. 늘 그렇듯이 쉬운 부분은 클라이언트와 서버였습니다. 그러나 라우터는 개발 중에 기성 솔루션이 부족했기 때문에 깨지기 힘든 것으로 판명되었습니다.

protobuf/gRPC와 같은 다른 옵션도 있지만, 프로젝트를 시작했을 때 gRPC는 상당히 새로운 것이었고 감히 이를 도입할 생각이 없었습니다.

물론, 우리는 우리 자신의 자전거를 만들 수 있었습니다(그리고 실제로 그래야 했습니다). Thrift에서 라우터를 구축하는 것에 비해 클라이언트-서버 아키텍처를 구현하는 것이 상대적으로 간단하기 때문에 필요한 프로토콜을 만드는 것이 더 쉬울 것입니다. 어떤 식으로든 자체 작성 프로토콜과 인기 있는 라이브러리의 구현에 대한 전통적인 편견이 있습니다(타당한 이유가 있음). 또한 토론 중에 항상 "이것을 다른 언어로 어떻게 포팅할 것인가?"라는 질문이 제기됩니다. 그래서 우리는 자전거에 대한 아이디어를 즉시 버렸습니다.

Msgpack은 JSON과 유사하지만 더 빠르고 더 작습니다. 여러 언어 간에 데이터를 교환할 수 있는 이진 데이터 직렬화 형식입니다.

첫 번째 수준에는 라우터가 메시지를 전달하는 데 필요한 최소한의 정보가 포함된 Thrift가 있습니다. 두 번째 수준에는 패키지된 msgpack 구조가 있습니다.

msgpack은 JSON에 비해 더 빠르고 컴팩트하기 때문에 선택했습니다. 그러나 더 중요한 것은 사용자 정의 데이터 유형을 지원하므로 원시 바이너리 전달이나 데이터 부재를 나타내는 특수 개체 전달과 같은 멋진 기능을 사용할 수 있다는 점입니다. 이는 "최근 안정" 방식에 중요했습니다.

JMES경로
JMESPath는 JSON 쿼리 언어입니다.
이는 공식 JMESPath 문서에서 얻은 설명과 정확히 일치하지만 실제로는 그 이상을 수행합니다. JMESPath를 사용하면 임의의 트리 구조에서 하위 트리를 검색 및 필터링하고 즉시 데이터에 변경 사항을 적용할 수 있습니다. 또한 특수 필터 및 데이터 변환 절차를 추가할 수도 있습니다. 물론 이해하려면 두뇌의 노력이 필요합니다.

진자
일부 소비자의 경우 구성을 파일로 전환해야 하므로 템플릿 엔진을 사용하므로 Jinja가 확실한 선택입니다. 도움을 받아 템플릿에서 구성 파일과 대상에서 받은 데이터를 생성합니다.

구성 파일을 생성하려면 JMESPath 요청, FS의 파일 위치에 대한 템플릿, 구성 자체에 대한 템플릿이 필요합니다. 이 단계에서는 파일 권한을 명확히 하는 것도 좋은 생각입니다. 이 모든 것이 하나의 파일에 성공적으로 결합되었습니다. 구성 템플릿을 시작하기 전에 나머지를 설명하는 YAML 형식의 헤더를 배치했습니다.

예를 들면 다음과 같습니다

---
selector: "[@][[email protected]._meta.version == `42`] | items([0].fft_config || `{}`)"
destination_filename: "fft/{{ match[0] }}.json"
file_mode: 0644
reload_daemons: [fft] ...
{{ dict(match[1]) | json(indent=2, sort_keys=True) }}


새로운 서비스에 대한 구성 파일을 만들기 위해서는 새로운 템플릿 파일만 추가하면 됩니다. PoP(Point of Presence)의 소스 코드나 소프트웨어를 변경할 필요가 없습니다.

QControl이 출시된 후 무엇이 바뀌었나요? 첫 번째이자 가장 중요한 것은 네트워크의 모든 노드에 구성 업데이트를 일관되고 안정적으로 전달하는 것입니다. 두 번째는 지원팀과 서비스 소비자가 구성을 확인하고 변경하기 위한 강력한 도구를 받는 것입니다.

우리는 구성 서버와 구성 수신자 간의 통신을 단순화하기 위해 최근 안정적인 업데이트 구성표를 사용하여 이 모든 작업을 수행할 수 있었습니다. XNUMX계층 프로토콜을 사용하여 콘텐츠 독립적인 데이터 라우팅 방식을 지원합니다. Jinja 기반 구성 생성 엔진을 분산 필터링 네트워크에 성공적으로 통합했습니다. 이 시스템은 분산형 및 이기종 주변 장치에 대한 광범위한 구성 방법을 지원합니다.

자료 작성에 도움을 주셔서 감사합니다. 볼란담로드, 평온함, 아니요.

영문판 우편.

출처 : habr.com