Azure AI Search에서 쿼리 요청 모니터링

이 문서에서는 기본 제공 메트릭 및 리소스 로깅을 사용하여 쿼리 성능 및 볼륨을 측정하는 방법을 설명합니다. 또한 애플리케이션 사용자가 입력한 쿼리 문자열을 가져오는 방법도 설명합니다.

Azure Portal은 쿼리 대기 시간, 쿼리 로드(QPS) 및 제한에 대한 기본 메트릭을 보여 줍니다. 이러한 메트릭에 피드되는 기록 데이터는 포털에서 30일 동안 액세스할 수 있습니다. 보존 기간을 연장하거나 운영 데이터 및 쿼리 문자열을 보고하려면 기록된 작업 및 메트릭을 유지하기 위한 스토리지 옵션을 지정하는 진단 설정을 추가해야 합니다. Log Analytics 작업 영역을 기록된 작업의 대상으로 사용하는 것이 좋습니다. Kusto 쿼리 및 데이터 탐색은 Log Analytics 작업 영역을 대상으로 합니다.

데이터 측정의 무결성을 최대화하는 조건은 다음과 같습니다.

  • 청구 가능한 서비스(기본 또는 표준 계층에서 만든 서비스)를 사용합니다. 체험 서비스는 여러 구독자가 공유하므로 로드 이동 과정에서 특정 양의 변동성을 도입합니다.

  • 가능한 경우 단일 복제본(replica) 및 파티션을 사용하여 포함된 격리된 환경을 만듭니다. 여러 복제본(replica) 사용하는 경우 쿼리 메트릭은 여러 노드에서 평균을 계산하므로 결과의 전체 자릿수가 낮아질 수 있습니다. 마찬가지로 여러 파티션을 가지는 것은 데이터가 분할되는 것을 의미하며, 인덱싱이 함께 진행 중인 경우 일부 파티션에서는 다른 데이터를 가질 수 있습니다. 쿼리 성능을 튜닝할 때 단일 노드 및 파티션은 테스트를 위해 보다 안정적인 환경을 제공합니다.

추가 클라이언트 쪽 코드 및 Application Insights를 사용하면 애플리케이션 사용자의 관심을 끄는 항목에 대한 심층적인 인사이트를 위해 클릭스루 데이터를 캡처할 수도 있습니다. 자세한 내용은 트래픽 분석 검색을 참조하세요.

쿼리 볼륨(QPS)

볼륨은 1분간 실행되는 쿼리의 평균, 개수, 최솟값 또는 최댓값으로 보고할 수 있는 기본 제공 메트릭인 QPS(초당 검색 쿼리)로 측정됩니다. 메트릭에 대한 1분 간격(TimeGrain = "PT1M")은 시스템 내에서 고정됩니다.

일반적으로 쿼리는 밀리초 단위로 실행되므로 초 단위로 측정되는 쿼리만 메트릭에 표시됩니다.

집계 유형 설명
평균 쿼리 실행이 발생한 1분 이내의 평균 시간(초)입니다.
Count 1분 간격 내에 로그에 내보낸 메트릭 수입니다.
최대 1분간 등록된 초당 최고 검색 쿼리 수.
최소 1분간 등록된 초당 최저 검색 쿼리 수.
Sum 1분 내에 실행된 모든 쿼리의 합계입니다.

예를 들어, 1분 내에 다음과 같은 패턴을 발견할 수 있습니다. SearchQueriesPerSecond에 대한 최대 로드 1초, 이후 평균 로드 58초, 그리고 마지막으로 최소값인 한 개의 쿼리만 있는 1초가 이어집니다.

또 다른 예: 노드에서 각 메트릭의 값이 40인 100개의 메트릭을 내보내는 경우 "Count"는 100, "Sum"은 4000, "Average"는 40, "Max"는 40입니다.

쿼리 성능

서비스 전체에서 쿼리 성능은 검색 대기 시간(쿼리가 완료되는 데 소요되는 시간) 및 리소스 경합의 결과로 드롭된 제한된 쿼리로 측정됩니다.

Search latency

집계 유형 대기 시간
평균 평균 쿼리 기간(밀리초)입니다.
Count 1분 간격 내에 로그에 내보낸 메트릭 수입니다.
최대 샘플에서 가장 오래 실행되는 쿼리입니다.
최소 샘플에서 가장 짧은 실행 쿼리입니다.
총계 샘플에 있는 모든 쿼리의 총 실행 시간(1분) 이내에 실행됩니다.

검색 대기 시간 메트릭에 대한 다음 예제를 고려합니다. 86개 쿼리의 평균 기간이 23.26 밀리초로 샘플링되었습니다. 최소 0은 일부 쿼리가 삭제되었음을 나타냅니다. 가장 오래 실행되는 쿼리를 완료하는 데 1000밀리초가 걸렸습니다. 총 실행 시간은 2초입니다.

Latency aggregations

제한된 쿼리

제한된 쿼리는 처리되지 않고 삭제된 쿼리를 나타냅니다. 대부분의 경우 제한은 서비스 실행의 일반적인 부분입니다. 그것은 반드시 뭔가 잘못이 있다는 표시가 아닙니다.

제한은 실행 중인 요청 수가 용량을 초과할 때 발생합니다. 복제본(replica) 회전에서 제거되거나 인덱싱하는 동안 제한 요청이 증가할 수 있습니다. 쿼리 및 인덱싱 요청은 모두 동일한 리소스 집합에 의해 처리됩니다.

서비스는 리소스 소비량에 따라 요청을 드롭할지 여부를 결정합니다. 메모리, CPU 및 디스크 IO에서 사용되는 리소스의 비율은 일정 기간 동안 평균됩니다. 해당 백분율이 임계값을 초과하는 경우 요청 볼륨이 감소할 때까지 인덱스에 대한 모든 요청이 제한됩니다.

클라이언트에 따라 다음과 같은 방법으로 제한된 요청이 표시됩니다.

  • 서비스에서 오류를 반환합니다. "You are sending too many requests. Please try again later."
  • 서비스에서 서비스를 현재 사용할 수 없음을 나타내는 503 오류 코드를 반환합니다.
  • 포털(예: 검색 탐색기)을 사용하는 경우 쿼리가 자동으로 삭제되고 검색을 다시 선택해야 합니다.

제한된 쿼리를 확인하려면 제한된 검색 쿼리 메트릭을 사용합니다. 이 문서에 설명된 대로 포털에서 메트릭을 탐색하거나 경고 메트릭을 만들 수 있습니다. 샘플링 간격 내에 삭제된 쿼리의 경우 Total을 사용하여 실행되지 않은 쿼리의 비율을 가져옵니다.

집계 유형 제한
평균 간격 내에 드롭된 쿼리의 비율.
Count 1분 간격 내에 로그에 내보낸 메트릭 수입니다.
최대 간격 내에 드롭된 쿼리의 비율.
최소 간격 내에 드롭된 쿼리의 비율.
총계 간격 내에 드롭된 쿼리의 비율.

제한된 검색 쿼리 백분율, 최소값, 최대값, 평균 및 합계의 경우 모두 1분 동안 총 검색 쿼리 수에서 제한된 검색 쿼리의 백분율과 같은 값을 갖습니다.

다음 스크린샷에서 첫 번째 숫자는 개수(또는 로그로 전송된 메트릭 수)입니다. 맨 위에 표시되거나 메트릭을 마우스로 가리킬 때 나타나는 다른 집계에는 평균, 최대 및 합계가 포함됩니다. 해당 샘플에서는 요청이 드롭되지 않았습니다.

Throttled aggregations

포털에서 메트릭 탐색

현재 숫자를 간략하게 살펴보려면 서비스 개요 페이지의 모니터링 탭에는 집계 유형을 변경하는 옵션과 함께 시간, 일 및 주 단위로 측정된 고정 간격에 대한 세 가지 메트릭(검색 대기 시간, 초당 검색 쿼리 수(검색 단위당), 제한된 검색 쿼리 백분율)이 표시됩니다.

심층 탐색을 위해 모니터링 메뉴에서 메트릭 탐색기를 열어 데이터를 계층화, 확대 및 시각화하여 추세 또는 변칙을 탐색할 수 있습니다. 메트릭 차트를 만드는 방법에 대한 이 자습서를 완료하여 메트릭 탐색기에 대해 자세히 알아봅니다.

  1. 모니터링 섹션에서 메트릭을 선택하여 범위가 검색 서비스로 설정된 메트릭 탐색기를 엽니다.

  2. 메트릭 아래에서 드롭다운 목록에서 하나를 선택하고 기본 설정 형식에 대해 사용 가능한 집계 목록을 검토합니다. 집계는 수집된 값이 시간 간격마다 샘플링되는 방법을 정의합니다.

    Metrics explorer for QPS metric

  3. 오른쪽 위 모서리에서 시간 간격을 설정합니다.

  4. 시각화를 선택합니다. 기본값은 꺾은선형 차트입니다.

  5. 메트릭 추가를 선택하고 다른 집계를 선택하여 더 많은 집계를 계층화합니다.

  6. 꺾은선형 차트에서 관심 영역을 확대합니다. 마우스 포인터를 영역의 시작 부분에 놓고 마우스 왼쪽 단추를 선택하고 길게 누른 다음 영역의 다른 쪽으로 끌어서 단추를 놓습니다. 차트는 해당 시간 범위를 확대합니다.

사용자가 입력한 쿼리 문자열 반환

리소스 로깅을 사용하도록 설정하면 시스템은 AzureDiagnostics 테이블에서 쿼리 요청을 캡처합니다 . 필수 구성 요소로서 로그 분석 작업 영역 또는 다른 스토리지 옵션 중에서 기록된 작업의 대상을 이미 지정해야 합니다.

  1. 모니터링 섹션에서 로그를 선택하여 Log Analytics 에서 빈 쿼리 창을 엽니다.

  2. 다음 식을 실행하여 작업을 검색 Query.Search 하고 작업 이름, 쿼리 문자열, 쿼리된 인덱스 및 찾은 문서 수로 구성된 테이블 형식 결과 집합을 반환합니다. 마지막 두 문은 결과의 노이즈를 줄이는 샘플 인덱스에 대해 비어 있거나 지정되지 않은 검색으로 구성된 쿼리 문자열을 제외합니다.

       AzureDiagnostics
    | project OperationName, Query_s, IndexName_s, Documents_d
    | where OperationName == "Query.Search"
    | where Query_s != "?api-version=2023-07-01-preview&search=*"
    | where IndexName_s != "realestate-us-sample-index"
    
  3. 선택에 따라 특정 구문이나 문자열을 검색하도록 Query_s 열 필터를 설정합니다. 예를 들어 필터링 이 같을 수 있습니다?api-version=2023-11-01&search=*&%24filter=HotelName.

    Logged query strings

해당 기법이 임시 조사를 수행하는 동안 보고서를 작성하여 분석에 보다 용이한 레이아웃으로 쿼리 문자열을 통합 및 표시할 수 있습니다.

장기 실행 쿼리 확인

기간 열을 추가하여 메트릭으로 선택한 쿼리뿐만 아니라 모든 쿼리에 대한 숫자를 가져옵니다. 이 데이터를 정렬하면 완료하는 데 가장 오래 걸리는 쿼리가 표시됩니다.

  1. 모니터링 섹션에서 로그를 선택하여 로그 정보를 쿼리합니다.

  2. 다음 기본 쿼리를 실행하여 지속 시간(밀리초)을 기준으로 정렬된 쿼리를 반환합니다. 가장 오래 실행되는 쿼리가 맨 위에 있습니다.

    AzureDiagnostics
    | project OperationName, resultSignature_d, DurationMs, Query_s, Documents_d, IndexName_s
    | where OperationName == "Query.Search"
    | sort by DurationMs
    

    Sort queries by duration

메트릭 경고 만들기

메트릭 경고는 미리 정의한 수정 작업을 트리거하거나 알림을 보내는 임계값을 설정합니다. 쿼리 실행과 관련된 경고를 만들 수 있지만 리소스 상태, 검색 서비스 구성 변경, 기술 실행 및 문서 처리(인덱싱)에 대한 경고를 만들 수도 있습니다.

모든 임계값은 사용자 정의이므로 경고를 트리거해야 하는 활동 수준을 파악해야 합니다.

쿼리 모니터링의 경우 검색 대기 시간 및 제한된 쿼리에 대한 메트릭 경고를 만드는 것이 일반적입니다. 쿼리가 삭제되는 시기를 알고 있는 경우 부하를 줄이거나 용량을 늘리는 구제를 찾을 수 있습니다. 예를 들어 인덱싱 중에 제한된 쿼리가 증가하는 경우 쿼리 작업이 가라앉을 때까지 연기할 수 있습니다.

특정 복제본(replica) 파티션 구성의 제한을 푸시하는 경우 QPS(쿼리 볼륨 임계값)에 대한 경고를 설정하는 것도 유용합니다.

  1. 모니터링에서 경고를 선택한 다음 경고 규칙 만들기를 선택합니다.

  2. 조건 아래에서 추가를 선택합니다.

  3. 신호 논리를 구성합니다. 신호 형식의 경우 메트릭을 선택한 다음, 신호를 선택합니다.

  4. 신호를 선택한 후 차트를 사용하여 조건 설정을 진행하는 방법에 대한 정보에 입각한 결정에 대한 기록 데이터를 시각화할 수 있습니다.

  5. 다음으로, 아래로 스크롤하여 경고 논리로 이동합니다. 개념 증명을 위해 테스트 목적으로 인위적으로 낮은 값을 지정할 수 있습니다.

  6. 다음으로 작업 그룹을 지정하거나 만듭니다. 임계값이 충족될 때 호출할 응답입니다. 푸시 알림 또는 자동화된 응답일 수 있습니다.

  7. 마지막으로 경고 세부 정보를 지정합니다. 경고 이름을 지정하고 설명하고, 심각도 값을 할당하고, 사용 또는 사용 안 함 상태로 규칙을 만들지 여부를 지정합니다.

전자 메일 알림을 지정한 경우 제목 줄이 "Azure: 활성화된 심각도: 3 <your rule name>"인 "Microsoft Azure"에서 전자 메일을 받습니다.

다음 단계

아직 수행하지 않은 경우 검색 서비스 모니터링의 기본 사항을 검토하여 전체 범위의 감독 기능에 대해 알아봅니다.