다음을 통해 공유

백그라운드 작업

많은 유형의 애플리케이션에는 UI(사용자 인터페이스)와 독립적으로 실행되는 백그라운드 작업이 필요합니다. 예를 들어 일괄 처리 작업, 집약적인 처리 작업 및 워크플로와 같은 장기 실행 프로세스가 있습니다. 백그라운드 작업은 사용자 상호 작용 없이 실행할 수 있습니다. 애플리케이션은 작업을 시작한 다음 사용자의 대화형 요청을 계속 처리할 수 있습니다. 이렇게 하면 애플리케이션 UI의 부하를 최소화하여 가용성을 개선하고 대화형 응답 시간을 줄일 수 있습니다.

예를 들어 애플리케이션이 사용자가 업로드한 이미지의 썸네일을 생성해야 하는 경우 백그라운드 작업으로 이 작업을 수행하고 완료될 때 사용자가 프로세스가 완료될 때까지 기다릴 필요 없이 썸네일을 스토리지에 저장할 수 있습니다. 동일한 방식으로 주문을 하는 사용자는 주문을 처리하는 백그라운드 워크플로를 시작할 수 있으며, UI를 사용하면 사용자가 웹앱을 계속 탐색할 수 있습니다. 백그라운드 작업이 완료되면 저장된 주문 데이터를 업데이트하고 주문을 확인하는 전자 메일을 사용자에게 보낼 수 있습니다.

작업을 백그라운드 작업으로 구현할지 여부를 고려할 때 주요 조건은 작업이 완료될 때까지 기다릴 필요 없이 사용자 상호 작용 없이 UI 없이 작업을 실행할 수 있는지 여부입니다. 사용자 또는 UI가 완료되는 동안 기다려야 하는 작업은 백그라운드 작업으로 적절하지 않을 수 있습니다.

백그라운드 작업의 유형

백그라운드 작업에는 일반적으로 다음 작업 유형 중 하나 이상이 포함됩니다.

  • CPU 집약적 작업(예: 수학 계산 또는 구조 모델 분석)
  • 일련의 스토리지 트랜잭션 실행 또는 파일 인덱싱과 같은 I/O 집약적 작업
  • 야간 데이터 업데이트 또는 예약된 처리와 같은 일괄 작업입니다.
  • 주문 처리 또는 프로비전 서비스 및 시스템과 같은 장기 실행 워크플로입니다.
  • 태스크가 처리를 위해 보다 안전한 위치로 전달되는 중요한 데이터 처리입니다. 예를 들어 웹 앱 내에서 중요한 데이터를 처리하고 싶지 않을 수 있습니다. 대신 Gatekeeper 패턴과 같은 패턴을 사용하여 보호된 저장소에 액세스할 수 있는 격리된 백그라운드 프로세스로 데이터를 전송할 수 있습니다.

유발 요소

백그라운드 작업은 여러 가지 방법으로 시작할 수 있습니다. 다음 범주 중 하나에 속합니다.

  • 이벤트 기반 트리거입니다. 이 작업은 일반적으로 사용자가 수행한 작업 또는 워크플로의 한 단계에 대한 응답으로 시작됩니다.
  • 일정 기반 트리거입니다. 작업은 타이머 기반 일정에 따라 호출됩니다. 이는 되풀이 일정 또는 나중에 지정된 일회성 호출일 수 있습니다.

이벤트 기반 트리거

이벤트 기반 호출은 트리거를 사용하여 백그라운드 작업을 시작합니다. 이벤트 기반 트리거를 사용하는 예는 다음과 같습니다.

  • UI 또는 다른 프로세스는 큐에 메시지를 배치합니다. 메시지에는 주문하는 사용자와 같이 수행된 작업에 대한 데이터가 포함됩니다. 백그라운드 작업은 이 큐에서 수신 대기하고 새 메시지의 도착을 감지합니다. 메시지를 읽고 그 안에 있는 데이터를 백그라운드 작업에 대한 입력으로 사용합니다. 이 패턴을 비동기 메시지 기반 통신이라고합니다.
  • UI 또는 다른 작업은 스토리지의 값을 저장하거나 업데이트합니다. 백그라운드 작업은 스토리지를 모니터링하고 변경 내용을 검색합니다. 데이터를 읽고 백그라운드 작업에 대한 입력으로 사용합니다.
  • UI 또는 다른 작업은 HTTPS URI 또는 웹 서비스로 노출되는 API와 같은 엔드포인트에 요청을 수행합니다. 요청의 일부로 백그라운드 작업을 완료하는 데 필요한 데이터를 전달합니다. 끝점 또는 웹 서비스는 데이터를 입력으로 사용하는 백그라운드 작업을 호출합니다.

이벤트 기반 호출에 적합한 작업의 일반적인 예로는 이미지 처리, 워크플로, 원격 서비스에 정보 보내기, 전자 메일 메시지 보내기, 다중 테넌트 애플리케이션에서 새 사용자 프로비전 등이 있습니다.

일정 기반 트리거

일정 기반 호출은 타이머를 사용하여 백그라운드 작업을 시작합니다. 일정 기반 트리거를 사용하는 예는 다음과 같습니다.

  • 애플리케이션 내에서 또는 애플리케이션 운영 체제의 일부로 로컬로 실행되는 타이머는 정기적으로 백그라운드 작업을 호출합니다.
  • Azure Logic Apps와 같은 다른 애플리케이션에서 실행되는 타이머는 정기적으로 API 또는 웹 서비스에 요청을 보냅니다. API 또는 웹 서비스는 백그라운드 작업을 호출합니다.
  • 별도의 프로세스 또는 애플리케이션은 지정된 시간 지연 후 또는 특정 시간에 백그라운드 작업이 한 번 호출되도록 하는 타이머를 시작합니다.

일정 기반 호출에 적합한 작업의 일반적인 예로는 일괄 처리 루틴(예: 최근 동작에 따라 사용자에 대한 관련 제품 목록 업데이트), 일상적인 데이터 처리 작업(예: 인덱스 업데이트 또는 누적 결과 생성), 일일 보고서에 대한 데이터 분석, 데이터 보존 정리 및 데이터 일관성 검사가 있습니다.

단일 인스턴스로 실행해야 하는 일정 기반 작업을 사용하는 경우 다음 사항에 유의하세요.

  • 스케줄러를 실행하는 컴퓨팅 인스턴스(예: Windows 예약 작업을 사용하는 가상 머신)의 크기를 조정하면 스케줄러의 여러 인스턴스가 실행됩니다. 이러한 작업은 작업의 여러 인스턴스를 시작할 수 있습니다. 이에 대한 자세한 내용은 이 블로그 게시물에서 멱등성에 대해 알아보세요.
  • 작업이 스케줄러 이벤트 사이의 기간보다 오래 실행되는 경우 이전 인스턴스가 계속 실행되는 동안 스케줄러가 작업의 다른 인스턴스를 시작할 수 있습니다.

결과 반환

백그라운드 작업은 UI 또는 백그라운드 작업을 호출한 프로세스에서 별도의 프로세스 또는 별도의 위치에서 비동기적으로 실행됩니다. 이상적으로 백그라운드 작업은 "실행 및 잊기" 작업이며 실행 진행률이 UI 또는 호출 프로세스에 영향을 주지 않습니다. 즉, 호출 프로세스는 태스크가 완료될 때까지 기다리지 않습니다. 따라서 작업이 종료되는 시기를 자동으로 감지할 수 없습니다.

백그라운드 작업이 진행률 또는 완료를 나타내기 위해 호출 태스크와 통신해야 하는 경우 이를 위한 메커니즘을 구현해야 합니다. 몇 가지 예는 다음과 같습니다.

  • 필요한 경우 이 값을 모니터링하거나 확인할 수 있는 UI 또는 호출자 태스크에 액세스할 수 있는 스토리지에 상태 표시기 값을 작성합니다. 백그라운드 작업이 호출자에게 반환해야 하는 다른 데이터는 동일한 스토리지에 배치할 수 있습니다.
  • UI 또는 호출자가 수신 대기하는 회신 큐를 설정합니다. 백그라운드 작업은 상태 및 완료를 나타내는 메시지를 큐에 보낼 수 있습니다. 백그라운드 작업이 호출자에게 반환해야 하는 데이터는 메시지에 배치할 수 있습니다. Azure Service Bus를 사용하는 경우 ReplyTo 및 CorrelationId 속성을 사용하여 이 기능을 구현할 수 있습니다.
  • UI 또는 호출자가 상태 정보를 얻기 위해 액세스할 수 있는 백그라운드 작업에서 API 또는 끝점을 노출합니다. 백그라운드 작업이 호출자에게 반환해야 하는 데이터는 응답에 포함될 수 있습니다.
  • 백그라운드 태스크가 API를 통해 UI 또는 호출자에게 다시 호출하여 미리 정의된 지점 또는 완료 시 상태를 표시하도록 합니다. 로컬로 또는 게시 및 구독 메커니즘을 통해 발생하는 이벤트를 통해 발생할 수 있습니다. 백그라운드 작업이 호출자에게 반환해야 하는 데이터는 요청 또는 이벤트 페이로드에 포함될 수 있습니다.

호스팅 환경

다양한 Azure 플랫폼 서비스를 사용하여 백그라운드 작업을 호스트할 수 있습니다.

  • Azure Web Apps 및 WebJobs. WebJobs를 사용하여 웹앱의 컨텍스트 내에서 다양한 유형의 스크립트 또는 실행 프로그램 범위에 따라 사용자 지정 작업을 실행할 수 있습니다.
  • Azure Functions. 오랫동안 실행되지 않는 백그라운드 작업에 함수를 사용할 수 있습니다. 또 다른 사용 사례는 워크로드가 App Service 계획에서 이미 호스트되고 사용이 미달인 경우입니다.
  • Azure 가상 컴퓨터. Windows 서비스가 있거나 Windows 작업 스케줄러를 사용하려는 경우 전용 가상 머신 내에서 백그라운드 작업을 호스트하는 것이 일반적입니다.
  • Azure 배치. Batch는 관리되는 가상 머신 컬렉션에서 실행되도록 계산 집약적인 작업을 예약하는 플랫폼 서비스입니다. 컴퓨팅 리소스의 크기를 자동으로 조정할 수 있습니다.
  • AKS(Azure Kubernetes Service). Azure Kubernetes Service는 Azure에서 Kubernetes에 대한 관리되는 호스팅 환경을 제공합니다.
  • Azure 컨테이너 앱. Azure Container Apps를 사용하면 컨테이너를 기반으로 서버리스 마이크로 서비스를 빌드할 수 있습니다.

다음 섹션에서는 이러한 옵션을 자세히 설명하고 적절한 옵션을 선택하는 데 도움이 되는 고려 사항을 포함합니다.

Azure 웹 애플리케이션 및 웹 작업

Azure WebJobs를 사용하여 Azure Web App 내에서 사용자 지정 작업을 백그라운드 작업으로 실행할 수 있습니다. WebJobs는 연속 프로세스로 웹앱의 컨텍스트 내에서 실행됩니다. 또한 WebJobs는 Azure Logic Apps의 트리거 이벤트 또는 스토리지 Blob 및 메시지 큐 변경과 같은 외부 요인에 대한 응답으로 실행됩니다. 요청 시 작업을 시작하고 중지하고 정상적으로 종료할 수 있습니다. 지속적으로 실행되는 WebJob이 실패하면 자동으로 다시 시작됩니다. 다시 시도 및 오류 작업을 구성할 수 있습니다.

WebJob을 구성하는 경우:

  • 작업이 이벤트 기반 트리거에 응답하도록 하려면 지속적으로 실행으로 구성해야 합니다. 스크립트 또는 프로그램은 site/wwwroot/app_data/jobs/continuous 폴더에 저장됩니다.
  • 작업이 일정 기반 트리거에 응답하도록 하려면 일정에 따라 실행으로 구성해야 합니다. 스크립트 또는 프로그램은 site/wwwroot/app_data/jobs/triggered라는 폴더에 저장됩니다.
  • 작업을 구성할 때 요청 시 실행 옵션을 선택하면 작업을 시작할 때 일정에 따라 실행 옵션과 동일한 코드가 실행됩니다.

Azure WebJobs는 웹앱의 샌드박스 내에서 실행됩니다. 즉, 환경 변수에 액세스하고 연결 문자열과 같은 정보를 웹앱과 공유할 수 있습니다. 작업은 작업이 실행되는 컴퓨터의 고유 식별자에 접근할 수 있습니다. AzureWebJobsStorage라는 연결 문자열은 애플리케이션 데이터에 대한 Azure Storage 큐, Blob 및 테이블에 대한 액세스 및 메시징 및 통신을 위해 Service Bus에 대한 액세스를 제공합니다. AzureWebJobsDashboard라는 연결 문자열은 작업 작업 로그 파일에 대한 액세스를 제공합니다.

Azure WebJobs에는 다음과 같은 특징이 있습니다.

  • 보안: WebJobs는 웹앱의 배포 자격 증명으로 보호됩니다.
  • 지원되는 파일 형식: 명령 스크립트(), 일괄 처리 파일(.cmd), PowerShell 스크립트(.bat), Bash 셸 스크립트(.ps1), PHP 스크립트(.sh), Python 스크립트(.php), JavaScript 코드(.py.js) 및 실행 프로그램(.exe등.jar)을 사용하여 WebJobs를 정의할 수 있습니다.
  • 배포: Azure Portal을 사용하거나, Visual Studio를 사용하거나, Azure WebJobs SDK를 사용하거나, 다음 위치에 직접 복사하여 스크립트 및 실행 파일을 배포할 수 있습니다.
    • 트리거된 실행의 경우: site/wwwroot/app_data/jobs/triggered/{job name}
    • 연속 실행의 경우: site/wwwroot/app_data/jobs/continuous/{job name}
  • 로깅: Console.Out은 INFO로 처리(표시)됩니다. Console.Error는 ERROR로 처리됩니다. Azure Portal을 사용하여 모니터링 및 진단 정보에 액세스할 수 있습니다. 사이트에서 직접 로그 파일을 다운로드할 수 있습니다. 다음 위치에 저장됩니다.
    • 트리거된 실행의 경우: Vfs/data/jobs/triggered/jobName
    • 연속 실행의 경우: Vfs/data/jobs/continuous/jobName
  • 구성: 포털, REST API 및 PowerShell을 사용하여 WebJobs를 구성할 수 있습니다. 작업 스크립트와 동일한 루트 디렉터리에서 settings.job이라는 구성 파일을 사용하여 작업에 대한 구성 정보를 제공할 수 있습니다. 예를 들어:
    • { "정지_대기_시간": 60 }
    • { "is_singleton": 참 }

고려 사항

  • 기본적으로 WebJobs는 웹앱을 사용하여 크기를 조정합니다. 그러나 is_singleton 구성 속성을 true로 설정하여 단일 인스턴스에서 실행되도록 작업을 구성할 수 있습니다. 단일 인스턴스 WebJobs는 다시 인덱싱, 데이터 분석 및 유사한 작업과 같이 동시에 여러 인스턴스로 크기를 조정하거나 실행하지 않으려는 작업에 유용합니다.
  • 작업이 웹앱의 성능에 미치는 영향을 최소화하려면 장기 실행 또는 리소스 집약적 WebJobs를 호스트하는 새 App Service 계획에서 빈 Azure Web App 인스턴스를 만드는 것이 좋습니다.

Azure Functions (애저 펑션)

WebJobs와 유사한 옵션은 Azure Functions입니다. 이 서비스는 짧은 기간 동안 실행되는 이벤트 기반 트리거에 가장 적합한 서버리스입니다. 설정된 시간에 실행되도록 구성된 경우 함수를 사용하여 타이머 트리거를 통해 예약된 작업을 실행할 수도 있습니다.

Azure Functions는 예기치 않은 시간 제한 문제를 일으킬 수 있으므로 장기 실행 작업이 큰 작업에 권장되지 않습니다. 그러나 호스팅 계획에 따라 일정 기반 트리거로 간주할 수 있습니다.

고려 사항

백그라운드 작업이 이벤트에 대한 응답으로 짧은 기간 동안 실행될 것으로 예상되는 경우 소비 계획에서 작업을 실행하는 것이 좋습니다. 실행 시간은 최대 시간까지 구성할 수 있습니다. 더 오래 실행되는 함수는 비용이 더 많이 듭니다. 또한 더 많은 메모리를 사용하는 CPU 집약적 작업은 비용이 더 많이 들 수 있습니다. 서비스의 추가 트리거를 작업의 일부로 사용하는 경우 별도로 요금이 청구됩니다.

프리미엄 플랜은 짧지만 지속적으로 실행될 것으로 예상되는 작업이 많은 경우에 더 적합합니다. 이 계획은 더 많은 메모리와 CPU가 필요하기 때문에 비용이 더 많이 듭니다. 이점은 가상 네트워크 통합과 같은 기능을 사용할 수 있다는 것입니다.

전용 계획은 워크로드가 이미 실행 중인 경우 백그라운드 작업에 가장 적합합니다. VM을 활용하지 않은 경우 동일한 VM에서 실행하고 컴퓨팅 비용을 공유할 수 있습니다.

자세한 내용은 다음 문서를 참조하세요.

Azure Virtual Machines

백그라운드 작업이 Azure Web Apps에 배포되지 않도록 하는 방식으로 구현되거나 이러한 옵션이 편리하지 않을 수 있습니다. 일반적인 예로는 Windows 서비스, 타사 유틸리티 및 실행 프로그램이 있습니다. 또 다른 예로 애플리케이션 호스팅과 다른 실행 환경을 위해 작성된 프로그램이 있을 수 있습니다. 예를 들어 Windows 또는 .NET 애플리케이션에서 실행하려는 Unix 또는 Linux 프로그램일 수 있습니다. Azure 가상 머신에 대한 다양한 운영 체제 중에서 선택하고 해당 가상 머신에서 서비스 또는 실행 파일을 실행할 수 있습니다.

자세한 내용은 다음 리소스를 참조하세요.

별도의 가상 머신에서 백그라운드 작업을 시작하려면 다양한 옵션을 사용할 수 있습니다.

  • 태스크가 노출하는 엔드포인트에 요청을 전송하여 애플리케이션에서 직접 요청 시 작업을 실행할 수 있습니다. 태스크에 필요한 모든 데이터를 전달합니다. 이 엔드포인트는 작업을 호출합니다.
  • 선택한 운영 체제에서 사용할 수 있는 스케줄러 또는 타이머를 사용하여 일정에 따라 실행되도록 작업을 구성할 수 있습니다. 예를 들어 Windows에서 Windows 작업 스케줄러를 사용하여 스크립트 및 작업을 실행할 수 있습니다. 또는 가상 머신에 SQL Server가 설치된 경우 SQL Server 에이전트를 사용하여 스크립트 및 작업을 실행할 수 있습니다.
  • Azure Logic Apps를 사용하여 태스크가 수신 대기하는 큐에 메시지를 추가하거나 태스크가 노출하는 API에 요청을 전송하여 작업을 시작할 수 있습니다.

백그라운드 작업을 시작하는 방법에 대한 자세한 내용은 이전 섹션 트리거 를 참조하세요.

고려 사항

Azure 가상 머신에서 백그라운드 작업을 배포할지 여부를 결정할 때 다음 사항을 고려합니다.

  • 별도의 Azure 가상 머신에서 백그라운드 작업을 호스팅하면 유연성을 제공하고 시작, 실행, 예약 및 리소스 할당을 정확하게 제어할 수 있습니다. 그러나 백그라운드 작업을 실행하기 위해 가상 머신을 배포해야 하는 경우 런타임 비용이 증가합니다.
  • Azure Portal에서 작업을 모니터링할 수 있는 기능이 없고 실패한 작업에 대한 자동 다시 시작 기능이 없습니다. 하지만 가상 머신의 기본 상태를 모니터링하고 Azure Resource Manager Cmdlet을 사용하여 관리할 수 있습니다. 그러나 컴퓨팅 노드에서 프로세스 및 스레드를 제어할 수 있는 기능은 없습니다. 일반적으로 가상 머신을 사용하려면 태스크의 계측 및 가상 머신의 운영 체제에서 데이터를 수집하는 메커니즘을 구현하기 위해 추가적인 노력이 필요합니다. 적절한 솔루션 중 하나는 Azure용 System Center 관리 팩을 사용하는 것입니다.
  • HTTP 엔드포인트를 통해 노출되는 모니터링 프로브를 만드는 것이 좋습니다. 이러한 프로브에 대한 코드는 상태 검사를 수행하거나, 운영 정보 및 통계를 수집하거나, 오류 정보를 수집하여 관리 애플리케이션에 반환할 수 있습니다. 자세한 내용은 상태 엔드포인트 모니터링 패턴을 참조하세요.

자세한 내용은 다음을 참조하세요.

Azure Batch (마이크로소프트의 클라우드 기반 일괄 처리 서비스)

수십, 수백 또는 수천 개의 VM에서 대규모 병렬 HPC(고성능 컴퓨팅) 워크로드를 실행해야 하는 경우 Azure Batch 를 고려합니다.

Batch 서비스는 VM을 프로비전하고, VM에 작업을 할당하고, 작업을 실행하고, 진행 상황을 모니터링합니다. Batch는 워크로드에 대한 응답으로 VM을 자동으로 확장할 수 있습니다. Batch는 작업 예약도 제공합니다. Azure Batch는 Linux 및 Windows VM을 모두 지원합니다.

고려 사항

Batch는 본질적으로 병렬 워크로드에서 잘 작동합니다. 또한 마지막에 축소 단계를 사용하여 병렬 계산을 수행하거나 노드 간에 메시지를 전달해야 하는 병렬 작업에 대해 MPI(메시지 전달 인터페이스) 애플리케이션 을 실행할 수 있습니다.

Azure Batch 작업은 노드 풀(VM)에서 실행됩니다. 한 가지 방법은 필요한 경우에만 풀을 할당한 다음 작업이 완료된 후에 삭제하는 것입니다. 이렇게 하면 노드가 유휴 상태가 아니지만 작업이 노드가 할당될 때까지 기다려야 하므로 사용률이 최대화됩니다. 또는 미리 풀을 만들 수 있습니다. 이 방법은 작업을 시작하는 데 걸리는 시간을 최소화하지만 유휴 상태인 노드가 발생할 수 있습니다. 자세한 내용은 풀 및 컴퓨팅 노드 수명을 참조하세요.

자세한 내용은 다음을 참조하세요.

Azure Kubernetes Service

AKS(Azure Kubernetes Service)는 호스트된 Kubernetes 환경을 관리하므로 컨테이너화된 애플리케이션을 쉽게 배포하고 관리할 수 있습니다.

컨테이너는 백그라운드 작업을 실행하는 데 유용할 수 있습니다. 몇 가지 이점은 다음과 같습니다.

  • 컨테이너는 고밀도 호스팅을 지원합니다. 각 VM에 여러 컨테이너를 배치하는 동안 컨테이너에서 백그라운드 작업을 격리할 수 있습니다.
  • 컨테이너 오케스트레이터는 내부 부하 분산을 처리하고 내부 네트워크 및 기타 구성 작업을 구성합니다.
  • 필요에 따라 컨테이너를 시작하고 중지할 수 있습니다.
  • Azure Container Registry를 사용하면 Azure 경계 내에 컨테이너를 등록할 수 있습니다. 여기에는 보안, 개인 정보 보호 및 근접 이점이 함께 제공됩니다.

고려 사항

  • 컨테이너 오케스트레이터를 사용하는 방법을 이해해야 합니다.

자세한 내용은 다음을 참조하세요.

Azure Container Apps (Azure 컨테이너 애플리케이션)

Azure Container Apps를 사용하면 컨테이너를 기반으로 서버리스 마이크로 서비스를 빌드할 수 있습니다. Container Apps의 고유한 기능은 다음과 같습니다.

고려 사항

Azure Container Apps는 기본 Kubernetes API에 대한 직접 액세스를 제공하지 않습니다. Kubernetes API 및 컨트롤 플레인에 액세스해야 하는 경우 Azure Kubernetes Service를 사용해야 합니다. 그러나 Kubernetes 스타일 애플리케이션을 빌드하고 모든 원시 Kubernetes API 및 클러스터 관리에 직접 액세스할 필요가 없는 경우 Container Apps는 모범 사례를 기반으로 완전 관리형 환경을 제공합니다. 이러한 이유로 많은 팀은 Azure Container Apps를 사용하여 컨테이너 마이크로 서비스 빌드를 시작하는 것을 선호합니다.

자세한 내용은 다음을 참조하세요.

빠른 시작을 사용하여 첫 번째 컨테이너 앱 빌드를 시작할 수 있습니다.

분할

기존 컴퓨팅 인스턴스 내에 백그라운드 작업을 포함하려는 경우 컴퓨팅 인스턴스의 품질 특성과 백그라운드 작업 자체에 미치는 영향을 고려해야 합니다. 이러한 요소는 기존 컴퓨팅 인스턴스를 사용하여 작업을 공동 배치할지 또는 별도의 컴퓨팅 인스턴스로 분리할지를 결정하는 데 도움이 됩니다.

  • 가용성: 백그라운드 작업은 애플리케이션의 다른 부분, 특히 사용자 상호 작용에 직접 관련된 UI 및 기타 부분과 동일한 수준의 가용성을 가질 필요가 없습니다. 백그라운드 작업은 대기 시간, 다시 시도하는 연결 실패 및 다른 가용성에 영향을 미치는 요인에 대해 더 관대할 수 있습니다. 이는 작업들이 대기열에 추가될 수 있어서 가능해집니다. 그러나 큐를 차단하고 애플리케이션 전체에 영향을 줄 수 있는 요청의 백업을 방지하기에 충분한 용량이 있어야 합니다.

  • 확장성: 백그라운드 작업에는 UI 및 애플리케이션의 대화형 부분과 다른 확장성 요구 사항이 있을 수 있습니다. 수요 최대를 충족하기 위해 UI 크기를 조정해야 할 수 있지만, 컴퓨팅 인스턴스 수가 적어 사용량이 적은 시간에 미해결 백그라운드 작업이 완료될 수 있습니다.

  • 복원력: 백그라운드 작업만 호스트하는 컴퓨팅 인스턴스의 오류는 태스크를 다시 사용할 수 있을 때까지 이러한 작업에 대한 요청을 큐에 대기하거나 연기할 수 있는 경우 애플리케이션 전체에 심각한 영향을 미치지 않을 수 있습니다. 컴퓨팅 인스턴스 또는 태스크를 적절한 간격 내에 다시 시작할 수 있는 경우 애플리케이션 사용자는 영향을 받지 않을 수 있습니다.

  • 보안: 백그라운드 작업에는 UI 또는 애플리케이션의 다른 부분과 다른 보안 요구 사항 또는 제한이 있을 수 있습니다. 별도의 컴퓨팅 인스턴스를 사용하여 작업에 대해 다른 보안 환경을 지정할 수 있습니다. 보안 및 분리를 최대화하기 위해 Gatekeeper와 같은 패턴을 사용하여 백그라운드 컴퓨팅 인스턴스를 UI에서 격리할 수도 있습니다.

  • 성능: 백그라운드 작업의 컴퓨팅 인스턴스 유형을 선택하여 태스크의 성능 요구 사항과 구체적으로 일치시킬 수 있습니다. 이는 태스크에 UI와 동일한 처리 기능이 필요하지 않은 경우 더 저렴한 컴퓨팅 옵션을 사용하거나 추가 용량과 리소스가 필요한 경우 더 큰 인스턴스를 사용하는 것을 의미할 수 있습니다.

  • 관리 효율성: 백그라운드 작업에는 주 애플리케이션 코드 또는 UI와 다른 개발 및 배포 리듬이 있을 수 있습니다. 별도의 컴퓨팅 인스턴스에 배포하면 업데이트 및 버전 관리를 간소화할 수 있습니다.

  • 비용: 백그라운드 작업을 실행하기 위해 컴퓨팅 인스턴스를 추가하면 호스팅 비용이 증가합니다. 추가 용량과 이러한 추가 비용 간의 균형을 신중하게 고려해야 합니다.

자세한 내용은 리더 선거 패턴 및 경쟁 소비자 패턴을 참조하세요.

갈등

백그라운드 작업의 여러 인스턴스가 있는 경우 데이터베이스 및 스토리지와 같은 리소스 및 서비스에 액세스하기 위해 경쟁할 수 있습니다. 이러한 동시 액세스로 인해 리소스 경합이 발생할 수 있으며, 이로 인해 서비스 가용성과 스토리지의 데이터 무결성에 충돌이 발생할 수 있습니다. 비관적 잠금 방법을 사용하여 리소스 경합을 해결할 수 있습니다. 이렇게 하면 작업의 경쟁 인스턴스가 동시에 서비스에 액세스하거나 데이터가 손상되지 않습니다.

충돌을 해결하는 또 다른 방법은 백그라운드 작업을 싱글톤으로 정의하여 인스턴스가 하나만 실행되도록 하는 것입니다. 그러나 이렇게 하면 다중 인스턴스 구성에서 제공할 수 있는 안정성 및 성능 이점이 제거됩니다. UI가 하나 이상의 백그라운드 작업에 충분한 작업을 제공할 수 있다면, 특히 그렇습니다.

백그라운드 작업이 자동으로 다시 시작될 수 있고 최대 수요에 대처할 수 있는 충분한 용량이 있는지 확인하는 것이 중요합니다. 충분한 리소스를 사용하여 컴퓨팅 인스턴스를 할당하거나, 수요가 감소할 때 나중에 실행 요청을 저장할 수 있는 큐 메커니즘을 구현하거나, 이러한 기술의 조합을 사용하여 이를 달성할 수 있습니다.

조정

백그라운드 작업은 복잡할 수 있으며 결과를 생성하거나 모든 요구 사항을 충족하기 위해 여러 개별 작업을 실행해야 할 수 있습니다. 이러한 시나리오에서는 작업을 여러 소비자가 실행할 수 있는 더 작은 개별 단계 또는 하위 작업으로 나누는 것이 일반적입니다. 다중 스텝 작업은 여러 작업에서 개별 단계를 다시 사용할 수 있으므로 더 효율적이고 유연할 수 있습니다. 단계의 순서를 쉽게 추가, 제거 또는 수정할 수 있습니다.

여러 작업 및 단계를 조정하는 것은 어려울 수 있지만 솔루션 구현을 안내하는 데 사용할 수 있는 세 가지 일반적인 패턴이 있습니다.

  • 작업을 재사용 가능한 여러 단계로 분해합니다. 애플리케이션은 처리하는 정보에 대해 다양한 복잡성의 다양한 작업을 수행해야 할 수 있습니다. 이 애플리케이션을 구현하는 간단하지만 유연하지 않은 방법은 모놀리식 모듈로 이 처리를 수행하는 것일 수 있습니다. 그러나 이 방법은 동일한 처리의 일부가 애플리케이션 내의 다른 곳에서 필요한 경우 코드를 리팩터링하거나 최적화하거나 재사용할 기회를 줄일 수 있습니다. 자세한 내용은 파이프 및 필터 패턴을 참조하세요.

  • 작업에 대한 단계 실행을 관리합니다. 애플리케이션은 여러 단계를 구성하는 작업을 수행할 수 있습니다(일부는 원격 서비스를 호출하거나 원격 리소스에 액세스할 수 있습니다). 개별 단계는 서로 독립적일 수 있지만 작업을 구현하는 애플리케이션 논리에 의해 오케스트레이션됩니다. 자세한 내용은 Scheduler 에이전트 감독자 패턴을 참조하세요.

  • 실패한 작업 단계에 대한 복구 관리 애플리케이션은 하나 이상의 단계가 실패할 경우 일련의 단계(최종적으로 일관된 작업을 함께 정의)에 의해 수행되는 작업을 실행 취소해야 할 수 있습니다. 자세한 내용은 보정 트랜잭션 패턴을 참조하세요.

복원력 고려사항

애플리케이션에 신뢰할 수 있는 서비스를 제공하려면 백그라운드 작업이 복원력이 있어야 합니다. 백그라운드 작업을 계획하고 디자인하는 경우 다음 사항을 고려합니다.

  • 백그라운드 작업은 데이터를 손상시키거나 애플리케이션에 불일치를 도입하지 않고 다시 시작을 정상적으로 처리할 수 있어야 합니다. 장기 실행 또는 다중 단계 작업의 경우 영구 스토리지에 작업 상태를 저장하여 확인 포인팅 을 사용하거나 적절한 경우 큐에 메시지로 사용하는 것이 좋습니다. 예를 들어 큐의 메시지에 상태 정보를 보관하고 작업 진행률로 이 상태 정보를 증분 방식으로 업데이트하여 처음부터 다시 시작하는 대신 마지막으로 알려진 정상 검사점에서 작업을 처리할 수 있습니다. Azure Service Bus 큐를 사용하는 경우 메시지 세션을 사용하여 동일한 시나리오를 사용하도록 설정할 수 있습니다. 세션을 사용하면 SetState 및 GetState 메서드를 사용하여 애플리케이션 처리 상태를 저장하고 검색 할 수 있습니다. 신뢰할 수 있는 다중 단계 프로세스 및 워크플로를 설계하는 방법에 대한 자세한 내용은 Scheduler 에이전트 감독자 패턴을 참조하세요.

  • 대기열을 사용하여 백그라운드 작업과 통신하는 경우 대기열은 애플리케이션의 로드가 평소보다 높은 동안 작업으로 전송된 요청을 저장하는 버퍼 역할을 할 수 있습니다. 이렇게 하면 작업이 사용량이 적은 기간 동안 UI를 따라잡을 수 있습니다. 또한 다시 시작이 UI를 차단하지 않음을 의미합니다. 자세한 내용은 Queue-Based 부하 평준화 패턴을 참조하세요. 일부 태스크가 다른 작업보다 더 중요한 경우 우선 순위 큐 패턴을 구현하여 덜 중요한 작업보다 이러한 작업이 실행되도록 하는 것이 좋습니다.

  • 메시지 또는 프로세스 메시지에서 시작되는 백그라운드 작업은 순서가 잘못된 메시지, 반복적으로 오류를 발생시키는 메시지( 포이즌 메시지라고도 함) 및 두 번 이상 배달되는 메시지와 같은 불일치를 처리하도록 설계되어야 합니다. 다음을 살펴보세요.

    • 기존 데이터 값에 따라 데이터를 변경하는 메시지(예: 기존 값에 값 추가)와 같이 특정 순서로 처리해야 하는 메시지는 전송된 원래 순서로 도착하지 않을 수 있습니다. 또는 각 인스턴스의 다양한 부하로 인해 백그라운드 작업의 다른 인스턴스에서 다른 순서로 처리될 수 있습니다. 특정 순서로 처리해야 하는 메시지에는 백그라운드 작업이 올바른 순서로 처리되도록 하는 데 사용할 수 있는 시퀀스 번호, 키 또는 기타 표시기가 포함되어야 합니다. Azure Service Bus를 사용하는 경우 메시지 세션을 사용하여 배달 순서를 보장할 수 있습니다. 그러나 메시지 순서가 중요하지 않도록 프로세스를 디자인하는 것이 일반적으로 더 효율적입니다.

    • 일반적으로 백그라운드 작업은 큐의 메시지를 확인하여 다른 메시지 소비자로부터 일시적으로 숨깁니다. 그런 다음 성공적으로 처리된 후 메시지를 삭제합니다. 메시지를 처리할 때 백그라운드 작업이 실패하면 피킹 제한 시간이 만료된 후 해당 메시지가 큐에 다시 나타납니다. 그런 다음 작업의 다른 인스턴스 또는 이 인스턴스의 다음 처리 주기 중에 처리됩니다. 메시지가 지속적으로 소비자에서 오류를 발생시키는 경우, 그것이 태스크를 차단하고, 계속해서 큐를 차단하며, 큐가 가득 차게 되면 결국 애플리케이션 자체를 차단합니다. 따라서 큐에서 포이즌 메시지를 감지하고 제거하는 것이 중요합니다. Azure Service Bus를 사용하는 경우 오류가 발생하는 메시지를 자동으로 또는 수동으로 연결된 배달 못 한 편지 큐로 이동할 수 있습니다.

    • 큐는 전달 방법을 한 번 이상 보장하지만, 동일한 메시지를 중복 전달할 수 있습니다. 또한 메시지를 처리한 후 큐에서 삭제하기 전에 백그라운드 작업이 실패하면 메시지를 다시 처리할 수 있게 됩니다. 백그라운드 작업은 idempotent여야 합니다. 즉, 동일한 메시지를 두 번 이상 처리해도 애플리케이션 데이터의 오류 또는 불일치가 발생하지 않습니다. 일부 작업은 저장된 값을 특정 새 값으로 설정하는 것과 같이 자연스럽게 멱등성을 가지게 됩니다. 그러나 저장된 값이 원래 메시지를 보냈을 때와 동일한지 확인하지 않고 기존 저장된 값에 값을 추가하는 등의 작업으로 인해 불일치가 발생합니다. 중복된 메시지를 자동으로 제거하도록 Azure Service Bus 큐를 구성할 수 있습니다. 최소 한 번 이상의 메시지 배달과 관련한 문제에 대한 자세한 내용은 idempotent 메시지 처리에 대한 지침을 참조하세요.

    • Azure Queue Storage 및 Azure Service Bus 큐와 같은 일부 메시징 시스템은 큐에서 메시지를 읽은 횟수를 나타내는 큐 수 해제 속성을 지원합니다. 반복 및 포이즌 메시지를 처리하는 데 유용할 수 있습니다. 자세한 내용은 비동기 메시징 입문서 및 Idempotency 패턴을 참조하세요.

확장 및 성능 고려 사항

백그라운드 작업은 애플리케이션을 차단하지 않도록 충분한 성능을 제공하거나 시스템이 로드 중일 때 지연된 작업으로 인해 불일치를 야기해야 합니다. 일반적으로 백그라운드 작업을 호스트하는 컴퓨팅 인스턴스의 크기를 조정하여 성능이 향상됩니다. 백그라운드 작업을 계획하고 디자인할 때 확장성 및 성능과 관련된 다음 사항을 고려합니다.

  • Azure는 Web Apps 및 Virtual Machines 호스팅 배포에 대해 현재 수요 및 로드 또는 미리 정의된 일정에 따라 자동 크기 조정(스케일 아웃 및 스케일 인 모두)을 지원합니다. 이 기능을 사용하여 런타임 비용을 최소화하면서 애플리케이션 전체에 충분한 성능 기능이 있는지 확인합니다.

  • 백그라운드 작업이 애플리케이션의 다른 부분(예: UI 또는 데이터 액세스 계층과 같은 구성 요소)과 다른 성능 기능을 갖는 경우 별도의 컴퓨팅 서비스에서 백그라운드 작업을 함께 호스팅하면 UI 및 백그라운드 작업을 독립적으로 확장하여 부하를 관리할 수 있습니다. 여러 백그라운드 작업에 서로 크게 다른 성능 기능이 있는 경우 이를 분할하고 각 형식의 크기를 독립적으로 조정하는 것이 좋습니다. 그러나 이렇게 하면 런타임 비용이 증가할 수 있습니다.

  • 단순히 컴퓨팅 리소스의 크기를 조정하는 것만으로는 로드 중인 성능 손실을 방지하기에 충분하지 않을 수 있습니다. 전체 처리 체인의 단일 지점이 병목 상태가 되지 않도록 스토리지 큐 및 기타 리소스의 크기를 조정해야 할 수도 있습니다. 또한 스토리지의 최대 처리량 및 애플리케이션 및 백그라운드 작업이 사용하는 기타 서비스와 같은 다른 제한 사항을 고려합니다.

  • 백그라운드 작업은 크기 조정을 위해 설계되어야 합니다. 예를 들어 메시지를 수신 대기하거나 적절한 큐로 보내기 위해 사용 중인 스토리지 큐 수를 동적으로 검색할 수 있어야 합니다.

  • 기본적으로 WebJobs는 연결된 Azure Web Apps 인스턴스로 크기를 조정합니다. 그러나 WebJob을 단일 인스턴스로만 실행하려면 JSON 데이터 { "is_singleton": true }를 포함하는 Settings.job 파일을 만들 수 있습니다. 이렇게 하면 연결된 웹앱의 인스턴스가 여러 개 있는 경우에도 Azure에서 WebJob의 인스턴스를 하나만 실행해야 합니다. 이는 단일 인스턴스로만 실행되어야 하는 예약된 작업에 유용한 기술일 수 있습니다.

다음 단계

  • Last updated on