Azure AI Search에서 대용량 데이터 세트 인덱싱
검색 솔루션에서 크거나 복잡한 데이터 집합을 인덱싱해야 하는 경우 이 문서에서는 Azure AI Search에서 장기 실행 프로세스를 수용하기 위한 전략을 살펴봅니다.
이러한 전략은 데이터를 가져오기 위한 두 가지 기본 방법, 즉 데이터를 인덱스로 푸시하거나 검색 인덱서로 지원되는 데이터 원본에서 데이터를 가져오는 방법을 잘 알고 있다고 가정합니다. 시나리오에 계산 집약적인 AI 보강이 포함되는 경우 인덱서에 대한 기술 세트 종속성을 고려할 때 인덱서가 필요합니다.
이 문서에서는 인덱스 및 쿼리 디자인에 대한 모범 사례를 제공하는 더 나은 성능을 위한 팁을 보완합니다. 필요한 필드와 특성만 포함하는 잘 설계된 인덱스는 대규모 인덱싱을 위한 중요한 필수 구성 요소입니다.
파티션당 더 높은 스토리지를 위해 2024년 4월 3일 이후에 만든 최신 검색 서비스를 사용하는 것이 좋습니다.
참고 항목
이 문서에서 설명하는 전략은 하나의 큰 데이터 원본을 가정합니다. 솔루션에 여러 데이터 원본의 인덱싱이 필요한 경우 권장 방법은 Azure AI Search의 여러 데이터 원본 인덱싱을 참조하세요.
푸시 API를 사용하여 데이터 인덱싱
문서 인덱스 REST API 또는 IndexDocuments 메서드(.NET용 Azure SDK)와 같은 푸시 API는 Azure AI Search에서 가장 널리 사용되는 인덱싱 형식입니다. 푸시 API를 사용하는 솔루션의 경우 장기 실행 인덱싱 전략에는 다음 구성 요소 중 하나 또는 둘 다 있습니다.
- 문서 일괄 처리
- 스레드 관리
요청당 여러 문서 일괄 처리
대량의 데이터를 인덱싱하는 간단한 메커니즘은 단일 요청에서 여러 문서 또는 레코드를 제출하는 것입니다. 전체 페이로드가 16MB 미만인 한 요청은 대량 업로드 작업에서 최대 1,000개의 문서를 처리할 수 있습니다. 이러한 한도는 .NET SDK에서 Documents Index REST API 또는 IndexDocuments 메서드를 사용하는지 여부에 관계없이 적용됩니다. 두 API 중 하나를 사용하여 각 요청의 본문에 1,000개의 문서를 패키지할 수 있습니다.
문서를 일괄 처리하면 대용량 데이터 볼륨을 통해 작업하는 데 걸리는 시간이 크게 단축됩니다. 가장 적합한 데이터 일괄 처리 크기를 결정하는 것은 인덱싱 속도를 최적화하는 핵심 구성 요소입니다. 최적의 일괄 처리 크기에 영향을 주는 두 가지 주요 요소는 다음과 같습니다.
- 인덱스의 스키마
- 데이터의 크기
최적의 일괄 처리 크기는 인덱스와 데이터에 따라 달라지므로 다양한 일괄 처리 크기를 테스트하여 시나리오에서 가장 빠른 인덱싱 속도를 달성할 수 있는 크기를 확인하는 것이 가장 좋습니다. .NET SDK를 사용하여 일괄 처리 크기를 테스트하는 샘플 코드는 자습서: 푸시 API를 사용하여 인덱싱 최적화를 참조하세요.
스레드 및 재시도 전략 관리
인덱서에는 기본 제공 스레드 관리가 있지만 푸시 API를 사용하는 경우 애플리케이션 코드에서 스레드를 관리해야 합니다. 특히 최근에 파티션을 늘리거나 더 높은 계층 검색 서비스로 업그레이드한 경우 사용 가능한 용량을 최대한 활용할 수 있는 충분한 스레드가 있는지 확인합니다.
클라이언트 코드에서 동시 스레드 수를 늘입니다.
검색 서비스에 대한 요청을 늘리면 요청이 완전히 성공하지 못했음을 나타내는 HTTP 상태 코드가 발생할 수 있습니다. 인덱싱 중에 발생하는 두 가지 일반적인 HTTP 상태 코드는 다음과 같습니다.
503 서비스를 사용할 수 없음: 이 오류는 시스템이 과부하 상태이며 현재 요청을 처리할 수 없음을 의미합니다.
207 다중 상태: 이 오류는 일부 문서가 성공했지만 하나 이상 실패했음을 의미합니다.
실패를 처리하려면 지수 백오프 다시 시도 전략을 사용하여 요청을 다시 시도해야 합니다.
Azure .NET SDK는 503 및 기타 실패한 요청을 자동으로 다시 시도하지만 207을 다시 시도하려면 사용자 고유의 논리를 구현해야 합니다. Polly와 같은 오픈 소스 도구를 사용하여 다시 시도 전략을 구현할 수도 있습니다.
인덱서 및 끌어오기 API 사용
인덱서에는 장기 실행 프로세스에 유용한 몇 가지 기능이 있습니다.
- 문서 일괄 처리
- 분할된 데이터에 대한 병렬 인덱싱
- 시간이 지남에 따라 새 문서와 변경된 문서만 인덱싱하기 위한 예약 및 변경 검색
인덱서 일정은 마지막으로 알려진 중단 지점에서 처리를 계속할 수 있습니다. 처리 창 내에서 데이터가 완전히 인덱싱되지 않은 경우 인덱서는 변경 검색을 제공하는 데이터 원본을 사용한다고 가정하여 다음 실행에서 중단된 위치를 선택합니다.
데이터를 작은 개별 데이터 원본으로 분할하면 병렬 처리가 가능합니다. Azure Blob Storage의 여러 컨테이너와 같은 원본 데이터를 분할하고 각 파티션에 대한 데이터 원본을 만든 다음, 검색 서비스의 검색 단위 수에 따라 인덱서를 병렬로 실행할 수 있습니다.
인덱서 일괄 처리 크기 확인
푸시 API와 마찬가지로 인덱서를 사용하여 일괄 처리당 항목 수를 구성할 수 있습니다. 만들기 인덱서 REST API에 따른 인덱서의 경우 batchSize 인수를 설정하여 데이터의 특징에 더 잘 일치하도록 이 설정을 사용자 지정할 수 있습니다.
기본 일괄 처리 크기는 데이터 원본에 따라 다릅니다. Azure SQL Database 및 Azure Cosmos DB의 기본 일괄 처리 크기는 1,000입니다. 반면 Azure Blob 인덱싱은 큰 평균 문서 크기를 고려하여 일괄 처리 크기를 문서 10개로 설정합니다.
장기 실행 프로세스에 대한 인덱서 예약
인덱서 예약은 큰 데이터 세트를 처리하고 보강 파이프라인에서 이미지 분석과 같이 느리게 실행되는 프로세스를 수용하기 위한 중요한 메커니즘입니다.
일반적으로 인덱서 처리는 2시간 이내에 실행됩니다. 인덱싱 워크로드를 완료하는 데 몇 시간이 아닌 며칠이 걸리는 경우 인덱서를 2시간마다 시작하는 연속된 되풀이 일정에 배치할 수 있습니다. 데이터 원본에 변경 내용 추적이 사용하도록 설정되어 있다고 가정하면 인덱서는 마지막으로 중단된 곳에서 처리를 다시 시작합니다. 이러한 주기로 인덱서는 처리되지 않은 모든 문서가 처리될 때까지 여러 날에 걸쳐 문서 백로그를 통해 작업을 수행할 수 있습니다.
{
"dataSourceName" : "hotels-ds",
"targetIndexName" : "hotels-idx",
"schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}
데이터 원본에 더 이상 새 문서나 업데이트된 문서가 없으면 인덱서 실행 기록은 처리된 문서를 보고 0/0 하며 처리가 수행되지 않습니다.
일정 설정에 대한 자세한 내용은 인덱서 REST API 만들기를 참조하거나 Azure AI Search에 대한 인덱서 예약을 참조하세요.
참고 항목
이전 런타임 아키텍처에서 실행되는 일부 인덱서는 최대 처리 기간이 2시간이 아닌 24시간입니다. 2시간 제한은 내부적으로 관리되는 다중 테넌트 환경에서 실행되는 최신 콘텐츠 프로세서에 대한 것입니다. 가능하면 Azure AI Search 인덱서 및 기술 세트 처리를 다중 테넌트 환경으로 오프로드하려고 시도합니다. 인덱서는 마이그레이션할 수 없는 경우 프라이빗 환경에서 실행되며 24시간 동안 실행할 수 있습니다. 이러한 특성을 나타내는 인덱서 예약하는 경우 24시간 처리 기간을 가정합니다.
인덱서를 병렬로 실행
데이터를 분할하는 경우 각 데이터 원본에서 끌어오고 동일한 검색 인덱스에 쓰는 여러 인덱서-데이터-원본 조합을 만들 수 있습니다. 각 인덱서는 고유하기 때문에 동시에 실행할 수 있으므로 순차적으로 실행한 경우보다 검색 인덱스가 더 빠르게 채워집니다.
충분한 용량이 있는지 확인합니다. 서비스에서 하나의 검색 단위가 지정된 시점에 하나의 인덱서를 실행할 수 있습니다. 여러 인덱서를 만드는 것은 병렬로 실행될 수 있을 때만 유용합니다.
동시에 실행할 수 있는 인덱싱 작업의 수는 텍스트 기반 인덱싱과 기술 기반 인덱싱에 따라 다릅니다. 자세한 내용은 인덱서 실행을 참조하세요.
데이터 원본이 Azure Blob Storage 컨테이너이거나 Azure Data Lake Storage Gen 2인 경우 이 작업이 완료될 때까지 많은 수의 Blob을 열거하는 데 긴 시간(심지어 수 시간)이 소요될 수 있습니다. 따라서 인덱서의 문서 성공 횟수는 해당 시간 동안 증가하지 않는 것으로 나타나며 진행되지 않는 것처럼 보일 수 있습니다. 많은 수의 Blob에 대해 문서 처리를 더 빠르게 수행하려면 데이터를 여러 컨테이너로 분할하고 단일 인덱스를 가리키는 병렬 인덱서를 만드는 것이 좋습니다.
Azure Portal에 로그인하고 검색 서비스에서 사용하는 검색 단위 수를 확인합니다. 설정>스케일링을 선택하여 페이지 맨 위에 있는 숫자를 봅니다. 병렬로 실행되는 인덱서의 수는 검색 단위 수와 거의 같습니다.
여러 컨테이너의 원본 데이터 또는 동일한 컨테이너 내의 여러 가상 폴더를 분할합니다.
각 인덱서에서 동일한 대상 검색 인덱스를 지정합니다.
인덱서를 예약합니다.
확인을 위해 인덱서 상태 및 실행 기록을 검토합니다.
병렬 인덱싱과 관련된 몇 가지 위험이 있습니다. 먼저 인덱싱이 백그라운드에서 실행되지 않으므로 쿼리가 제한되거나 삭제될 가능성이 높아집니다.
둘째, Azure AI Search는 업데이트를 위해 인덱스를 잠그지 않습니다. 동시 쓰기가 관리되어 첫 번째 시도에서 특정 쓰기가 성공하지 못하는 경우 재시도를 호출하지만 인덱싱 실패가 증가할 수 있습니다.
여러 인덱서-데이터 원본 집합은 동일한 인덱스를 대상으로 할 수 있지만 인덱스의 기존 값을 덮어쓸 수 있는 인덱서 실행에 주의해야 합니다. 두 번째 인덱서-데이터 원본이 동일한 문서와 필드를 대상으로 하는 경우 첫 번째 실행의 모든 값을 덮어씁니다. 필드 값이 전부 바뀝니다. 인덱서는 여러 실행의 값을 동일한 필드로 병합할 수 없습니다.
Spark에서 빅 데이터 인덱싱
빅 데이터 아키텍처가 있고 데이터가 Spark 클러스터에 있는 경우 데이터를 로드하고 인덱싱하는 데 SynapseML을 사용하는 것이 좋습니다. 이 자습서에는 AI 보강을 위해 Azure AI 서비스를 호출하는 단계가 포함되어 있지만 텍스트 인덱싱에 AzureSearchWriter API를 사용할 수도 있습니다.