모놀리식 애플리케이션에서 마이크로서비스 아키텍처로 전환하면서 우리는 새로운 과제에 직면하게 됩니다.

모놀리식 애플리케이션에서는 일반적으로 시스템의 어느 부분에서 오류가 발생했는지 확인하는 것이 매우 쉽습니다. 대부분의 경우 문제는 모놀리스 자체의 코드나 데이터베이스에 있습니다. 그러나 마이크로서비스 아키텍처에서 문제를 찾기 시작하면 모든 것이 더 이상 명확하지 않습니다. 요청이 처음부터 끝까지 이동한 전체 경로를 찾아 수백 개의 마이크로서비스 중에서 선택해야 합니다. 더욱이 그들 중 다수는 자체 저장 시설을 가지고 있기 때문에 논리적 오류는 물론 성능 및 내결함성 문제도 발생할 수 있습니다.

나는 그러한 문제를 해결하는 데 도움이 되는 도구를 오랫동안 찾고 있었습니다. (나는 Habré에 이에 대해 썼습니다: 1, 2), 하지만 결국에는 나만의 오픈 소스 솔루션을 만들었습니다. 이 기사에서는 서비스 메시 접근 방식의 이점에 대해 설명하고 해당 구현을 위한 새로운 도구를 공유합니다.

분산 추적은 분산 시스템에서 오류를 찾는 문제에 대한 일반적인 솔루션입니다. 그러나 네트워크 상호 작용에 대한 정보를 수집하는 이러한 접근 방식이 아직 시스템에 구현되지 않았거나, 더 나쁘게도 시스템의 일부에서는 이미 제대로 작동하지만 부분적으로는 이전 서비스에 추가되지 않았기 때문에 작동하지 않는 경우에는 어떻게 될까요? ? 문제의 정확한 근본 원인을 파악하려면 시스템에서 무슨 일이 일어나고 있는지에 대한 완전한 그림이 필요합니다. 주요 비즈니스에 중요한 경로에 어떤 마이크로서비스가 관련되어 있는지 이해하는 것이 특히 중요합니다.

여기에서는 서비스 자체가 작동하는 것보다 낮은 수준에서 네트워크 정보를 수집하기 위한 모든 기계를 처리하는 서비스 메시 접근 방식이 도움이 될 수 있습니다. 이 접근 방식을 사용하면 모든 트래픽을 가로채서 즉시 분석할 수 있습니다. 게다가 애플리케이션은 이에 대해 아무것도 알 필요조차 없습니다.

서비스 메시 접근 방식

서비스 메시 접근 방식의 주요 아이디어는 네트워크를 통해 또 다른 인프라 계층을 추가하는 것입니다. 이를 통해 서비스 간 상호 작용으로 모든 작업을 수행할 수 있습니다. 대부분의 구현은 다음과 같이 작동합니다. 투명한 프록시가 있는 추가 사이드카 컨테이너가 각 마이크로서비스에 추가되고, 이를 통해 서비스의 모든 들어오고 나가는 트래픽이 전달됩니다. 그리고 바로 이곳에서 클라이언트 밸런싱을 수행하고, 보안 정책을 적용하고, 요청 수에 제한을 가하고, 프로덕션 서비스 상호 작용에 대한 중요한 정보를 수집할 수 있습니다.

솔루션

이 접근 방식은 이미 여러 가지 구현이 있습니다. 이스 티오 и 링커드2. 그들은 기본적으로 많은 기능을 제공합니다. 그러나 동시에 리소스에 큰 오버헤드가 발생합니다. 더욱이, 그러한 시스템이 운영되는 클러스터가 클수록 새로운 인프라를 유지하는 데 더 많은 리소스가 필요합니다. Avito에서는 수천 개의 서비스 인스턴스를 포함하는 kubernetes 클러스터를 운영하고 있으며 그 수는 계속해서 빠르게 증가하고 있습니다. 현재 구현에서 Istio는 서비스 인스턴스당 최대 300Mb의 RAM을 사용합니다. 가능성이 많기 때문에 투명한 균형 조정은 서비스의 전체 응답 시간(최대 10ms)에도 영향을 미칩니다.

그 결과, 우리는 지금 당장 필요한 기능이 무엇인지 정확히 살펴보았고, 이러한 솔루션을 구현하기 시작한 주된 이유는 전체 시스템에서 추적 정보를 투명하게 수집하는 능력이라고 판단했습니다. 우리는 또한 서비스의 상호 작용을 제어하고 서비스 간에 전송되는 헤더를 사용하여 다양한 조작을 원했습니다.

그 결과, 우리는 다음과 같은 결정을 내렸습니다.  네트라메시.

네트라메시

네트라메시 시스템의 서비스 수에 관계없이 무한히 확장할 수 있는 경량 서비스 메시 솔루션입니다.

새로운 솔루션의 주요 목표는 낮은 리소스 오버헤드와 높은 성능이었습니다. 주요 기능 중 우리는 즉시 추적 범위를 Jaeger 시스템에 투명하게 보낼 수 있기를 원했습니다.

오늘날 대부분의 클라우드 솔루션은 Golang으로 구현됩니다. 물론 여기에는 이유가 있습니다. I/O와 비동기적으로 작동하고 필요에 따라 코어 전체에 확장되는 네트워크 애플리케이션을 Golang으로 작성하는 것은 편리하고 매우 간단합니다. 그리고 또한 매우 중요한 것은 성능이 이 문제를 해결하기에 충분하다는 것입니다. 그래서 우리도 Golang을 선택했습니다.

Производительность

우리는 최대의 생산성을 달성하기 위해 노력을 집중해 왔습니다. 서비스의 각 인스턴스 옆에 배포되는 솔루션의 경우 RAM 및 CPU 시간이 약간 소모됩니다. 그리고 물론 응답 지연도 작아야 합니다.

우리가 어떤 결과를 얻었는지 봅시다.

램

Netramesh는 트래픽 없이 ~10Mb를 소비하고 인스턴스당 최대 50RPS의 로드로 최대 10000Mb를 소비합니다.

Istio 특사 프록시는 수천 개의 인스턴스가 있는 클러스터에서 항상 ~300Mb를 소비합니다. 이는 전체 클러스터로 확장되는 것을 허용하지 않습니다.

Netramesh를 사용하면 메모리 소비가 최대 10배 감소했습니다.

CPU

CPU 사용량은 로드 시 상대적으로 동일합니다. 사이드카에 대한 단위 시간당 요청 수에 따라 다릅니다. 최대 초당 요청 3000건의 값:

한 가지 더 중요한 점이 있습니다. Netramesh - 컨트롤 플레인과 로드가 없는 솔루션은 CPU 시간을 소비하지 않습니다. Istio를 사용하면 사이드카가 항상 서비스 엔드포인트를 업데이트합니다. 결과적으로 우리는 로드 없이 이 그림을 볼 수 있습니다:

우리는 서비스 간 통신을 위해 HTTP/1을 사용합니다. Envoy를 통해 프록시할 때 Istio의 응답 시간 증가는 최대 5~10ms였으며, 이는 밀리초 내에 응답할 준비가 된 서비스의 경우 상당히 많은 시간입니다. Netramesh를 사용하면 이 시간이 0.5-2ms로 단축되었습니다.

확장성

각 프록시는 소량의 리소스를 소비하므로 이를 각 서비스 옆에 배치하는 것이 가능합니다. Netramesh는 단순히 각 사이드카를 가볍게 유지하기 위해 제어 평면 구성 요소 없이 의도적으로 만들어졌습니다. 서비스 메시 솔루션에서 제어 플레인은 서비스 검색 정보를 각 사이드카에 배포하는 경우가 많습니다. 이와 함께 시간 초과 및 균형 조정 설정에 대한 정보도 제공됩니다. 이 모든 기능을 통해 많은 유용한 작업을 수행할 수 있지만 불행히도 사이드카의 크기가 부풀려집니다.

서비스 발견

Netramesh는 서비스 검색을 위한 추가 메커니즘을 추가하지 않습니다. 모든 트래픽은 Netra 사이드카를 통해 투명하게 프록시 처리됩니다.

Netramesh는 HTTP/1 애플리케이션 프로토콜을 지원합니다. 이를 정의하기 위해 구성 가능한 포트 목록이 사용됩니다. 일반적으로 시스템에는 HTTP 통신이 이루어지는 여러 포트가 있습니다. 예를 들어 서비스와 외부 요청 간의 상호 작용에는 80, 8890, 8080을 사용하는데, 이 경우 환경 변수를 사용하여 설정할 수 있습니다. NETRA_HTTP_PORTS.

Kubernetes를 오케스트레이터로 사용하고 서비스 간 클러스터 내 통신을 위한 해당 서비스 엔터티 메커니즘을 사용하는 경우 메커니즘은 정확히 동일하게 유지됩니다. 먼저 마이크로서비스는 kube-dns를 사용하여 서비스 IP 주소를 획득하고 이에 대한 새 연결을 엽니다. 이 연결은 먼저 로컬 netra-sidecar를 통해 설정되며 모든 TCP 패킷은 처음에 netra에 도착합니다. 다음으로 netra-sidecar는 원래 대상과의 연결을 설정합니다. 노드의 포드 IP에 대한 NAT는 netra가 없는 것과 정확히 동일하게 유지됩니다.

분산 추적 및 컨텍스트 전달

Netramesh는 HTTP 상호 작용에 대한 추적 범위를 보내는 데 필요한 기능을 제공합니다. Netra-sidecar는 HTTP 프로토콜을 구문 분석하고, 요청 지연을 측정하고, HTTP 헤더에서 필요한 정보를 추출합니다. 궁극적으로 우리는 단일 Jaeger 시스템에서 모든 추적을 얻습니다. 세분화된 구성을 위해 공식 라이브러리에서 제공하는 환경 변수를 사용할 수도 있습니다. 예거 도서관에 가다.

하지만 문제가 있습니다. 서비스가 특별한 uber 헤더를 생성하고 보낼 때까지 시스템에서 연결된 추적 범위를 볼 수 없습니다. 그리고 이것이 바로 문제의 원인을 빠르게 찾아내기 위해 필요한 것입니다. 여기에서도 Netramesh가 해결책을 가지고 있습니다. 프록시는 HTTP 헤더를 읽고 Uber 추적 ID가 포함되어 있지 않으면 헤더를 생성합니다. Netramesh는 또한 사이드카에 들어오고 나가는 요청에 대한 정보를 저장하고 필요한 나가는 요청 헤더로 이를 강화하여 일치시킵니다. 서비스에서 해야 할 일은 헤더 하나만 보내는 것 뿐입니다. X-Request-Id, 환경 변수를 사용하여 구성할 수 있음 NETRA_HTTP_REQUEST_ID_HEADER_NAME. Netramesh에서 컨텍스트 크기를 제어하려면 다음 환경 변수를 설정할 수 있습니다. NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (컨텍스트가 저장되는 시간) 및 NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (컨텍스트 정리 빈도).

특수 세션 토큰으로 표시하여 시스템의 여러 경로를 결합하는 것도 가능합니다. Netra를 사용하면 다음을 설치할 수 있습니다. HTTP_HEADER_TAG_MAP HTTP 헤더를 해당 추적 범위 태그로 변환합니다. 이는 테스트에 특히 유용할 수 있습니다. 기능 테스트를 통과한 후 해당 세션 키를 기준으로 필터링하면 시스템의 어느 부분이 영향을 받았는지 확인할 수 있습니다.

요청 소스 결정

요청이 어디서 왔는지 확인하려면 소스와 함께 헤더를 자동으로 추가하는 기능을 사용할 수 있습니다. 환경 변수 사용 NETRA_HTTP_X_SOURCE_HEADER_NAME 자동으로 설치될 헤더 이름을 지정할 수 있습니다. 사용하여 NETRA_HTTP_X_SOURCE_VALUE 모든 나가는 요청에 대해 X-Source 헤더가 설정될 값을 설정할 수 있습니다.

이를 통해 이 유용한 헤더를 네트워크 전체에 균일하게 배포할 수 있습니다. 그런 다음 이를 서비스에서 사용하고 로그 및 지표에 추가할 수 있습니다.

트래픽 라우팅 및 Netramesh 내부

Netramesh는 두 가지 주요 구성 요소로 구성됩니다. 첫 번째인 netra-init는 트래픽을 가로채기 위한 네트워크 규칙을 설정합니다. 그는 사용한다 iptables 리디렉션 규칙 Netramesh의 두 번째 주요 구성 요소인 사이드카의 트래픽 전체 또는 일부를 차단합니다. 들어오고 나가는 TCP 세션에 대해 가로채야 하는 포트를 구성할 수 있습니다. INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

이 도구에는 확률적 라우팅이라는 흥미로운 기능도 있습니다. 추적 범위 수집을 위해 Netramesh를 독점적으로 사용하는 경우 프로덕션 환경에서 리소스를 절약하고 변수를 사용하여 확률적 라우팅을 활성화할 수 있습니다. NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0에서 1까지). 기본값은 1(모든 트래픽이 차단됨)입니다.

차단에 성공한 후 Netra 사이드카는 새 연결을 수락하고 다음을 사용합니다. SO_ORIGINAL_DST 원래 대상을 가져오는 소켓 옵션입니다. 그런 다음 Netra는 원래 IP 주소에 대한 새 연결을 열고 당사자 간에 양방향 TCP 통신을 설정하여 통과하는 모든 트래픽을 수신합니다. 포트가 HTTP로 정의된 경우 Netra는 포트를 구문 분석하고 추적하려고 시도합니다. HTTP 구문 분석이 실패하면 Netra는 TCP로 대체되어 바이트를 투명하게 프록시합니다.

종속성 그래프 작성

Jaeger에서 많은 양의 추적 정보를 받은 후 시스템의 상호 작용에 대한 완전한 그래프를 얻고 싶습니다. 그러나 시스템 로드가 상당히 많고 하루에 수십억 개의 추적 범위가 누적되는 경우 이를 집계하는 것은 그리 쉬운 작업이 아닙니다. 이를 수행하는 공식적인 방법이 있습니다: 스파크 종속성. 그러나 완전한 그래프를 작성하는 데는 몇 시간이 걸리며 지난 XNUMX시간 동안 Jaeger에서 전체 데이터 세트를 다운로드해야 합니다.

Elasticsearch를 사용하여 추적 범위를 저장하는 경우 다음을 사용할 수 있습니다. 간단한 Golang 유틸리티, Elasticsearch의 기능을 사용하여 몇 분 안에 동일한 그래프를 구축합니다.

Netramesh를 사용하는 방법

Netra는 오케스트레이터를 실행하는 모든 서비스에 쉽게 추가할 수 있습니다. 예를 볼 수 있습니다 여기에.

현재 Netra에는 서비스에 사이드카를 자동으로 구현하는 기능이 없지만 구현 계획이 있습니다.

네트라메시의 미래

주요 목표 네트라메시 서비스 간 통신에 대한 관찰 및 제어를 위한 기본 기능을 제공하여 최소한의 리소스 비용과 높은 성능을 달성하는 것입니다.

앞으로 Netramesh는 HTTP 외에 다른 애플리케이션 계층 프로토콜을 지원할 예정입니다. L7 라우팅은 가까운 시일 내에 제공될 예정입니다.

유사한 문제가 발생하면 Netramesh를 사용하고 질문과 제안 사항을 보내주십시오.

출처 : habr.com