검색 서비스의 용량 예측 및 관리

Azure AI 검색 용량을 다르게 처리하는 두 가지 가격 책정 모델을 제공합니다.

• 전용: 복제본 및 파티션의 크기를 조정하고 서비스 계층을 선택하여 용량을 계획합니다.

  • 복제본 및 파티션을 사용하여 용량을 직접 미리 프로비전합니다.
  • 필요한 스토리지(파티션) 및 필요한 처리량(복제본)을 예측합니다.
  • 예상 최대 수요에 따라 필요한 용량을 프로비전할 서비스 계층을 선택합니다.
  • 용량을 미리 구성한 후에는 사용량에 관계없이SU(검색 단위)로 측정한 시간당 요금을 지불합니다.

• 서버리스(미리 보기): 서비스는 사용량 및 서비스 제한에 따라 용량을 자동으로 관리합니다. 용량을 미리 프로비전할 필요가 없습니다. 대신 워크로드 효율성을 최적화하여 비용을 관리합니다.

  • 용량은 수요에 따라 자동으로 크기 조정됩니다(유휴 상태일 때 0으로 확장할 수 있음).
  • CPU(컴퓨팅 단위) 및 스토리지로 측정된 실제 사용량에 따라 요금이 청구됩니다.
  • 인프라보다는 쿼리 패턴, 인덱스 크기 및 증가, 데이터 수집 패턴과 같은 비용 동인에 중점을 둡니다. 서버리스 모델에 대한 비용 최적화를 참조하세요.

자세한 내용은 다음 방법을 참조하세요.

• 비용 계획 및 관리
• 가격 책정 모델 및 서비스 계층 선택
• 서버리스 가격 책정 모델을 사용하여 비용 최적화

전용 모델에 대한 용량 계획

전용 모델에서는 SU(검색 단위)를 사용하여 용량을 프로비전합니다.

• SU(검색 단위) = 복제본 × 파티션
• 복제본: 검색 엔진의 복사본입니다. 쿼리 처리량 및 고가용성을 제공합니다.
• 파티션: 스토리지 단위입니다. 스토리지 및 인덱싱 처리량을 제공합니다.

각 서비스는 1개의 복제본 × 1개의 파티션(1 SU)으로 시작합니다. 변동하는 워크로드를 수용하기 위해 복제본과 파티션을 독립적으로 추가하거나 제거할 수 있습니다. 용량을 추가하면 검색 서비스 실행 비용이 증가합니다.

36개 단위 제한을 초과하지 않는 가능한 조합을 보려면 파티션 및 복제본 표를 검토합니다.

처리 속도 및 디스크 IO와 같은 복제본 및 파티션의 물리적 특성은 서비스 계층에 따라 다릅니다. 표준 검색 서비스에서 복제본과 파티션은 기본 서비스의 복제본과 파티션보다 빠르고 큽니다.

전용 모델에 대한 용량을 추가하는 경우

다음과 같은 경우 복제본 또는 파티션을 추가하는 것이 좋습니다.

• 쿼리 대기 시간이 증가하거나 서비스 수준 계약 조건이 충족되지 않습니다.
• HTTP 503(서비스를 사용할 수 없음) 오류의 빈도가 증가합니다.
• HTTP 429(너무 많은 요청) 오류의 빈도가 증가하여 요청 제한을 나타냅니다.
• 대용량 쿼리 볼륨이 필요함
• 인덱싱 작업이 느리거나 뒤처지고 있습니다.
• 스토리지 또는 인덱싱 처리량이 부족합니다.

크기 조정 지침:

• 쿼리 처리량 및 가용성을 높이기 위해 복제본 을 추가합니다.
• 파티션을 추가하여 스토리지 및 인덱싱 성능을 향상합니다.
• 쿼리가 많은 워크로드에는 일반적으로 더 많은 복제본이 필요합니다.
• 큰 인덱스에는 성능을 유지하기 위해 추가 복제본이 필요할 수 있습니다.

선택하는 서비스 계층에 따라 파티션 크기 및 속도가 결정됩니다. 각 계층은 다양한 시나리오에 맞는 특성 집합을 중심으로 최적화됩니다. 더 높은 수준의 계층을 선택하는 경우 S1을 사용할 때보다 더 적은 파티션이 필요할 수 있습니다. 자체 지향 테스트를 통해 답변해야 하는 질문 중 하나는 더 크고 비용이 많이 드는 파티션이 낮은 계층에서 프로비전된 서비스에서 두 개의 저렴한 파티션보다 더 나은 성능을 생성하는지 여부입니다.

단일 서비스에는 모든 워크로드(인덱싱 및 쿼리)를 처리할 만큼 충분한 리소스가 있어야 합니다. 백그라운드에서 실행되는 워크로드는 없습니다. 쿼리 요청이 자주 발생하지 않는 시간에 대해 인덱싱을 예약할 수 있지만, 서비스가 다른 작업보다 우선 순위를 지정하지는 않습니다. 또한 특정 중복성은 서비스 또는 노드가 내부적으로 업데이트될 때 쿼리 성능을 향상시킵니다.

일반적으로 검색 애플리케이션에는 파티션보다 더 많은 복제본이 필요하며 특히 서비스 작업이 쿼리 워크로드를 기반으로 하는 경우 더욱 그렇습니다. 각 복제본은 인덱스의 복사본이므로 서비스는 여러 복사본에 대한 요청 부하를 분산할 수 있습니다. Azure AI 검색 인덱스의 모든 부하 분산 및 복제를 관리합니다. 서비스에 할당된 복제본 수는 언제든지 변경할 수 있습니다. 표준 검색 서비스에서는 최대 12개, 기본 검색 서비스에서는 최대 3개의 복제본을 할당할 수 있습니다. Azure 포털 또는 프로그래밍 방식 옵션 중 하나에서 복제본을 할당할 수 있습니다.

추가 파티션은 집약적인 인덱싱 워크로드에 유용합니다. 추가 파티션은 더 많은 수의 컴퓨팅 리소스에 읽기 및 쓰기 작업을 분산합니다.

마지막으로 인덱스가 클수록 쿼리하는 데 더 오래 걸립니다. 따라서 파티션을 증분 방식으로 증가시킬 때마다 더 작지만 비례적으로 복제본도 늘려야 합니다. 쿼리 및 쿼리 볼륨의 복잡성은 쿼리 실행이 얼마나 빨리 전환되는지에 영향을 줍니다.

서비스 제한 및 유효한 크기 조정 범위는 다음을 참조하세요.

• 계층 및 SKU에 대한 서비스 제한
• 가격 책정 모델 및 서비스 계층 선택

용량을 관리하고 조정하는 방법

용량 변경은 즉각적으로 적용되지 않습니다. 데이터 볼륨 및 작업 유형에 따라 크기 조정에 몇 분에서 몇 시간이 걸릴 수 있습니다.

검색 서비스를 확장하는 경우 다음 도구와 방법 중에서 선택할 수 있습니다.

• Azure 포털
• Azure PowerShell
• Azure CLI
• 관리 REST API

서비스 용량을 늘리거나 줄이려면 다음 두 가지 옵션이 있습니다.

• 파티션 및 복제본 추가 또는 제거
• 가격 책정 계층 변경

파티션 및 복제본 추가 또는 제거

1. Azure 포털 검색 서비스로 이동합니다.

2. 왼쪽 창에서 [설정>배율]을 선택합니다.

   다음 스크린샷은 하나의 복제본과 파티션으로 프로비전된 표준 서비스를 보여 줍니다. 아래의 수식은 사용되는 검색 단위의 수를 나타냅니다 (1). 단위 가격이 $100(실제 가격이 아님)인 경우 이 서비스를 실행하는 월간 비용은 평균적으로 $100가 됩니다.

   

3. 슬라이더를 사용하여 파티션 수를 늘리거나 줄인 다음 저장을 선택합니다.

   이 예에서는 두 번째 복제본과 파티션을 추가합니다. 검색 단위 수를 확인하세요. 요금 청구 수식은 복제본에 파티션을 곱하는 것이므로(2x2), 이제 4입니다. 용량을 2배 늘리면 서비스 실행 비용도 2배 증가합니다. 검색 단위 비용이 $100인 경우 이제 새로운 월간 청구 비용은 $400가 됩니다.

   각 계층의 현재 단위 비용은 가격 책정 페이지를 참조하세요.

   

4. 알림을 확인하여 작업이 시작되었음을 확인합니다.

   Azure 포털에서 크기 조정 작업 알림 스크린샷.

   이 작업을 완료하는 데 몇 시간이 걸릴 수 있습니다. 백그라운드에서 발생하므로 검색 서비스가 완전히 작동하고 읽기 및 쓰기 작업에 사용할 수 있습니다.

   작업을 취소하거나 진행 상황을 모니터링할 수 없습니다. 그러나 변경이 진행되는 동안 다음 메시지가 표시됩니다.

   

가격 책정 계층 변경

가격 책정 계층은 전용 가격 책정 모델에 대한 검색 서비스의 최대 스토리지를 결정합니다. 용량이 더 많거나 적게 필요한 경우 스토리지 요구 사항을 수용하는 다른 가격 책정 계층으로 전환할 수 있습니다. (전용 가격 책정 모델 계층에만 적용됩니다. 서버리스 모델 개발자 계층은 선택한 후에는 변경할 수 없습니다).

가격 책정 계층은 용량 외에도 인덱스, 인덱서 및 기타 검색 개체에 대한 제한을 결정합니다. 계속하기 전에 현재 계층의 서비스 제한과 원하는 계층을 비교합니다. 일반적으로 더 높은 계층으로 전환하면 스토리지 제한 및 벡터 제한이 증가하고, 요청 처리량이 증가하고, 대기 시간이 감소하지만, 하위 계층으로 전환하면 반대의 효과가 발생합니다.

더 높은 가격 책정 계층으로 전환하면 검색 서비스 실행 비용도 증가합니다. 자세한 내용은 가격 책정 페이지를 참조하십시오.

가격 책정 계층을 변경하려면 다음을 수행합니다.

1. Azure 포털 검색 서비스로 이동합니다.

2. 왼쪽 창에서 [설정>배율]을 선택합니다.

3. 현재 계층에서 가격 책정 계층 변경을 선택합니다.

   Azure Portal에서 가격 책정 계층 변경 버튼의 스크린샷.

4. 가격 책정 계층 선택 페이지에서 목록에서 다른 계층을 선택합니다.

   Basic, S1, S2 및 S3 간에 전환할 수 있지만 Free, S3HD, L1 또는 L2 간에 전환할 수는 없습니다. 이러한 계층은 선택할 수 없으며 흐리게 표시됩니다.

   

5. 크기 조정 작업을 시작하려면 저장을 선택합니다.

   Azure 포털에서 저장 단추의 스크린샷.

   이 작업을 완료하는 데 몇 시간이 걸릴 수 있습니다. 백그라운드에서 발생하므로 검색 서비스가 완전히 작동하고 읽기 및 쓰기 작업에 사용할 수 있습니다.

   작업을 취소하거나 진행 상황을 모니터링할 수 없습니다. 그러나 변경이 진행되는 동안 다음 메시지가 표시됩니다.

   

전용 모델에 대해 크기 조정 요청을 처리하는 방법

검색 서비스에서 크기 조정 요청을 받으면 다음을 수행합니다.

1. 요청이 유효한지 확인합니다.
2. 데이터 및 시스템 정보를 백업하기 시작합니다.
3. 서비스가 이미 프로비전 상태인지 여부를 확인합니다(현재 복제본 또는 파티션을 추가하거나 제거하는 중).
4. 프로비저닝을 시작합니다.

서비스의 크기 및 요청 범위에 따라 서비스 크기를 조정하는 데 몇 분에서 몇 시간이 걸릴 수 있습니다. 백업 기간은 데이터 양과 파티션 및 복제본 수에 따라 달라집니다.

크기 조정 요청을 처리하는 단계는 완전히 연속되지 않습니다. 예를 들어 시스템은 안전하게 프로비저닝할 수 있을 때 프로비전을 시작하는데, 백업이 종료되는 동안일 수 있습니다.

크기 조정 중 오류

다음 표에서는 크기 조정 작업 중에 발생할 수 있는 오류에 대한 원인 및 솔루션을 나열합니다.

¹ 크기 조정 연습을 방해할 가능성이 거의 없는 내부 작업인 백업에 대한 상태가 없습니다.

² 검색 서비스가 프로비저닝 상태에서 중단된 것처럼 보이면 쿼리 볼륨이 없고 인덱스 업데이트가 없는 분리된 인덱스를 사용할 수 없는지 확인합니다. 사용할 수 없는 인덱스 때문에 서비스 용량 변경이 차단될 수 있습니다. 특히 키가 더 이상 유효하지 않은 CMK 암호화 인덱스를 찾습니다. 인덱스 삭제 또는 키를 복원하여 인덱스 다시 온라인 상태로 만들고 크기 조정 작업의 차단을 해제합니다.

파티션 및 복제본 조합

다음 차트는 표준 계층 이상에 적용됩니다. 이는 서비스당 최대 36개의 검색 단위에 따라 파티션과 복제본의 가능한 모든 조합을 보여 줍니다.

기본 검색 서비스는 검색 단위 수가 적습니다.

• 2024년 4월 3일 이전에 만든 검색 서비스에서 기본 서비스에는 정확히 하나의 파티션과 최대 3개의 SU 제한에 대한 최대 3개의 복제본이 있을 수 있습니다. 유일하게 조정할 수 있는 리소스는 복제본입니다. 그러나 서비스를 업그레이드하여 파티션 수를 늘릴 수 있습니다.

• 지원되는 지역에서 2024년 4월 3일 이후에 생성된 검색 서비스: 기본 서비스는 최대 3개의 파티션과 3개의 복제본을 가질 수 있습니다. 최대 SU 제한은 파티션 및 복제본의 완전한 보완을 지원하기 위해 9개입니다.

청구 가능한 계층의 검색 서비스의 경우 작성 날짜에 관계없이 쿼리에 대한 고가용성을 위해 최소 두 개의 복제본이 필요합니다.

계층 및 통화당 청구 요금은 Azure AI 검색 가격 책정 페이지 참조하세요.

전용 가격 책정 모델 계층을 사용하여 용량 예측

스토리지 요구는 빌드할 인덱스의 크기에 따라 달라집니다. 추정에 도움이 되는 견고한 추론이나 일반적인 지침은 없습니다. 인덱스의 크기를 확인하는 유일한 방법은 인덱스 크기를 작성하는 것입니다. 크기는 토큰화 및 포함 및 제안기, 필터링 및 정렬을 사용하도록 설정할지 또는 벡터 압축을 활용할 수 있는지에 따라 달라집니다.

청구 가능 계층(기본 이상)에서 용량을 예측합니다. 무료 계층은 여러 고객이 공유하는 실제 리소스에서 실행되며 제어할 수 없는 요인의 영향을 받습니다. 청구 가능한 쿼리 서비스의 전용 리소스만이 개발 중 인덱스 수량, 크기 및 쿼리 볼륨을 보다 현실적으로 예상하기 위해 더 큰 샘플링 및 처리 시간을 수용할 수 있습니다.

1. 하위 계층이 필요한 인덱스 수를 지원할 수 있는지 여부를 결정할 각 계층에서 서비스 제한 검토입니다. 적극적인 개발, 테스트 및 프로덕션을 위해 인덱스의 여러 복사본이 필요한지 여부를 고려합니다.

   검색 서비스에는 개체 제한(최대 인덱스 수, 인덱서, 기술 세트 등) 및 스토리지 제한이 적용됩니다. 먼저 도달한 제한이 유효한 한도입니다.

2. 청구 가능 계층에서 서비스를 만듭니다. 계층은 특정 워크로드에 최적화되어 있습니다. 예를 들어 스토리지 최적화 계층은 적은 수의 큰 인덱스를 지원하도록 설계되었기 때문에 10개의 인덱스로 제한됩니다.

   • 예상되는 부하에 대해 확실하지 않은 경우 기본 또는 S1에서 작은 규모로 시작합니다.

   • 테스트에 대규모 인덱싱 및 쿼리 부하가 포함된 경우 S2 또는 S3에서 대규모로 시작합니다.

   • 내부 비즈니스 애플리케이션과 마찬가지로 많은 양의 데이터를 인덱싱하고 쿼리 부하가 상대적으로 낮은 경우에는 L1 또는 L2에서 스토리지 최적화로 시작합니다.

3. 원본 데이터가 인덱스로 변환되는 방법을 결정하려면 초기 인덱스를 만듭니다. 인덱스 크기를 추정하는 유일한 방법입니다. 필드 정의의 특성은 실제 스토리지 요구 사항에 영향을 미칩니다.

   • 키워드 검색의 경우 필드를 필터링 및 정렬 가능으로 표시하면 인덱스 크기가 늘어납니다.

   • 벡터 검색의 경우 매개 변수를 설정하여 벡터 크기를 줄일 수 있습니다.

4. Azure 포털의 모니터 스토리지, 서비스 제한, 쿼리 볼륨 및 대기 시간. Azure 포털에는 초당 쿼리, 제한된 쿼리 및 검색 대기 시간이 표시됩니다. 이러한 값은 올바른 계층을 선택했는지 여부를 결정하는 데 도움이 될 수 있습니다.

5. 고가용성을 위해 복제본을 추가하거나 느린 쿼리 성능을 완화합니다.

   쿼리 부하를 수용하는 데 필요한 복제본 수에 대한 지침은 없습니다. 쿼리 성능은 쿼리 및 경합 워크로드의 복잡성에 따라 다릅니다. 복제본을 추가하면 성능이 확실히 증가하지만 결과가 반드시 비례하지는 않습니다. 즉, 복제본을 세 개 추가한다고 해서 처리량이 3배가 되는 것은 아닙니다. 솔루션에 대한 QPS를 예측하는 지침은 성능 분석 및 쿼리 모니터링을 참조하세요.

반전된 인덱스의 경우 크기와 복잡성은 피드하는 데이터의 양이 아니라 콘텐츠에 따라 결정됩니다. 높은 중복성이 있는 대형 데이터 원본은 매우 가변적 콘텐츠를 포함하는 작은 데이터 세트보다 더 작은 인덱스로 나타날 수 있습니다. 따라서 원래 데이터 세트의 크기에 따라 인덱스 크기를 유추하는 일은 거의 불가능합니다.

검색하지 않는 데이터를 포함하는 경우 스토리지 요구 사항이 확장될 수 있습니다. 이상적으로 문서는 검색 환경에 필요한 데이터만 포함합니다.

서비스 수준 계약 고려 사항

SLA(서비스 수준 계약) 는 무료 계층 및 미리 보기 기능을 다루지 않습니다. 모든 청구 가능 계층에 대해 서비스에 충분한 중복성을 프로비전할 때 SLA가 적용됩니다.

• 두 개 이상의 복제본이 쿼리(읽기) SLA를 충족합니다.

• 3개 이상의 복제본이 쿼리 및 인덱싱(읽기-쓰기) SLA를 충족합니다.

파티션의 수는 SLA에 영향을 미치지 않습니다.

서버리스 모델에 대한 비용 최적화

서버리스 가격 책정 모델에서:

• 서비스는 용량을 자동으로 관리합니다.
• 복제본, 파티션 또는 검색 단위를 구성할 필요가 없습니다.
• 컴퓨팅은 워크로드(쿼리 및 인덱싱 수요)에 따라 동적으로 확장되며 유휴 상태일 때 0으로 확장할 수 있습니다.

서버리스 모델의 제한 사항에 대한 자세한 내용은 서비스 제한을 참조하세요.

청구는 다음 두 가지 차원을 기반으로 합니다.

• CPU(컴퓨팅 사용량): 쿼리 및 인덱싱 작업에 따라 요금이 청구됩니다.
• 인덱싱된 스토리지: 월별 GB당 청구됩니다.

청구는 소비 기반이므로 비용은 사용량에 직접 연결됩니다.

• 복잡한 쿼리는 더 많은 컴퓨팅을 사용합니다.
• 비효율적인 스키마 디자인은 인덱싱 및 쿼리 비용을 모두 증가합니다.
• 대용량 또는 자주 업데이트되는 인덱스가 있는 잘못된 쿼리 패턴은 스토리지 및 컴퓨팅 사용량을 증가합니다.

워크로드 효율성 최적화

비효율성은 서버리스 모델에서 비용으로 표시되므로 워크로드 인식 디자인을 연습하지 않는 경우 동일한 작업에 대해 더 많은 비용을 지불합니다. 서버리스 지출을 제어하는 가장 좋은 방법은 처음부터 인덱스 및 쿼리를 효율적으로 디자인하는 것입니다.

서버리스 가격 책정 모델을 사용할 때 효율성을 위해 워크로드를 디자인하려면 다음을 고려합니다.

인덱스 디자인

• 쿼리에 사용되는 필드만 포함합니다.
• 가능한 경우 벡터 차원을 줄입니다.
• 불필요한 필터링 가능, 정렬 가능 또는 패싯 가능 특성을 방지합니다.

쿼리 패턴

• 반환된 필드를 제한하는 데 사용합니다 $select .
• 필터를 조기에 적용하여 결과 집합을 줄입니다.
• 깊은 페이징($skip)을 방지합니다.
• 광범위한 전체 텍스트 쿼리보다 대상 쿼리를 선호합니다.
• 높은 컴퓨팅 비용으로 인해 하이브리드 검색을 신중하게 사용합니다.

Monitoring

• CU 사용량을 모니터링하여 비용이 많이 드는 쿼리를 식별합니다.
• 스토리지 증가를 추적하고 사용되지 않는 데이터를 제거합니다.

서버리스에서 성능 향상(더 빠르고 더 많은 대상 쿼리)은 일반적으로 비용을 절감합니다.

자세한 내용은 Azure AI 검색 참조하세요.

지역별 용량 고려 사항

용량 및 가용성은 지원되는 지역에 따라 달라질 수 있습니다. 일부 지역에는 새 서비스를 프로비전하거나 기존 서비스를 확장하는 데 제약 조건이 있을 수 있습니다.

용량 제약 조건으로 인해 기본 Azure AI 검색 지역을 사용할 수 없는 경우 Azure AI 검색 참조하세요.

다음 단계