Yandex.Cloud의 네트워크 부하 분산 장치 아키텍처

안녕하세요, 저는 Sergey Elantsev입니다. 저는 개발을 하고 있습니다. 네트워크 로드 밸런서 Yandex.Cloud에서. 이전에 저는 Yandex 포털용 L7 밸런서 개발을 이끌었습니다. 동료들은 제가 무엇을 하든 밸런서가 된다고 농담했습니다. 나는 Habr 독자들에게 클라우드 플랫폼에서 로드를 관리하는 방법, 이 목표를 달성하기 위한 이상적인 도구, 그리고 이 도구를 구축하기 위해 어떻게 나아가고 있는지 알려줄 것입니다.

먼저 몇 가지 용어를 소개하겠습니다.

• VIP(가상 IP) - 밸런서 IP 주소
• 서버, 백엔드, 인스턴스 - 애플리케이션을 실행하는 가상 머신
• RIP(실제 IP) - 서버 IP 주소
• 상태 확인 - 서버 준비 상태 확인
• 가용 영역, AZ - 데이터 센터의 격리된 인프라
• 지역 - 다양한 AZ의 통합

로드 밸런서는 XNUMX가지 주요 작업을 해결합니다. 즉, 밸런싱 자체를 수행하고 서비스의 내결함성을 향상하며 확장을 단순화합니다. 자동 트래픽 관리를 통해 내결함성이 보장됩니다. 밸런서는 애플리케이션의 상태를 모니터링하고 활성 확인을 통과하지 못한 인스턴스를 밸런싱에서 제외합니다. 인스턴스 전체에 로드를 균등하게 분배하고 인스턴스 목록을 즉시 업데이트함으로써 확장이 보장됩니다. 밸런싱이 충분히 균일하지 않으면 일부 인스턴스가 용량 제한을 초과하는 로드를 받게 되며 서비스의 안정성이 떨어집니다.

로드 밸런서는 실행되는 OSI 모델의 프로토콜 계층에 따라 분류되는 경우가 많습니다. Cloud Balancer는 네 번째 계층인 L4에 해당하는 TCP 수준에서 작동합니다.

Cloud Balancer 아키텍처의 개요로 넘어가겠습니다. 점차적으로 디테일을 높여보겠습니다. 우리는 밸런서 구성 요소를 세 가지 클래스로 나눕니다. 구성 평면 클래스는 사용자 상호 작용을 담당하고 시스템의 대상 상태를 저장합니다. 제어 플레인은 시스템의 현재 상태를 저장하고 클라이언트에서 인스턴스로 트래픽을 전달하는 일을 직접 담당하는 데이터 플레인 클래스의 시스템을 관리합니다.

데이터 플레인

트래픽은 보더 라우터(Border Router)라고 불리는 고가의 장치에서 종료됩니다. 내결함성을 높이기 위해 여러 장치가 하나의 데이터 센터에서 동시에 작동합니다. 다음으로 트래픽은 클라이언트용 BGP를 통해 모든 AZ에 애니캐스트 IP 주소를 알리는 밸런서로 이동합니다. 

트래픽은 ECMP를 통해 전송됩니다. 이는 대상에 대해 동일하게 양호한 경로가 여러 개 있을 수 있고(이 경우 대상은 대상 IP 주소임) 패킷이 그 중 하나를 따라 전송될 수 있는 라우팅 전략입니다. 또한 다음 구성표에 따라 여러 가용성 영역에서의 작업을 지원합니다. 각 영역의 주소를 광고하고 트래픽은 가장 가까운 주소로 이동하며 제한을 초과하지 않습니다. 나중에 게시물에서 트래픽에 어떤 일이 일어나는지 더 자세히 살펴보겠습니다.

구성 평면

 
구성 플레인의 핵심 구성 요소는 밸런서를 사용한 기본 작업(인스턴스 생성, 삭제, 구성 변경, 상태 확인 결과 가져오기 등)이 수행되는 API입니다. 한편으로 이것은 REST API이고 다른 한편으로는 다른 한편, 클라우드에서는 gRPC 프레임워크를 자주 사용하므로 REST를 gRPC로 "변환"한 다음 gRPC만 사용합니다. 모든 요청으로 인해 Yandex.Cloud 작업자의 공통 풀에서 실행되는 일련의 비동기 멱등성 작업이 생성됩니다. 작업은 언제든지 일시 중지했다가 다시 시작할 수 있는 방식으로 작성됩니다. 이는 확장성, 반복성 및 작업 로깅을 보장합니다.

결과적으로 API의 작업은 Go로 작성된 밸런서 서비스 컨트롤러에 요청을 보냅니다. 밸런서를 추가 및 제거하고 백엔드 및 설정 구성을 변경할 수 있습니다. 

서비스는 곧 사용할 수 있는 분산 관리형 데이터베이스인 Yandex 데이터베이스에 상태를 저장합니다. Yandex.Cloud에서는 이미 그랬듯이 말한, 개밥 개념이 적용됩니다. 우리가 우리 서비스를 사용하면 고객도 기꺼이 서비스를 사용할 것입니다. Yandex 데이터베이스는 이러한 개념을 구현한 예입니다. 우리는 모든 데이터를 YDB에 저장하므로 데이터베이스 유지 관리 및 확장에 대해 생각할 필요가 없습니다. 이러한 문제는 해결되었으며 데이터베이스를 서비스로 사용합니다.

밸런서 컨트롤러로 돌아가 보겠습니다. 그 작업은 밸런서에 대한 정보를 저장하고 상태 확인 컨트롤러에 가상 머신의 준비 상태를 확인하는 작업을 보내는 것입니다.

상태 확인 컨트롤러

검사 규칙 변경 요청을 수신하고 이를 YDB에 저장하며 healtcheck 노드에 작업을 배포하고 결과를 집계한 다음 데이터베이스에 저장하고 로드 밸런서 컨트롤러로 전송합니다. 그런 다음 데이터 플레인의 클러스터 구성을 로드 밸런서 노드로 변경하라는 요청을 보냅니다. 이에 대해서는 아래에서 설명하겠습니다.

건강검진에 대해 좀 더 이야기해 보겠습니다. 여러 클래스로 나눌 수 있습니다. 감사에는 다양한 성공 기준이 있습니다. TCP 검사는 고정된 시간 내에 성공적으로 연결을 설정해야 합니다. HTTP 검사에는 성공적인 연결과 200 상태 코드의 응답이 모두 필요합니다.

또한 수표는 행동 등급이 다릅니다. 즉, 능동형과 수동형입니다. 패시브 검사는 특별한 조치를 취하지 않고 트래픽에서 발생하는 상황을 간단히 모니터링합니다. 이는 상위 수준 프로토콜의 논리에 따라 달라지기 때문에 L4에서는 잘 작동하지 않습니다. L4에서는 작업에 걸린 시간이나 연결 완료가 좋은지 나쁜지에 대한 정보가 없습니다. 활성 검사를 위해서는 밸런서가 각 서버 인스턴스에 요청을 보내야 합니다.

대부분의 로드 밸런서는 활성 상태 검사를 자체적으로 수행합니다. 클라우드에서는 확장성을 높이기 위해 시스템의 이러한 부분을 분리하기로 결정했습니다. 이 접근 방식을 사용하면 서비스에 대한 상태 확인 요청 수를 유지하면서 밸런서 수를 늘릴 수 있습니다. 검사는 검사 대상이 분할되고 복제되는 별도의 상태 검사 노드에 의해 수행됩니다. 한 호스트에서는 검사가 실패할 수 있으므로 검사를 수행할 수 없습니다. 그러면 우리는 그가 확인한 인스턴스의 상태를 얻지 못할 것입니다. 우리는 최소 XNUMX개 이상의 상태 확인 노드에서 모든 인스턴스에 대한 확인을 수행합니다. 일관된 해싱 알고리즘을 사용하여 노드 간 검사 목적을 분할합니다.

밸런싱과 상태 확인을 분리하면 문제가 발생할 수 있습니다. healthcheck 노드가 밸런서(현재 트래픽을 제공하지 않는)를 우회하여 인스턴스에 요청하는 경우 이상한 상황이 발생합니다. 리소스가 살아있는 것처럼 보이지만 트래픽이 리소스에 도달하지 않습니다. 우리는 이 문제를 이런 방식으로 해결합니다. 즉, 밸런서를 통해 상태 확인 트래픽을 시작하도록 보장됩니다. 즉, 클라이언트와 상태 확인의 트래픽으로 패킷을 이동하는 방식은 최소한으로 다릅니다. 두 경우 모두 패킷은 밸런서에 도달하여 대상 리소스로 전달됩니다.

차이점은 클라이언트가 VIP에 요청하는 반면 상태 확인은 각 개별 RIP에 요청한다는 것입니다. 여기서 흥미로운 문제가 발생합니다. 우리는 사용자에게 회색 IP 네트워크에서 리소스를 생성할 수 있는 기회를 제공합니다. 밸런서 뒤에 서비스를 숨긴 두 명의 서로 다른 클라우드 소유자가 있다고 가정해 보겠습니다. 각각은 주소가 동일한 10.0.0.1/24 서브넷에 리소스를 가지고 있습니다. 이를 어떻게든 구별할 수 있어야 하며 여기서 Yandex.Cloud 가상 네트워크의 구조를 자세히 살펴봐야 합니다. 자세한 내용은 에서 알아보시는 것이 좋을 것 같습니다 about:cloud 이벤트의 동영상, 이제 네트워크가 다중 계층으로 구성되어 있고 서브넷 ID로 구별할 수 있는 터널이 있다는 점이 우리에게 중요합니다.

상태 확인 노드는 소위 준IPv6 주소를 사용하여 밸런서에 접속합니다. 준주소는 IPv6 주소와 사용자 서브넷 ID가 내부에 포함된 IPv4 주소입니다. 트래픽은 밸런서에 도달하여 IPv4 리소스 주소를 추출하고 IPv6를 IPv4로 대체한 후 패킷을 사용자 네트워크로 보냅니다.

역방향 트래픽도 같은 방식으로 진행됩니다. 밸런서는 대상이 상태 검사기의 회색 네트워크임을 확인하고 IPv4를 IPv6로 변환합니다.

VPP - 데이터 플레인의 핵심

밸런서는 네트워크 트래픽 일괄 처리를 위한 Cisco의 프레임워크인 VPP(벡터 패킷 처리) 기술을 사용하여 구현됩니다. 우리의 경우 프레임워크는 사용자 공간 네트워크 장치 관리 라이브러리인 DPDK(Data Plane Development Kit) 위에서 작동합니다. 이는 높은 패킷 처리 성능을 보장합니다. 커널에서 발생하는 인터럽트가 훨씬 적고 커널 공간과 사용자 공간 사이에 컨텍스트 전환이 없습니다. 

VPP는 더 나아가 패키지를 배치로 결합하여 시스템에서 더 많은 성능을 끌어냅니다. 성능 향상은 최신 프로세서에서 캐시를 적극적으로 사용함으로써 발생합니다. 데이터 캐시(패킷은 "벡터"로 처리되고 데이터는 서로 가깝습니다)와 명령 캐시가 모두 사용됩니다. VPP에서 패킷 처리는 동일한 작업을 수행하는 기능을 포함하는 노드가 있는 그래프를 따릅니다.

예를 들어, VPP에서 IP 패킷 처리는 다음 순서로 발생합니다. 먼저 패킷 헤더가 구문 분석 노드에서 구문 분석된 다음 노드로 전송되고, 노드는 라우팅 테이블에 따라 패킷을 추가로 전달합니다.

약간 하드 코어. VPP 작성자는 프로세서 캐시 사용 시 타협을 용납하지 않으므로 패킷 벡터를 처리하기 위한 일반적인 코드에는 수동 벡터화가 포함됩니다. "큐에 XNUMX개의 패킷이 있습니다"와 같은 상황이 처리되는 처리 루프가 있습니다. 그런 다음 두 사람에게도 동일하고, 그다음에는 한 사람에게도 동일합니다. 프리페치 명령어는 데이터를 캐시에 로드하여 후속 반복에서 캐시에 대한 액세스 속도를 높이는 데 자주 사용됩니다.

n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
    vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
    // ...
    while (n_left_from >= 4 && n_left_to_next >= 2)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            vlib_buffer_t *p2, *p3;

            p2 = vlib_get_buffer (vm, from[2]);
            p3 = vlib_get_buffer (vm, from[3]);

            vlib_prefetch_buffer_header (p2, LOAD);
            vlib_prefetch_buffer_header (p3, LOAD);

            CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
            CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                to_next, n_left_to_next,
                bi0, bi1, next0, next1);
    }

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

따라서 상태 확인은 IPv6를 통해 VPP와 통신하여 VPP를 IPv4로 전환합니다. 이는 알고리즘 NAT라고 하는 그래프의 노드에 의해 수행됩니다. 역방향 트래픽(및 IPv6에서 IPv4로의 변환)의 경우 동일한 알고리즘 NAT 노드가 있습니다.

밸런서 클라이언트의 직접 트래픽은 밸런싱 자체를 수행하는 그래프 노드를 통과합니다. 

첫 번째 노드는 고정 세션입니다. 해시를 저장합니다. 5튜플 설정된 세션의 경우. 5-튜플에는 정보가 전송되는 클라이언트의 주소와 포트, 트래픽 수신에 사용할 수 있는 리소스의 주소와 포트, 네트워크 프로토콜이 포함됩니다. 

5튜플 해시는 후속 일관된 해싱 노드에서 더 적은 계산을 수행할 뿐만 아니라 밸런서 뒤에서 리소스 목록 변경 사항을 더 잘 처리하는 데 도움이 됩니다. 세션이 없는 패킷이 밸런서에 도착하면 일관된 해싱 노드로 전송됩니다. 여기에서 일관된 해싱을 사용하여 균형이 이루어집니다. 사용 가능한 "라이브" 리소스 목록에서 리소스를 선택합니다. 다음으로, 패킷은 실제로 대상 주소를 대체하고 체크섬을 다시 계산하는 NAT 노드로 전송됩니다. 보시다시피, 우리는 프로세서 캐시의 효율성을 높이기 위해 비슷한 계산을 그룹화하는 '좋아요'와 같은 VPP 규칙을 따릅니다.

일관된 해싱

우리는 왜 그것을 선택했으며 그것은 무엇입니까? 먼저, 목록에서 리소스를 선택하는 이전 작업을 고려해 보겠습니다. 

불일치 해싱을 사용하면 수신 패킷의 해시가 계산되고 이 해시를 리소스 수로 나눈 나머지로 목록에서 리소스가 선택됩니다. 목록이 변경되지 않는 한 이 체계는 잘 작동합니다. 항상 동일한 5-튜플이 포함된 패킷을 동일한 인스턴스로 보냅니다. 예를 들어 일부 리소스가 상태 확인에 대한 응답을 중지한 경우 해시의 상당 부분에 대한 선택이 변경됩니다. 클라이언트의 TCP 연결이 끊어집니다. 이전에 인스턴스 A에 도달한 패킷이 이 패킷의 세션에 익숙하지 않은 인스턴스 B에 도달하기 시작할 수 있습니다.

일관된 해싱은 설명된 문제를 해결합니다. 이 개념을 설명하는 가장 쉬운 방법은 다음과 같습니다. 해시별로(예: IP:포트별로) 리소스를 배포하는 링이 있다고 상상해 보세요. 리소스를 선택하는 것은 패킷의 해시에 의해 결정되는 각도에 따라 휠을 돌리는 것입니다.

이는 리소스 구성이 변경될 때 트래픽 재분배를 최소화합니다. 리소스를 삭제하면 해당 리소스가 있던 일관된 해싱 링 부분에만 영향을 미칩니다. 리소스를 추가하면 배포도 변경되지만 이미 설정된 세션을 새 리소스로 전환할 수 없는 고정 세션 노드가 있습니다.

우리는 밸런서와 리소스 간의 직접적인 트래픽에 어떤 일이 일어나는지 살펴보았습니다. 이제 반환 트래픽을 살펴보겠습니다. 이는 트래픽 확인과 동일한 패턴을 따릅니다. 즉, 알고리즘 NAT를 통해, 즉 클라이언트 트래픽의 경우 역방향 NAT 44를 통해, 상태 확인 트래픽의 경우 NAT 46을 통해 수행됩니다. 우리는 자체 계획을 고수합니다. 상태 확인 트래픽과 실제 사용자 트래픽을 통합합니다.

로드밸런서 노드 및 조립된 구성요소

VPP의 밸런서 및 리소스 구성은 로컬 서비스인 loadbalancer-node에 의해 보고됩니다. 이는 로드 밸런서-컨트롤러의 이벤트 스트림을 구독하고 현재 VPP 상태와 컨트롤러에서 수신한 대상 상태 간의 차이를 표시할 수 있습니다. 우리는 폐쇄형 시스템을 얻습니다. API의 이벤트가 밸런서 컨트롤러로 전달되어 리소스의 "활성"을 확인하기 위해 상태 확인 컨트롤러에 작업을 할당합니다. 그런 다음 healthcheck 노드에 작업을 할당하고 결과를 집계한 후 다시 밸런서 컨트롤러로 보냅니다. Loadbalancer-node는 컨트롤러의 이벤트를 구독하고 VPP의 상태를 변경합니다. 이러한 시스템에서 각 서비스는 인접 서비스에 대해 필요한 것만 알고 있습니다. 연결 수는 제한되어 있으며 다양한 세그먼트를 독립적으로 운영하고 확장할 수 있습니다.

어떤 문제를 피할 수 있었나요?

컨트롤 플레인의 모든 서비스는 Go로 작성되었으며 우수한 확장성 및 안정성 특성을 가지고 있습니다. Go에는 분산 시스템 구축을 위한 많은 오픈 소스 라이브러리가 있습니다. 우리는 GRPC를 적극적으로 사용하고 있으며 모든 구성 요소에는 서비스 검색의 오픈 소스 구현이 포함되어 있습니다. 우리 서비스는 서로의 성능을 모니터링하고 구성을 동적으로 변경할 수 있으며 이를 GRPC 밸런싱과 연결했습니다. 측정항목의 경우 오픈 소스 솔루션도 사용합니다. 데이터 플레인에서는 괜찮은 성능과 대규모 리소스 보유량을 얻었습니다. 철제 네트워크 카드가 아닌 VPP의 성능에 의존할 수 있는 스탠드를 조립하는 것이 매우 어려웠습니다.

문제 및 해결책

무엇이 그렇게 잘 되지 않았나요? Go에는 자동 메모리 관리 기능이 있지만 메모리 누수는 여전히 발생합니다. 이를 처리하는 가장 쉬운 방법은 고루틴을 실행하고 이를 종료하는 것을 기억하는 것입니다. 요점: Go 프로그램의 메모리 소비를 살펴보세요. 종종 좋은 지표는 고루틴의 수입니다. 이 이야기에는 장점이 있습니다. Go에서는 메모리 소비, 실행 중인 고루틴 수 및 기타 여러 매개변수와 같은 런타임 데이터를 쉽게 얻을 수 있습니다.

또한 Go는 기능 테스트에 가장 적합한 선택이 아닐 수도 있습니다. 이는 매우 장황하며 "CI의 모든 것을 일괄 실행"하는 표준 접근 방식은 그다지 적합하지 않습니다. 사실 기능 테스트는 리소스를 더 많이 요구하고 실제 시간 초과를 유발합니다. 이로 인해 CPU가 단위 테스트로 바쁘기 때문에 테스트가 실패할 수 있습니다. 결론: 가능하다면 단위 테스트와 별도로 "무거운" 테스트를 수행하십시오. 

마이크로서비스 이벤트 아키텍처는 모놀리스보다 더 복잡합니다. 수십 개의 서로 다른 시스템에서 로그를 수집하는 것은 그다지 편리하지 않습니다. 결론: 마이크로서비스를 만든다면 즉시 추적에 대해 생각해 보세요.

우리의 계획

우리는 내부 밸런서인 IPv6 밸런서를 출시하고, Kubernetes 스크립트에 대한 지원을 추가하고, 서비스를 계속 샤딩하고(현재 healthcheck-node 및 healthcheck-ctrl만 샤딩됨), 새로운 상태 확인을 추가하고, 검사의 스마트 집계도 구현할 것입니다. 우리는 서비스가 서로 직접적으로 통신하지 않고 메시지 대기열을 사용하여 통신할 수 있도록 서비스를 더욱 독립적으로 만들 가능성을 고려하고 있습니다. SQS 호환 서비스가 최근 클라우드에 등장했습니다. Yandex 메시지 대기열.

최근 Yandex Load Balancer가 공개 출시되었습니다. 탐구하다 문서 서비스에 편리한 방식으로 밸런서를 관리하고 프로젝트의 내결함성을 높이십시오!

출처 : habr.com