PowerShell과 Azure Functions 또는 Azure Automation을 사용하여 자동으로 작업 일시 중지

일부 애플리케이션의 경우 스트림 처리 방법(예: Azure Stream Analytics를 통해)은 필요하지만, 지속적으로 실행할 필요는 없습니다. 그 이유는 다음과 같습니다.

일정에 따라 도착하는 입력 데이터(예: 정시)
희소하거나 낮은 볼륨의 들어오는 데이터(분당 몇 개 레코드)
시간 범위 기능을 활용하지만, 기본적으로 일괄 처리로 실행되는 비즈니스 프로세스(예: 재무 또는 HR)
소규모 장기 실행 작업을 포함하는 데모, 프로토타입 또는 테스트

Stream Analytics 작업은 시간이 경과함에 따라 스트리밍 단위당 청구되므로 이러한 작업을 지속적으로 실행하지 않으면 비용을 절감할 수 있습니다.

이 문서에서는 Azure Stream Analytics 작업에 자동 일시 중지를 설정하는 방법을 설명합니다. 그리고 일정에 따라 작업을 자동으로 일시 중지하고 다시 시작하는 작업을 구성합니다. 일시 중지 용어는 청구를 방지하기 위해 작업 상태가 중지된 것을 의미합니다.

이 문서에서는 전체적인 설계와 필수 구성 요소, 일부 구현 세부 정보를 설명합니다.

참고

작업 자동 일시 중지에는 단점이 있습니다. 주요 단점은 짧은 대기 시간/실시간 기능 손실과 작업이 일시 중지되는 동안 입력 이벤트 백로그가 감독되지 않고 증가할 수 있는 잠재적 위험입니다. 조직에서는 대규모로 실행되는 대부분 프로덕션 시나리오에 자동 일시 중지를 고려해서는 안 됩니다.

디자인

이 문서의 예제에서 사용자는 M분 동안 일시 중지하기 전에 N분 동안 작업을 실행하려고 합니다. 작업이 일시 중지되면 입력 데이터가 소비되지 않고 업스트림이 누적됩니다. 작업이 시작되면 해당 백로그를 따라잡고 다시 종료되기 전에 데이터를 처리합니다.

시간 경과에 따라 자동으로 일시 중지된 작업의 동작을 보여 주는 다이어그램.

작업이 실행 중이면 메트릭이 정상 상태가 될 때까지 작업이 중지되지 않아야 합니다. 주의해야 할 메트릭은 입력 백로그와 워터마크입니다. 둘 다 N분 이상 기준선에 있는지 확인합니다. 이 동작은 다음 두 가지 작업으로 변환됩니다.

중지된 작업은 M분 후에 다시 시작됩니다.
실행 중인 작업은 N분 후 백로그 및 워터마크 메트릭이 정상 상태가 되는 즉시 언제든지 중지됩니다.

작업의 가능한 상태를 보여 주는 다이어그램.

예를 들어 N = 5분, M = 10분이라고 가정해 봅시다. 이 설정을 사용하면 작업이 15분 동안 받은 모든 데이터를 처리하는 데 최소 5분이 걸립니다. 잠재적 비용 절감은 최대 66%입니다.

작업을 다시 시작하려면 마지막 중지 시시작 옵션을 사용합니다. 이 옵션은 작업이 중지된 이후 업스트림으로 백로그된 모든 이벤트를 처리하도록 Stream Analytics에 지시합니다.

이 상황에서는 두 가지 주의 사항이 있습니다. 첫째, 입력 스트림의 보존 기간보다 오랜 시간 동안 작업을 중지할 수 없습니다. 하루에 한 번만 작업을 실행하는 경우 이벤트의 보존 기간이 1일 이상인지 확인해야 합니다. 둘째, 마지막 중지 시간 모드를 수락하려면 작업이 한 번 이상 시작되었어야 합니다(아니면 말 그대로 이전에 중지된 적이 없음). 따라서 작업의 첫 번째 실행은 수동이어야 합니다. 그렇지 않으면 스크립트를 확장하여 해당 케이스를 처리해야 합니다.

마지막 고려 사항은 해당 작업을 idempotent로 설정하는 것입니다. 그런 다음에는 사용 편의성과 복원력을 위해 부작용 없이 원하는 속도로 반복할 수 있습니다.

구성 요소

API 호출

이 문서에서는 다음과 같은 측면에서 Stream Analytics와 상호 작용해야 할 필요성이 있다고 가정합니다.

현재 작업 상태 가져오기(Stream Analytics 리소스 관리):
- 작업이 실행 중인 경우:
  - 작업이 시작된 이후의 시간(로그)을 가져옵니다.
  - 현재 메트릭 값(메트릭)을 가져옵니다.
  - 해당하는 경우 작업을 중지합니다(Stream Analytics 리소스 관리).
- 작업이 중지된 경우:
  - 작업이 중지된 이후의 시간(로그)을 가져옵니다.
  - 해당하는 경우 작업을 시작합니다(Stream Analytics 리소스 관리).

Stream Analytics 리소스 관리의 경우 REST API, .NET SDK 또는 CLI 라이브러리(Azure CLI 또는 PowerShell) 중 하나를 사용할 수 있습니다.

메트릭과 로그의 경우 Azure의 모든 항목은 비슷한 API 표면을 사용하여 Azure Monitor 아래에 중앙 집중화됩니다. 로그와 메트릭은 API를 쿼리할 때 항상 1~3분 후에 옵니다. 따라서 N을 5로 설정하면 대게 작업은 실제로 6~8분 동안 실행됩니다.

또 다른 고려 사항은 메트릭이 항상 내보내진다는 사실입니다. 작업이 중지된 경우 API는 빈 레코드를 반환합니다. 관련 값에 집중하려면 API 호출의 출력을 정리해야 합니다.

스크립트 언어

이 문서에서는 PowerShell에서 자동 일시 중지를 구현합니다. 이 옵션을 선택하는 첫 번째 이유는 PowerShell을 이제 여러 플랫폼에서 이용할 수 있기 때문입니다. 모든 운영 체제에서 PowerShell을 실행할 수 있으므로 배포가 더 쉬워집니다. 두 번째 이유는 문자열이 아닌 개체를 사용하고 반환하기 때문입니다. 개체를 사용하면 자동화 작업을 더욱 쉽게 구문 분석하고 처리할 수 있습니다.

PowerShell에서 필요한 모든 것을 위해 Az.Monitor 모듈(Az.Monitor 및 Az.StreamAnalytics 시작)을 사용하세요.

Get-AzStreamAnalyticsJob - 현재 작업 상태 가져오기
Start-AzStreamAnalyticsJob 또는 Stop-AzStreamAnalyticsJob
을(를) 사용하여 InputEventsSourcesBacklogged(Stream Analytics 메트릭에서)
(으)로 시작하는 이벤트 이름을 위해 Stop Job

호스팅 서비스

PowerShell 작업을 호스트하려면 예약된 실행을 제공하는 서비스가 필요합니다. 많은 옵션이 있지만, 서버리스 옵션으로는 다음 두 가지가 있습니다.

Azure Functions - 거의 모든 코드를 실행할 수 있는 컴퓨팅 엔진입니다. 최대 1초마다 실행될 수 있는 타이머 트리거를 제공합니다.
Azure Automation - 클라우드 워크로드 및 리소스를 운영하기 위한 관리형 서비스입니다. 용도는 적절하지만, 최소 예약 간격이 1시간(해결 방법을 사용할 경우 1시간 미만)입니다.

해결 방법을 사용해도 괜찮다면 Azure Automation이 작업을 배포하기에 더 편리한 방법입니다. 하지만 이 문서에서는 비교할 수 있도록 먼저 로컬 스크립트를 작성합니다. 제대로 작동하는 스크립트가 준비되면 Functions와 Automation 계정 모두에 배포합니다.

개발자 도구

Functions와 Stream Analytics의 경우 모두 Visual Studio Code를 통해 로컬로 개발하는 것이 좋습니다. 로컬 개발 환경을 사용하면 소스 제어를 사용할 수 있으며 배포를 쉽게 반복할 수 있습니다. 그러나 이 문서에서는 간단히 Azure Portal의 프로세스를 설명합니다.

로컬에서 PowerShell 스크립트 작성

스크립트를 개발하는 가장 좋은 방법은 로컬에서 개발하는 것입니다. PowerShell은 여러 플랫폼에서 사용할 수 있으므로 스크립트를 작성하고 모든 운영 체제에서 테스트할 수 있습니다. Windows에서는 Windows 터미널 및 PowerShell 7과 Azure PowerShell을 사용할 수 있습니다.

이 문서에서 사용하는 최종 스크립트는 Azure Functions와 Azure Automation에서 사용할 수 있습니다. 호스팅 환경(Functions 또는 Automation)에 연결된다는 측면에서 다음 스크립트와 다릅니다. 이 문서에서는 나중에 해당 측면을 설명합니다. 먼저 로컬에서만 실행되는 스크립트 버전을 단계별로 실행합니다.

이 스크립트는 모든 사용자가 이해할 수 있도록 일부러 간단한 형식으로 작성되었습니다.

맨 위에서 필요한 매개 변수를 설정하고 초기 작업 상태를 확인합니다.


# Setting variables
$restartThresholdMinute = 10 # This is M
$stopThresholdMinute = 5 # This is N

$maxInputBacklog = 0 # The amount of backlog you tolerate when stopping the job (in event count, 0 is a good starting point)
$maxWatermark = 10 # The amount of watermark you tolerate when stopping the job (in seconds, 10 is a good starting point at low Streaming Units)

$subscriptionId = "<Replace with your Subscription Id - not the name>"
$resourceGroupName = "<Replace with your Resource Group Name>"
$asaJobName = "<Replace with your Stream Analytics job name>"

$resourceId = "/subscriptions/$($subscriptionId )/resourceGroups/$($resourceGroupName )/providers/Microsoft.StreamAnalytics/streamingjobs/$($asaJobName)"

# If not already logged, uncomment and run the two following commands:
# Connect-AzAccount
# Set-AzContext -SubscriptionId $subscriptionId

# Check current Stream Analytics job status
$currentJobState = Get-AzStreamAnalyticsJob  -ResourceGroupName $resourceGroupName -Name $asaJobName | Foreach-Object {$_.JobState}
Write-Output "asaRobotPause - Job $($asaJobName) is $($currentJobState)."

작업이 실행 중인 경우 작업이 N분 이상 실행 중인지 확인합니다. 백로그와 워터마크도 확인합니다.


# Switch state
if ($currentJobState -eq "Running")
{
    # First, look up the job start time with Get-AzActivityLog
    ## Get-AzActivityLog issues warnings about deprecation coming in future releases. Here you ignore them via -WarningAction Ignore.
    ## You check in 1,000 records of history, to make sure you're not missing what you're looking for. It might need adjustment for a job that has a lot of logging happening.
    ## There's a bug in Get-AzActivityLog that triggers an error when Select-Object First is in the same pipeline (on the same line). So you move it down.
    $startTimeStamp = Get-AzActivityLog -ResourceId $resourceId -MaxRecord 1000 -WarningAction Ignore | Where-Object {$_.EventName.Value -like "Start Job*"}
    $startTimeStamp = $startTimeStamp | Select-Object -First 1 | Foreach-Object {$_.EventTimeStamp}

    # Then gather the current metric values
    ## Get-AzMetric issues warnings about deprecation coming in future releases. Here you ignore them via -WarningAction Ignore.
    $currentBacklog = Get-AzMetric -ResourceId $resourceId -TimeGrain 00:01:00 -MetricName "InputEventsSourcesBacklogged" -DetailedOutput -WarningAction Ignore
    $currentWatermark = Get-AzMetric -ResourceId $resourceId -TimeGrain 00:01:00 -MetricName "OutputWatermarkDelaySeconds" -DetailedOutput -WarningAction Ignore

    # Metrics are always lagging 1-3 minutes behind, so grabbing the last N minutes actually means checking N+3. This might be overly safe and can be fine-tuned down per job.
    $Backlog =  $currentBacklog.Data |
                    Where-Object {$_.Maximum -ge 0} | # Remove the empty records (when the job is stopped or starting)
                    Sort-Object -Property Timestamp -Descending |
                    Where-Object {$_.Timestamp -ge $startTimeStamp} | # Keep only the records of the latest run
                    Select-Object -First $stopThresholdMinute | # Take the last N records
                    Measure-Object -Sum Maximum # Sum over those N records
    $BacklogSum = $Backlog.Sum

    $Watermark = $currentWatermark.Data |
                    Where-Object {$_.Maximum -ge 0} |
                    Sort-Object -Property Timestamp -Descending |
                    Where-Object {$_.Timestamp -ge $startTimeStamp} |
                    Select-Object -First $stopThresholdMinute |
                    Measure-Object -Average Maximum # Here you average
    $WatermarkAvg = [int]$Watermark.Average # Rounding the decimal value and casting it to integer

    # Because you called Get-AzMetric with a TimeGrain of a minute, counting the number of records gives you the duration in minutes
    Write-Output "asaRobotPause - Job $($asaJobName) is running since $($startTimeStamp) with a sum of $($BacklogSum) backlogged events, and an average watermark of $($WatermarkAvg) sec, for $($Watermark.Count) minutes."

    # -le for lesser or equal, -ge for greater or equal
    if (
        ($BacklogSum -ge 0) -and ($BacklogSum -le $maxInputBacklog) -and ` # is not null and is under the threshold
        ($WatermarkAvg -ge 0) -and ($WatermarkAvg -le $maxWatermark) -and ` # is not null and is under the threshold
        ($Watermark.Count -ge $stopThresholdMinute) # at least N values
        )
    {
        Write-Output "asaRobotPause - Job $($asaJobName) is stopping..."
        Stop-AzStreamAnalyticsJob -ResourceGroupName $resourceGroupName -Name $asaJobName
    }
    else {
        Write-Output "asaRobotPause - Job $($asaJobName) is not stopping yet, it needs to have less than $($maxInputBacklog) backlogged events and under $($maxWatermark) sec watermark for at least $($stopThresholdMinute) minutes."
    }
}

작업이 중지된 경우 로그를 확인하여 마지막 Stop Job 작업이 발생한 시기를 찾습니다.


elseif ($currentJobState -eq "Stopped")
{
    # First, look up the job start time with Get-AzActivityLog
    ## Get-AzActivityLog issues warnings about deprecation coming in future releases. Here you ignore them via -WarningAction Ignore.
    ## You check in 1,000 records of history, to make sure you're not missing what you're looking for. It might need adjustment for a job that has a lot of logging happening.
    ## There's a bug in Get-AzActivityLog that triggers an error when Select-Object First is in the same pipeline (on the same line). So you move it down.
    $stopTimeStamp = Get-AzActivityLog -ResourceId $resourceId -MaxRecord 1000 -WarningAction Ignore | Where-Object {$_.EventName.Value -like "Stop Job*"}
    $stopTimeStamp = $stopTimeStamp | Select-Object -First 1 | Foreach-Object {$_.EventTimeStamp}

    # Get-Date returns a local time. You project it to the same time zone (universal) as the result of Get-AzActivityLog that you extracted earlier.
    $minutesSinceStopped = ((Get-Date).ToUniversalTime()- $stopTimeStamp).TotalMinutes

    # -ge for greater or equal
    if ($minutesSinceStopped -ge $restartThresholdMinute)
    {
        Write-Output "asaRobotPause - Job $($jobName) was paused $([int]$minutesSinceStopped) minutes ago, set interval is $($restartThresholdMinute), it is now starting..."
        Start-AzStreamAnalyticsJob -ResourceGroupName $resourceGroupName -Name $asaJobName -OutputStartMode LastOutputEventTime
    }
    else{
        Write-Output "asaRobotPause - Job $($jobName) was paused $([int]$minutesSinceStopped) minutes ago, set interval is $($restartThresholdMinute), it will not be restarted yet."
    }
}
else {
    Write-Output "asaRobotPause - Job $($jobName) is not in a state I can manage: $($currentJobState). Let's wait a bit, but consider helping is that doesn't go away!"
}

마지막으로 작업 완료를 로깅합니다.


# Final Stream Analytics job status check
$newJobState = Get-AzStreamAnalyticsJob  -ResourceGroupName $resourceGroupName -Name $asaJobName | Foreach-Object {$_.JobState}
Write-Output "asaRobotPause - Job $($asaJobName) was $($currentJobState), is now $($newJobState). Job completed."

옵션 1: Azure Functions에서 작업 호스트

참조용으로 Azure Functions 팀은 포괄적인 PowerShell 개발자 가이드를 유지 관리합니다.

먼저 새 함수 앱이 필요합니다. 함수 앱은 여러 함수를 호스트할 수 있는 솔루션과 유사합니다.

전체 프로시저를 가져올 수도 있지만, Azure Portal로 이동하여 다음을 사용하여 새 함수 앱을 만드는 것이 좋습니다.

게시: 코드
런타임: PowerShell Core
버전: 7 이상

함수 앱을 프로비전한 후 전체 구성으로 시작합니다.

Azure Functions 관리 ID

이 함수에는 Stream Analytics 작업을 시작하고 중지할 수 있는 권한이 필요합니다. 관리 ID를 사용하여 이러한 권한을 할당합니다.

첫 번째 단계는 이 절차에 따라 함수에 시스템이 할당한 관리 ID를 사용하도록 설정하는 것입니다.

이제 자동으로 일시 중지하려는 Stream Analytics 작업에서 해당 ID에 올바른 권한을 부여할 수 있습니다. 이 작업을 수행하려면 함수 작업이 아닌 Stream Analytics 작업의 포털 영역 IAM(Access Control)에서 관리 ID 형식인 구성원의 기여자 역할에 역할 할당을 추가합니다. 이전의 함수 이름을 선택합니다.

Stream Analytics 작업에 대한 액세스 제어 설정의 스크린샷.

PowerShell 스크립트에서 관리 ID가 제대로 설정되었는지 확인하는 검사를 추가할 수 있습니다. (최종 스크립트는 GitHub에서 사용할 수 있습니다.)


# Check if a managed identity has been enabled and granted access to a subscription, resource group, or resource
$AzContext = Get-AzContext -ErrorAction SilentlyContinue
if (-not $AzContext.Subscription.Id)
{
    Throw ("Managed identity is not enabled for this app or it has not been granted access to any Azure resources. Please see /azure/app-service/overview-managed-identity for additional details.")
}

다음과 같은 몇 가지 로깅 정보를 추가하여 함수가 실행되고 있는지 확인하세요.


$currentUTCtime = (Get-Date).ToUniversalTime()

# Write an information log with the current time.
Write-Host "asaRobotPause - PowerShell timer trigger function is starting at time: $currentUTCtime"

Azure Functions에 대한 매개 변수

Functions의 스크립트에 매개 변수를 전달하는 가장 좋은 방법은 함수 앱의 애플리케이션 설정을 환경 변수로 사용하는 것입니다.

첫 번째 단계는 프로시저에 따라 함수 앱의 페이지에서 앱 설정 매개 변수를 정의하는 것입니다. 다음 작업을 수행해야 합니다.

이름	값
`maxInputBacklog`	작업을 중지할 때 허용할 백로그의 양입니다. 이벤트 수에서 `0`은(는) 좋은 시작점입니다.
`maxWatermark`	작업을 중지할 때 허용할 워터마크의 양입니다. `10`초는 낮은 스트리밍 단위에서 좋은 시작점입니다.
`restartThresholdMinute`	M: 중지된 작업이 다시 시작될 때까지의 시간(분)입니다.
`stopThresholdMinute`	N: 실행 중인 작업이 중지될 때까지의 휴지 시간(분)입니다. 해당 시간 동안 입력 백로그는 `0`(으)로 유지되어야 합니다.
`subscriptionId`	자동으로 일시 중지될 Stream Analytics 작업의 구독 ID(이름 아님)입니다.
`resourceGroupName`	자동으로 일시 중지될 Stream Analytics 작업의 리소스 그룹 이름입니다.
`asaJobName`	자동으로 일시 중지될 Stream Analytics 작업의 이름입니다.

그런 다음 그에 따라 변수를 로드하도록 PowerShell 스크립트를 업데이트합니다.

$maxInputBacklog = $env:maxInputBacklog
$maxWatermark = $env:maxWatermark

$restartThresholdMinute = $env:restartThresholdMinute
$stopThresholdMinute = $env:stopThresholdMinute

$subscriptionId = $env:subscriptionId
$resourceGroupName = $env:resourceGroupName
$asaJobName = $env:asaJobName

PowerShell 모듈 요구 사항

Stream Analytics 명령(예: Start-AzStreamAnalyticsJob)을 사용하기 위해 Azure PowerShell을 로컬로 설치해야 했던 것과 마찬가지로 함수 앱 호스트에 추가해야 합니다.

함수 앱 페이지의 Functions 아래에서 앱 파일을 선택한 다음 requirements.psd1를 선택합니다.
'Az' = '6.*' 줄의 주석 처리를 제거합니다.
변경 내용이 적용되도록 앱을 다시 시작합니다.

함수 앱의 앱 파일 설정 스크린샷.

함수 만들기

모든 구성을 완료한 후 함수 앱 내에서 특정 함수를 만들어 스크립트를 실행할 수 있습니다.

포털에서 타이머에서 트리거되는 함수를 개발합니다. 함수가 0 */1 * * * *을(를) 사용하여 1분마다 트리거되고, "1분마다 두 번째 0에서" 읽는지 확인합니다.

함수 앱에서 새 타이머 트리거 함수를 만드는 스크린샷.

필요한 경우 일정을 업데이트하여 통합의 타이머 값을 변경할 수 있습니다.

함수의 통합 설정 스크린샷.

그런 다음 코드 + 테스트에서 run.ps1의 스크립트를 복사하여 테스트할 수 있습니다. 또는 GitHub의 전체 스크립트를 복사할 수 있습니다. 처리하는 동안 오류가 발생하는 경우 적절한 오류를 생성하기 위해 비즈니스 논리가 try/catch 문으로 이동되었습니다.

함수의 코드+테스트 창 스크린샷.

코드 + 테스트 창에서 테스트/실행을 선택하여 모든 항목이 제대로 실행되는지 확인할 수 있습니다. 모니터 창을 확인할 수도 있지만 항상 몇 개의 실행이 지연됩니다.

성공적인 실행의 출력 스크린샷.

함수 실행에 대한 경고 설정

마지막으로 함수가 성공적으로 실행되지 않는 경우 경고를 통해 알림을 받습니다. 경고에는 약간의 비용이 들지만 비용이 많이 드는 상황을 방지할 수 있습니다.

함수 앱 페이지의 로그 아래에서 다음 쿼리를 실행합니다. 지난 5분 동안 실패한 모든 실행을 반환합니다.

requests
| where success == false
| where timestamp > ago(5min)
| summarize failedCount=sum(itemCount) by operation_Name
| order by failedCount desc

쿼리 편집기에서 새 경고 규칙을 선택합니다. 열리는 창에서 측정값을 다음과 같이 정의합니다.

측정값: failedCount
집계 형식: 총계
집계 세분성: 5분

그다음 경고 논리를 다음과 같이 설정합니다.

연산자: 보다 큼
임계값: 0
평가 빈도: 5분

여기에서 작업 그룹을 다시 사용하거나 새로 만듭니다. 그런 다음 구성을 완료합니다.

경고를 올바르게 설정했는지 확인하려면 PowerShell 스크립트의 아무 곳에나 throw "Testing the alert"을(를) 추가한 다음 5분 동안 기다려서 전자 메일을 받을 수 있습니다.

옵션 2: Azure Automation에서 작업 호스트

먼저 새 Automation 계정이 필요합니다. Automation 계정은 여러 Runbook을 호스트할 수 있는 솔루션과 유사합니다.

절차는 Azure Portal의 빠른 시작을 사용하여 Automation 계정 만들기를 참조하세요. 고급 탭에서 시스템이 할당한 관리 ID를 직접 사용하도록 선택할 수 있습니다.

참고로 Automation 팀에는 PowerShell Runbook을 시작하기 위한 자습서가 있습니다.

Azure Automation에 대한 매개 변수

Runbook을 사용하면 PowerShell의 클래식 매개 변수 구문을 통해 인수를 전달할 수 있습니다.

Param(
    [string]$subscriptionId,
    [string]$resourceGroupName,
    [string]$asaJobName,

    [int]$restartThresholdMinute,
    [int]$stopThresholdMinute,

    [int]$maxInputBacklog,
    [int]$maxWatermark
)

Azure Automation 관리 ID

Automation 계정은 프로비전 중에 관리 ID를 받습니다. 그러나 필요한 경우 이 절차를 사용하여 관리 ID를 사용하도록 설정할 수 있습니다.

함수에 대해 했던 것처럼 자동으로 일시 중지하려는 Stream Analytics 작업에서 올바른 권한을 부여해야 합니다.

권한을 부여하려면 Automation 페이지가 아닌 Stream Analytics 작업의 포털 영역 IAM( Access Control)에서 관리 ID 형식인 구성원의 기여자 역할에 역할 할당을 추가합니다. 이전의 Automation 계정 이름을 선택합니다.

Stream Analytics 작업에 대한 액세스 제어 설정의 스크린샷.

PowerShell 스크립트에서 관리 ID가 제대로 설정되었는지 확인하는 검사를 추가할 수 있습니다. (최종 스크립트는 GitHub에서 사용할 수 있습니다.)

# Ensure that you don't inherit an AzContext in your runbook
Disable-AzContextAutosave -Scope Process | Out-Null

# Connect by using a managed service identity
try {
        $AzureContext = (Connect-AzAccount -Identity).context
    }
catch{
        Write-Output "There is no system-assigned user identity. Aborting.";
        exit
    }

Runbook 만들기

구성을 완료한 후 Automation 계정 내에 특정 Runbook을 만들어 스크립트를 실행할 수 있습니다. 여기서는 Azure PowerShell을 요구 사항으로 추가할 필요가 없습니다. 이미 기본 제공됩니다.

포털의 프로세스 자동화 아래에서 Runbook을 선택합니다. 그런 다음 Runbook 만들기를 선택하고, Runbook 유형으로 PowerShell을 선택한 다음 7 이상 버전을 버전으로 선택합니다(현재 7.1(미리 보기)).

이제 스크립트를 붙여넣고 테스트할 수 있습니다. 전체 스크립트는 GitHub에서 복사할 수 있습니다. 처리하는 동안 오류가 발생하는 경우 적절한 오류를 생성하기 위해 비즈니스 논리가 try/catch 문으로 이동되었습니다.

Azure Automation의 Runbook 스크립트 편집기 스크린샷.

테스트 창에서 모든 것이 제대로 설정되었는지 확인할 수 있습니다.

그런 다음 Runbook을 일정에 연결할 수 있도록 게시를 선택하여 작업을 게시해야 합니다. 일정을 만들고 연결하는 프로세스는 간단합니다. 이때, 1시간 미만의 일정 간격을 달성하기 위한 해결 방법이 있다는 것에 유의해야 합니다.

마지막으로 경고를 설정할 수 있습니다. 첫 번째 단계는 Automation 계정의 진단 설정을 사용하여 로그를 사용하도록 설정하는 것입니다. 두 번째 단계는 Functions와 마찬가지로 쿼리를 사용하여 오류를 캡처하는 것입니다.

결과

Stream Analytics 작업에서 모든 항목이 두 위치에서 예상대로 실행되고 있는지 확인할 수 있습니다.

활동 로그는 다음과 같습니다.

Stream Analytics 작업의 로그 스크린샷.

메트릭은 다음과 같습니다.

Stream Analytics 작업의 메트릭 스크린샷.

스크립트를 이해한 후 범위를 확장하기 위해 스크립트를 다시 작업하는 작업은 간단합니다. 단일 작업 대신 작업 목록을 대상으로 지정하도록 스크립트를 쉽게 업데이트할 수 있습니다. 태그, 리소스 그룹 또는 전체 구독을 사용하여 더 큰 범위를 정의하고 처리할 수 있습니다.

지원 받기

추가 지원이 필요한 경우 Azure Stream Analytics에 대한 Microsoft Q&A 페이지를 참조하세요.

다음 단계

PowerShell을 사용하여 Azure Stream Analytics 작업의 관리를 자동화하는 기본을 알아보았습니다. 자세히 알아보려면 다음 아티클을 참조하세요.

피드백

이 페이지가 도움이 되었나요?

Last updated on 2024-07-17