다음을 통해 공유

백그라운드 작업

  • 아티클

다양한 유형의 애플리케이션을 사용하려면 사용자 인터페이스(UI)와 독립적으로 실행되는 백그라운드 작업이 필요합니다. 이러한 작업의 예로 배치 작업, 집약적인 처리 작업, 워크플로 등의 장기 실행 프로세스가 있습니다. 백그라운드 작업은 사용자 조작 없이 실행할 수 있으며, 애플리케이션은 작업을 시작한 다음, 사용자의 조작 요청을 계속 처리할 수 있습니다. 따라서 애플리케이션 UI에 대한 부담을 최소화하므로 가용성을 개선하고 대화형 응답 시간을 줄일 수 있습니다.

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

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

백그라운드 작업의 유형

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

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

트리거

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

  • 이벤트 기반 트리거. 작업은 이벤트, 일반적으로 사용자 또는 워크플로 단계에 의해 실행된 동작에 응답하여 시작됩니다.
  • 일정 기반 트리거. 타이머를 기준으로 일정에 따라 작업이 호출됩니다. 이는 되풀이 일정 또는 이후 시간에 대해 지정된 일회성 호출일 수 있습니다.

이벤트 기반 트리거

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

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

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

일정 기반 트리거

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

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

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

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

  • 스케줄러를 실행하는 컴퓨팅 인스턴스(Windows 예약된 작업을 사용하는 가상 머신 등)가 확장된 경우, 스케줄러의 여러 인스턴스가 실행됩니다. 이 인스턴스가 작업의 복수 인스턴스를 시작할 수 있습니다. 이에 대한 자세한 내용은 idempotence에 대한 이 블로그 게시물을 참조하세요.
  • 작업이 스케줄러 이벤트 간의 기간보다 더 오래 실행되는 경우, 스케줄러는 이전 인스턴스가 여전히 실행하는 동안 작업의 다른 인스턴스를 시작할 수 있습니다.

결과 반환

백그라운드 작업이 별도 프로세스 또는 심지어 별도 위치에서, UI 또는 백그라운드 작업을 호출한 프로세스에서 비동기 방식으로 실행합니다. 백그라운드 작업은 "시작 후 잊어 버리는" 작업이 가장 좋으며, 해당 작업의 실행 진행률이 UI 또는 호출 프로세스에 영향을 미치지 않습니다. 즉, 호출 프로세스는 작업이 완료될 때까지 기다리지 않으므로 작업이 종료되는 시기를 자동으로 감지할 수 없습니다.

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

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

호스팅 환경

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

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

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

Azure Web Apps 및 WebJobs

Azure WebJobs를 사용하여 Azure 웹앱 내에서 사용자 지정 작업을 백그라운드 작업으로 실행할 수 있습니다. 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 WebJob은 다음과 같은 특성을 가지고 있습니다.

  • 보안: 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 포털을 사용하여 액세스할 수 있으며 로그 파일은 사이트에서 직접 다운로드할 수 있습니다. 다음 위치에 저장됩니다.
    • 트리거된 실행의 경우: Vfs/data/jobs/triggered/jobName
    • 연속 실행의 경우: Vfs/data/jobs/continuous/jobName
  • 구성: 포털, REST API 및 PowerShell을 사용하여 WebJobs를 구성할 수 있습니다. 루트 디렉터리의 settings.job이라는 구성 파일을 작업 스크립트로 사용하여 작업에 대한 구성 정보를 제공할 수 있습니다. 예:
    • { "stopping_wait_time": 60 }
    • { "is_singleton": true }

고려 사항

  • 기본적으로 WebJobs 웹앱을 통해 확장됩니다. 그러나 is_singleton 구성 속성을 true로 설정하여 작업을 단일 인스턴스에서 실행되도록 구성할 수 있습니다. 단일 인스턴스 WebJobs는 확장을 원하지 않거나 인덱싱 다시 수행, 데이터 분석 및 유사한 작업 등 동시에 복수 인스턴스의 실행을 원하지 않는 작업에 유용합니다.
  • 웹앱 성능에 대한 작업의 영향을 최소화하려면 새 App Service 요금제에서 빈 Azure Web App 인스턴스를 만들어 장기 실행 또는 리소스 집약적인 WebJobs를 호스팅하는 것이 좋습니다.

Azure 기능

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

Azure Functions는 예기치 않은 시간 초과 문제를 일으킬 수 있으므로 대규모 장기 실행 작업에 권장되는 옵션이 아닙니다. 그러나 호스팅 계획에 따라 일정 기반 트리거에 대해 고려할 수 있습니다.

고려 사항

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

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

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

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

Azure Virtual Machines

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

Virtual Machines를 사용할 때 선택하는 방법은 Azure App Services, Cloud Services 및 Virtual Machines 비교를 참조하세요. Virtual Machines를 위한 옵션에 대한 자세한 내용은 Azure의 Windows 가상 머신 크기를 참조하세요. Virtual Machines에 사용할 수 있는 운영 체제 및 미리 작성된 이미지에 대한 자세한 내용은 Azure Virtual Machines Marketplace를 참조하세요.

별도 가상 머신에서 백그라운드 작업을 시작하려는 경우 다양한 옵션이 있습니다.

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

백그라운드 작업을 시작할 수 있는 방법은 이전 섹션 트리거를 참조하세요.

고려 사항

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

  • 별도 Azure 가상 머신에서 백그라운드 작업을 호스트하면 유연성을 제공하며 시작, 실행, 예약 및 리소스 할당을 정확하게 제어할 수 있습니다. 그러나 단지 백그라운드 작업을 실행하기 위해 가상 머신을 배포해야 한다면 런타임 비용이 증가합니다.
  • Azure Portal에서 작업을 모니터링하는 기능은 없고 실패한 작업을 자동으로 다시 시작하는 기능도 없지만, Azure Resource Manager Cmdlet을 사용하여 가상 머신의 기본 상태를 모니터링하고 이를 관리할 수 있습니다. 그러나 컴퓨팅 노드의 프로세스 및 스레드를 제어하는 기능은 없습니다. 일반적으로 가상 컴퓨터를 사용하려면 작업의 구현 및 가상 컴퓨터의 운영 체제에서 데이터를 수집하는 메커니즘을 구현하기 위해 추가적인 노력이 필요합니다. 적절할 수 있는 한 가지 해결책은 System Center Management Pack for Azure를 사용하는 것입니다.
  • 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 경계 내에서 컨테이너를 등록할 수 있습니다. 이를 통해 보안, 개인 정보 보호 및 근접성 이점을 얻을 수 있습니다.

고려 사항

  • 컨테이너 오케스트레이터를 사용하는 방법을 이해해야 합니다. DevOps 팀의 기술 집합에 따라 문제가 될 수도 있고 그렇지 않을 수도 있습니다.

자세한 내용은 다음을 참조하십시오.

Azure Container Apps

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 또는 애플리케이션의 다른 부분과는 다를 수 있습니다. 별도 컴퓨팅 인스턴스를 사용하면 작업에 대해 다른 보안 환경을 지정할 수 있습니다. 또한 보안 및 분리를 최대화하기 위해 게이트키퍼 같은 패턴을 사용하여 백그라운드 컴퓨팅 인스턴스를 UI와 격리할 수 있습니다.

  • 성능: 작업의 성능 요구 사항을 구체적으로 일치시키기 위해 백그라운드 작업에 대한 컴퓨팅 인스턴스 유형을 선택할 수 있습니다. 즉, 작업에 UI와 같은 처리 용량이 필요하지 않은 경우 비용이 적은 컴퓨팅 옵션을 사용하거나, 또는 추가 용량 및 리소스가 필요한 경우 더 큰 인스턴스를 사용할 수 있습니다.

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

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

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

충돌

백그라운드 작업의 여러 인스턴스가 있는 경우, 데이터베이스 및 스토리지 같은 서비스와 리소스의 액세스에 대해 계산할 수 있습니다. 이 동시 액세스로 인해 리소스 경합을 초래하여 서비스 가용성 및 스토리지의 데이터 무결성에 충돌이 발생할 수 있습니다. 리소스 경합은 비관적 잠금 접근 방식을 사용하여 해결할 수 있습니다. 이는 작업의 경합 인스턴스가 동시에 서비스에 액세스하거나 데이터를 손상시키지 못하도록 합니다.

충돌을 해결 하는 다른 방법은 언제나 하나의 인스턴스만 실행되도록 백그라운드 작업을 단일 항목으로 정의하는 것입니다. 그러나 이렇게 하면 특히 UI가 둘 이상의 백그라운드 작업을 사용하도록 유지할 만큼 충분한 작업을 제공할 수 있는 경우 복수 인스턴스 구성이 제공할 수 있는 안정성 및 성능 이점이 제거됩니다.

백그라운드 작업이 자동으로 다시 시작되고 최고 수요를 극복하기에 충분한 용량을 갖도록 해야 합니다. 컴퓨팅 인스턴스에 충분한 리소스 할당, 수요가 감소할 때 요청을 나중에 실행하도록 저장할 수 있는 큐 메커니즘 또는 두 기법의 조합에 의해 이를 실현할 수 있습니다.

조정

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

복수의 작업과 단계를 조정하는 것은 쉽지 않을 수 있지만, 해결책 구현을 안내하기 위해 사용할 수 있는 일반적인 패턴 세 가지가 있습니다.

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

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

  • 실패한 작업 단계에 대한 복구 관리. 애플리케이션은 결국 함께 모여서 일관된 작업을 정의하는 일련의 단계에 의해 수행되는 작업을 하나 이상의 단계가 실패하면 취소해야 할 수 있습니다. 자세한 내용은 보정 트랜잭션 패턴을 참조하세요.

복원력 고려 사항

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

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

  • 큐를 사용하여 백그라운드 작업과 통신하는 경우, 큐는 애플리케이션이 평시 부하보다 더 높은 상태에 있는 동안 작업에 보내진 요청을 저장하는 버퍼 역할을 할 수 있습니다. 이 방법으로 사용량이 적은 기간 동안 작업이 UI를 불러오게 할 수 있습니다. 또한 다시 시작은 UI를 차단하지 않습니다. 자세한 내용은 큐 기반 부하 평준화 패턴을 참조하십시오. 일부 작업이 다른 작업보다 더 중요 한 경우, 이러한 작업이 덜 중요한 작업보다 먼저 실행되도록 우선 순위 큐 패턴의 구현을 고려합니다.

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

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

    • 일반적으로 백그라운드 작업은 큐의 메시지를 엿보고 메시지를 다른 메시지 소비자로부터 일시적으로 숨긴 다음, 해당 메시지가 성공적으로 처리된 후에 삭제합니다. 메시지를 처리할 때 백그라운드 작업이 실패한 경우, 해당 메시지는 엿보기 시간 제한이 만료된 후 큐에 다시 나타나며, 작업의 다른 인스턴스에 의해 또는 이 인스턴스의 다음 처리 주기 동안 처리됩니다. 메시지가 소비자에서 일관되게 오류를 발생시키면 해당 메시지 때문에 작업, 큐 및 큐가 꽉 찬 경우 결국 애플리케이션 자체가 차단됩니다. 그러므로 큐에서 포이즌 메시지를 감지하여 제거해야 합니다. Azure Service Bus를 사용하는 경우, 오류를 야기하는 메시지를 연결된 배달 못한 메시지 큐로 자동 또는 수동으로 이동할 수 있습니다.

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

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

확장 및 성능 고려 사항

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

  • Azure는 현재 수요와 부하 또는 Web Apps 및 Virtual Machines에 호스트되는 배포의 경우 미리 정의된 일정을 기반으로 자동 크기 조정을 지원합니다(확장 및 축소 모두). 런타임 비용을 최소화하면서 애플리케이션이 전체적으로 충분한 성능을 갖게 하려면 이 기능을 사용합니다.

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

  • 단순히 컴퓨팅 리소스의 크기만 조정하면 부하를 받을 때 성능 손실을 방지하기에 부족할 수 있습니다. 또한 전체 처리 체인의 단일 지점이 병목 상태가 되는 것을 방지하기 위해 스토리지 큐 및 다른 리소스를 크기 조정해야 할 수 있습니다. 또한 스토리지의 최대 처리량 및 애플리케이션과 백그라운드 작업이 의존하는 다른 서비스 등 다른 제한도 고려해야 합니다.

  • 백그라운드 작업은 크기 조정을 고려하여 디자인해야 합니다. 예를 들어 이러한 작업은 스토리지 큐에서 수신 대기하거나 메시지를 해당 큐에 보내기 위해 사용 중인 스토리지 큐 수를 동적으로 감지할 수 있어야 합니다.

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

다음 단계