다음을 통해 공유


사용자 지정 플러그 인을 사용한 Azure Load Testing

솔루션 아이디어

이 문서는 솔루션 아이디어 설명입니다. 클라우드 설계자는 이 지침을 사용하여 이 아키텍처의 일반적인 구현을 위한 주요 구성 요소를 시각화할 수 있습니다. 이 문서를 시작점으로 사용하여 워크로드의 특정 요구 사항에 맞는 잘 설계된 솔루션을 디자인할 수 있습니다.

이 솔루션은 Apache JMeter 스크립트 및 사용자 지정 플러그 인을 실행하여 사용자 및 디바이스 동작을 시뮬레이션할 수 있는 서비스인 Azure Load Testing을 사용하는 방법에 대한 지침을 제공합니다. 또한 이 솔루션은 KPI(핵심 성과 지표)를 디자인하고 Azure Functions 및 Azure Event Hubs를 사용하여 샘플 애플리케이션에서 부하 테스트 결과를 모니터링하고 분석하기 위한 대시보드를 개발하는 방법을 설명합니다. 이 문서에서는 JMeter, 플러그 인 및 사용자 지정 플러그 인뿐만 아니라 Azure Functions 및 Event Hubs에 대해 잘 알고 있다고 가정합니다.

아키텍처

부하 테스트를 수행하려면 테스트 중에 수행할 작업을 JMeter에 알려주는 일련의 지침인 테스트 계획이 필요합니다. 테스트 계획에는 각각 다른 설정 및 구성이 있는 여러 테스트 시나리오가 포함될 수 있습니다. 예를 들어 웹 애플리케이션에 액세스하는 단일 사용자를 시뮬레이트하는 시나리오와 동일한 애플리케이션에 동시에 액세스하는 여러 사용자를 시뮬레이트하는 다른 시나리오가 있을 수 있습니다.

또한 테스트 계획에는 각각 다른 설정 및 구성이 있는 여러 테스트 사례가 포함될 수 있습니다. 이 경우 특정 기간 동안 온도 및 습도를 보고하는 디바이스가 있다고 가정합니다. 디바이스가 Azure의 이벤트 허브로 데이터를 보내고 있습니다. 이벤트 허브는 데이터를 처리한 다음 Azure SQL Database와 같은 다른 다운스트림 서비스로 데이터를 보내는 Azure Function을 트리거합니다. Azure Function은 테스트하려는 서비스입니다. 테스트 계획은 디바이스의 동작을 시뮬레이션하고 이벤트 허브로 데이터를 보내도록 설계되었습니다.

부하 테스트를 위한 샘플 아키텍처의 다이어그램.

이 아키텍처의 Visio 파일을 다운로드합니다.

데이터 흐름

이 예제에서 데이터 흐름은 다음과 같습니다.

  1. 시뮬레이션된 디바이스는 Azure Load Testing 에이전트를 통해 이벤트 허브로 데이터를 보냅니다. JMeter 사용자 지정 플러그 인을 사용하여 디바이스의 모든 동작을 시뮬레이션할 수 있습니다. Azure Load Test 에이전트는 모든 유형의 시뮬레이션된 디바이스에 대한 사용자 지정 플러그 인을 실행한 후 이벤트 허브로 데이터를 전송합니다.
  2. 이벤트 허브는 데이터를 처리한 다음 Azure SQL Database 및 Azure Digital Twins와 같은 다른 다운스트림 서비스로 데이터를 보내는 Azure Function을 트리거합니다.
  3. Azure Monitor 서비스는 Azure Function 및 Event Hubs를 모니터링하는 데 사용됩니다.
  4. Azure Load Testing 서비스는 Azure Monitor 서비스에서 데이터를 수집한 다음 대시보드에 표시합니다.

구성 요소

이 예제에서는 다음 구성 요소가 사용됩니다.

  • Azure 부하 테스트: Azure Load Testing을 사용하면 Apache JMeter 스크립트 및 사용자 지정 플러그 인을 실행하여 사용자 및 디바이스 동작을 시뮬레이션할 수 있습니다. 부하 테스트를 관리하고 실행하기 위한 웹 기반 인터페이스와 프로세스를 자동화하는 데 사용할 수 있는 API 집합을 제공합니다. Azure Load Testing은 완전히 관리되는 서비스이므로 서버 또는 인프라 관리에 대해 걱정할 필요가 없습니다. JMeter 스크립트 및 사용자 지정 플러그 인을 업로드할 수 있으며 Azure Load Testing은 나머지를 처리합니다.
  • Azure Event Hubs: Azure Event Hubs는 다양한 원본에서 이벤트 및 스트리밍 데이터를 실시간으로 수집, 처리 및 분석하는 데 사용할 수 있는 클라우드 기반 이벤트 처리 서비스입니다. Event Hubs는 AMQP(고급 메시지 큐 프로토콜), HTTPS, Kafka 프로토콜, MQTT(메시지 큐 원격 분석 전송) 및 WebSocket을 통한 AMQP를 비롯한 여러 프로토콜을 지원합니다. 올바른 프로토콜을 선택하는 것은 작업 중인 데이터 형식, 애플리케이션의 특정 요구 사항, 프로토콜 자체의 기능 및 제한 사항 등 여러 가지 요인에 따라 달라집니다.
  • Azure Functions: Azure Functions는 서버 또는 인프라를 관리할 필요 없이 코드를 실행할 수 있는 서버리스 컴퓨팅 서비스입니다. C#, F#, Java, JavaScript, PowerShell, Python 및 TypeScript를 비롯한 여러 프로그래밍 언어를 지원합니다. Azure Functions를 사용하여 Event Hubs의 이벤트 및 스트리밍 데이터뿐만 아니라 Azure Storage 및 Azure Cosmos DB와 같은 다른 원본도 처리할 수 있습니다.
  • JMeter GUI: JMeter GUI는 주로 웹 애플리케이션의 성능을 테스트하는 데 사용되는 오픈 소스 부하 테스트 도구입니다. 원래 웹 애플리케이션 테스트를 위해 개발되었습니다. 그러나 SOAP 및 REST 웹 서비스, FTP 서버 및 데이터베이스와 같은 다른 유형의 애플리케이션을 테스트하는 데 사용할 수도 있습니다.
  • Azure Monitor: Azure Monitor는 Azure 리소스에 대한 모니터링 및 경고 기능을 제공합니다. 이를 통해 애플리케이션의 성능 및 상태와 기본 인프라도 모니터링할 수 있습니다. Azure Monitor를 사용하여 Event Hubs 및 Azure Functions뿐만 아니라 Azure Storage 및 Azure Cosmos DB와 같은 다른 Azure 서비스를 모니터링할 수 있습니다.

시나리오 정보

Azure Load Testing을 사용하면 기존 Apache JMeter 스크립트를 사용하여 모든 Azure 리소스에서 클라우드 규모로 부하 테스트를 실행할 수 있습니다.

JMeter를 사용하면 테스터가 부하 테스트, 스트레스 테스트 및 기능 테스트를 만들고 실행할 수 있습니다. 여러 사용자가 동시에 웹 애플리케이션에 액세스하는 것을 시뮬레이션하여 테스터가 부하가 많이 발생할 수 있는 잠재적인 성능 병목 상태 또는 기타 문제를 식별할 수 있도록 합니다. JMeter를 사용하여 응답 시간, 처리량 및 오류 속도와 같은 다양한 성능 메트릭을 측정할 수 있습니다.

JMeter는 GUI 기반 인터페이스를 사용하여 사용자가 여러 테스트 시나리오를 포함할 수 있는 테스트 계획을 만들 수 있도록 하며, 각각 다른 설정과 구성이 있습니다. 테스터는 플러그 인을 사용하거나 사용자 지정 코드를 작성하여 JMeter를 사용자 지정할 수 있으므로 기본적으로 제공되는 기능 이상으로 기능을 확장할 수 있습니다. 플러그 인은 AMQP 및 Websocket과 같은 비 HTTP 프로토콜을 사용하는 서비스를 사용하는 데 도움이 될 수 있습니다.

JMeter는 부하 테스트를 위한 다양한 기능과 기능을 제공하지만 기본 제공 기능에서 다루지 않는 특정 사용 사례 또는 요구 사항이 있을 수 있습니다. 테스터는 사용자 지정 플러그 인을 개발하여 새 기능을 추가하거나 기존 기능을 사용자 지정하여 요구 사항에 더 잘 맞도록 할 수 있습니다.

예를 들어 사용자 지정 플러그 인을 개발하여 특정 유형의 사용자 동작을 시뮬레이션하거나 보다 현실적인 테스트 데이터를 생성할 수 있습니다. 또한 사용자 지정 플러그 인을 개발하여 로깅 및 보고 도구 또는 연속 통합 및 배포 파이프라인과 같은 다른 도구 또는 시스템과 JMeter를 통합할 수 있습니다. 사용자 지정 플러그 인을 사용하면 테스트 프로세스를 간소화하고 부하 테스트를 전체 소프트웨어 개발 워크플로에 쉽게 통합할 수 있습니다. 전반적으로 테스터는 JMeter를 특정 요구 사항에 맞게 조정하고 부하 테스트 작업의 정확도와 효율성을 향상시킬 수 있습니다.

이 예제에서는 일정 기간 동안 온도 및 습도를 보고하는 디바이스가 있다고 가정합니다. 사용자 지정 JMeter 플러그 인을 사용하여 이 간단한 동작을 시뮬레이션할 수 있습니다. 여기에 제공된 사용자 지정 플러그 인의 현재 구현에서는 제공된 템플릿을 사용하여 임의 데이터를 생성합니다. 그러나 플러그 인은 모든 디바이스에 대해 가능한 복잡한 동작을 포함할 수 있습니다. 이 예제에서 디바이스는 Azure의 이벤트 허브로 데이터를 보냅니다. 이벤트 허브는 데이터를 처리한 다음 Azure SQL Database와 같은 다른 다운스트림 서비스로 데이터를 보내는 Azure Function을 트리거합니다. Azure Function은 테스트하려는 서비스입니다. 테스트 계획은 디바이스의 동작을 시뮬레이션하고 이벤트 허브로 데이터를 보내도록 설계되었습니다.

잠재적인 사용 사례

사용자 지정 플러그 인과 함께 Azure Load Testing을 사용하는 것은 다음과 같은 다양한 시나리오에서 유용할 수 있습니다.

  • AMQP 및 Websocket과 같은 비 HTTP 프로토콜을 사용하는 애플리케이션의 성능을 테스트합니다.
  • 사용자 지정 프로토콜을 사용하는 애플리케이션의 성능을 테스트합니다.
  • 비 Microsoft SDK를 사용하는 애플리케이션의 성능 테스트
  • 특정 유형의 사용자 또는 디바이스 동작을 시뮬레이션하거나 보다 현실적인 테스트 데이터를 생성합니다.

사용자 지정 플러그 인

JMeter 컨텍스트의 사용자 지정 플러그 인은 기본적으로 제공되는 기능 이상으로 기능을 확장하기 위해 JMeter에 추가할 수 있는 소프트웨어 구성 요소입니다. 사용자 또는 비 Microsoft 개발자는 JMeter에 새 기능, 함수 또는 통합을 추가하는 사용자 지정 플러그 인을 개발할 수 있습니다. 사용자 지정 플러그 인은 Java 프로그래밍 언어 및 JMeter PDK(플러그 인 개발 키트)를 사용하여 개발할 수 있습니다. PDK는 GUI 요소, 수신기 및 샘플러를 포함하여 새 플러그 인을 더 쉽게 만들 수 있는 도구 및 API 집합을 제공합니다.

사용자 지정 플러그 인은 JMeter에 다양한 기능을 추가할 수 있습니다. 또한 로깅 및 보고 도구와 같은 다른 시스템과 JMeter를 통합하거나 테스트 데이터에 다른 데이터 원본을 사용할 수 있습니다. 전반적으로 사용자 지정 플러그 인을 사용하면 사용자가 특정 요구 사항에 맞게 JMeter를 확장하고 부하 테스트 작업의 정확도와 효율성을 향상시킬 수 있습니다.

JMeter에서 Event Hubs에 대한 사용자 지정 샘플러를 구현하려면 Azure Load Testing 플러그 인제공된 지침을 따릅니다. 사용자 지정 샘플러가 구현되면 다른 샘플러와 마찬가지로 Azure Load Test의 JMeter 테스트 계획에서 사용할 수 있습니다.

특정 시나리오를 실행하는 스레드 수(가상 사용자 및 디바이스)를 제어하는 스레드 그룹을 사용하여 테스트 계획을 구현할 수 있습니다. 각 스레드 그룹은 스레드 수, 램프업 기간, 루프 수 및 기간에 대해 서로 다른 설정을 가질 수 있습니다. 스레드 그룹은 테스트 계획 구성 및 애플리케이션 요구 사항에 따라 순차적으로 또는 병렬로 실행할 수 있습니다. 샘플러를 스레드 그룹에 추가하고, 매개 변수를 설정하고, 필요에 따라 구성할 수 있습니다. 사용자 지정 샘플러는 JMeter에서 강력한 도구가 될 수 있으므로 기본 제공 샘플러가 지원하지 않는 복잡한 시나리오 및 요청을 시뮬레이션할 수 있습니다.

사용자 지정 플러그 인을 사용하여 Apache JMeter 스크립트 만들기

이 섹션에서는 Event Hubs를 사용하여 애플리케이션을 로드하는 샘플 JMeter 테스트 스크립트를 만듭니다.

JMeter 테스트 스크립트 샘플을 만들려면 다음을 수행합니다.

  1. 로컬 컴퓨터에 LoadTest.jmx 파일을 만듭니다.

    touch LoadTest.jmx
    
  2. 텍스트 편집기에서 LoadTest.jmx를 열고 파일에 다음 코드 조각을 붙여넣습니다. 이 스크립트는 이벤트 허브에 이벤트를 동시에 전송하는 36개의 가상 머신의 부하 테스트를 시뮬레이션하고 완료하는 데 10분이 걸립니다.

    <?xml version="1.0" encoding="UTF-8"?>
    <jmeterTestPlan version="1.2" properties="5.0" jmeter="5.5">
        <hashTree>
        <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Test Plan" enabled="true">
            <stringProp name="TestPlan.comments"></stringProp>
            <boolProp name="TestPlan.functional_mode">false</boolProp>
            <boolProp name="TestPlan.tearDown_on_shutdown">true</boolProp>
            <boolProp name="TestPlan.serialize_threadgroups">false</boolProp>
            <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
            <collectionProp name="Arguments.arguments"/>
            </elementProp>
            <stringProp name="TestPlan.user_define_classpath"></stringProp>
        </TestPlan>
        <hashTree>
            <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Thread Group" enabled="true">
            <stringProp name="ThreadGroup.on_sample_error">continue</stringProp>
            <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true">
                <boolProp name="LoopController.continue_forever">false</boolProp>
                <intProp name="LoopController.loops">-1</intProp>
            </elementProp>
            <stringProp name="ThreadGroup.num_threads">36</stringProp>
            <stringProp name="ThreadGroup.ramp_time">20</stringProp>
            <boolProp name="ThreadGroup.scheduler">true</boolProp>
            <stringProp name="ThreadGroup.duration">600</stringProp>
            <stringProp name="ThreadGroup.delay"></stringProp>
            <boolProp name="ThreadGroup.same_user_on_next_iteration">false</boolProp>
            </ThreadGroup>
            <hashTree>
            <com.microsoft.eventhubplugin.EventHubPlugin guiclass="com.microsoft.eventhubplugin.EventHubPluginGui" testclass="com.microsoft.eventhubplugin.EventHubPlugin" testname="Azure Event Hubs Sampler" enabled="true">
                <stringProp name="eventHubConnectionVarName">EventHubConnectionString</stringProp>
                <stringProp name="eventHubName">telemetry-data-changed-eh</stringProp>
                <stringProp name="liquidTemplateFileName">StreamingDataTemplate.liquid</stringProp>
            </com.microsoft.eventhubplugin.EventHubPlugin>
            <hashTree/>
            </hashTree>
        </hashTree>
        </hashTree>
    </jmeterTestPlan>
    

    com.microsoft.eventhubplugin.EventHubPluginGui com.microsoft.eventhubplugin.EventHubPlugin 구현은 Azure 샘플에서 사용할 수 있습니다.

  3. 파일에서 노드 값을 eventHubConnectionVarName Event Hubs 연결 문자열 호스트를 지정하는 변수 이름으로 설정합니다. 예를 들어 Event Hubs의 연결 문자열 저장하는 환경 변수를 EventHubConnectionString원하는 경우 이 변수를 설정하여 EventHubConnectionString 환경 변수의 값을 설정합니다.

    Important

    부하 테스트 스크립트를 실행하기 전에 값 EventHubConnectionString 이 Azure 부하 테스트 만들기 프로세스의 일부로 설정되었는지 확인합니다.

  4. 파일에서 노드 값을 eventHubName 이벤트 허브 이름(예: .)으로 telemetry-data-changed-eh설정합니다.

  5. 노드 값을 liquidTemplateFileName 이벤트 허브로 전송되는 메시지가 포함된 파일로 설정합니다. 예를 들어 다음과 같은 이름의 파일을 만듭니다 StreamingDataTemplate.liquid .

    {
        {% assign numberOfMachines = 36 %}
        {% assign machineId = dataGenerator.randomNaturalNumber | modulo: numberOfMachines %}
        "MachineId": "{{machineId | prepend: '0000000000000000000000000000000000000000' | slice: -27, 27 }}"
        "Temperature": {{dataGenerator.randomInt | modulo: 100 }},
        "Humidity": {{dataGenerator.randomInt | modulo: 100 }}
    }
    

    이 예제에서 이벤트 허브 메시지에 대한 페이로드는 3개의 속성을 포함하는 MachineIdTemperatureJSON 개체이며Humidity, 여기서 MachineId 길이가 27인 임의로 생성된 ID이며 Temperature Humidity 100 미만의 임의 정수입니다. 이 파일은 Liquid 템플릿 구문입니다. Liquid 템플릿은 다양한 웹 개발 프레임워크에서 사용되는 인기 있는 템플릿 언어입니다. Liquid 템플릿을 사용하면 개발자가 쉽게 업데이트하고 수정할 수 있는 동적 콘텐츠를 만들 수 있습니다. 변수, 조건, 루프 및 기타 동적 요소를 이벤트 허브 메시지에 삽입할 수 있습니다. 구문은 간단하며 시작하는 데 도움이 되는 많은 온라인 리소스가 있습니다. 전반적으로 Liquid 템플릿은 사용자 지정 가능한 동적 메시지를 만드는 강력하고 유연한 방법을 제공합니다.

  6. 파일을 저장 후 닫습니다.

    Important

    JMeter 스크립트의 샘플러 이름에 개인 데이터를 포함하지 마세요. 샘플러 이름은 Azure Load Testing 테스트 결과 대시보드에 표시됩니다. JMeter 스크립트 파일과 함께 Liquid 템플릿 샘플을 Azure 샘플에서 다운로드할 수 있습니다.

새 플러그 인을 사용하여 부하 테스트 실행

Azure Load Testing이 부하 테스트를 시작하면 먼저 다른 모든 파일과 함께 JMeter 스크립트를 테스트 엔진 인스턴스에 배포한 다음 Apache JMeter 플러그 인 및 Azure Load Testing을 사용하여 부하 테스트 사용자 지정에 지시된 대로 부하 테스트를 시작합니다. 테스트를 실행하기 전에 매개 변수 탭으로 이동하여 정의EventHubConnectionString한 다음 이벤트 허브에 연결 문자열 제공합니다.

테스트의 매개 변수를 보여 주는 스크린샷

환경에 대한 성능 테스트 설정

모든 성능 테스트에서 프로덕션 환경과 유사한 환경을 갖는 것이 중요합니다. 이 예제에서는 시스템 용량 및 시스템 성능을 더 잘 이해하기 위해 성능 테스트에 다음 환경이 사용됩니다.

샘플 아키텍처에 따라 성능 테스트에 다음 서비스를 사용할 수 있습니다.

서비스 구성
Eventhub PU(처리 장치)가 하나 있는 프리미엄입니다.
Azure 함수 프리미엄 플랜(EP1)이 있는 Linux - 210 ACU, 3.5GB 메모리 및 1개 vCPU 해당 Standard_D1_v2
지역 미국 동부

Event Hubs 및 Azure Functions를 비롯한 모든 Azure 서비스에 적합한 서비스 계층을 선택하는 것은 복잡한 프로세스이며 여러 요인에 따라 달라집니다. 자세한 내용은 Azure Event Hubs 가격 책정Azure Functions 가격 책정을 참조하세요.

성능 테스트를 위한 KPI 디자인

성능 테스트를 위해 KPI(핵심 성과 지표)를 디자인하려면 비즈니스 요구 사항과 시스템 아키텍처의 두 가지가 필요합니다. 비즈니스 요구 사항은 응답 시간, 처리량 또는 오류 비율과 같이 측정하려는 KPI를 알려줍니다. 시스템 아키텍처는 웹 서버, 데이터베이스 또는 API와 같은 각 구성 요소의 성능을 테스트하는 방법을 알려줍니다. 또한 부하 테스트, 스트레스 테스트 또는 지구력 테스트와 같은 최상의 성능 테스트 전략을 선택하는 데 도움이 됩니다.

이 예제에서 비즈니스 요구 사항은 다음과 같습니다.

  • 시스템은 초당 1,000개의 요청을 처리할 수 있어야 합니다.
  • 시스템 안정성은 0.99보다 높아야 합니다.
  • 시스템은 개인 데이터 정보를 보고하는 1,000개의 동시 디바이스를 처리할 수 있어야 합니다.
  • 지원될 수 있는 디바이스 수 측면에서 시스템의 최대 용량을 지정합니다. 예를 들어 현재 용량의 3배를 가진 시스템에서 1,000개의 동시 디바이스를 지원할 수 있나요?

이러한 요구 사항에 따라 성능 테스트를 위한 KPI는 다음과 같습니다.

KPI 설명
RPS 이벤트 허브에 대한 초당 요청 수
LOAD 성능 테스트 중 이벤트 허브로 전송된 로드 또는 요청 수
IR 함수 실행 수 또는 수집 속도
RT Azure 함수 실행 시간의 평균 시간
AMU Azure Functions의 평균 메모리 사용량
SR 모든 함수 실행의 성공률
ARS 평균 다운스트림 서비스 응답 시간(예: SQL Server 또는 마이크로 서비스)
DF 내부 Azure 함수 오류를 포함한 종속성 오류 수
MRPS 이벤트 허브에 백로그가 없는 최대 RPS(시스템 용량)

KPI를 측정하는 방법

KPI를 측정하려면 성능 테스트 전략이 있어야 합니다. 이 전략은 각 구성 요소에 대한 성능 테스트 접근 방식을 정의합니다. 이 예제에서는 다음 성능 테스트 전략이 사용됩니다.

  • Event Hubs: 이벤트 허브에 대한 성능 테스트 방법은 이벤트 허브에 많은 메시지를 보낸 다음 RPS 및 LOAD를 측정하는 것입니다. RPS는 초당 이벤트 허브로 전송되는 메시지 수입니다. LOAD는 성능 테스트 중에 이벤트 허브로 전송되는 총 메시지 수입니다. Azure Load Testing 서비스는 RPS 및 LOAD를 측정할 수 있습니다.
  • Azure Functions: Azure Functions의 성능 테스트 접근 방식은 다음 메트릭을 측정하는 것입니다.
    • IR은 함수 실행 또는 수집 속도의 수입니다.
    • RT는 Azure 함수 실행 시간의 평균 시간입니다.
    • AMU는 Azure Functions의 평균 메모리 사용량입니다.
    • SR은 모든 함수 실행의 성공률입니다.
    • ARS는 평균 다운스트림 서비스 응답 시간입니다.
    • DF는 내부 Azure 함수 오류를 포함한 종속성 오류 수입니다.
    • Azure Monitor 서비스는 AMU, ARS 및 DF를 측정할 수 있지만 IR, RT 또는 SR은 측정할 수 없습니다.

Azure Monitor 서비스를 사용하여 KPI를 측정하려면 Azure Functions에 Application Insights를 사용하도록 설정해야 합니다. 자세한 내용은 Application Insights 통합 사용을 참조하세요.

Azure Monitor 서비스를 사용하도록 설정한 후 다음 쿼리를 사용하여 KPI를 측정할 수 있습니다.

  • IR: FunctionAppLogs | where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize count() by FunctionName, Level, bin(TimeGenerated, 1h) | order by FunctionName desc
  • RT: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed "| parse Message with "Executed " Name " (" Result ", Id=" Id ", Duration=" Duration:long "ms)"| project TimeGenerated, Message, FunctionName, Result, FunctionInvocationId, Duration
  • SR: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize Success=countif(Level == "Information" ), Total=count() by FunctionName| extend Result=Success*100.0/Total| project FunctionName, Result| order by FunctionName desc

Azure Monitor 대시보드 샘플

다음은 쿼리를 기반으로 Azure Functions용 KPI를 보여 주는 Azure Monitor 대시보드의 샘플입니다.

Azure Monitor 대시보드의 스크린샷 샘플.

결론

이 문서에서는 KPI를 디자인하고 Azure 부하 테스트용 대시보드를 개발하는 방법을 알아보았습니다. 또한 JMeter에서 사용자 지정 플러그 인을 사용하여 Event Hubs와 통합된 Azure Functions에서 부하 테스트를 수행하는 방법을 알아보았습니다. 동일한 방법을 사용하여 다른 Azure 서비스에서 부하 테스트를 수행할 수 있습니다. Azure DevOps를 사용하여 부하 테스트 스크립트에 대한 CI/CD(연속 통합 및 배달) 파이프라인을 설정할 수도 있습니다.

자세한 내용은 Azure Load Testing을 참조하세요.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계