Azure 부하 테스트를 사용하여 컨테이너 앱에서 Azure Functions 크기 조정 테스트

동기 부여

나는 현재 이것을 Azure Container Apps 으로 전송할 수 있는지 여부와 방법을 평가하고 있습니다.

당시 Service Fabric을 사용하는 주된 이유는 이제 일반 Azure Functions(Premium)/App Service 호스팅에서도 사용할 수 있는 자체 가상 네트워크(인바운드 및 아웃바운드) 내에서 Azure Functions를 호스팅할 수 있다는 것이었습니다. 그러나 이러한 유형의 호스팅에는 다른 제한 사항이 있습니다. 필요한 아웃바운드 IP 주소의 양 - 이 시나리오에는 맞지 않습니다.

컨테이너 앱은 시나리오 및 요구 사항BYO/bring-your-own virtual network feature을 사용할 수 있게 되면 유효한 호스팅 옵션이 되는 것 같습니다.

"you could do Kubernetes" ... yeah, but there would be no operational savings & gain for us, compared to Service Fabric; I want the real deal: I just don't care about the cluster/compute resource

기다리는 동안 나중에 유용할 수 있는 다른 기능을 살펴보고 싶습니다. auto scaling 부터 시작합니다.

설정

the steps described in the accompanying repository을 사용하여 이러한 리소스가 생성됩니다. Pulumi Native을 사용하여 다음 리소스 세트가 생성됩니다.

the step - change ca-pulumi-dotnet/Program.cs to FunctionAppStack.cs - before deploying is important in case to test any of the other Container Apps workload like Dapr; to get the exact working version it makes sense to checkout the tagged version

2개의 Function App의 이미지를 저장하기 위한 Container Registry

2개의 컨테이너 앱을 호스팅하는 컨테이너 앱 환경: fapp1 = Service Bus에 대한 HTTP 수신, fapp2 = Service Bus 큐 수신

대기 중인 수신을 처리하기 위한 Service Bus 네임스페이스

실제 부하 테스트를 실행하기 위한 부하 테스트 리소스

일부 조정 동작을 평가하기 위한 Application Insights 인스턴스

여기에서 Pulumi로 생성된 것은 Azure CLI, ARM 또는 Bicep 또는 그 조합으로도 달성할 수 있습니다. 하나의 간결한 스크립트에서 Docker 이미지 생성을 포함한 전체 스택을 원했습니다.

특별한 재료

Pulumi IaC를 처음 사용하기 때문에 이러한 사항에 대해 더 많은 탐색과 작업이 필요했습니다.

개인 Container Registry 자격 증명을 Container App 배포에 연결

함수 앱에서 Application Insights 후킹

배포를 실행하는 사람에게 부하 테스트 소유자 역할 할당을 포함하여 부하 테스트 서비스 생성

기능 호스트 ID 고려

"자체적으로"컨테이너에서 함수 앱을 호스팅할 때/App Services 외부에 있고 적절한 싱글톤 및 확장 동작을 갖기를 원한다는 이 게시물의 원래 생성 후 며칠 후,

환경 변수가 있는 동일한 함수 앱의 모든 컨테이너 인스턴스에서 동일한 값으로 능동적으로 설정hostIdAzureFunctionsWebHost__hostId

Functions 런타임이 환경 변수와 모든 동기화 정보를 유지하는 스토리지 계정에 연결합니다AzureWebJobsStorage.

    new EnvironmentVarArgs
    {
        Name = "AzureWebJobsStorage",
        SecretRef = "storageconnection",
    },
    new EnvironmentVarArgs
    {
        Name = "AzureFunctionsWebHost__hostId",
        Value = Guid.NewGuid().ToString().Replace("-", ""),
    }

I conducted the test again after this addition, however it had no noticeable influence on scaling and test results.

부하 테스트 생성 및 실행

간단한 JMeter 테스트 계획을 생성하고 이를 저장소에 ca-pulumi-dotnet/loadtest.jmx로 추가한 다음 테스트를 생성할 때 Pulumi 출력 값을 매개변수loadtesturlfapp1로 삽입ingress_url할 수 있습니다.



테스트 계획이 생성되면 실행할 수 있습니다. 10000개의 요청을 제출한 다음 중지하도록 구성됩니다.

an error Non HTTP response code: java.net.UnknownHostException indicates, that the URL passed into the ingress_url parameter is not correct

시험 결과

간단한 Application Insights 쿼리는 컨테이너 앱 환경의 효과적인 크기 조정을 표시할 수 없지만 두 함수 앱(둘 다 분홍색)이 최소 단일 인스턴스로 15-30초 동안 머문 다음 최대 기어로 시작하여 증가된 부하 처리:

requests
| where timestamp between ( todatetime("2022-01-30T12:45:00") .. todatetime("2022-01-30T12:55:00"))
| summarize count() by bin(timestamp,15s), cloud_RoleInstance
| render columnchart 

오후 12:49:00부터 HTTP 수신이 완료되고 fapp2 인스턴스가 대기열에 있는 수신을 균형 잡힌 방식으로 처리하는 것을 볼 수 있습니다.

또한 동일한 양의 인스턴스가 시작 및 중지되었는지 확인하기 위해 이 Azure Monitor 쿼리를 작성했습니다.

ContainerAppConsoleLogs_CL 
| where ContainerImage_s contains "fapp"
| where TimeGenerated between( todatetime("2022-01-30T12:45:00") .. todatetime("2022-01-30T13:15:00") )
| where Log_s contains "Application is shutting down..." or Log_s startswith "Application started."
| parse Log_s with * "Application" eventName "." *
| summarize count() by eventName, bin(TimeGenerated, 5m)
| render columnchart 

Application started is logged twice, I only take the entry where the message starts in the beginning without leading blanks.

결론

나에게 단순함

호스팅

스케일링

부하 테스트

이 샘플에서는 압도적입니다. 그 과정에서 우리 팀을 기다리고 있는 몇 가지 기발한 일이 있을 것이라고 확신합니다. 여기에 계속 게시하겠습니다.

유사한 게시물