백그라운드 작업 개발을 위한 권장 사항

  • 아티클

이 Azure Well-Architected Framework 안정성 검사 목록 권장 사항에 적용됩니다.

RE:07 자기 보존 및 자가 복구 조치를 구현하여 워크로드의 복원력과 복구 가능성을 강화합니다. 인프라 기반 안정성 패턴 및 소프트웨어 기반 디자인 패턴을 사용하여 구성 요소 오류 및 일시적인 오류를 처리하여 솔루션에 기능을 빌드합니다. 시스템에 기능을 빌드하여 솔루션 구성 요소 오류를 감지하고 워크로드가 전체 또는 축소된 기능에서 계속 작동하는 동안 자동으로 수정 작업을 시작합니다.

관련 가이드:일시적인 오류 | 자체 보존

이 가이드에서는 백그라운드 작업을 개발하기 위한 권장 사항을 설명합니다. 백그라운드 작업은 사용자 상호 작용 없이 자동으로 실행됩니다. 많은 애플리케이션에는 UI와 독립적으로 실행되는 백그라운드 작업이 필요합니다.

백그라운드 작업의 몇 가지 예로는 일괄 처리 작업, 집중적인 처리 작업 및 워크플로와 같은 장기 실행 프로세스가 있습니다. 애플리케이션은 작업을 시작하고 사용자의 대화형 요청을 처리합니다. 예를 들어 애플리케이션에서 사용자가 업로드하는 이미지의 썸네일을 생성해야 하는 경우 백그라운드 작업을 수행하여 썸네일을 생성하고 스토리지에 저장할 수 있습니다. 사용자는 프로세스가 완료되기를 기다릴 필요가 없습니다. 또 다른 예로 고객은 주문을 처리하는 백그라운드 워크플로를 시작하는 주문을 배치합니다. 고객은 백그라운드 작업이 실행되는 동안 웹앱을 계속 검색합니다. 백그라운드 작업이 완료되면 저장된 주문 데이터를 업데이트하고 고객에게 이메일을 보내 주문을 확인합니다.

백그라운드 작업은 애플리케이션 UI의 부하를 최소화하여 가용성을 개선하고 대화형 응답 시간을 줄이는 데 도움이 됩니다.

주요 디자인 전략

백그라운드 작업으로 지정할 작업을 선택하려면 사용자 상호 작용 없이 작업이 실행되는지 여부와 UI가 작업이 완료되기를 기다려야 하는지 여부를 고려합니다. 사용자 또는 UI가 실행되는 동안 기다려야 하는 작업은 일반적으로 적절한 백그라운드 작업이 아닙니다.

백그라운드 작업의 유형

백그라운드 작업의 몇 가지 예는 다음과 같습니다.

  • 수학 계산, 구조 모델 분석 등 CPU를 많이 사용하는 작업.

  • 일련의 스토리지 트랜잭션 실행 또는 파일 인덱싱과 같은 I/O 집약적인 작업입니다.

  • 야간 데이터 업데이트 또는 예약된 처리 같은 Batch 작업.

  • 주문 처리 또는 프로비저닝 서비스 및 시스템과 같은 장기 실행 워크플로.

  • 처리를 위해 작업을 보다 안전한 위치로 전송하는 중요한 데이터 처리입니다. 예를 들어 웹앱 내에서 중요한 데이터를 처리하지 않고 대신 게이트키퍼 같은 패턴을 사용하여 보호되는 스토리지에 액세스할 수 있는 격리된 백그라운드 프로세스에 데이터를 전송할 수 있습니다.

트리거

다음을 사용하여 백그라운드 작업을 시작합니다.

  • 이벤트 기반 트리거: 이벤트(일반적으로 사용자 작업 또는 워크플로의 단계)는 작업을 트리거합니다.

  • 일정 기반 트리거: 타이머를 기반으로 하는 일정이 작업을 호출합니다. 작업은 되풀이 또는 단일 실행에 대해 예약할 수 있습니다.

이벤트 기반 트리거

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

  • UI 또는 다른 작업은 Web-Queue-Worker 아키텍처 스타일에 설명된 대로 메시지를 큐에 배치합니다. 메시지에는 주문을 한 고객과 같이 이전에 수행한 작업에 대한 데이터가 포함되어 있습니다. 백그라운드 작업은 이 큐를 모니터링하고 새 메시지의 도착을 검색합니다. 메시지를 읽고 메시지의 데이터를 백그라운드 작업에 대한 입력으로 사용합니다. 이 패턴을 비동기 메시지 기반 통신이라고 합니다.

  • UI 또는 다른 작업은 스토리지에 있는 값을 저장하거나 업데이트합니다. 백그라운드 작업은 스토리지를 모니터링하고 변경 내용을 검색합니다. 데이터를 읽고 백그라운드 작업에 대한 입력으로 사용합니다.

  • UI 또는 다른 작업은 웹 서비스로 노출되는 HTTPS URI 또는 API와 같은 엔드포인트에 요청을 수행합니다. 요청의 일부로 UI 또는 작업은 백그라운드 작업에 필요한 데이터를 전송합니다. 엔드포인트 또는 웹 서비스가 데이터를 자체의 입력으로 사용하는 백그라운드 작업을 호출합니다.

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

일정 기반 트리거

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

  • 애플리케이션 내에서 또는 애플리케이션 운영 체제의 일부로 로컬로 실행되는 타이머는 백그라운드 작업을 정기적으로 호출합니다.

  • Azure Logic Apps와 같은 다른 애플리케이션에서 실행되는 타이머는 정기적으로 요청을 API 또는 웹 서비스로 보냅니다. API 또는 웹 서비스가 백그라운드 작업을 호출합니다.

  • 별도의 프로세스 또는 애플리케이션은 시간 지연 후 또는 특정 시간에 백그라운드 작업을 호출하는 타이머를 시작합니다.

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

단일 instance 실행해야 하는 일정 기반 작업을 사용하는 경우 다음 고려 사항을 검토합니다.

  • Windows 예약 작업을 사용하는 VM(가상 머신)과 같이 스케줄러를 실행하는 컴퓨팅 instance 크기가 조정되면 스케줄러의 여러 인스턴스를 실행합니다. 스케줄러의 여러 인스턴스는 작업의 여러 인스턴스를 시작할 수 있습니다. 자세한 내용은 소프트웨어 시스템에서 idempotent는 무엇을 의미하나요?를 참조하세요.

  • 작업이 스케줄러 이벤트 사이의 기간보다 오래 실행되는 경우 스케줄러는 이전 작업이 실행되는 동안 작업의 다른 instance 시작할 수 있습니다.

결과 반환

백그라운드 작업은 UI 또는 백그라운드 작업을 호출한 프로세스에서 별도의 프로세스 또는 별도의 위치에서 비동기적으로 실행됩니다. 이상적으로 백그라운드 작업은 실행되고 작업을 잊어버리 는 것이 좋습니다. 런타임 진행률이 UI 또는 호출 프로세스에 영향을 주지 않으므로 호출 프로세스가 작업이 완료되기를 기다리지 않습니다. UI 및 호출 프로세스는 작업이 종료되는 시기를 감지할 수 없습니다.

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

  • 이 값을 모니터링하거나 검사 수 있는 UI 또는 호출자 태스크에 액세스할 수 있는 스토리지에 상태 표시기 값을 작성합니다. 백그라운드 작업이 호출자에게 반환하는 다른 데이터는 동일한 스토리지에 배치할 수 있습니다.

  • UI 또는 호출자가 모니터링하는 회신 큐를 설정합니다. 백그라운드 작업은 상태 나타내는 메시지를 큐에 보낼 수 있습니다. 백그라운드 작업이 호출자에게 반환하는 데이터는 메시지에 배치할 수 있습니다. Azure Service Bus 및 속성을 사용하여 ReplyToCorrelationId 이 기능을 구현합니다.

  • UI 또는 호출자가 상태 정보를 가져오기 위해 액세스할 수 있는 백그라운드 작업에서 API 또는 엔드포인트를 표시합니다. 응답에는 백그라운드 작업이 호출자에게 반환하는 데이터가 포함될 수 있습니다.

  • API를 통해 UI 또는 호출자에게 다시 호출하여 미리 정의된 지점 또는 완료 시 상태 나타내도록 백그라운드 작업을 구성합니다. 로컬로 발생한 이벤트 또는 게시 및 구독 메커니즘을 사용할 수 있습니다. 요청 또는 이벤트 페이로드는 백그라운드 작업이 호출자에게 반환하는 데이터를 포함할 수 있습니다.

파티션 백그라운드 작업

기존 컴퓨팅 instance 백그라운드 작업을 포함하는 경우 이러한 변경 내용이 컴퓨팅 instance 및 백그라운드 작업의 품질 특성에 미치는 영향을 고려합니다. 다음 요소를 고려하여 기존 컴퓨팅 instance 작업을 공동 배치할지 아니면 다른 컴퓨팅 instance 구분할지 결정합니다.

  • 가용성: 백그라운드 작업은 애플리케이션의 다른 부분, 특히 사용자 상호 작용을 직접 포함하는 UI 및 부분과 동일한 수준의 가용성이 필요하지 않을 수 있습니다. 백그라운드 작업은 대기 시간, 다시 시도된 연결 오류 및 작업이 큐에 대기될 수 있으므로 가용성에 영향을 주는 기타 요인에 대한 허용 오차가 더 높을 수 있습니다. 그러나 큐를 차단하고 전체 애플리케이션에 영향을 줄 수 있는 백업 요청을 방지할 수 있는 충분한 용량이 있어야 합니다.

  • 확장성: 백그라운드 작업에는 UI 및 애플리케이션의 대화형 부분에 비해 확장성 요구 사항이 다를 수 있습니다. 최대 수요에 맞게 UI 크기를 조정해야 할 수 있습니다. 실행 중인 백그라운드 작업은 사용량이 적은 시간과 컴퓨팅 인스턴스 수가 적은 동안 실행할 수 있습니다.

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

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

  • 성능: 특히 태스크의 성능 요구 사항과 일치하는 백그라운드 작업에 대한 컴퓨팅 instance 유형을 선택합니다. 태스크에 UI와 동일한 처리 기능이 필요하지 않은 경우 저렴한 컴퓨팅 옵션을 사용할 수 있습니다. 또는 작업에 더 많은 용량과 리소스가 필요한 경우 더 큰 instance 사용할 수 있습니다.

  • 관리 효율성: 백그라운드 작업은 기본 애플리케이션 코드 또는 UI에 비해 개발 및 배포 리듬이 다를 수 있습니다. 업데이트 및 버전 관리를 간소화하려면 백그라운드 작업을 별도의 컴퓨팅 instance 배포합니다.

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

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

충돌

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

충돌을 resolve 또 다른 방법은 백그라운드 작업을 싱글톤으로 정의하여 하나의 instance 실행하는 것입니다. 그러나 이 방법은 다중 instance 구성에서 제공하는 안정성 및 성능 이점을 제거합니다. 이 단점은 UI가 둘 이상의 백그라운드 작업을 사용할 수 있는 충분한 작업을 제공하는 경우에 특히 그렇습니다.

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

조정

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

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

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

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

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

복원력 고려 사항

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

  • 백그라운드 작업은 데이터를 손상시키거나 애플리케이션에 불일치를 도입하지 않고 다시 시작을 정상적으로 처리해야 합니다. 장기 실행 또는 다단계 작업의 경우 검사점 사용을 고려하세요. 검사점 을 사용하여 작업 상태를 영구 스토리지 또는 큐의 메시지로 저장합니다. 예를 들어 큐에 있는 메시지에 상태 정보를 저장하고 작업 진행률로 이 상태 정보를 증분 방식으로 업데이트할 수 있습니다. 작업을 처음부터 다시 시작하는 대신 마지막으로 알려진 검사점에서 처리할 수 있습니다.

    Service Bus 큐의 경우 이 목적을 위해 메시지 세션을 사용합니다. 메시지 세션을 사용하여 SetState 및 GetState 메서드를 사용하여 애플리케이션 처리 상태를 저장하고 검색합니다. 신뢰할 수 있는 다중 단계 프로세스 및 워크플로를 디자인하는 방법에 대한 자세한 내용은 Scheduler 에이전트 감독자 패턴을 참조하세요.

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

메시지

순서가 잘못된 메시지, 반복적으로 오류를 일으키는 메시지(포이즌 메시지) 및 두 번 이상 전달되는 메시지와 같이 메시지에서 시작하거나 메시지를 처리하여 불일치를 처리하는 백그라운드 작업을 구성합니다. 다음 권장 사항을 고려할 수 있습니다.

  • 기존 데이터 값에 따라 데이터를 변경하는 메시지(예: 기존 값에 값 추가)와 같이 특정 순서로 메시지를 처리해야 하는 경우가 있습니다. 메시지가 전송된 순서대로 항상 도착하지는 않습니다. 또한 백그라운드 작업의 다른 인스턴스는 각 instance 다양한 부하로 인해 메시지를 다른 순서로 처리할 수 있습니다.

    특정 순서로 처리해야 하는 메시지의 경우 백그라운드 작업이 올바른 순서로 메시지를 처리하는 데 사용할 수 있는 시퀀스 번호, 키 또는 다른 표시기를 포함합니다. Service Bus의 경우 메시지 세션을 사용하여 올바른 배달 순서를 보장합니다. 메시지 순서가 중요하지 않도록 프로세스를 디자인하는 것이 더 효율적입니다. 자세한 내용은 메시지 시퀀싱 및 타임스탬프를 참조하세요.

  • 일반적으로 백그라운드 작업은 큐의 메시지를 피킹하여 다른 메시지 소비자로부터 일시적으로 숨깁니다. 태스크가 메시지를 성공적으로 처리하면 메시지가 삭제됩니다. 메시지를 처리할 때 백그라운드 작업이 실패하면 피킹 시간 제한이 만료된 후 해당 메시지가 큐에 다시 나타납니다. 작업의 다른 instance 메시지를 처리하거나 원래 instance 다음 처리 주기가 메시지를 처리합니다.

    메시지가 지속적으로 소비자에게 오류를 발생시키는 경우 큐가 가득 차면 작업, 큐 및 결국 애플리케이션 자체를 차단합니다. 큐에서 포이즌 메시지를 검색하고 제거하는 것이 중요합니다. Service Bus를 사용하는 경우 포이즌 메시지를 자동으로 또는 수동으로 연결된 배달 못한 편지 큐로 이동합니다.

  • 큐는 한 번 이상 배달 메커니즘이지만 동일한 메시지를 두 번 이상 배달할 수 있습니다. 백그라운드 작업이 메시지를 처리한 후 큐에서 삭제하기 전에 실패하면 메시지를 다시 처리할 수 있습니다.

    백그라운드 작업은 idempotent여야 합니다. 즉, 태스크가 동일한 메시지를 두 번 이상 처리할 때 애플리케이션 데이터의 오류 또는 불일치가 발생하지 않습니다. 일부 작업은 저장 값이 특정 새 값으로 설정된 경우와 같이 자연스럽게 멱등성입니다. 그러나 일부 작업에서는 예를 들어 저장된 값이 메시지가 원래 전송되었을 때와 동일한지 확인하지 않고 기존 저장된 값에 값이 추가되는 경우와 같은 불일치가 발생합니다. 중복된 메시지를 자동으로 제거하도록 Service Bus 큐를 구성합니다. 자세한 내용은 Idempotent 메시지 처리를 참조하세요.

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

확장 및 성능 고려 사항

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

  • Azure Virtual Machines 및 Azure App Service Web Apps 기능은 배포를 호스트할 수 있습니다. 스케일 아웃 및 스케일 인을 모두 지원하는 자동 크기 조정을 지원합니다. 자동 크기 조정은 수요 및 로드 또는 미리 정의된 일정에 따라 결정됩니다. 자동 크기 조정을 사용하면 런타임 비용을 최소화하면서 애플리케이션에 충분한 성능 기능이 있는지 확인할 수 있습니다.

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

  • 부하가 있는 성능 손실을 방지하려면 스토리지 큐 및 기타 리소스를 확장해야 처리 체인의 단일 지점이 병목 현상을 일으키지 않도록 할 수도 있습니다. 스토리지의 최대 처리량 및 애플리케이션 및 백그라운드 작업이 사용하는 기타 서비스와 같은 다른 제한 사항을 고려합니다.

  • 크기 조정을 위한 백그라운드 작업을 디자인합니다. 예를 들어 백그라운드 작업은 메시지를 모니터링하거나 적절한 큐로 메시지를 보내기 위해 사용된 스토리지 큐 수를 동적으로 검색해야 합니다.

  • 기본적으로 WebJob은 연결된 Web Apps instance 스케일링합니다. 그러나 WebJob을 단일 instance 실행하려면 JSON 데이터가 { "is_singleton": true }포함된 Settings.job 파일을 만들 수 있습니다. 이 메서드는 연결된 웹앱의 인스턴스가 여러 개 있는 경우에도 Azure에서 WebJob의 instance 하나만 실행하도록 강제합니다. 이 기술은 단일 instance 실행해야 하는 예약된 작업에 유용합니다.

  • 백그라운드 작업은 특히 백그라운드 작업이 서로 또는 다른 데이터 원본에 의존하는 경우 데이터 동기화 및 프로세스 조정에 대한 과제를 만들 수 있습니다. 예를 들어 백그라운드 작업은 데이터 일관성 문제, 경합 상태, 교착 상태 또는 시간 제한을 처리할 수 있습니다.

  • 백그라운드 작업의 결과가 사용자에게 표시되는 경우 백그라운드 작업은 사용자 환경에 영향을 줄 수 있습니다. 예를 들어 백그라운드 작업을 수행하려면 사용자가 알림을 기다리거나, 페이지를 새로 고치거나, 작업의 상태 수동으로 검사 수 있습니다. 이러한 동작은 사용자 상호 작용의 복잡성을 증가시키고 사용자 환경에 부정적인 영향을 줄 수 있습니다.

절충: 백그라운드 작업은 시스템에 더 많은 구성 요소와 종속성을 도입하여 솔루션의 복잡성 및 유지 관리 비용을 증가시킬 수 있습니다. 예를 들어 백그라운드 작업에는 별도의 큐 서비스, 작업자 서비스, 모니터링 서비스 및 재시도 메커니즘이 필요할 수 있습니다.

Azure 촉진

다음 섹션에서는 백그라운드 작업을 호스트, 실행, 구성 및 관리하는 데 사용할 수 있는 Azure 서비스에 대해 설명합니다.

호스트 환경

백그라운드 작업을 호스트할 수 있는 여러 Azure 플랫폼 서비스가 있습니다.

  • Web Apps 및 WebJobs: App Service WebJobs 기능을 사용하여 웹앱에서 실행할 수 있는 다양한 스크립트 또는 프로그램을 기반으로 하는 사용자 지정 작업을 실행합니다.

  • Azure Functions: 오랫동안 실행되지 않는 백그라운드 작업에 함수 앱을 사용합니다. 사용량이 부족한 App Service 계획에서 워크로드를 호스트하는 경우에도 함수 앱을 사용할 수 있습니다.

  • Virtual Machines: Windows 서비스가 있거나 Windows 작업 스케줄러를 사용하려는 경우 전용 VM에서 백그라운드 작업을 호스트합니다.

  • Azure Batch: Batch는 관리되는 VM 컬렉션에서 실행되도록 계산 집약적인 작업을 예약하는 데 사용할 수 있는 플랫폼 서비스입니다. 이 기능은 컴퓨팅 리소스 크기를 자동으로 조정할 수 있습니다.

  • AKS(Azure Kubernetes Service): AKS는 Azure의 Kubernetes에 대한 관리형 호스팅 환경을 제공합니다.

  • Azure Container Apps: Container Apps를 사용하면 컨테이너를 기반으로 하는 서버리스 마이크로 서비스를 빌드할 수 있습니다.

다음 섹션에서는 최상의 옵션을 선택하는 데 도움이 되는 각 옵션에 대한 고려 사항을 제공합니다.

Web Apps 및 WebJobs

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

WebJob을 구성하는 경우

  • 작업이 이벤트 기반 트리거에 응답하도록 하려면 지속적으로 실행하도록 구성합니다. 스크립트 또는 프로그램은 site/wwwroot/app_data/jobs/continuous라는 폴더에 저장됩니다.

  • 작업이 일정 기반 트리거에 응답하도록 하려면 일정에 따라 실행하도록 구성합니다. 스크립트 또는 프로그램은 site/wwwroot/app_data/jobs/triggered라는 폴더에 저장됩니다.

  • 작업을 구성할 때 요청 시 실행 옵션을 선택하면 작업을 시작할 때 일정에 따라 실행 옵션과 동일한 코드를 실행합니다.

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

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

  • 보안: 웹앱의 배포 자격 증명은 WebJobs에 대한 보호를 제공합니다.

  • 지원되는 파일 형식: 명령 스크립트(.cmd), 일괄 처리 파일(.bat), PowerShell 스크립트(.ps1), Bash 셸 스크립트(.sh), PHP 스크립트(.php), Python 스크립트(.py), JavaScript 코드(.js) 및 실행 프로그램(.exe 및 .jar)을 사용하여 WebJobs를 정의합니다.

  • 배포: Azure Portal, Visual Studio 또는 WebJobs SDK를 사용하여 스크립트 및 실행 파일을 배포하거나 다음 위치에 직접 복사할 수 있습니다.

    • 트리거된 배포의 경우: site/wwwroot/app_data/jobs/triggered/<job name>

    • 지속적인 배포의 경우: site/wwwroot/app_data/jobs/continuous/<job name>

  • 로그 파일: Console.Out 로 처리되거나 로 표시됩니다 INFO. Console.Error 는 로 ERROR처리됩니다. 포털을 사용하여 모니터링 및 진단 정보에 액세스합니다. 웹 사이트에서 직접 로그 파일을 다운로드합니다. 로그 파일은 다음 위치에 저장됩니다.

    • 트리거된 배포의 경우: Vfs/data/jobs/triggered/<job name>

    • 연속 배포의 경우: Vfs/data/jobs/continuous/<job name>

  • 구성: 포털, REST API 및 PowerShell을 사용하여 WebJobs를 구성합니다. WebJob 스크립트와 동일한 루트 디렉터리에 있는 settings.job이라는 구성 파일을 사용하여 WebJob에 대한 구성 정보를 제공합니다. 예를 들면 다음과 같습니다.

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

Web Apps 및 WebJobs 고려 사항

  • 기본적으로 WebJobs 웹앱을 통해 확장됩니다. 단일 instance 실행되도록 WebJobs를 구성하려면 구성 속성을 로 true설정합니다is_singleton. 단일 instance WebJobs는 다시 인덱싱 또는 데이터 분석과 같은 여러 인스턴스를 동시에 확장하거나 실행하지 않으려는 작업에 유용합니다.

  • WebJobs가 웹앱의 성능에 미치는 영향을 최소화하려면 장기 실행 또는 리소스 집약적 WebJobs를 호스트하는 새 App Service 계획에서 빈 웹앱 instance 만듭니다.

Azure Functions

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

Azure Functions 함수로 인해 예기치 않은 시간 초과가 발생할 수 있으므로 장기 실행되는 대규모 작업에는 권장되지 않습니다. 그러나 호스팅 계획에 따라 일정 기반 트리거에 함수를 사용하는 것이 좋습니다.

Azure Functions 고려 사항

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

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

전용 계획은 워크로드가 전용 계획에서 이미 실행되는 경우 백그라운드 작업에 적합합니다. 사용량이 부족한 VM이 있는 경우 동일한 VM에서 전용 계획을 실행하고 컴퓨팅 비용을 공유할 수 있습니다.

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

Virtual Machines

백그라운드 작업이 Web Apps 배포되지 않도록 구현할 수 있습니다. 예를 들어 Windows 서비스, 타사 유틸리티 또는 실행 프로그램을 사용하여 작업을 구현할 수 있습니다. 애플리케이션을 호스트하는 환경과 다른 런타임 환경에 대해 작성된 프로그램을 사용할 수도 있습니다. 예를 들어 Windows 또는 .NET 애플리케이션에서 실행하려는 Unix 또는 Linux 프로그램을 사용할 수 있습니다. Azure VM에 대한 여러 운영 체제 중에서 선택하고 해당 VM에서 서비스 또는 실행 파일을 실행합니다.

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

별도의 VM에서 백그라운드 작업을 시작하려면 다음을 수행할 수 있습니다.

  • 애플리케이션에서 직접 요청 시 작업을 실행하기 위해 태스크가 노출하는 엔드포인트에 요청을 보냅니다. 요청은 태스크에 필요한 데이터를 전송합니다. 엔드포인트는 작업을 호출합니다.

  • 선택한 운영 체제의 스케줄러 또는 타이머를 사용하여 일정에 따라 실행되도록 작업을 구성합니다. 예를 들어 Windows에서 Windows 작업 스케줄러를 사용하여 스크립트 및 작업을 실행할 수 있습니다. VM에 SQL Server 설치한 경우 SQL Server 에이전트 사용하여 스크립트 및 작업을 실행합니다.

  • Logic Apps를 사용하여 태스크가 모니터링하는 큐에 메시지를 추가하거나 태스크가 노출하는 API에 요청을 전송하여 작업을 시작합니다.

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

Virtual Machines 고려 사항

Azure VM에서 백그라운드 작업을 배포할 때 다음 사항을 고려합니다.

  • 별도의 Azure VM에서 백그라운드 작업을 호스트하여 시작, 배포, 일정 및 리소스 할당에 대한 유연성과 정확한 제어를 제공합니다. 그러나 백그라운드 작업을 위해서만 VM을 배포하는 경우 런타임 비용이 증가합니다.

  • 포털에서 작업을 모니터링할 수 있는 기능이 없으며 실패한 작업에 대한 자동 다시 시작 기능이 없습니다. 그러나 Azure Resource Manager cmdlet을 사용하여 VM의 상태 모니터링하고 관리할 수 있습니다. 컴퓨팅 노드에서 프로세스 및 스레드를 제어할 수 있는 기능이 없습니다. 일반적으로 VM을 사용하는 경우 태스크의 계측 및 VM의 운영 체제에서 데이터를 수집하는 메커니즘을 구현해야 합니다. 이 목적을 위해 Azure용 System Center 관리 팩 을 사용할 수 있습니다.

  • HTTP 엔드포인트를 통해 노출되는 모니터링 프로브를 만드는 것이 좋습니다. 상태 검사를 수행하고 운영 정보 및 통계를 수집하도록 이러한 프로브에 대한 코드를 구성할 수 있습니다. 프로브를 사용하여 오류 정보를 수집하고 관리 애플리케이션에 반환할 수도 있습니다.

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

Batch

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

Batch를 사용하여 VM을 준비하고, VM에 작업을 할당하고, 작업을 실행하고, 진행 상황을 모니터링하고, 워크로드에 대한 응답으로 VM을 자동으로 스케일 아웃합니다. 또한 Batch는 작업 예약을 제공하고 Linux 및 Windows VM을 지원합니다.

일괄 처리 고려 사항

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

Batch 작업은 노드 또는 VM 풀에서 실행됩니다. 필요한 경우에만 풀을 할당한 다음 작업이 완료된 후에 삭제할 수 있습니다. 이 방법은 노드가 유휴 상태가 아니므로 사용률을 최대화하지만 작업은 노드를 할당할 때까지 기다려야 합니다. 또는 풀을 미리 만들 수 있습니다. 이 방법은 작업을 시작하는 데 걸리는 시간을 최소화하지만 노드가 유휴 상태가 될 수 있습니다.

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

Azure Kubernetes Service

AKS를 사용하여 컨테이너화된 애플리케이션을 쉽게 배포하고 관리할 수 있도록 호스트된 Kubernetes 환경을 관리합니다.

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

  • 컨테이너는 고밀도 호스팅을 지원합니다. 각 VM에 여러 컨테이너를 배치하면서, 백그라운드 작업을 하나의 컨테이너에 격리할 수 있습니다.

  • 컨테이너 오케스트레이터를 사용하여 내부 부하 분산을 수행하고, 내부 네트워크를 구성하고, 다른 구성 작업을 수행합니다.

  • 필요에 따라 컨테이너를 시작하고 중지할 수 있습니다.

  • Azure Container Registry 사용하면 Azure 경계 내에 컨테이너를 등록하여 보안, 개인 정보 보호 및 근접 이점을 제공할 수 있습니다.

AKS 고려 사항

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

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

컨테이너 앱

Container Apps를 사용하면 컨테이너를 기반으로 하는 서버리스 마이크로 서비스를 빌드할 수 있습니다. Container Apps:

  • 범용 컨테이너, 특히 컨테이너에 배포된 많은 마이크로 서비스에 걸쳐 있는 애플리케이션을 실행하기 위해 최적화됩니다.

  • Kubernetes 및 Dapr, Kubernetes KEDA(이벤트 기반 자동 크기 조정) 및 Envoy와 같은 오픈 소스 기술로 구동됩니다.

  • 서비스 검색 및 트래픽 분할과 같은 기능을 통해 Kubernetes 스타일 앱 및 마이크로 서비스를 지원합니다.

  • 트래픽을 기반으로 하는 크기 조정을 지원하고 크기 조정을 0으로 포함하여 큐와 같은 이벤트 원본에서 끌어와 이벤트 기반 애플리케이션 아키텍처를 사용하도록 설정합니다.

  • 장기 실행 프로세스를 지원하고 백그라운드 작업을 실행할 수 있습니다.

Container Apps 고려 사항

Container Apps는 기본 Kubernetes API에 대한 직접 액세스를 제공하지 않습니다. Kubernetes API 및 컨트롤 플레인에 액세스해야 하는 경우 AKS를 사용합니다. Kubernetes 스타일 애플리케이션을 빌드하려는데 네이티브 Kubernetes API 및 클러스터 관리에 직접 액세스할 필요가 없는 경우 완전히 관리되는 환경을 위해 Container Apps를 사용합니다. Container Apps는 컨테이너 마이크로 서비스를 빌드하는 데 가장 적합합니다.

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

안정성 검사 목록

전체 권장 사항 집합을 참조하세요.

안정성 검사 목록