검색 서비스의 용량 예측 및 관리
Azure AI 검색에서 용량은 워크로드로 확장할 수 있는 복제본 및 파티션을 기반으로 합니다. 복제본은 검색 엔진의 복사본입니다. 파티션은 스토리지의 단위입니다. 각 새 검색 서비스는 각각 하나씩 시작되지만 변동 워크로드를 수용하도록 복제본 및 파티션을 독립적으로 추가 또는 제거할 수 있습니다. 용량을 추가하면 검색 서비스 실행 비용이 증가합니다.
처리 속도 및 디스크 IO와 같은 복제본 및 파티션의 물리적 특성은 서비스 계층에 따라 달라집니다. 표준 검색 서비스에서 복제본과 파티션은 기본 서비스의 복제본과 파티션보다 빠르고 큽니다.
용량 변경은 즉각적으로 적용되지 않습니다. 특히 많은 양의 데이터가 있는 서비스에서 파티션을 준비하거나 서비스 해제하는 데 최대 한 시간이 걸릴 수 있습니다.
검색 서비스를 확장하는 경우 다음 도구와 방법 중에서 선택할 수 있습니다.
개념: 검색 단위, 복제본, 파티션, 분할
용량은 파티션과 복제본의 조합에 할당될 수 있는 검색 단위로 표현되며 기본 분할 메커니즘을 사용하여 유연한 구성을 지원합니다.
| 개념 | 정의 |
|---|---|
| 검색 단위 | 사용 가능한 총 용량(36개 단위)의 단일 증분입니다. Azure AI 검색 서비스에 대한 청구 단위이기도 합니다. 서비스를 실행하려면 최소한 1개의 단위가 필요합니다. |
| 복제본 | 검색 서비스의 인스턴스로 쿼리 작업을 부하 분산하는 데 주로 사용됩니다. 각 복제본은 인덱스의 사본 하나를 호스트합니다. 3개의 복제본을 할당하는 경우 쿼리 요청을 처리하는 데 사용할 수 있는 인덱스의 복사본 3개가 있는 셈입니다. |
| 파티션 | 읽기/쓰기 작업(예: 인덱스를 다시 작성하거나 새로 고치는 경우)을 위한 실제 스토리지 및 I/O를 제공합니다. 각 파티션에는 전체 인덱스의 조각이 있습니다. 3개의 파티션을 할당하면 인덱스가 1/3로 나뉩니다. |
| 분할 | 인덱스의 청크입니다. Azure AI 검색은 (새 검색 단위로 분할을 이동하여) 파티션 추가 프로세스 속도를 높이기 위해 각 검색 단위를 분할로 나눕니다. |
다음 다이어그램에서는 복제본, 파티션, 분할 및 검색 단위 간의 관계를 보여줍니다. 단일 인덱스가 2개의 복제본과 2개의 파티션이 있는 서비스에서 4개의 검색 단위에 걸쳐 존재하는 방법의 예를 보여줍니다. 4개의 각 검색 단위는 인덱스 분할의 절반만 저장합니다. 왼쪽 열에 있는 검색 단위는 분할의 첫 절반을 저장하여 첫 번째 파티션을 구성하고, 오른쪽 열은 분할의 나머지 절반을 저장하여 두 번째 파티션을 구성합니다. 2개의 복제본이 있으므로 각 인덱스 분할의 복사본이 2개 있습니다. 상단 행의 검색 단위는 1개의 복사본을 저장하여 첫 번째 복제본을 구성하고, 하단 행은 다른 복사본을 저장하여 두 번째 복제본을 구성합니다.
위의 다이어그램은 한 가지 예시에 불과합니다. 최대 36개의 검색 단위에서 파티션 및 복제본의 여러 조합을 사용할 수 있습니다.
Azure AI 검색에서 분할 관리는 구현 세부 정보이며 구성할 수 없습니다. 하지만 인덱스가 분할된다는 점을 알면 순위 지정과 자동 완성 동작 중의 간헐적인 변칙을 이해하는 데 도움이 됩니다.
순위 지정 변칙: 검색 점수가 먼저 분할 수준에서 계산된 다음 단일 결과 집합으로 집계됩니다. 분할 콘텐츠의 특성에 따라 한 분할의 일치에 다른 분할의 일치보다 더 높은 순위가 지정될 수 있습니다. 검색 결과에 직관적이지 않은 순위가 있는 경우, 특히 인덱스가 작을 때 나타나는 분할 효과 때문일 가능성이 높습니다. 전체 인덱스에서 전역적으로 점수를 계산을 선택하여 순위 지정 변칙을 피할 수 있지만 이 경우 성능 저하가 발생합니다.
자동 완성 변칙: 부분적으로 입력된 용어의 처음 몇 개 문자에서 일치가 이루어지는 자동 완성 쿼리는 철자의 작은 편차를 용인하는 유사 매개 변수를 허용합니다. 자동 완성의 경우 유사 일치는 현재 분할 내 용어로 제한됩니다. 예를 들어 분할에 "Microsoft"가 있고 부분 용어인 "micro"가 입력되면 검색 엔진에서 해당 분할의 "Microsoft"와 일치시킵니다. 하지만 인덱스의 나머지를 보유한 다른 분할에서는 일치시키지 않습니다.
예측 대상
용량 계획에는 개체 제한(예: 서비스에서 허용되는 최대 인덱스 수) 및 스토리지 제한이 포함되어야 합니다. 서비스 계층은 개체 및 스토리지 제한을 결정합니다. 먼저 도달한 제한이 유효한 한도입니다.
인덱스 및 기타 개체의 수는 일반적으로 비즈니스 및 엔지니어링 요구 사항에 따라 결정됩니다. 예를 들어 활성 개발, 테스트 및 프로덕션을 위해 동일한 인덱스의 여러 버전이 있을 수 있습니다.
저장소 요구 사항은 빌드에 필요한 인덱스 크기에 따라 결정됩니다. 추정에 도움이 되는 견고한 추론 또는 추상론은 없습니다. 인덱스의 크기를 확인하는 유일한 방법은 하나를 빌드하는 것입니다. 크기는 가져온 데이터, 텍스트 분석 및 인덱스 구성(예: 확인기, 필터링 및 정렬 사용 설정 여부)을 기반으로 합니다.
전체 텍스트 검색의 경우 주 데이터 구조는 원본 데이터와 특성이 다른 반전된 인덱스 구조입니다. 반전된 인덱스의 경우 크기와 복잡성은 피드하는 데이터의 양이 아니라 콘텐츠에 따라 결정됩니다. 높은 중복성이 있는 대형 데이터 원본은 매우 가변적 콘텐츠를 포함하는 작은 데이터 세트보다 더 작은 인덱스로 나타날 수 있습니다. 따라서 원래 데이터 세트의 크기에 따라 인덱스 크기를 유추하는 일은 거의 불가능합니다.
필터 및 정렬 사용과 같은 인덱스의 특성은 스토리지 요구 사항에 영향을 줍니다. 제안기를 사용하면 스토리지에도 영향을 미칩니다. 자세한 내용은 특성 및 인덱스 크기를 참조하세요.
참고 항목
인덱스 및 스토리지에 대한 향후 요구를 예측하는 것이 짐작에 불과하다고 느낄 수 있지만 가치 있는 작업입니다. 계층의 용량이 너무 적은 경우 더 높은 계층에서 새 서비스를 프로비전한 다음 인덱스를 다시 로드해야 합니다. 한 계층에서 다른 계층으로의 서비스의 현재 위치 업그레이드는 없습니다.
무료 계층으로 예측
용량을 예측하기 위한 한 방법은 무료 계층으로 시작하는 것입니다. 무료 서비스는 최대 3개 인덱스, 50MB의 스토리지 및 인덱싱 시간 2분을 제공합니다. 이러한 제약 조건으로 프로젝션된 인덱스 크기를 측정하기 어려울 수 있지만 다음과 같은 단계가 있습니다.
크기가 작은 대표적인 데이터 세트를 준비합니다.
인덱스를 만들고 데이터를 로드합니다. 데이터 세트가 인덱서에서 지원하는 Azure 데이터 원본에서 호스팅될 수 있는 경우 포털에서 데이터 가져오기 마법사를 사용하여 인덱스를 만들고 로드할 수 있습니다. 그렇지 않은 경우 REST API를 사용하여 인덱스를 만들고 데이터를 푸시할 수 있습니다. 푸시 모델을 사용하려면 데이터가 JSON 문서 형식이어야 합니다. 여기서 문서의 필드는 인덱스의 필드에 해당합니다.
인덱스에 대한 정보(예: 크기)를 수집합니다. 기능 및 특성은 스토리지에 영향을 줍니다. 예를 들어 확인기(입력 시 검색 쿼리)를 추가하면 저장소 요구 사항이 증가합니다.
동일한 데이터 세트를 사용하여 각 필드에서 특성이 서로 다른 인덱스의 여러 버전을 만들어 저장소 요구 사항이 어떻게 변하는지 알 수 있습니다. 자세한 내용은 기본 인덱스 만들기의 "저장소 영향"을 참조하세요.
대략적인 예측을 사용하는 경우 두 인덱스(개발 및 프로덕션)에 대한 예산에 해당하는 금액을 두 배로 늘리고 그에 따라 계층을 선택할 수 있습니다.
청구 가능 계층으로 예측
전용 리소스는 개발 동안 인덱스 수량, 크기 및 쿼리 볼륨의 실제적인 예측이 가능하도록 대규모 샘플링 및 처리 시간을 수용할 수 있습니다. 일부 고객은 청구 가능한 계층으로 바로 이동한 다음 개발 프로젝트가 성숙될 때 재평가합니다.
하위 계층이 필요한 인덱스 수를 지원할 수 있는지 여부를 결정할 각 계층에서 서비스 제한 검토입니다. 기본, S1 및 S2 계층 전체에서 인덱스 제한은 각각 15, 50 및 200입니다. 스토리지 최적화 계층은 10개 인덱스로 제한되는데, 이는 적은 수의 매우 큰 인덱스를 지원하도록 설계되었기 때문입니다.
-
- 예상되는 부하에 대해 확실하지 않은 경우 기본 또는 S1에서 작은 규모로 시작합니다.
- 테스트에 대규모 인덱싱 및 쿼리 부하가 포함된 경우 S2 또는 S3에서 대규모로 시작합니다.
- 내부 비즈니스 애플리케이션과 마찬가지로 많은 양의 데이터를 인덱싱하고 쿼리 부하가 상대적으로 낮은 경우에는 L1 또는 L2에서 스토리지 최적화로 시작합니다.
원본 데이터가 인덱스로 변환되는 방법을 결정하려면 초기 인덱스를 만듭니다. 인덱스 크기를 추정하는 유일한 방법입니다.
포털에서 스토리지, 서비스 제한, 쿼리 볼륨 및 대기 시간을 모니터링합니다. 포털은 초당 쿼리, 제한된 쿼리 및 검색 대기 시간을 보여줍니다. 이 모든 값이 올바른 계층에 있는지 결정하는 데 도움을 줄 수 있습니다.
고가용성을 위해 복제본을 추가하거나 느린 쿼리 성능을 완화합니다.
쿼리 부하를 수용하는 데 필요한 복제본 수에 대한 지침은 없습니다. 쿼리 성능은 쿼리 및 경합 워크로드의 복잡성에 따라 다릅니다. 복제본을 추가하면 성능이 확실히 증가하지만 결과가 반드시 비례하지는 않습니다. 즉, 복제본을 세 개 추가한다고 해서 처리량이 3배가 되는 것은 아닙니다. 솔루션에 대한 QPS 예측 지침은 성능 분석 및 쿼리 모니터링을 참조하세요.
참고 항목
검색하지 않을 데이터를 포함하는 경우 저장소 요구 사항이 팽창될 수 있습니다. 이상적으로 문서는 검색 환경에 필요한 데이터만 포함합니다. 이진 데이터는 검색할 수 없으며 Azure 테이블 또는 Blob storage에 별도로 저장해야 합니다. 그런 다음 인덱스에 필드를 추가하여 외부 데이터에 대한 URL 참조를 저장해야 합니다. 개별 검색 문서의 최대 크기는 16MB(한 개의 요청으로 여러 문서를 대량 업로드하는 경우 이보다 작음)입니다. 자세한 내용은 Azure AI 검색의 서비스 제한 사항을 참조하세요.
쿼리 볼륨 고려 사항
QPS(초당 쿼리)는 성능 튜닝 중에 중요한 메트릭입니다. 하지만 용량 계획에 대해서는 처음에 높은 쿼리 볼륨이 필요할 것으로 예측하는 경우에만 고려 사항입니다.
표준 계층을 통해 복제본과 파티션의 균형을 맞출 수 있습니다. 부하 분산을 위해 복제본을 추가하거나 병렬 처리를 위해 파티션을 추가하여 쿼리 소요 시간을 단축할 수 있습니다. 서비스를 프로비전한 후 성능을 조정할 수 있습니다.
처음부터 높고 지속적인 쿼리 볼륨을 기대하는 경우 더 강력한 하드웨어에서 지원하는 표준 이상의 계층을 고려해야 합니다. 파티션 및 복제본을 오프라인으로 가져오거나 해당 쿼리 볼륨이 발생하지 않는 경우 하위 계층 서비스로 전환할 수도 있습니다. 쿼리 처리량을 계산하는 방법에 대한 자세한 내용은 쿼리 모니터링을 참조하세요.
스토리지 최적화 계층은 대량의 데이터 워크로드에 유용하며 쿼리 대기 시간 요구 사항이 그다지 중요하지 않은 경우에 전체적으로 사용 가능한 인덱스 저장소를 지원합니다. 부하 분산을 위해 추가 복제본을 사용하고 병렬 처리를 위해 추가 파티션을 사용해야 합니다. 서비스를 프로비전한 후 성능을 조정할 수 있습니다.
서비스 수준 계약
무료 계층 및 미리 보기 기능은 SLA(서비스 수준 계약)에 포함되지 않습니다. 모든 청구 가능 계층에 대해 서비스에 충분한 중복성을 프로비전할 때 SLA가 적용됩니다. 쿼리(읽기) SLA에는 두 개 이상의 복제본이 있어야 합니다. 쿼리 및 인덱싱(읽기-쓰기) SLA에는 세 개 이상의 복제본이 있어야 합니다. 파티션의 수는 SLA에 영향을 미치지 않습니다.
용량 계획 팁
쿼리 관련 메트릭 작성을 허용하고 사용량 패턴에 관한 데이터(업무 시간 중 쿼리, 사용량이 적은 시간 중 인덱싱)를 수집합니다. 이 데이터를 사용하여 서비스 프로비저닝 결정을 알립니다. 매시간 또는 매일 케이던스에서 효율적이지 않지만 쿼리 볼륨에서 계획된 변경을 수용할 수 있도록 파티션 및 리소스를 역동적으로 조정할 수 있습니다. 또한 작업 수행을 보증할 정도로 수준이 충분히 오래 유지되는 경우 계획되지 않았지만 지속적인 변경을 수용할 수 있습니다.
부족한 프로비저닝의 유일한 단점은 실제 요구 사항이 예측보다 많은 경우에 서비스를 종료해야 할 수 있습니다. 서비스 중단을 방지하려면 상위 계층에서 새 서비스를 만들고 모든 앱과 요청이 새 엔드포인트를 대상으로 할 때까지 이를 나란히 실행합니다.
용량을 추가하는 경우
처음 서비스에는 1개 파티션과 1개 복제본으로 구성된 최소 수준의 리소스가 할당됩니다. 선택한 계층에 따라 파티션 크기와 속도가 결정되고 각 계층은 다양한 시나리오에 맞는 특성 집합을 중심으로 최적화됩니다. 더 높은 수준의 계층을 선택하는 경우 S1을 사용할 때보다 더 적은 파티션이 필요할 수 있습니다. 하위 계층에서 프로비전되는 서비스에 2개의 저렴한 파티션을 두는 것보다 더 크고 비용이 많이 드는 파티션이 더 나은 성능을 얻을 수 있는지 여부를 확인해야 합니다.
단일 서비스에는 모든 워크로드(인덱싱 및 쿼리)를 처리할 만큼 충분한 리소스가 있어야 합니다. 백그라운드에서 실행되는 워크로드는 없습니다. 쿼리 요청 빈도가 자연히 적은 시간에 인덱싱을 예약할 수 있지만, 그 외에는 서비스가 작업의 우선 순위를 지정하지 않습니다. 또한 특정 중복성은 서비스 또는 노드가 내부적으로 업데이트될 때 쿼리 성능을 향상시킵니다.
용량 추가 여부를 결정하기 위한 몇 가지 지침은 다음과 같습니다.
- 서비스 수준 계약에 대한 고가용성 조건 충족
- HTTP 503 오류의 빈도가 늘어남
- 대용량 쿼리 볼륨이 필요함
일반적으로 검색 애플리케이션에는 파티션보다 더 많은 복제본이 필요하며 특히 서비스 작업이 쿼리 워크로드를 기반으로 하는 경우 더욱 그렇습니다. 각 복제본은 인덱스의 사본으로 서비스가 여러 사본으로 요청의 부하를 분산할 수 있게 해줍니다. 모든 인덱스의 부하 분산 및 복제는 Azure AI 검색을 통해 관리되며 언제든지 서비스에 할당되는 복제본 수를 변경할 수 있습니다. 표준 검색 서비스에서는 최대 12개, 기본 검색 서비스에서는 최대 3개의 복제본을 할당할 수 있습니다. Azure Portal 또는 프로그래매틱 옵션 중 하나에서 복제본 할당을 수행할 수 있습니다.
거의 실시간으로 진행되는 데이터 새로 고침을 필요로 하는 검색 애플리케이션은 복제본보다 비례적으로 더 많은 파티션이 필요합니다. 파티션을 추가하면 많은 수의 컴퓨팅 리소스로 읽기/쓰기 작업이 분산됩니다. 또한 추가 인덱스와 문서를 저장하기 위한 더 많은 디스크 공간이 보장됩니다.
마지막으로 인덱스가 클수록 쿼리하는 데 더 오래 걸립니다. 따라서 파티션을 증분 방식으로 증가시킬 때마다 더 작지만 비례적으로 복제본도 늘려야 합니다. 쿼리의 복잡성과 쿼리 용량은 쿼리 실행이 얼마나 빠르게 진행되는지에 영향을 줍니다.
참고 항목
복제본 또는 파티션을 더 추가하면 서비스 실행 비용이 증가하고 결과가 정렬되는 방식에 약간의 변화가 발생할 수 있습니다. 가격 책정 계산기를 사용하여 노드 추가 시의 비용 영향을 이해해야 합니다. 아래 차트는 특정 구성에 대해 필요한 검색 단위의 수를 교차 참조하는 데 도움이 될 수 있습니다. 추가 복제본이 쿼리 성능에 어떤 영향을 미치는지에 대한 자세한 내용은 결과 정렬을 참조하세요.
복제본 및 파티션 추가 또는 줄이기
Azure Portal 에 로그인하고 검색 서비스를 선택합니다.
설정에서 규모 페이지를 열고 복제본 및 파티션을 조정합니다.
다음 스크린샷은 하나의 복제본과 파티션으로 프로비전된 기본 표준을 보여줍니다. 아래의 수식은 사용되는 검색 단위의 수를 나타냅니다 (1). 단위 가격이 $100(실제 가격이 아님)인 경우 이 서비스를 실행하는 월간 비용은 평균적으로 $100가 됩니다.
슬라이더를 사용하여 파티션 수를 늘리거나 줄입니다. 저장을 선택합니다.
이 예에서는 두 번째 복제본과 파티션을 추가합니다. 검색 단위 수를 확인하세요. 요금 청구 수식은 복제본에 파티션을 곱하는 것이므로(2x2), 이제 4입니다. 용량을 2배 늘리면 서비스 실행 비용도 2배 증가합니다. 검색 단위 비용이 $100인 경우 이제 새로운 월간 청구 비용은 $400가 됩니다.
각 계층의 현재 단위 비용은 가격 책정 페이지를 참조하세요.
저장한 후에는 알림을 확인하여 작업이 성공했는지 확인할 수 있습니다.
용량 변경 작업은 완료하는 데 15분에서 몇 시간까지 걸릴 수 있습니다. 프로세스가 시작된 후에는 취소할 수 없으며 복제본 및 파티션 조정은 실시간 모니터링되지 않습니다. 하지만 변경이 진행되는 동안에는 다음 메시지가 표시됩니다.
참고 항목
서비스가 프로비전된 후에는 상위 계층으로 업그레이드할 수 없습니다. 새 계층에서 검색 서비스를 만들고 인덱스를 다시 로드해야 합니다. 서비스 프로비전에 대한 도움말은 포털에서 Azure AI 검색 서비스 만들기를 참조하세요.
크기 조정 요청을 처리하는 방법
크기 조정 요청이 수신되면 검색 서비스는 다음을 수행합니다.
- 요청이 유효한지 확인합니다.
- 데이터 및 시스템 정보를 백업하기 시작합니다.
- 서비스가 이미 프로비전 상태인지 여부를 확인합니다(현재 복제본 또는 파티션을 추가하거나 제거하는 중).
- 프로비저닝을 시작합니다.
서비스 크기 및 요청 범위에 따라 서비스의 크기 조정은 최소 15분 또는 1시간 이상 걸릴 수 있습니다. 백업은 데이터의 양과 파티션 및 복제본의 수에 따라 몇 분 정도 걸릴 수 있습니다.
위의 단계가 전부 순서대로 진행되는 것은 아닙니다. 예를 들어 시스템은 안전하게 프로비저닝할 수 있을 때 프로비전을 시작하는데, 백업이 종료되는 동안일 수 있습니다.
크기 조정 중 오류
"이전 요청을 처리 중이므로 현재 서비스 업데이트 작업이 허용되지 않습니다"라는 오류 메시지는 서비스가 이미 이전 요청을 처리하고 있을 때 스케일 다운 또는 업 요청을 반복하는 경우 표시됩니다.
서비스 상태를 검사하여 프로비저닝 상태를 확인하여 이 오류를 해결합니다.
- 관리 REST API, Azure PowerShell 또는 Azure CLI를 사용하여 서비스 상태를 가져옵니다.
- PowerShell 또는 CLI에 대해 서비스 가져오기(REST) 또는 이와 동등한 항목을 호출합니다.
- “provisioningState”: “provisioning”에 대한 응답을 확인합니다.
상태가 "프로비전 중"인 경우 요청이 완료되기를 기다립니다. 상태는 다른 요청을 시도하기 전에 “성공” 또는 “실패”여야 합니다. 백업에 대한 상태는 없습니다. 백업은 내부 작업이며 크기 조정 연습의 중단에 영향을 주지 않을 수 있습니다.
검색 서비스가 프로비전 중 상태에서 멈춘 것으로 보이는 경우, 사용할 수 없고 쿼리량이 0이며 인덱스 업데이트가 없는 분리된 인덱스가 있는지 확인합니다. 사용할 수 없는 인덱스 때문에 서비스 용량 변경이 차단될 수 있습니다. 특히 키가 더 이상 유효하지 않은 CMK 암호화 인덱스가 있는지 확인합니다. 인덱스가 다시 온라인 상태가 되고 스케일링 작업의 차단을 해제하려면 인덱스를 삭제하거나 키를 복원해야 합니다.
파티션 및 복제본 조합
2024년 4월 3일 이전에 만든 검색 서비스: 기본은 최대 3개의 SU 제한에 대해 정확히 하나의 파티션과 최대 3개의 복제본을 가질 수 있습니다. 유일하게 조정할 수 있는 리소스는 복제본입니다.
지원되는 지역에서 2024년4월 3일 이후에 생성된 검색 서비스: 기본은 최대 3개의 파티션과 3개의 복제본을 가질 수 있습니다. 최대 SU 제한은 파티션 및 복제본의 완전한 보완을 지원하기 위해 9개입니다.
청구 가능한 계층의 검색 서비스의 경우 작성 날짜에 관계없이 쿼리에 대한 고가용성을 위해 최소 두 개의 복제본이 필요합니다.
모든 표준 및 스토리지 최적화 검색 서비스는 이러한 계층에 허용된 36개 검색 단위 제한에서 다음 복제본 및 파티션 조합을 가정할 수 있습니다.
| 파티션 1개 | 파티션 2개 | 파티션 3개 | 파티션 4개 | 파티션 6개 | 파티션 12개 | |
|---|---|---|---|---|---|---|
| 복제본 1개. | 1 SU | 2 SU | 3 SU | 4 SU | 6 SU | 12 SU |
| 복제본 2개 | 2 SU | 4 SU | 6 SU | 8 SU | 12 SU | 24 SU |
| 복제본 3개 | 3 SU | 6 SU | 9 SU | 12 SU | 18 SU | 36 SU |
| 복제본 4개 | 4 SU | 8 SU | 12 SU | 16 SU | 24 SU | 해당 없음 |
| 복제본 5개 | 5 SU | 10 SU | 15 SU | 20 SU | 30 SU | 해당 없음 |
| 복제본 6개 | 6 SU | 12 SU | 18 SU | 24 SU | 36 SU | 해당 없음 |
| 복제본 12개 | 12 SU | 24 SU | 36 SU | 해당 없음 | 해당 없음 | 해당 없음 |
SU, 가격 책정 및 용량에 대해서는 Azure Websites에 자세히 설명되어 있습니다. 자세한 내용은 가격 정보를 참조하세요.
참고 항목
복제본 및 파티션 수는 12를 고르게 나눌 수 있는 값입니다(특히 1, 2, 3, 4, 6, 12). Azure AI 검색은 각 인덱스를 모든 파티션 사이에 고르게 분할할 수 있도록 12개의 부분으로 미리 나눕니다. 예를 들어, 서비스에 파티션이 세 개 있는 상태에서 인덱스를 하나 만들 경우 각 파티션에는 분할된 인덱스가 4개가 포함됩니다. Azure AI 검색에서 인덱스를 분할하는 방법은 구현에 관한 세부 정보이며 이후 릴리스에서 변경될 수 있습니다. 지금은 그 숫자가 12이지만 이후에 12가 아닌 값으로 바뀔 수도 있습니다.