Yandex.Market 검색 작동 방식 및 서버 중 하나에 오류가 발생하면 어떻게 됩니까?

안녕하세요, 제 이름은 Evgeniy입니다. 저는 Yandex.Market 검색 인프라에서 일하고 있습니다. 나는 Habr 커뮤니티에 Market의 내부 주방에 대해 이야기하고 싶습니다. 말할 것이 많습니다. 우선, 시장 검색의 작동 방식, 프로세스 및 아키텍처에 대해 알아보세요. 긴급 상황에 대처하는 방법: 서버 하나가 다운되면 어떻게 되나요? 그러한 서버가 100개 있다면 어떨까요?

또한 여러 서버에서 동시에 새로운 기능을 구현하는 방법도 배우게 됩니다. 그리고 사용자에게 불편을 주지 않으면서 복잡한 서비스를 프로덕션 환경에서 직접 테스트하는 방법도 있습니다. 일반적으로 모든 사람이 즐거운 시간을 보낼 수 있도록 시장 검색이 작동하는 방식입니다.

우리에 대해 조금 : 우리가 해결하는 문제

텍스트를 입력하거나, 매개변수로 제품을 검색하거나, 여러 매장의 가격을 비교하면 모든 요청이 검색 서비스로 전송됩니다. 검색은 마켓에서 가장 큰 서비스입니다.

우리는 market.yandex.ru, beru.ru 사이트, Supercheck 서비스, Yandex.Advisor, 모바일 애플리케이션 등 모든 검색 요청을 처리합니다. 또한 yandex.ru의 검색 결과에 제품 제안이 포함됩니다.

검색 서비스란 검색 자체뿐만 아니라 시장의 모든 제안이 포함된 데이터베이스를 의미합니다. 규모는 다음과 같습니다. 하루에 XNUMX억 개 이상의 검색 요청이 처리됩니다. 그리고 모든 것이 중단 없이 빠르게 작동하고 항상 원하는 결과를 생성해야 합니다.

무엇이 무엇인가: 시장 구조

현재 시장 구조에 대해 간략하게 설명하겠습니다. 아래 다이어그램으로 대략적으로 설명할 수 있습니다.

파트너 매장이 우리에게 온다고 가정 해 보겠습니다. 그는 내가 장난감을 팔고 싶다고 말했습니다. 이 사악한 고양이는 삐걱거리는 소리를 냅니다. 그리고 또 다른 화난 고양이는 삐걱거리는 소리가 없습니다. 그리고 그냥 고양이. 그런 다음 매장에서는 시장이 검색할 제안을 준비해야 합니다. 상점은 제안이 포함된 특수 xml을 생성하고 제휴 인터페이스를 통해 이 xml에 대한 경로를 전달합니다. 그런 다음 인덱서는 정기적으로 이 XML을 다운로드하고 오류를 확인한 다음 모든 정보를 거대한 데이터베이스에 저장합니다.

저장된 XML이 많이 있습니다. 이 데이터베이스에서 검색 색인이 생성됩니다. 인덱스는 내부 형식으로 저장됩니다. 색인을 생성한 후 레이아웃 서비스는 색인을 검색 서버에 업로드합니다.

그 결과, 데이터베이스에는 삐걱거리는 소리를 내는 화난 고양이가 나타나고, 서버에는 고양이의 색인이 나타납니다.

검색 아키텍처 부분에서 고양이를 검색하는 방법을 알려드리겠습니다.

시장 검색 아키텍처

우리는 마이크로서비스의 세계에 살고 있습니다. 들어오는 모든 요청 market.yandex.ru 많은 하위 쿼리가 발생하고 해당 처리에는 수십 개의 서비스가 포함됩니다. 다이어그램에는 몇 가지만 표시되어 있습니다.

단순화된 요청 처리 방식

각 서비스에는 놀라운 기능이 있습니다. 고유한 이름을 가진 자체 밸런서입니다.

밸런서는 서비스 관리에 있어 더 큰 유연성을 제공합니다. 예를 들어 업데이트에 종종 필요한 서버를 끌 수 있습니다. 밸런서는 서버를 사용할 수 없음을 확인하고 자동으로 요청을 다른 서버나 데이터 센터로 리디렉션합니다. 서버를 추가하거나 제거하면 로드가 서버 간에 자동으로 재분배됩니다.

밸런서의 고유 이름은 데이터 센터에 따라 달라지지 않습니다. 서비스 A가 B에 요청하면 기본적으로 밸런서 B는 요청을 현재 데이터 센터로 리디렉션합니다. 서비스를 사용할 수 없거나 현재 데이터 센터에 존재하지 않는 경우 요청은 다른 데이터 센터로 리디렉션됩니다.

모든 데이터 센터에 대한 단일 FQDN을 사용하면 서비스 A가 위치에서 완전히 추상화될 수 있습니다. B 서비스에 대한 그의 요청은 항상 처리됩니다. 단, 서비스가 모든 데이터 센터에 위치하는 경우는 예외입니다.

하지만 이 밸런서로 모든 것이 그렇게 장밋빛인 것은 아닙니다. 추가 중간 구성 요소가 있습니다. 밸런서가 불안정할 수 있으며 이 문제는 중복 서버로 해결됩니다. 또한 서비스 A와 B 사이에는 추가 지연이 있습니다. 그러나 실제로는 1ms 미만이며 대부분의 서비스에서 이는 중요하지 않습니다.

예상치 못한 상황 처리: 검색 서비스 균형 조정 및 복원력

붕괴가 발생했다고 상상해 보십시오. 삐걱거리는 고양이를 찾아야 하는데 서버가 충돌합니다. 또는 100개의 서버. 나가는 방법? 정말 고양이 없이 사용자를 남겨둘 건가요?

상황은 두렵지만 우리는 준비가 되어 있습니다. 순서대로 말씀드리겠습니다.

검색 인프라는 여러 데이터 센터에 있습니다.

설계할 때 하나의 데이터 센터를 폐쇄할 가능성도 포함합니다. 인생은 놀라움으로 가득 차 있습니다. 예를 들어 굴착기로 지하 케이블을 절단할 수 있습니다(예, 그런 일이 일어났습니다). 나머지 데이터 센터의 용량은 최대 부하를 견딜 수 있을 만큼 충분해야 합니다.

단일 데이터 센터를 생각해 봅시다. 각 데이터 센터에는 동일한 밸런서 작동 방식이 있습니다.

하나의 밸런서는 최소 XNUMX개의 물리적 서버입니다. 이러한 중복성은 신뢰성을 위해 만들어졌습니다. 밸런서는 HAProx에서 실행됩니다.

우리는 고성능, 낮은 리소스 요구 사항 및 광범위한 기능 때문에 HAProx를 선택했습니다. 우리의 검색 소프트웨어는 각 서버 내에서 실행됩니다.

한 서버가 실패할 가능성은 낮습니다. 그러나 서버가 많으면 적어도 하나가 다운될 가능성이 높아집니다.

이것이 실제로 일어나는 일입니다. 서버가 충돌합니다. 따라서 모든 서버의 상태를 지속적으로 모니터링해야 합니다. 서버가 응답을 중지하면 자동으로 트래픽 연결이 끊어집니다. 이를 위해 HAProxy에는 상태 확인 기능이 내장되어 있습니다. HTTP 요청 "/ping"을 통해 XNUMX초에 한 번씩 모든 서버로 이동합니다.

HAProxy의 또 다른 기능: 에이전트 확인을 사용하면 모든 서버를 균등하게 로드할 수 있습니다. 이를 위해 HAProxy는 모든 서버에 연결하고 현재 로드에 따라 가중치를 1부터 100까지 반환합니다. 가중치는 처리를 위해 대기열에 있는 요청 수와 프로세서의 로드를 기반으로 계산됩니다.

이제 고양이를 찾는 것에 대해. 검색 결과는 다음과 같습니다. /search?text=화난+고양이. 검색 속도를 높이려면 전체 cat 인덱스가 RAM에 맞아야 합니다. SSD에서 읽는 것조차 충분히 빠르지 않습니다.

옛날 옛적에 제안 데이터베이스는 작았으며 한 서버의 RAM이면 충분했습니다. 제안 기반이 커짐에 따라 모든 것이 더 이상 이 RAM에 맞지 않고 데이터가 샤드 1과 샤드 2의 두 부분으로 나누어졌습니다.

그러나 이런 일은 항상 발생합니다. 어떤 해결책이라도 좋은 해결책이라 할지라도 다른 문제가 발생합니다.

밸런서는 여전히 모든 서버로 이동했습니다. 그러나 요청이 들어온 컴퓨터에는 인덱스가 절반만 있었습니다. 나머지는 다른 서버에 있었습니다. 따라서 서버는 인접한 컴퓨터로 이동해야 했습니다. 두 서버 모두에서 데이터를 수신한 후 결과를 결합하고 순위를 다시 매겼습니다.

밸런서가 요청을 균등하게 분배하기 때문에 모든 서버는 단순히 데이터를 보내는 것이 아니라 순위 재지정에 참여했습니다.

주변 서버를 사용할 수 없는 경우 문제가 발생했습니다. 해결책은 우선순위가 서로 다른 여러 서버를 "이웃" 서버로 지정하는 것이었습니다. 먼저 요청이 현재 랙의 서버로 전송되었습니다. 응답이 없으면 이 데이터 센터의 모든 서버로 요청이 전송되었습니다. 그리고 마지막으로 요청이 다른 데이터 센터로 전달되었습니다.
제안 수가 늘어나면서 데이터는 네 부분으로 나누어졌습니다. 그러나 이것이 한계는 아니었습니다.

현재 XNUMX개의 샤드 구성이 사용됩니다. 또한, 더 많은 메모리를 절약하기 위해 인덱스를 검색하는 부분(검색에 사용되는 부분)과 스니펫 부분(검색에 참여하지 않는 부분)으로 나누었습니다.

하나의 서버에는 하나의 샤드에 대한 정보만 포함됩니다. 따라서 전체 인덱스를 검색하려면 서로 다른 샤드가 포함된 XNUMX개의 서버에서 검색해야 합니다.

서버는 클러스터로 그룹화됩니다. 각 클러스터에는 XNUMX개의 검색 엔진과 XNUMX개의 스니펫 서버가 포함되어 있습니다.

스니펫 서버는 정적 데이터가 포함된 키-값 데이터베이스를 실행합니다. 예를 들어 삐걱거리는 고양이에 대한 설명과 같은 문서를 발행하는 데 필요합니다. 검색 서버의 메모리에 부하가 걸리지 않도록 데이터를 별도의 서버로 특별히 전송합니다.

문서 ID는 하나의 인덱스 내에서만 고유하므로 코드 조각에 문서가 없는 상황이 발생할 수 있습니다. 글쎄요, 아니면 하나의 ID에 대해 다른 콘텐츠가 있을 것입니다. 따라서 검색이 작동하고 결과가 반환되려면 전체 클러스터에 걸쳐 일관성이 필요했습니다. 일관성을 모니터링하는 방법을 아래에서 설명하겠습니다.

검색 자체는 다음과 같이 구성됩니다. 검색 요청은 1개의 서버 중 하나에 올 수 있습니다. 그가 서버 XNUMX에 왔다고 가정해 보겠습니다. 이 서버는 모든 인수를 처리하고 무엇을 어떻게 찾아야 하는지 이해합니다. 들어오는 요청에 따라 서버는 필요한 정보에 대해 외부 서비스에 추가 요청을 할 수 있습니다. 하나의 요청 뒤에 외부 서비스에 대한 요청이 최대 XNUMX개까지 올 수 있습니다.

필요한 정보를 수집한 후 제안 데이터베이스에서 검색이 시작됩니다. 이를 위해 클러스터에 있는 XNUMX개 서버 모두에 하위 쿼리가 생성됩니다.

응답이 수신되면 결과가 결합됩니다. 결국 결과를 생성하려면 코드 조각 서버에 대한 하위 쿼리가 여러 개 더 필요할 수 있습니다.

클러스터 내의 검색 쿼리는 다음과 같습니다. /shard1?text=화난+고양이. 또한 클러스터 내의 모든 서버 간에 XNUMX초에 한 번씩 다음 형식의 하위 쿼리가 지속적으로 생성됩니다. /상태.

주장 /상태 서버를 사용할 수 없는 상황을 감지합니다.

또한 검색 엔진 버전과 인덱스 버전이 모든 서버에서 동일하도록 제어합니다. 그렇지 않으면 클러스터 내에 일관되지 않은 데이터가 있게 됩니다.

하나의 스니펫 서버가 XNUMX개 검색 엔진의 요청을 처리한다는 사실에도 불구하고 해당 프로세서의 로드는 매우 적습니다. 따라서 이제 스니펫 데이터를 별도의 서비스로 전송하고 있습니다.

데이터를 전송하기 위해 문서용 범용 키를 도입했습니다. 이제 하나의 키를 사용하여 다른 문서의 콘텐츠를 반환하는 상황은 불가능합니다.

그러나 다른 아키텍처로의 전환은 아직 완료되지 않았습니다. 이제 전용 스니펫 서버를 제거하려고 합니다. 그런 다음 클러스터 구조에서 완전히 벗어나십시오. 이를 통해 계속해서 쉽게 확장할 수 있습니다. 추가 보너스는 상당한 철분 절약입니다.

이제 해피엔딩으로 끝나는 무서운 이야기를 살펴보겠습니다. 서버를 사용할 수 없는 몇 가지 사례를 고려해 보겠습니다.

끔찍한 일이 발생했습니다. 서버 한 대를 사용할 수 없습니다.

하나의 서버를 사용할 수 없다고 가정해 보겠습니다. 그러면 클러스터의 나머지 서버가 계속 응답할 수 있지만 검색 결과는 불완전합니다.

상태 확인을 통해 /상태 인접한 서버는 하나를 사용할 수 없음을 이해합니다. 따라서 완전성을 유지하기 위해 클러스터의 모든 서버는 요청별로 /핑 그들은 또한 사용할 수 없다는 밸런서에 응답하기 시작합니다. 클러스터의 모든 서버가 종료된 것으로 나타났습니다(사실이 아님). 이것이 우리 클러스터 계획의 주요 단점입니다. 이것이 바로 우리가 클러스터 계획에서 벗어나고 싶은 이유입니다.

오류로 인해 실패한 요청은 다른 서버의 밸런서에 의해 다시 전송됩니다.
또한 밸런서는 작동하지 않는 서버로의 사용자 트래픽 전송을 중지하지만 계속해서 상태를 확인합니다.

서버가 사용 가능해지면 응답하기 시작합니다. /핑. 죽은 서버의 핑에 대한 정상적인 응답이 도착하자마자 밸런서는 그곳으로 사용자 트래픽을 보내기 시작합니다. 클러스터 작동이 복원되었습니다. 만세.

더 나쁜 점은 많은 서버를 사용할 수 없다는 것입니다.

데이터 센터의 서버 중 상당 부분이 절단되었습니다. 무엇을 해야 할지, 어디로 달려야 할까요? 밸런서가 다시 구출됩니다. 각 밸런서는 현재 라이브 서버 수를 메모리에 지속적으로 저장합니다. 현재 데이터센터가 처리할 수 있는 최대 트래픽 양을 지속적으로 계산합니다.

데이터 센터의 많은 서버가 다운되면 밸런서는 이 데이터 센터가 모든 트래픽을 처리할 수 없다는 것을 인식합니다.

그러면 초과 트래픽이 다른 데이터 센터로 무작위로 분산되기 시작합니다. 모든 것이 작동하고 모두가 행복합니다.

수행 방법: 릴리스 게시

이제 서비스 변경 사항을 게시하는 방법에 대해 이야기해 보겠습니다. 여기에서 우리는 프로세스를 단순화하는 길을 택했습니다. 새 릴리스 출시는 거의 완전히 자동화되었습니다.
프로젝트에 일정 개수의 변경 사항이 누적되면 자동으로 새 릴리스가 생성되고 해당 빌드가 시작됩니다.

그런 다음 서비스가 테스트 단계로 출시되어 운영 안정성이 확인됩니다.

동시에 자동 성능 테스트가 시작됩니다. 이는 특별 서비스에 의해 처리됩니다. 지금은 그것에 대해 이야기하지 않겠습니다. 이에 대한 설명은 별도의 기사에 합당합니다.

테스트 게시가 성공하면 prestable 릴리스 게시가 자동으로 시작됩니다. Prestable은 일반 사용자 트래픽이 전달되는 특수 클러스터입니다. 오류가 반환되면 밸런서는 프로덕션에 다시 요청합니다.

Prestable에서는 응답 시간을 측정하고 프로덕션의 이전 릴리스와 비교합니다. 모든 것이 정상이면 사람이 연결되어 로드 테스트의 그래프와 결과를 확인한 다음 프로덕션으로 롤아웃을 시작합니다.

모든 것이 사용자에게 돌아갑니다: A/B 테스트

서비스 변경이 실질적인 이점을 가져올지 여부가 항상 명확한 것은 아닙니다. 변화의 유용성을 측정하기 위해 사람들은 A/B 테스트를 생각해 냈습니다. Yandex.Market 검색에서 어떻게 작동하는지 조금 말씀드리겠습니다.

모든 것은 새로운 기능을 활성화하는 새로운 CGI 매개변수를 추가하는 것부터 시작됩니다. 매개변수를 다음과 같이 설정합니다. market_new_function=1. 그런 다음 코드에서 플래그가 있으면 이 기능을 활성화합니다.

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

새로운 기능이 프로덕션에 출시되고 있습니다.

A/B 테스트를 자동화하기 위해 자세한 정보를 제공하는 전용 서비스가 있습니다. 여기에 설명되어 있습니다. 서비스에서 실험이 생성됩니다. 트래픽 공유는 예를 들어 15%로 설정됩니다. 백분율은 쿼리가 아닌 사용자를 위해 설정됩니다. 실험 기간도 표시됩니다(예: 일주일).

여러 실험을 동시에 실행할 수 있습니다. 설정에서 다른 실험과의 교차가 가능한지 여부를 지정할 수 있습니다.

결과적으로 서비스는 자동으로 인수를 추가합니다. market_new_function=1 사용자의 15%에게. 또한 선택한 측정항목을 자동으로 계산합니다. 실험이 완료된 후 분석가는 결과를 보고 결론을 도출합니다. 조사 결과에 따라 생산 또는 개선에 착수하기로 결정됩니다.

시장의 능숙한 손: 생산 테스트

프로덕션 환경에서 새로운 기능의 작동을 테스트해야 하지만 부하가 심한 "전투" 조건에서 해당 기능이 어떻게 작동할지 확신할 수 없는 경우가 종종 있습니다.

해결책이 있습니다. CGI 매개변수의 플래그는 A/B 테스트뿐만 아니라 새로운 기능을 테스트하는 데에도 사용할 수 있습니다.

우리는 서비스를 위험에 노출시키지 않고 수천 대의 서버에서 구성을 즉시 변경할 수 있는 도구를 만들었습니다. '스톱 탭'이라고 합니다. 원래 아이디어는 레이아웃 없이 일부 기능을 빠르게 비활성화할 수 있는 것이었습니다. 그런 다음 도구가 확장되고 더욱 복잡해졌습니다.

서비스 흐름 다이어그램은 다음과 같습니다.

플래그 값은 API를 통해 설정됩니다. 관리 서비스는 이러한 값을 데이터베이스에 저장합니다. 모든 서버는 XNUMX초마다 한 번씩 데이터베이스로 이동하여 플래그 값을 펌핑하고 이 값을 각 요청에 적용합니다.

정지 탭에서는 두 가지 유형의 값을 설정할 수 있습니다.

1) 조건식. 값 중 하나가 true인 경우 적용됩니다. 예를 들어:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

요청이 DC3 위치에서 처리되면 값 "1"이 적용됩니다. 그리고 beru.ru 사이트에 대한 두 번째 클러스터에서 요청이 처리될 때 값은 "4"입니다.

2) 무조건적인 가치. 어떤 조건도 충족되지 않으면 기본적으로 적용됩니다. 예를 들어:

가치, 가치!

값이 느낌표로 끝나면 더 높은 우선순위가 부여됩니다.

CGI 매개변수 파서는 URL을 구문 분석합니다. 그런 다음 Stop Tap의 값을 적용합니다.

다음 우선순위의 값이 적용됩니다.

1. Stop Tap(느낌표)의 우선순위가 높아졌습니다.
2. 요청 값입니다.
3. 정지 탭의 기본값입니다.
4. 코드의 기본값입니다.

조건부 값으로 표시되는 많은 플래그가 있습니다. 이는 우리에게 알려진 모든 시나리오에 충분합니다.

• 데이터 센터.
• 환경: 프로덕션, 테스트, 섀도우.
• 장소: 마켓, 베루.
• 클러스터 번호.

이 도구를 사용하면 특정 서버 그룹(예: 하나의 데이터 센터에서만)에서 새로운 기능을 활성화하고 전체 서비스에 대한 특별한 위험 없이 이 기능의 작동을 테스트할 수 있습니다. 어딘가에서 심각한 실수를 하여 모든 것이 무너지기 시작하고 전체 데이터 센터가 다운되더라도 밸런서는 요청을 다른 데이터 센터로 리디렉션합니다. 최종 사용자는 아무 것도 눈치 채지 못할 것입니다.

문제가 발견되면 즉시 플래그를 이전 값으로 되돌릴 수 있으며 변경 사항은 롤백됩니다.

이 서비스에는 단점도 있습니다. 개발자는 이 서비스를 매우 좋아하고 종종 모든 변경 사항을 Stop Tap에 적용하려고 합니다. 우리는 오용을 근절하기 위해 노력하고 있습니다.

Stop Tap 접근 방식은 프로덕션에 출시할 준비가 된 안정적인 코드가 이미 있는 경우에 잘 작동합니다. 동시에, 당신은 여전히 ​​의구심을 갖고 있으며 "전투" 조건에서 코드를 확인하고 싶습니다.

그러나 Stop Tap은 개발 중 테스트에는 적합하지 않습니다. "섀도우 클러스터"라는 개발자를 위한 별도의 클러스터가 있습니다.

비밀 테스트: 섀도우 클러스터

클러스터 중 하나의 요청이 섀도우 클러스터에 복제됩니다. 그러나 밸런서는 이 클러스터의 응답을 완전히 무시합니다. 작동 다이어그램은 다음과 같습니다.

실제 "전투" 조건에 있는 테스트 클러스터를 얻습니다. 일반 사용자 트래픽이 그곳으로 이동합니다. 두 클러스터의 하드웨어는 동일하므로 성능과 오류를 비교할 수 있습니다.

그리고 밸런서는 응답을 완전히 무시하므로 최종 사용자는 섀도우 클러스터의 응답을 볼 수 없습니다. 그러므로 실수하는 것은 무섭지 않습니다.

조사 결과

그렇다면 시장 검색은 어떻게 구축했나요?

모든 일을 원활하게 진행하기 위해 기능을 별도의 서비스로 분리합니다. 이런 방식으로 필요한 구성요소만 확장하고 구성요소를 더 단순하게 만들 수 있습니다. 별도의 구성 요소를 다른 팀에 할당하고 해당 작업에 대한 책임을 공유하는 것은 쉽습니다. 이 접근 방식을 사용하면 철분을 크게 절약할 수 있다는 점은 분명한 장점입니다.

섀도우 클러스터는 또한 우리에게 도움이 됩니다. 서비스를 개발하고 프로세스에서 테스트하며 사용자를 방해하지 않을 수 있습니다.

물론 프로덕션 테스트도 마찬가지입니다. 수천 대의 서버에서 구성을 변경해야 합니까? 간단합니다. Stop Tap을 사용하세요. 이렇게 하면 이미 만들어진 복잡한 솔루션을 즉시 출시하고 문제가 발생할 경우 안정적인 버전으로 롤백할 수 있습니다.

끊임없이 증가하는 제안 기반을 통해 시장을 빠르고 안정적으로 만드는 방법을 보여줄 수 있었으면 좋겠습니다. 서버 문제를 해결하고, 엄청난 수의 요청을 처리하고, 서비스의 유연성을 향상시키며, 작업 프로세스를 중단하지 않고 이를 수행하는 방법입니다.

출처 : habr.com