Vinted 검색 확장 2장: srouter를 사용하여 Elasticsearch 요청

Elasticsearch 클러스터 업그레이드에서 시작됩니다.모든 주요 Elasticsearch 버전은 새로운 기능, 무료 성능, 호환성 문제와 불확실성을 가져온다.
또한 우리는 요청을 분석하여 요청과 응답을 결합시켜 분석하고 압력 테스트의 조회를 기록하며 매초의 모든 요청을 해석하고 싶습니다.
이러한 수요를 고려하여 우리는 메인 응용 프로그램 옆에 sidecar 구성 요소를 구축했다.
맨 왼쪽 구성 요소는 핵심 프로그램입니다. 여러 개의 Elasticsearch 그룹이 검색 요청을 처리하고 있는지 모릅니다.
다음 구성 요소는 sidecar 프로그래밍 언어로 작성된 Rust 서비스입니다. 우리는 srouter라고 부릅니다.
그림1.스루트
Srouter sidecar는 검색 요청 경로를 여러 개의 Elasticsearch 그룹에 연결하는 세분화 제어를 제공합니다. 이것은 실시간 생산 작업 부하 테스트와 비교적 다른 Elasticsearch 버전을 사용할 수 있도록 해 줍니다. 생산에 영향을 주지 않습니다.
서비스는 특정 HTTP 요청 경로를 세분화할 수 있는 간단하고 읽기 쉬운 방식으로 구성됩니다.
또는 greedy, 용례에 따라 요구합니다.
다음은 간단한 구성 예입니다.

--------
whitelist_ends_with:
  - /_count
  - /_search
routes:
  main-items/_search:
    main:
      - http://127.0.0.1:1000
    mirror:
      - http://127.0.0.1:1010
    amplify: 4
    timeout: 311

  lt-main-items/_count:
    main:
      - http://127.0.0.1:1100
    timeout: 100
    sampling: 10
    storage:
      - http://dc1-host.example.com:8082/topics/storage

  default:
    main:
      - http://127.0.0.1:2000
    timeout: 200

생산을 작성할 때 우리는 10개의 맞춤형 노선을 정의했는데 생산 과정에서 어떤 노선을 변경하는 데 최대 30분이 걸리고 대부분의 시간을 배치에 쓴다.
설정은git 저장소에 저장되어 변경 사항을 추적합니다.구성 예에서는 미러링 트래픽이 4배로 확대된 greedy 노선이 있습니다.
제2조main-items/_search 루트의 시간 초과는 100ms이고 10%의 요청이 샘플링Kafka되었다.
일치하지 않는 라우트가 lt-main-items/_count 라우트로 반환됩니다.스루터는 사용하는 HTTP 방법에 대해 까다롭다. 서비스는 모든 경로의 HTTP GET 요청을 허용하고, HTTP POST 요청은 화이트 리스트이며, 그 어떠한 상황에서도 서비스가 되돌아온다. 405: method not allowed 상태.
HTTP 방법은 의외로 인덱스를 삭제하고 직접 인덱스를 삭제하는 것을 방지하며 엔지니어가 Elasticsearch의 스위치에 안전하게 접근하는 것을 충당할 수 있다.
구성 유연성은 특정 유형의 요청을 처리하는 데 전문적으로 사용되는 Elasticsearch 집단을 만들어 상상력을 방출하고 검색 규모를 길들인다.
SIGHUP 신호를 사용하여 서비스 중단 없이 구성 라우트를 원활하게 업데이트합니다.
업데이트 신호를 받은 후 atomic pointer를 사용하여 새로운 경로를 업데이트함으로써 업데이트를 완성합니다.
원자 바늘은 relaxed memory ordering 동기화되어 새로 업데이트된 HashMap 경로를 가리킨다.
스루터는 OSI layer 7 공유기로서 밑바닥hyper 서버와 tokio이 비동기적으로 실행될 때 구축된다.
Rust는 성능으로 유명하기 때문에 이 서비스도 예외가 아니다. 이 서비스는 초당 500k개의 요청을 제공할 수 있고, 10밀리초마다 200개의 루트를 업데이트할 수 있다.
스루터의 단일 실례 생산 자원 점용은 CPU 1개당 tokio 핵심 스레드 1개를 차지하고 전체 가상 메모리는 124메가바이트이며 대부분의 메모리(97%)는 Prometheus metrics 서비스에서 공개적으로 사용된다.
이 서비스가 제공하는 지표는 labeled개의 요청 경로이다.
sidecar 서비스에서 탭의 집중화는 주요 응용 프로그램을 더욱 간단하게 합니다.
라벨 도량은 조회 빈도와 수량에 대한 기본적인 이해를 제공합니다. 생산 전에 오류 요청을 검측하고, 모든 요청의 비율을 측정하며, 요청의 정확한 수량을 추적하는 데 도움이 됩니다.
지표 외에, 우리는 일부 조회와 모든 성공하지 못한 응답에 대해 샘플링을 진행한다.
요청, 응답 헤더, srouter를 통해 요청을 완성하는 데 필요한 서비스 시간과 Elasticsearch 응답을 통해 샘플링 요청을 풍부하게 했다.
저장된 요청/응답 조합은 Elasticsearchslow query logs를 반대하고 입출력 활동을 줄이며 조회의 충전 샘플을 개선할 수 있습니다.
검색의 전체 견본은'느린'(그 중에서 느린 것은 내부 ES 도량에 의해 정의될 뿐만 아니라 검색 요청 대기열, 색인 부하, GC 등) 검색을 통해 견본을 채취할 수 있을 뿐만 아니라 통일된 방식으로 신속하고 심지어 실패한 검색을 다시 한 번 샘플링하여 개선할 수 있다.
스루터는 우리가 계획한 확장 전략의 관건적인 서비스로 증명되었다.Anthony Williams는 C++Concurrency in Action[1]에서 "프로세서가 증가함에 따라 작업을 수행하는 데 필요한 시간(시간 감소)을 줄이거나 주어진 시간 내에 처리할 수 있는 데이터 양을 늘리는 것(처리량 증가)"이라고 신축성을 정의했다.
우리는 두 가지 간단한 예scaling cubes를 총결하였다.
그림2.입방체 축척
미래의 장에서 우리가 어떻게'축소 입방체'를 사용하여 Elasticsearch를 축소하는지 연구할 것이다.
읽은 거 좋아해요?저희는 현재 검색 엔지니어를 모집하여 더 많은 정보를 얻고 있습니다here.
참조:

[1] Anthony Williams에서 작성한 C++ 동시 작업https://www.manning.com/books/c-plus-plus-concurrency-in-action

Brian L.Troutwinehttps://www.amazon.com/Hands-Concurrency-Rust-Confidently-memory-safe/dp/1788399978 Rust에서 메모리 보안, 병렬 및 효율적인 소프트웨어 구축

도쿄https://github.com/tokio-rs/tokio

초과https://hyper.rs,https://github.com/hyperium/hyper

축척 입방체: https://en.wikipedia.org/wiki/Scale_cube

탐욕의 정규 표현식: https://www.regular-expressions.info/repeat.html