검색 서비스의 용량 예측 및 관리
Azure AI 검색에서 용량은 워크로드로 확장할 수 있는 복제본 및 파티션을 기반으로 합니다. 복제본은 검색 엔진의 복사본입니다. 파티션은 스토리지의 단위입니다. 각 새 검색 서비스는 각각 하나씩 시작되지만 변동 워크로드를 수용하도록 복제본 및 파티션을 독립적으로 추가 또는 제거할 수 있습니다. 용량을 추가하면 검색 서비스 실행 비용이 증가합니다.
처리 속도 및 디스크 IO와 같은 복제본 및 파티션의 물리적 특성은 서비스 계층에 따라 달라집니다. 표준 검색 서비스에서 복제본과 파티션은 기본 서비스의 복제본과 파티션보다 빠르고 큽니다.
용량 변경은 즉각적으로 적용되지 않습니다. 특히 많은 양의 데이터가 있는 서비스에서 파티션을 준비하거나 서비스 해제하는 데 최대 한 시간이 걸릴 수 있습니다.
검색 서비스를 확장하는 경우 다음 도구와 방법 중에서 선택할 수 있습니다.
개념: 검색 단위, 복제본, 파티션
용량은 파티션과 복제본의 조합으로 할당할 수 있는 검색 단위로 표현됩니다.
| 개념 | 정의 |
|---|---|
| 검색 단위 | 사용 가능한 총 용량(36개 단위)의 단일 증분입니다. Azure AI 검색 서비스에 대한 청구 단위이기도 합니다. 서비스를 실행하려면 최소한 1개의 단위가 필요합니다. |
| 복제본 | 검색 서비스의 인스턴스로 쿼리 작업을 부하 분산하는 데 주로 사용됩니다. 각 복제본은 인덱스의 사본 하나를 호스트합니다. 3개의 복제본을 할당하는 경우 쿼리 요청을 처리하는 데 사용할 수 있는 인덱스의 복사본 3개가 있는 셈입니다. |
| 파티션 | 읽기/쓰기 작업(예: 인덱스를 다시 작성하거나 새로 고치는 경우)을 위한 실제 스토리지 및 I/O를 제공합니다. 각 파티션에는 전체 인덱스의 조각이 있습니다. 3개의 파티션을 할당하면 인덱스가 1/3로 나뉩니다. |
36개 단위 제한을 초과하지 않는 가능한 조합을 보려면 파티션 및 복제본 표를 검토합니다.
청구 가능 계층으로 예측
저장소 요구 사항은 빌드에 필요한 인덱스 크기에 따라 결정됩니다. 추정에 도움이 되는 견고한 추론 또는 추상론은 없습니다. 인덱스의 크기를 확인하는 유일한 방법은 하나를 빌드하는 것입니다. 크기는 토큰화 및 포함, 제안기, 필터링 및 정렬 사용 설정 여부 또는 벡터 압축 활용 가능 여부에 따라 결정됩니다.
청구 가능한 계층, 기본 이상에서 예측하는 것이 좋습니다. 무료 계층은 여러 고객이 공유하는 실제 리소스에서 실행되며 제어할 수 없는 요인의 영향을 받습니다. 청구 가능한 쿼리 서비스의 전용 리소스만이 개발 중 인덱스 수량, 크기 및 쿼리 볼륨을 보다 현실적으로 예상하기 위해 더 큰 샘플링 및 처리 시간을 수용할 수 있습니다.
하위 계층이 필요한 인덱스 수를 지원할 수 있는지 여부를 결정할 각 계층에서 서비스 제한 검토입니다. 적극적인 개발, 테스트 및 프로덕션을 위해 인덱스의 여러 복사본이 필요한지 여부를 고려합니다.
검색 서비스에는 개체 제한(인덱스, 인덱서, 기술 세트 등의 최대 수) 및 저장 한도가 적용됩니다. 먼저 도달한 제한이 유효한 한도입니다.
청구 가능 계층에서 서비스를 만듭니다. 계층은 특정 워크로드에 최적화되어 있습니다. 예를 들어, 스토리지 최적화 계층은 10개 인덱스로 제한되는데, 이는 적은 수의 매우 큰 인덱스를 지원하도록 설계되었기 때문입니다.
예상되는 부하에 대해 확실하지 않은 경우 기본 또는 S1에서 작은 규모로 시작합니다.
테스트에 대규모 인덱싱 및 쿼리 부하가 포함된 경우 S2 또는 S3에서 대규모로 시작합니다.
내부 비즈니스 애플리케이션과 마찬가지로 많은 양의 데이터를 인덱싱하고 쿼리 부하가 상대적으로 낮은 경우에는 L1 또는 L2에서 스토리지 최적화로 시작합니다.
원본 데이터가 인덱스로 변환되는 방법을 결정하려면 초기 인덱스를 만듭니다. 인덱스 크기를 추정하는 유일한 방법입니다. 필드 정의의 특성은 실제 스토리지 요구 사항에 영향을 미칩니다.
키워드 검색의 경우 필드를 필터링 및 정렬 가능으로 표시하면 인덱스 크기가 늘어납니다.
벡터 검색의 경우 매개 변수를 설정하여 스토리지를 줄일 수 있습니다.
포털에서 스토리지, 서비스 제한, 쿼리 볼륨 및 대기 시간을 모니터링합니다. 포털은 초당 쿼리, 제한된 쿼리 및 검색 대기 시간을 보여줍니다. 이 모든 값이 올바른 계층에 있는지 결정하는 데 도움을 줄 수 있습니다.
고가용성을 위해 복제본을 추가하거나 느린 쿼리 성능을 완화합니다.
쿼리 부하를 수용하는 데 필요한 복제본 수에 대한 지침은 없습니다. 쿼리 성능은 쿼리 및 경합 워크로드의 복잡성에 따라 다릅니다. 복제본을 추가하면 성능이 확실히 증가하지만 결과가 반드시 비례하지는 않습니다. 즉, 복제본을 세 개 추가한다고 해서 처리량이 3배가 되는 것은 아닙니다. 솔루션에 대한 QPS 예측 지침은 성능 분석 및 쿼리 모니터링을 참조하세요.
반전된 인덱스의 경우 크기와 복잡성은 피드하는 데이터의 양이 아니라 콘텐츠에 따라 결정됩니다. 높은 중복성이 있는 대형 데이터 원본은 매우 가변적 콘텐츠를 포함하는 작은 데이터 세트보다 더 작은 인덱스로 나타날 수 있습니다. 따라서 원래 데이터 세트의 크기에 따라 인덱스 크기를 유추하는 일은 거의 불가능합니다.
검색하지 않을 데이터를 포함하는 경우 저장소 요구 사항이 팽창될 수 있습니다. 이상적으로 문서는 검색 환경에 필요한 데이터만 포함합니다.
서비스 수준 계약 고려 사항
무료 계층 및 미리 보기 기능은 SLA(서비스 수준 계약)에 포함되지 않습니다. 모든 청구 가능 계층에 대해 서비스에 충분한 중복성을 프로비전할 때 SLA가 적용됩니다.
두 개 이상의 복제본이 쿼리(읽기) SLA를 충족합니다.
3개 이상의 복제본이 쿼리 및 인덱싱(읽기-쓰기) 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 암호화 인덱스가 있는지 확인합니다. 인덱스가 다시 온라인 상태가 되고 스케일링 작업의 차단을 해제하려면 인덱스를 삭제하거나 키를 복원해야 합니다.
파티션 및 복제본 조합
다음 차트는 표준 계층 이상에 적용됩니다. 이는 서비스당 최대 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 | 해당 없음 | 해당 없음 | 해당 없음 |
기본 검색 서비스는 검색 단위 수가 적습니다.
2024년 4월 3일 이전에 만들어진 검색 서비스에서 기본 검색 서비스는 정확히 1개의 파티션과 최대 3개의 복제본을 가질 수 있으며 최대 SU 제한은 3개입니다. 유일하게 조정할 수 있는 리소스는 복제본입니다.
지원되는 지역에서 2024년4월 3일 이후에 생성된 검색 서비스: 기본 서비스는 최대 3개의 파티션과 3개의 복제본을 가질 수 있습니다. 최대 SU 제한은 파티션 및 복제본의 완전한 보완을 지원하기 위해 9개입니다.
청구 가능한 계층의 검색 서비스의 경우 작성 날짜에 관계없이 쿼리에 대한 고가용성을 위해 최소 두 개의 복제본이 필요합니다.
계층 및 통화별 청구 요율은 Azure AI 검색 가격 책정 페이지를 참조하세요.