10억개 수준의 검색엔진을 구축하고 유지하는 것은 쉽지 않으며, 단번에 찾아오는 최적의 관리 방법도 없습니다. 본 글은 지속적인 학습과 실무 요약의 결과로, 수천만에서 수억에 이르는 제품을 지원할 수 있는 검색 시스템을 구축하고, 전체 쿼리 QPS가 수백에서 수천으로 증가하는 것을 실현하고, 작성하는 방법을 소개합니다. 총 QPS 레벨 100에서 레벨 10,000으로 증가하는 과정입니다. 그 중에서도 ES 자원 확장은 필수적이지만, 이 글에서는 확장으로 해결할 수 없는 몇 가지 ES 성능 문제에 대해서도 집중적으로 살펴보겠습니다. 이 기사를 통해 ES 사용 시나리오에 대한 더 많은 데이터와 사용 참고 자료를 얻을 수 있기를 바랍니다. 지면의 제약으로 인해 안정성 거버넌스에 대한 부분은 다음 글에서 소개하도록 하겠습니다.

사업소개

플랫폼 투자 관리 시스템은 Douyin 전자상거래 플랫폼 활동의 다중 엔터티 투자 시나리오를 제공하며, 투자 플랫폼을 통해 제품을 수집 및 선택한 후 다양한 C 측 시스템에 제품을 배포합니다. 투자를 유치하는 주체도 생방송방, 상품투자, 쿠폰투자 등 매우 다양합니다. 그 중 상품투자는 당사의 최대 투자주체입니다.

투자 플랫폼 서비스 구조

데이터 센터

데이터센터는 구성 가능하고 확장 가능하며 보편적인 데이터 수집 및 조정 서비스를 제공하는 ES 기반 검색 서비스입니다. 투자 플랫폼에서 데이터 쿼리를 지원하는 보편적인 서비스입니다.

이해해야 할 주요 개념:

지표 : 지표는 제품명, 매장 경험 점수, 전문가 수준, 등록 기록 ID 등 개체 또는 개체의 속성을 설명하는 데 사용하는 메타데이터입니다. 동시에 최소한의 업데이트 및 획득일 수도 있습니다. 상품 가격 비교 정보 등의 단위입니다. 명확한 의미를 지닌 모든 필드를 지표로 정의할 수 있습니다 .
집합(Set) : 상품속성집합, 매장속성집합 등 일부 공통성에 의해 수렴될 수 있는 집합을 나타내며, 각각 상품ID와 매장ID로 얻을 수 있으며, 상품등록기록 모음일 수도 있다. 등록기록 ID 입니다. 비즈니스 용어로 관련 지표들의 집합을 표현하며, 지표들은 일대다 관계에 있습니다.
솔루션 : 데이터 수집 솔루션은 데이터를 가장 작은 단위로 얻을 수 있고 지속적으로 수평적으로 확장할 수 있도록 지표와 컬렉션의 두 가지 개념을 추상화합니다. 솔루션은 다양한 컬렉션에서 지표를 얻는 방법을 추상화하는 데 도움이 됩니다.
사용자 정의 헤더 : 사용자 정의 헤더는 2차원 행 데이터 목록에 표시되는 제목을 의미하며 표시기와 일대다 관계를 갖습니다.
필터 항목 : 필터 항목은 2차원 행 데이터 목록에서 사용해야 하는 필터 항목을 의미하며 1:1 관계를 나타낼 수 있습니다.
감사 보기 : 감사 보기는 감사 비즈니스 시나리오의 사용자 정의 헤더 집합과 필터 항목 집합에서 동적으로 렌더링할 수 있는 감사 페이지를 나타냅니다.

기능적 설계에서는 지표-->[필터 항목, 사용자 정의 헤더]-->감사 보기-->최종적으로 감사 페이지를 동적으로 렌더링하는 프로세스를 통해 여러 엔터티와 여러 시나리오로 투자를 모집하므로 서로 다른 엔터티가 있습니다. 다양한 감사 보기가 필요하므로 우리가 설계한 이 일련의 기능은 필요한 감사 보기 효과를 동적으로 결합할 수 있습니다.

데이터 센터는 데이터 동기화 및 데이터 쿼리를 포함하여 상위 계층 비즈니스를 위한 일반적인 데이터 수집 기능을 제공합니다. 현재 외부 RPC 인터페이스와 등록 기록 ES라는 두 가지 데이터 소스가 있습니다. 데이터 센터는 두 가지 데이터 수집 솔루션 세트를 통합하고 외부 세계를 전혀 인식하지 못합니다. 즉, 어떤 데이터 지표가 수집되는지만 얻으면 됩니다. .

ES 구축의 목적은 투자등록기록의 심사 및 통계 기능을 지원하고, 상위사업에 원하는 데이터 콘텐츠를 출력하는 것입니다.

0에서 1까지 ES 클러스터 구축

0에서 1까지의 시스템을 구축하려면 기본적인 비즈니스 요구 사항을 충족하는 것을 기반으로 안정성이 다음 두 가지 사항을 지원해야 합니다.

기본 재해 복구 메커니즘은 기본 구성 요소와 읽기 및 쓰기 트래픽의 변경으로 인해 시스템 성능이 영향을 받을 때 비즈니스가 제때에 스스로 조정할 수 있음을 의미합니다.
데이터의 최종 일관성은 등록기록 DB --> ES 다중 기계실 데이터가 완성되었음을 의미합니다.

프로그램 연구

ES 클러스터 용량 평가

ES 클러스터 용량 평가는 클러스터가 구축된 후 일정 기간 동안 안정적인 서비스를 제공할 수 있는지 확인하는 것입니다. 주로 다음 문제를 해결할 수 있어야 합니다.

각 인덱스에 대해 얼마나 많은 샤드를 설정해야 하는지, 후속 데이터 증가가 예상되는 정도, 예상 트래픽 읽기 및 쓰기 등이 포함됩니다.
단일 클러스터에 얼마나 많은 데이터 인스턴스를 설정해야 하는지, 단일 데이터 인스턴스에는 어떤 사양을 사용해야 하는지.
수직적 확장과 수평적 확장의 차이점을 이해하고, 데이터량이 예기치 않게 급증하거나 트래픽이 급증할 때의 대응 전략은 무엇인지, ES 클러스터 재해 복구는 어떻게 설계해야 하는지를 이해합니다.

주요 솔루션:

ES 인덱스 샤드 수는 한번 설정되면 수정할 수 없으므로 샤드 수를 결정하는 것이 중요합니다. 일반적으로 샤드 수는 로드 밸런싱을 보장하기 위해 ES 인스턴스의 정수배입니다.
단일 샤드의 크기는 10~30G 사이로 비교적 합리적입니다. 과도한 인덱싱은 쿼리 성능에 영향을 미칩니다.
트래픽 급증은 용량 확장으로 해결할 수 있고, 데이터 급증은 오래된 데이터를 삭제하거나 샤드 수를 늘려 해결할 수 있으며, 다중 머신룸 재해 복구 구축 계획으로 구축해야 서로 재해에 강한 기계실입니다.

데이터 동기화 링크 선택

주로 DB 등록 기록을 ES에 동기화하는 방법, 기타 관련 지표를 ES에 쓰는 방법, 데이터 일관성을 업데이트하고 보장하는 방법을 해결합니다.

DB -> ES는 준실시간 데이터 스트림이어야 하며, 등록 기록 및 기타 정보의 변경 사항을 준실시간으로 검색할 수 있어야 합니다.
등록 레코드는 자체 필드 외에도 등록된 상품, 매장, 전문가 등의 속성 필드를 보완해야 하며 ES에도 작성되고 부분 업데이트를 지원할 수 있으므로 ES 작성 방법은 Upsert 방법만 가능합니다. ;
개별 등록 기록에 대한 업데이트는 순서대로 이루어져야 하며 충돌해서는 안 됩니다.

ES지수 기본구성 조사

필수적인 ES 기본 사항 및 구성을 이해합니다.

{"dynamic": false}는 es 매핑의 자동 확장이나 예상치 못한 인덱스 유형의 추가를 방지합니다.
index.translog.durability=async, translog를 비동기적으로 새로 고치면 쓰기 성능을 향상시키는 데 도움이 되지만 데이터 손실 위험이 있습니다.
ES의 기본 새로 고침 간격은 1초입니다. 이는 쓰기 성공 후 1초 만에 데이터를 찾을 수 있음을 의미합니다.

데이터 동기화 솔루션

데이터 동기화 링크 다이어그램

DB --> ES 데이터 동기화 솔루션은 궁극적으로 다중 기계실 소비를 위해 이기종 데이터를 RocketMQ + Flink에 동기적으로 쓰는 방식을 채택합니다. 동시에 등록 기록이 처음으로 기록되면 확장 표시가 채워집니다. Faas 사용자 정의 변환 스크립트를 통해 확장 표시기의 업데이트 종속성은 메시지 수신 및 예약 작업의 두 가지 방법을 변경합니다. 조사 과정에서 실제로 DB -> ES 다중 컴퓨터실에는 세 가지 옵션이 있었습니다. 결국 세 번째 옵션을 선택했습니다.

해결 방법 1: 이기종 데이터 동기화(Dsyncer)를 통해 ES 다중 기계실에 직접 쓰기

결점:

직접 쓰기는 여러 개의 이기종 데이터를 동시에 배포하고 별도로 쓰는 것이 여러 컴퓨터실에서 성공적인 쓰기를 보장할 수 없기 때문에 여러 컴퓨터실을 동시에 배포해야 하는 ES의 요구 사항을 충족하는 데 불리합니다. 예, 즉, 작업 부하가 약 12개의 인덱스로 3배 증가합니다.
직접 쓰기 대량의 쓰기 기능은 상대적으로 약하며 트래픽 변동에 따라 쓰기 급증이 더 분명해지며 이는 ES의 쓰기 성능에 적합하지 않습니다.
ES에 여러 업데이트 항목이 있는 경우 직접 작성하면 단일 등록 레코드의 순차적 업데이트가 보장되지 않습니다. 글로벌 버전을 늘릴 수 있나요? 예, 하지만 너무 무거워요.

장점: 가장 짧은 종속성 경로, 낮은 쓰기 대기 시간 및 최소 시스템 위험은 소규모 트래픽 비즈니스 및 간단한 동기화 시나리오를 사용하는 비즈니스에는 전혀 문제가 되지 않습니다.

옵션 2: RocketMQ를 통해 ES 단일 컴퓨터실 작성

DB가 RocketMQ를 통해 ES 단일 전산실에 쓴 후, ES가 제공하는 데이터 클러스터 간 복제 기능을 통해 데이터가 다른 전산실에 동기화됩니다.

옵션 3: RocketMQ + Flink를 통해 ES 다중 기계실 작성 ✅

DB가 RocketMQ를 통해 ES 클러스터에 쓰면 여러 개의 독립적인 소비자 그룹 작업이 시작됩니다. 시스템은 Flink 분산 시스템을 사용하여 여러 컴퓨터실에 데이터를 쓸 수 있습니다.

방식 2와 방식 3에는 단 한 가지 차이점이 있습니다. 여러 컴퓨터실에 쓰는 방법이 다릅니다. 방식 2는 하나의 컴퓨터실에 쓴 다음 준실시간으로 다른 컴퓨터실에 데이터를 동기화하는 것입니다. 세 번째는 여러 독립 소비자 방을 별도로 작성하는 것입니다.

옵션 2와 3의 단점은 동일합니다. 종속성 경로가 가장 길고 쓰기 지연이 기본 구성 요소의 지터에 쉽게 영향을 받습니다. 그러나 옵션 2의 치명적인 단점은 단일 위험 지점이 있다는 것입니다. LF를 통해 데이터가 HL 및 LQ에 동기화되었다고 가정하면 LF가 끊긴 후에는 시스템을 사용할 수 없게 됩니다 .

옵션 3의 장점은 여러 컴퓨터실의 쓰기 링크가 서로 독립적이라는 점입니다. 옵션 2에 비해 링크에 문제가 있어도 비즈니스에 위험을 초래하지 않으며 RocketMQ는 단일 키 순차적 업데이트 문제를 쉽게 해결할 수 있습니다. , 이는 옵션 1 때문에 바람직하지 않습니다 .

RocketMQ를 통해 글쓰기를 하면 왜 질서와 갈등의 문제를 해결할 수 있을까요?

우선 ES 쓰기는 버전 번호를 기반으로 한 낙관적 잠금으로 제어됩니다. 동일한 레코드가 동시에 동시에 업데이트되면 동시에 얻는 버전은 동일하며 1이라고 가정하면 모두가 됩니다. 쓰기 위해 버전을 2로 업데이트하면 충돌이 발생하고 충돌로 인해 항상 업데이트 손실 문제가 발생합니다.
일반 비즈니스 시나리오에서는 키 및 파티션 순서를 기반으로 한 순서대로 소비해야 합니다. 순서대로 사용하려면 두 가지 필수 조건이 필요합니다. 즉, 메시지가 저장될 때 메시지가 소비되는 순서와 일치해야 합니다. 어디에 저장되어 있는지.

따라서 기업이 메시지를 순서대로 소비하려면 동일한 Key를 사용하여 전송된 메시지가 동일한 파티션으로 전송되도록 해야 하며, 소비된 메시지는 동일한 Key를 가진 메시지가 항상 동일한 파티션에서 소비되도록 보장해야 합니다. 동일한 소비자. 그러나 실제로는 위에서 언급한 두 가지 필수 조건이 완벽하게 보장되지 않는 경우도 있습니다. 예를 들어 특정 Broker 인스턴스 작성이 계속 실패하는 경우는 다음과 같습니다.

RocketMQ 파티션 순서를 보여주는 그림

지정된 Topic에 대해 모든 메시지는 Sharding Key에 따라 여러 개(Queue)로 나누어집니다.
동일한 대기열의 메시지는 엄격한 FIFO 순서에 따라 게시되고 소비됩니다.
Sharding Key는 순차적 메시지에서 서로 다른 파티션을 구분하기 위해 사용되는 키 필드로, 일반 메시지의 Key와는 전혀 다른 개념입니다.
적용 가능한 시나리오: 고성능 요구 사항 메시지의 분할 키를 기반으로 메시지가 전송되는 대기열을 결정합니다. 일반적으로 질서 있는 분할은 비즈니스 요구 사항을 충족할 수 있으며 성능이 뛰어납니다.

여기서 주목해야 할 점은 RocketMQ 가 비즈니스에서 잘못된 순서 문제의 99%를 해결하는 데 도움이 되었을 수 있지만 100%는 아니라는 점입니다. 극단적인 경우에는 메시지에 여전히 잘못된 순서 사용 문제가 있을 수 있습니다. Partiton이 실패하는 등의 ABA 현상으로 메시지가 다른 Partition Queue 등으로 반복적으로 전송되므로 일관성 조정이 필수적입니다.

다층 조정 메커니즘

조정 메커니즘은 DB->ES의 데이터 일관성 문제를 해결합니다. 앞서 언급한 것처럼 DB -> ES는 준실시간 데이터 흐름이며 종속성 링크가 상대적으로 길기 때문에 다양한 상태에서 해당 모니터링이 필요합니다. 최종 데이터 일관성을 보장하기 위한 조정 및 보상 전략.

여기서는 3단계 조정을 수행했습니다. 분 단위 조정과 오프라인 조정을 달성하기 위해 조정 플랫폼을 사용합니다. 다단계 조정이 필요한 이유는 아래에서 하나씩 설명합니다.

DB 동기화 ES 링크 장애 분석 다이어그램

비즈니스 검증 플랫폼( BCP ) 2차 조정

위 그림을 보면 DB --> ES 동기화가 여러 종속 구성요소에 의존하고 있음을 알 수 있습니다. 이 경우 동기화 링크 문제, 즉 BCP 실시간 조정을 발견하기 위해서는 글로벌 관점의 조정이 필요합니다.

BCP 조정은 Binlog를 모니터링하고 ES 다중 기계실 조정을 직접 확인하는 단일 스트림 조정입니다. Binlog 스트림에만 의존합니다. 중간 링크의 데이터 동기화 지연이나 차단은 BCP 조정을 통해 빠르게 발견할 수 있습니다. Binlog가 끊어지고 BCP 조정이 불가능할 경우 이 상황을 해결하는 방법은 나중에 논의되지만 적어도 DB->DBus를 제외하면 BCP 조정만으로 대부분의 동기화 지연을 발견하기에 충분하다는 것을 알 수 있습니다. 문제. 다중 스트림이 아닌 단일 스트림을 사용하는 이유는 무엇입니까?

멀티 스트림 조정을 위한 긴 데이터 흐름 링크로 인해 발생하는 제어할 수 없는 지연 문제를 방지하여 검증 정확도가 낮아집니다.
멀티 스트림을 사용하는 경우 유지 관리를 위해 더 기본적인 구성 요소에 의존하는 다중 컴퓨터실 조정을 위해 여러 BCP 조정을 유지해야 하기 때문에 BCP 조정의 유지 관리 비용이 크게 절감됩니다.

BCP 조정 DB 쓰기는 항상 ES의 특정 쿼리 리소스를 소비하는 ES Get 요청을 트리거하지만 Get 요청은 성능이 매우 좋은 쿼리 방법입니다. 예를 들어 1000 QPS 내에서는 쓰기에 문제가 없습니다.

Get 요청은 요청 시 False로 설정되어야 하는 Realtime 매개변수에 주의를 기울여야 합니다. 그렇지 않으면 요청될 때마다 새로 고침 작업이 트리거되어 시스템 쓰기 성능에 영향을 미칩니다.

mgetReq := EsClient.MultiGet(). 실시간(거짓)

분 단위 조정

앞선 절에서 언급했듯이 BCP(Business Verification Platform) 조정이 커버할 수 없는 경로는 DB->DBus인데, 이는 Binlog가 끊어지는 상황이다. 일반적으로 Binlog 중단은 더 심각한 사고를 의미할 수 있지만, 우리가 해야 할 일은 가능한 모든 조치를 취하는 것입니다.

분 단위 조정은 어떤 구성 요소에도 의존하지 않고 DB와 ES에 직접 쿼리하여 불일치가 발생하면 자동 보상이 수행됩니다. 한편으로는 분 단위 조정으로 BCP 조정의 단점을 보완하고, 두 번째로는 보상 메커니즘을 추가한다는 점이다. BCP가 보상하지 않는 이유는 BCP가 주로 문제를 발견하기 위한 것이므로 가볍고 빠르다는 점을 유지해야 하며, 여전히 RocketMQ 및 DBus와 같은 기본 구성 요소에 의존하기 때문입니다.

기본적으로 3분마다 조정을 위해 컴포넌트 기능은 그대로 유지되지만 노드의 짧은 지연으로 인해 보상이 발생하는 것으로 간주합니다. 보상 알람이 자주 발생하는 경우 링크에 어떤 문제가 있는지 추가 분석이 필요합니다. 이때 저희 시나리오에서는 링크를 2개로 나누어 RocketMQ의 이전 링크에 문제가 있는지, RocketMQ와 후속 소비 링크에 문제가 있는지 확인하도록 하겠습니다. 오류 분석 다이어그램을 통해 Binlog 중단, 이기종 데이터 동기화 플랫폼 구성 요소 중단 등 RocketMQ 이전 링크에 문제가 있는 경우 보상 데이터가 RocketMQ에 직접 기록되어 여러 컴퓨터실에서 소비됩니다. 시간이 지나면 읽기 트래픽을 차단할 필요가 없으며 여러 컴퓨터실의 데이터 일관성을 보장할 수 있습니다. 그러나 RocketMQ가 중단되면 ES에 직접 기록됩니다. 현재로서는 여러 컴퓨터실이 동시에 성공적으로 기록될 수 있다고 보장할 수 없기 때문에 단일 컴퓨터실에만 기록하고 모든 트래픽을 다음으로 전환하기로 결정했습니다. 단 하나의 컴퓨터실.

RocketMQ 끊김은 매우 나쁜 신호이며 여기서 상황은 더 복잡합니다. ES에 대한 직접 쓰기로 인해 쓰기 트래픽이 높을 경우 시스템은 현재 제한 보호를 상실하며 ES는 이를 견딜 수 없으며 단일 컴퓨터실은 모든 읽기 트래픽을 견딜 수 없습니다. 동시에 쓰기 충돌이 자주 발생하면 비즈니스 쓰기 포트를 다운그레이드해야 합니다. 따라서 RocketMQ가 끊기면 쓰기 링크의 중앙 시스템이 마비되는 것으로 이해할 수 있습니다. 이는 가장 보고 싶지 않은 것이므로 RocketMQ의 SLA가 비즈니스의 기본입니다.

T+1 오프라인 조정

오프라인 조정은 매일 DB와 ES의 데이터를 Hive에 동기화하는 것이며, 증분 데이터가 일치하지 않는 경우 자동으로 보상이 시작됩니다. 데이터는 늦어도 +1 보상에 성공해야 합니다.

요약하다

위에서 구축, 재해 복구 배포, 일관성 조정 및 기본 시스템 예외 대응 전략의 첫 번째 단계를 완료했습니다. 현재 ES는 수천만 개의 제품 인덱스에 대한 읽기 및 쓰기 요청을 지원할 수 있습니다. 단일 전산실의 트래픽은 500~100 QPS 사이에서 변동하며, 쓰기 트래픽은 기본적으로 500 QPS 정도에서 유지됩니다.

그러나 비즈니스가 발전함에 따라 ES 클러스터는 CPU 급증을 여러 번 경험했으며, 하나 이상의 컴퓨터실이 동시에 가득 차고 쿼리 지연이 갑자기 증가했지만 읽기 및 쓰기 트래픽은 크게 변동하지 않거나 그렇지 않습니다. 이는 시스템 피크보다 훨씬 적습니다. 이는 ES 클러스터에서 발생하는 성능 문제와 기업의 사용 자세에 기인합니다. 이 부분은 ES 검색엔진의 안정성 관리에 대한 다음 글에서 계속 소개하도록 하겠습니다.

기사 출처 ByteDance 비즈니스 플랫폼 Wang Dan

0에서 1까지 10억급 제품 ES 검색엔진 구축