ElasticSearch를 사용하여 Highload 프로젝트에서 로드 최적화

헤이 하브르! 저는 FINCH에서 분석가이자 프로젝트 관리자로 일하고 있는 Maxim Vasiliev입니다. 오늘 저는 ElasticSearch를 사용하여 15분 만에 6만 건의 요청을 처리하고 고객 사이트의 일일 로드를 최적화할 수 있었던 방법을 말씀드리고자 합니다. 불행히도 우리는 NDA가 있기 때문에 이름없이해야 할 것입니다. 기사의 내용이 이로 인해 고통받지 않기를 바랍니다. 갑시다.

프로젝트 작동 방식

백엔드에서 고객의 웹사이트 및 모바일 애플리케이션의 성능을 보장하는 서비스를 만듭니다. 일반적인 구조는 다이어그램에서 볼 수 있습니다.

작업 과정에서 우리는 구매, 결제, 사용자 잔액이 있는 작업 등 많은 트랜잭션을 처리하며 많은 로그를 저장하고 이 데이터를 외부 시스템으로 가져오고 내보냅니다.

클라이언트로부터 데이터를 받아 사용자에게 전달할 때도 역과정이 있습니다. 또한 지불 및 보너스 프로그램 작업을 위한 프로세스가 아직 남아 있습니다.

간략한 배경

처음에는 PostgreSQL을 유일한 데이터 저장소로 사용했습니다. DBMS에 대한 표준 이점: 트랜잭션의 존재, 개발된 데이터 샘플링 언어, 광범위한 통합 도구 좋은 성능과 결합하여 꽤 오랫동안 우리의 요구를 충족시켰습니다.

거래부터 뉴스까지 모든 데이터를 Postgres에 저장했습니다. 그러나 사용자 수가 증가했고 이에 따라 요청 수도 증가했습니다.

이해를 돕기 위해 2017년 데스크톱 사이트의 연간 세션 수는 131억 2018만입니다. 125년에는 2019억 130만, 100년에는 다시 200억 XNUMX만입니다. 모바일 버전 사이트와 모바일 애플리케이션에서 XNUMX억 ~ XNUMX억을 추가하면 엄청난 수의 요청을 받게 됩니다.

프로젝트가 성장함에 따라 Postgres는 부하 처리를 중단했고 시간이 없었습니다. 다양한 쿼리가 많이 나타나 충분한 수의 인덱스를 만들 수 없었습니다.

우리는 우리의 요구 사항을 제공하고 PostgreSQL의 부담을 덜어줄 다른 데이터 저장소가 필요하다는 것을 이해했습니다. Elasticsearch와 MongoDB가 가능한 옵션으로 고려되었습니다. 후자는 다음과 같은 점에서 패배했습니다.

1. 인덱스의 데이터 양이 증가함에 따라 인덱싱 속도가 느려집니다. Elastic을 사용하면 데이터 양에 따라 속도가 달라지지 않습니다.
2. 전체 텍스트 검색 없음

그래서 우리는 스스로 Elastic을 선택했고 전환을 준비했습니다.

Elastic으로 전환

1. 판매 시점 검색 서비스에서 전환을 시작했습니다. 우리 고객은 총 약 70개의 판매 지점을 보유하고 있으며 이를 위해서는 사이트와 애플리케이션에서 여러 유형의 검색이 필요합니다.

• 도시 이름으로 텍스트 검색
• 어떤 지점에서 주어진 반경 내에서 지오서치. 예를 들어, 사용자가 자신의 집에서 가장 가까운 판매 지점을 확인하려는 경우입니다.
• 지정된 사각형으로 검색 - 사용자가 지도에 사각형을 그리면 이 반경의 모든 지점이 사용자에게 표시됩니다.
• 추가 필터로 검색합니다. 판매 지점은 구색이 서로 다릅니다.

조직에 대해 이야기하면 Postgres에는 지도와 뉴스 모두에 대한 데이터 소스가 있고 Elastic Snapshots에서는 원본 데이터에서 가져옵니다. 사실 처음에는 Postgres가 모든 기준으로 검색에 대처할 수 없었습니다. 인덱스가 많을 뿐만 아니라 중복될 수 있기 때문에 Postgres 스케줄러가 길을 잃고 어떤 인덱스를 사용해야 하는지 이해하지 못했습니다.

2. 다음 줄은 뉴스 섹션이었습니다. 간행물은 사용자가 정보의 흐름에서 길을 잃지 않도록 매일 사이트에 나타나며 발행하기 전에 데이터를 정렬해야 합니다. 이것이 검색의 목적입니다. 텍스트 일치로 사이트를 검색하고 동시에 추가 필터를 연결할 수 있습니다. 필터도 Elastic을 통해 만들어지기 때문입니다.

3. 그런 다음 거래 처리를 옮겼습니다. 사용자는 사이트에서 특정 제품을 구매하고 경품 추첨에 참여할 수 있습니다. 이러한 구매 후에는 특히 주말과 공휴일에 많은 양의 데이터를 처리합니다. 비교를 위해 평일 구매 건수가 1,5 ~ 2 만 건이면 휴일에는 53 만 건에 달할 수 있습니다.

동시에 데이터는 가능한 한 최단 시간 내에 처리되어야 합니다. 사용자는 며칠 동안 결과를 기다리는 것을 좋아하지 않습니다. Postgres를 통해 이러한 기한을 달성할 수 있는 방법은 없습니다. 우리는 종종 잠금을 받았고 모든 요청을 처리하는 동안 사용자는 상품을 받았는지 여부를 확인할 수 없었습니다. 이것은 비즈니스에 그다지 유쾌하지 않기 때문에 처리를 Elasticsearch로 옮겼습니다.

주기율

이제 업데이트는 다음 조건에 따라 이벤트 기반으로 구성됩니다.

1. 판매 포인트. 외부 소스에서 데이터를 수신하는 즉시 업데이트를 시작합니다.
2. 소식. 뉴스가 사이트에서 편집되는 즉시 자동으로 Elastic으로 전송됩니다.

여기서 다시 Elastic의 장점을 언급할 가치가 있습니다. Postgres에서는 요청을 보낼 때 정직하게 모든 레코드를 처리할 때까지 기다려야 합니다. 10개의 레코드를 Elastic에 보내고 레코드가 모든 샤드에 배포될 때까지 기다리지 않고 즉시 작업을 시작할 수 있습니다. 물론 일부 Shard 또는 Replica는 데이터를 바로 볼 수 없지만 곧 모든 것을 사용할 수 있습니다.

통합 방법

Elastic과 통합하는 방법에는 두 가지가 있습니다.

1. TCP를 통한 기본 클라이언트를 통해. 기본 드라이버는 점차 사라지고 있습니다. 더 이상 지원되지 않으며 구문이 매우 불편합니다. 따라서 실제로 사용하지 않고 완전히 버리려고합니다.
2. JSON 요청과 Lucene 구문을 모두 사용할 수 있는 HTTP 인터페이스를 통해. 마지막은 Elastic을 사용하는 텍스트 엔진입니다. 이 버전에서는 HTTP를 통한 JSON 요청을 통해 일괄 처리할 수 있습니다. 이것은 우리가 사용하려고 하는 옵션입니다.

HTTP 인터페이스 덕분에 HTTP 클라이언트의 비동기 구현을 제공하는 라이브러리를 사용할 수 있습니다. 우리는 Batch와 비동기식 API를 활용할 수 있으며, 그 결과 높은 성능을 얻을 수 있으며 이는 대규모 프로모션 기간 동안 많은 도움이 되었습니다(자세한 내용은 아래 참조).

비교를 위한 몇 가지 숫자:

• 그룹화 없이 20개의 스레드에서 Postgres 바운티 사용자 저장: 460713초에 42개의 레코드
• 탄력적 + 10개의 스레드에 대한 반응형 클라이언트 + 1000개의 요소에 대한 배치: 596749초에 11개 레코드
• 10개의 스레드에 대한 Elastic + 반응형 클라이언트 + 1000개의 요소에 대한 배치: 23801684분 안에 4개 항목

이제 JSON을 Batch가 아닌 Batch로 빌드하고 라이브러리에 관계없이 모든 HTTP 클라이언트를 통해 전송하는 HTTP 요청 관리자를 작성했습니다. 동기식 또는 비동기식으로 요청을 보내도록 선택할 수도 있습니다.

일부 통합에서는 여전히 공식 전송 클라이언트를 사용하지만 이는 다음 리팩토링의 문제일 뿐입니다. 이 경우 Spring WebClient를 기반으로 구축된 사용자 정의 클라이언트가 처리에 사용됩니다.

큰 승진

XNUMX년에 한 번 이 프로젝트는 사용자를 위한 큰 프로모션을 개최합니다. 이것은 현재 수천만 명의 사용자와 동시에 작업하기 때문에 동일한 Highload입니다.

일반적으로 휴일에 최대 부하가 발생하지만 이번 프로모션은 완전히 다른 수준입니다. 재작년 프로모션 당일 27개의 상품을 판매했습니다. 데이터가 580분 이상 처리되어 사용자에게 불편을 끼쳤습니다. 사용자는 참여에 대한 보상을 받았지만 프로세스를 가속화해야 한다는 것이 분명해졌습니다.

2019년 초에 우리는 ElasticSearch가 필요하다고 결정했습니다. XNUMX년 내내 우리는 수신된 데이터를 Elastic에서 처리하고 모바일 애플리케이션 및 웹사이트의 API에서 발급하는 작업을 조직했습니다. 그 결과 내년 캠페인 기간 동안 15분 동안 131개의 항목.

상품을 구매하고 경품추첨에 참여하고 싶은 분들이 많아 일시적인 조치입니다. 지금은 Elastic에 최신 정보를 보내고 있지만 앞으로 몇 달 동안 보관된 정보를 Postgres에 영구 저장소로 전송할 계획입니다. 한계가 있는 Elastic 인덱스를 막히지 않기 위해서입니다.

결론/결론

현재 우리가 원했던 모든 서비스를 Elastic으로 이전했으며 지금은 이 작업을 일시 중지했습니다. 이제 우리는 사용자 부하를 인계받는 Postgres의 기본 영구 스토리지 위에 Elastic에 인덱스를 구축하고 있습니다.

향후 데이터 요청이 너무 다양해지고 열 수에 제한이 없는 것으로 파악되면 서비스를 이전할 계획입니다. 이것은 더 이상 Postgres의 작업이 아닙니다.

기능상 전체 텍스트 검색이 필요하거나 다양한 검색 기준이 있는 경우 이를 Elastic으로 번역해야 한다는 것을 이미 알고 있습니다.

⌘⌘⌘

읽어 주셔서 감사합니다. 귀사에서도 ElasticSearch를 사용하고 자체 구현 사례가 있는 경우 알려주십시오. 다른 사람들이 어떤지 아는 것은 흥미로울 것입니다 🙂

출처 : habr.com