기사 번역 : Envoy 스레딩 모델 - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

나는 이 기사가 매우 흥미롭다고 생각하며 Envoy는 "istio"의 일부로 또는 단순히 kubernetes의 "수신 컨트롤러"로 가장 자주 사용되기 때문에 대부분의 사람들은 예를 들어 일반적인 Envoy와 동일한 직접적인 상호 작용을 하지 않습니다. Nginx 또는 Haproxy 설치. 그러나 무언가가 고장난 경우 내부에서 어떻게 작동하는지 이해하는 것이 좋습니다. 특수 단어를 포함하여 가능한 한 많은 내용을 러시아어로 번역하려고 노력했으며, 이것을 보는 것이 고통스럽다고 생각하는 분들을 위해 원문을 괄호 안에 남겨 두었습니다. 고양이에 오신 것을 환영합니다.

Envoy 코드베이스에 대한 낮은 수준의 기술 문서는 현재 매우 드물습니다. 이 문제를 해결하기 위해 저는 Envoy의 다양한 하위 시스템에 대한 일련의 블로그 게시물을 작성할 계획입니다. 이것이 첫 번째 기사이므로 귀하의 생각과 향후 기사에 관심이 있을 만한 내용을 알려주십시오.

Envoy에 관해 제가 받는 가장 일반적인 기술적 질문 중 하나는 Envoy가 사용하는 스레딩 모델에 대한 낮은 수준의 설명을 묻는 것입니다. 이 게시물에서는 Envoy가 연결을 스레드에 매핑하는 방법과 Envoy가 코드를 더 병렬적이고 고성능으로 만들기 위해 내부적으로 사용하는 스레드 로컬 스토리지 시스템에 대해 설명하겠습니다.

스레딩 개요

Envoy는 세 가지 유형의 스트림을 사용합니다.

• 기본: 이 스레드는 프로세스 시작 및 종료, DNS, 상태 확인, 일반 클러스터 및 런타임 관리, 통계 재설정, 관리 및 일반 프로세스 관리(Linux 신호, 핫 재시작 등)를 포함한 XDS(xDiscovery Service) API의 모든 처리를 제어합니다. 이 스레드에서 발생하는 것은 비동기식이며 "비차단"입니다. 일반적으로 메인 스레드는 실행하는 데 많은 양의 CPU가 필요하지 않은 모든 중요한 기능 프로세스를 조정합니다. 이를 통해 대부분의 제어 코드를 단일 스레드인 것처럼 작성할 수 있습니다.
• 노동자: 기본적으로 Envoy는 시스템의 각 하드웨어 스레드에 대해 작업자 스레드를 생성합니다. 이는 옵션을 사용하여 제어할 수 있습니다. --concurrency. 각 작업자 스레드는 각 리스너의 수신을 담당하는 "비차단" 이벤트 루프를 실행합니다. 이 글을 쓰는 시점(29년 2017월 XNUMX일)에는 리스너의 샤딩이 없으며 새 연결을 수락하고 필터 스택을 인스턴스화합니다. 연결 수명 동안 모든 입출력(IO) 작업을 처리합니다. 다시 말하지만, 이를 통해 대부분의 연결 처리 코드를 단일 스레드인 것처럼 작성할 수 있습니다.
• 파일 플러셔: Envoy가 작성하는 각 파일(주로 액세스 로그)에는 현재 독립적인 차단 스레드가 있습니다. 이는 다음을 사용하는 경우에도 파일 시스템에 의해 캐시된 파일에 쓰기가 가능하기 때문입니다. O_NONBLOCK 가끔 차단될 수도 있어요(한숨). 작업자 스레드가 파일에 써야 하는 경우 데이터는 실제로 메모리의 버퍼로 이동되어 결국 스레드를 통해 플러시됩니다. 파일 플러시. 이는 기술적으로 모든 작업자 스레드가 메모리 버퍼를 채우려고 시도하는 동안 동일한 잠금을 차단할 수 있는 코드 영역 중 하나입니다.

연결 처리

위에서 간략하게 설명한 것처럼 모든 작업자 스레드는 샤딩 없이 모든 리스너를 수신합니다. 따라서 커널은 허용된 소켓을 작업자 스레드에 정상적으로 보내는 데 사용됩니다. 최신 커널은 일반적으로 이 작업에 매우 능숙합니다. 동일한 소켓에서 수신 대기하고 라운드 로빈을 사용하지 않는 다른 스레드를 사용하기 전에 스레드를 작업으로 채우기 위해 입출력(IO) 우선 순위 향상과 같은 기능을 사용합니다. 각 요청을 처리하기 위한 잠금(Spinlock)입니다.
작업자 스레드에서 연결이 승인되면 해당 스레드를 떠나지 않습니다. 연결에 대한 모든 추가 처리는 전달 동작을 포함하여 전적으로 작업자 스레드에서 처리됩니다.

이는 다음과 같은 몇 가지 중요한 결과를 가져옵니다.

• Envoy의 모든 연결 풀은 작업자 스레드에 할당됩니다. 따라서 HTTP/2 연결 풀은 한 번에 각 업스트림 호스트에 대해 하나의 연결만 생성하지만 작업자 스레드가 2개라면 안정적인 상태에서는 업스트림 호스트당 XNUMX개의 HTTP/XNUMX 연결이 있게 됩니다.
• Envoy가 이런 방식으로 작동하는 이유는 모든 것을 단일 작업자 스레드에 유지함으로써 거의 모든 코드를 차단 없이 단일 스레드인 것처럼 작성할 수 있기 때문입니다. 이 디자인을 사용하면 많은 코드를 쉽게 작성할 수 있으며 거의 ​​무제한의 작업자 스레드로 확장할 수 있습니다.
• 그러나 주요 시사점 중 하나는 메모리 풀과 연결 효율성의 관점에서 볼 때 실제로 --concurrency. 필요한 것보다 더 많은 작업자 스레드가 있으면 메모리가 낭비되고 더 많은 유휴 연결이 생성되며 연결 풀링 속도가 감소합니다. Lyft에서 특사 사이드카 컨테이너는 매우 낮은 동시성으로 실행되므로 성능은 옆에 있는 서비스와 거의 일치합니다. 우리는 최대 동시성에서만 Envoy를 에지 프록시로 실행합니다.

비차단이란 무엇을 의미하나요?

"비차단"이라는 용어는 지금까지 메인 스레드와 작업자 스레드의 작동 방식을 논의할 때 여러 번 사용되었습니다. 모든 코드는 아무것도 차단되지 않는다는 가정하에 작성되었습니다. 그러나 이는 전적으로 사실이 아닙니다(전적으로 사실이 아닌 것은 무엇입니까?).

Envoy는 여러 가지 긴 프로세스 잠금을 사용합니다.

• 설명한 대로 액세스 로그를 작성할 때 모든 작업자 스레드는 메모리 내 로그 버퍼가 채워지기 전에 동일한 잠금을 획득합니다. 잠금 유지 시간은 매우 낮아야 하지만 높은 동시성과 높은 처리량에서 잠금이 경합될 수 있습니다.
• Envoy는 매우 복잡한 시스템을 사용하여 스레드에 대한 로컬 통계를 처리합니다. 이것은 별도의 게시물의 주제가 될 것입니다. 그러나 로컬에서 스레드 통계를 처리하는 과정의 일부로 중앙 "통계 저장소"에 대한 잠금을 획득해야 하는 경우가 있다는 점을 간략하게 언급하겠습니다. 이 잠금은 절대로 필요하지 않습니다.
• 기본 스레드는 주기적으로 모든 작업자 스레드와 조정해야 합니다. 이는 메인 스레드에서 작업자 스레드로, 때로는 작업자 스레드에서 다시 메인 스레드로 "게시"함으로써 수행됩니다. 전송하려면 게시된 메시지를 나중에 배달하기 위해 대기열에 넣을 수 있도록 잠금이 필요합니다. 이러한 잠금은 심각하게 논쟁을 벌여서는 안 되지만 기술적으로는 여전히 차단될 수 있습니다.
• Envoy는 시스템 오류 스트림(표준 오류)에 로그를 기록할 때 전체 프로세스에 대한 잠금을 획득합니다. 일반적으로 Envoy의 로컬 로깅은 성능 측면에서 형편없는 것으로 간주되어 개선에 많은 관심을 기울이지 않았습니다.
• 몇 가지 다른 임의 잠금이 있지만 그 중 어느 것도 성능에 중요하지 않으며 도전해서는 안 됩니다.

스레드 로컬 저장소

Envoy가 메인 스레드의 책임과 작업자 스레드의 책임을 분리하는 방식으로 인해 복잡한 처리를 메인 스레드에서 수행한 다음 고도로 동시적인 방식으로 각 작업자 스레드에 제공할 수 있어야 한다는 요구 사항이 있습니다. 이 섹션에서는 Envoy TLS(Thread Local Storage)를 높은 수준에서 설명합니다. 다음 섹션에서는 클러스터를 관리하는 데 사용되는 방법을 설명합니다.


이미 설명했듯이 메인 스레드는 Envoy 프로세스의 거의 모든 관리 및 제어 평면 기능을 처리합니다. 여기서 컨트롤 플레인은 약간 오버로드되지만 Envoy 프로세스 자체 내에서 이를 살펴보고 작업자 스레드가 수행하는 전달과 비교하면 의미가 있습니다. 일반적인 규칙은 기본 스레드 프로세스가 일부 작업을 수행한 다음 해당 작업의 결과에 따라 각 작업자 스레드를 업데이트해야 한다는 것입니다. 이 경우 작업자 스레드는 각 액세스에 대해 잠금을 획득할 필요가 없습니다..

Envoy의 TLS(스레드 로컬 스토리지) 시스템은 다음과 같이 작동합니다.

• 메인 스레드에서 실행되는 코드는 전체 프로세스에 TLS 슬롯을 할당할 수 있습니다. 이는 추상화되어 있지만 실제로는 벡터에 대한 인덱스이며 O(1) 액세스를 제공합니다.
• 메인 스레드는 임의의 데이터를 해당 슬롯에 설치할 수 있습니다. 이 작업이 완료되면 데이터가 일반 이벤트 루프 이벤트로 각 작업자 스레드에 게시됩니다.
• 작업자 스레드는 TLS 슬롯에서 읽고 거기에서 사용 가능한 모든 스레드 로컬 데이터를 검색할 수 있습니다.

매우 간단하고 믿을 수 없을 정도로 강력한 패러다임이지만 RCU(Read-Copy-Update) 차단 개념과 매우 유사합니다. 기본적으로 작업자 스레드는 작업이 실행되는 동안 TLS 슬롯의 데이터 변경 사항을 볼 수 없습니다. 변경은 작업 이벤트 사이의 휴식 기간 동안에만 발생합니다.

Envoy는 이를 두 가지 방법으로 사용합니다.

• 각 작업자 스레드에 서로 다른 데이터를 저장하면 차단 없이 데이터에 액세스할 수 있습니다.
• 각 작업자 스레드에서 읽기 전용 모드로 전역 데이터에 대한 공유 포인터를 유지합니다. 따라서 각 작업자 스레드에는 작업이 실행되는 동안 감소할 수 없는 데이터 참조 수가 있습니다. 모든 작업자가 진정하고 새로운 공유 데이터를 업로드해야만 기존 데이터가 파기됩니다. 이는 RCU와 동일합니다.

클러스터 업데이트 스레딩

이번 섹션에서는 TLS(Thread Local Storage)를 사용하여 클러스터를 관리하는 방법에 대해 설명합니다. 클러스터 관리에는 xDS API 및/또는 DNS 처리와 상태 확인이 포함됩니다.


클러스터 흐름 관리에는 다음 구성 요소와 단계가 포함됩니다.

1. Cluster Manager는 알려진 모든 클러스터 업스트림, CDS(Cluster Discovery Service) API, SDS(Secret Discovery Service) 및 EDS(Endpoint Discovery Service) API, DNS 및 활성 외부 검사를 관리하는 Envoy 내의 구성 요소입니다. 검색된 호스트와 상태를 포함하는 각 업스트림 클러스터의 "최종 일관성" 보기를 생성하는 역할을 담당합니다.
2. 상태 검사기는 활성 상태 검사를 수행하고 상태 변경 사항을 클러스터 관리자에 보고합니다.
3. CDS(Cluster Discovery Service) / SDS(Secret Discovery Service) / EDS(Endpoint Discovery Service) / DNS를 수행하여 클러스터 멤버십을 확인합니다. 상태 변경이 클러스터 관리자로 반환됩니다.
4. 각 작업자 스레드는 지속적으로 이벤트 루프를 실행합니다.
5. 클러스터 관리자는 클러스터 상태가 변경되었음을 확인하면 클러스터 상태에 대한 새로운 읽기 전용 스냅샷을 생성하여 각 작업자 스레드로 보냅니다.
6. 다음 조용한 기간 동안 작업자 스레드는 할당된 TLS 슬롯의 스냅샷을 업데이트합니다.
7. 로드 밸런싱할 호스트를 결정해야 하는 I/O 이벤트 동안 로드 밸런서는 호스트에 대한 정보를 얻기 위해 TLS(Thread local Storage) 슬롯을 요청합니다. 여기에는 잠금이 필요하지 않습니다. 또한 TLS는 로드 밸런서 및 기타 구성 요소가 캐시, 데이터 구조 등을 다시 계산할 수 있도록 업데이트 이벤트를 트리거할 수도 있습니다. 이는 이 게시물의 범위를 벗어나지만 코드의 다양한 위치에서 사용됩니다.

위 절차를 사용하면 Envoy는 차단 없이 모든 요청을 처리할 수 있습니다(앞에서 설명한 경우 제외). TLS 코드 자체의 복잡성을 제외하면 대부분의 코드는 멀티스레딩 작동 방식을 이해할 필요가 없으며 단일 스레드로 작성할 수 있습니다. 이를 통해 성능이 향상될 뿐만 아니라 대부분의 코드를 더 쉽게 작성할 수 있습니다.

TLS를 사용하는 기타 하위 시스템

Envoy에서는 TLS(Thread Local Storage) 및 RCU(Read Copy Update)가 널리 사용됩니다.

사용 예 :

• 실행 중 기능을 변경하는 메커니즘: 현재 활성화된 기능 목록은 메인 스레드에서 계산됩니다. 그런 다음 각 작업자 스레드에는 RCU 의미 체계를 사용하여 읽기 전용 스냅샷이 제공됩니다.
• 라우팅 테이블 교체: RDS(Route Discovery Service)에서 제공하는 라우팅 테이블의 경우 메인 스레드에서 라우팅 테이블이 생성됩니다. 이후에 읽기 전용 스냅샷은 RCU(Read Copy Update) 의미 체계를 사용하여 각 작업자 스레드에 제공됩니다. 이를 통해 경로 테이블을 원자적으로 효율적으로 변경할 수 있습니다.
• HTTP 헤더 캐싱: 결과적으로 각 요청에 대한 HTTP 헤더를 계산하는 것은(코어당 ~25K+ RPS를 실행하는 동안) 상당히 비용이 많이 듭니다. Envoy는 약 XNUMX초마다 중앙에서 헤더를 계산하고 이를 TLS 및 RCU를 통해 각 작업자에게 제공합니다.

다른 경우도 있지만 이전 예는 TLS가 사용되는 용도에 대한 좋은 이해를 제공해야 합니다.

알려진 성능 문제

Envoy는 전반적으로 매우 우수한 성능을 발휘하지만 매우 높은 동시성 및 처리량과 함께 사용될 때 주의가 필요한 몇 가지 주목할만한 영역이 있습니다.

• 이 문서에 설명된 대로 현재 모든 작업자 스레드는 액세스 로그 메모리 버퍼에 쓸 때 잠금을 획득합니다. 높은 동시성과 높은 처리량에서는 최종 파일에 쓸 때 순서가 잘못된 전달을 희생하여 각 작업자 스레드에 대한 액세스 로그를 일괄 처리해야 합니다. 또는 각 작업자 스레드에 대해 별도의 액세스 로그를 생성할 수 있습니다.
• 통계는 고도로 최적화되어 있지만 동시성 및 처리량이 매우 높으면 개별 통계에 대한 원자적 경합이 발생할 가능성이 높습니다. 이 문제에 대한 해결책은 중앙 카운터를 주기적으로 재설정하는 작업자 스레드당 카운터입니다. 이에 대해서는 후속 게시물에서 논의하겠습니다.
• 상당한 처리 리소스가 필요한 연결이 거의 없는 시나리오에 Envoy가 배포된 경우 현재 아키텍처는 제대로 작동하지 않습니다. 연결이 작업자 스레드 간에 고르게 분산된다는 보장은 없습니다. 이는 작업자 스레드 간 연결 교환을 허용하는 작업자 연결 균형 조정을 구현하여 해결할 수 있습니다.

결론

Envoy의 스레딩 모델은 올바르게 구성되지 않으면 잠재적으로 메모리와 연결이 낭비되는 대신 프로그래밍의 용이성과 대규모 병렬성을 제공하도록 설계되었습니다. 이 모델을 사용하면 매우 높은 스레드 수와 처리량에서 매우 우수한 성능을 발휘할 수 있습니다.
제가 Twitter에서 간략하게 언급한 것처럼 이 디자인은 DPDK(Data Plane Development Kit)와 같은 전체 사용자 모드 네트워킹 스택 위에서도 실행될 수 있으며, 이로 인해 기존 서버는 전체 L7 처리로 초당 수백만 개의 요청을 처리할 수 있습니다. 앞으로 몇 년 안에 무엇이 만들어질지 지켜보는 것은 매우 흥미로울 것입니다.
마지막 간단한 설명: 왜 Envoy를 위해 C++를 선택했는지 여러 번 질문을 받았습니다. 그 이유는 이 게시물에 설명된 아키텍처를 구축할 수 있는 널리 사용되는 유일한 산업용 언어이기 때문입니다. C++는 확실히 모든 프로젝트 또는 심지어 많은 프로젝트에 적합하지 않지만 특정 사용 사례에서는 여전히 작업을 완료하는 유일한 도구입니다.

코드 링크

이 게시물에서 논의된 인터페이스 및 헤더 구현이 포함된 파일에 대한 링크:

• github.com/lyft/envoy/blob/master/include/envoy/thread_local/thread_local.h
• github.com/lyft/envoy/blob/master/source/common/thread_local/thread_local_impl.h
• github.com/lyft/envoy/blob/master/include/envoy/upstream/cluster_manager.h
• github.com/lyft/envoy/blob/master/source/common/upstream/cluster_manager_impl.h

출처 : habr.com