다음을 통해 공유

웹Queue-Worker 아키텍처 스타일

Azure App Service

이 아키텍처의 핵심 구성 요소는 클라이언트 요청을 제공하는 웹 프런트 엔드 및 리소스 집약적 작업, 장기 실행 워크플로 또는 일괄 작업을 수행하는 작업자 입니다. 웹 프런트 엔드는 메시지 큐를 통해 작업자와 통신합니다.

웹Queue-Worker 아키텍처 스타일의 논리적 다이어그램

이 아키텍처에 일반적으로 통합되는 다른 구성 요소는 다음과 같습니다.

  • 하나 이상의 데이터베이스.
  • 빠른 읽기를 위해 데이터베이스의 값을 저장하는 캐시입니다.
  • 정적 콘텐츠를 제공하는 CDN
  • 원격 서비스(예: 이메일 또는 SMS 서비스) 이러한 기능은 종종 타사에서 제공합니다.
  • 인증을 위한 ID 공급자입니다.

웹과 작업자는 모두 상태 비 상태입니다. 세션 상태는 분산 캐시에 저장할 수 있습니다. 장기 실행 작업은 작업자가 비동기적으로 수행합니다. 작업자는 큐의 메시지에 의해 트리거되거나 일괄 처리 일정에 따라 실행할 수 있습니다. 작업자는 선택적 구성 요소입니다. 장기 실행 작업이 없으면 작업자를 생략할 수 있습니다.

프런트 엔드는 웹 API로 구성될 수 있습니다. 클라이언트 쪽에서는 AJAX를 호출하는 단일 페이지 애플리케이션 또는 네이티브 클라이언트 애플리케이션에서 웹 API를 사용할 수 있습니다.

이 아키텍처를 사용하는 경우

웹Queue-Worker 아키텍처는 일반적으로 관리형 컴퓨팅 서비스(Azure App Service 또는 Azure Cloud Services)를 사용하여 구현됩니다.

다음 아키텍처 스타일을 고려합니다.

  • 비교적 간단한 도메인을 사용하는 애플리케이션.
  • 일부 장기 실행 워크플로 또는 일괄 처리 작업이 있는 애플리케이션.
  • IaaS(Infrastructure as a Service) 대신 관리되는 서비스를 사용하려는 경우

혜택

  • 이해하기 쉬운 비교적 간단한 아키텍처입니다.
  • 쉽게 배포 및 관리할 수 있습니다.
  • 우려의 명확한 분리.
  • 프런트 엔드는 비동기 메시징을 사용하여 작업자에서 분리됩니다.
  • 프런트 엔드와 작업자는 독립적으로 크기를 조정할 수 있습니다.

과제들

  • 신중하게 설계하지 않으면 프런트 엔드와 작업자가 유지 관리 및 업데이트하기 어려운 대규모 모놀리식 구성 요소가 될 수 있습니다.
  • 프런트 엔드와 작업자가 데이터 스키마 또는 코드 모듈을 공유하는 경우 숨겨진 종속성이 있을 수 있습니다.
  • 웹 프런트 엔드는 데이터베이스에 성공적으로 유지된 후 큐에 메시지를 내보내기 전에 오작동할 수 있습니다. 이로 인해 작업자가 논리의 해당 부분을 수행하지 않으므로 일관성 문제가 발생할 수 있습니다. 트랜잭션 아웃박스 패턴과 같은 기술을 사용하여 이 문제를 완화할 수 있지만, 나가는 메시지의 라우팅을 먼저 별도의 큐를 통해 "루프백"으로 변경해야 합니다. 이 기술에 대한 지원을 제공하는 라이브러리 중 하나는 NServiceBus 트랜잭션 세션입니다.

모범 사례

Azure App Service의 웹Queue-Worker

이 섹션에서는 Azure App Service를 사용하는 권장 웹Queue-Worker 아키텍처에 대해 설명합니다.

웹Queue-Worker 아키텍처 스타일의 물리적 다이어그램

이 아키텍처의 Visio 파일을 다운로드합니다.

워크플로

  • 프런트 엔드는 Azure App Service 웹앱으로 구현되고 작업자는 Azure Functions 앱으로 구현됩니다. 웹앱과 함수 앱은 모두 VM 인스턴스를 제공하는 App Service 계획과 연결됩니다.

  • 메시지 큐에 Azure Service Bus 또는 Azure Storage 큐를 사용할 수 있습니다. (다이어그램은 Azure Storage 큐를 보여 줍니다.)

  • Azure Cache for Redis 는 짧은 대기 시간 액세스가 필요한 세션 상태 및 기타 데이터를 저장합니다.

  • Azure CDN 은 이미지, CSS 또는 HTML과 같은 정적 콘텐츠를 캐시하는 데 사용됩니다.

  • 스토리지의 경우 애플리케이션의 요구에 가장 적합한 스토리지 기술을 선택합니다. 여러 스토리지 기술(다각형 지속성)을 사용할 수 있습니다. 이 아이디어를 설명하기 위해 다이어그램은 Azure SQL Database 및 Azure Cosmos DB를 보여 줍니다.

자세한 내용은 App Service 웹 애플리케이션 참조 아키텍처 및 NServiceBus 및 Azure Service Bus를 사용하여 메시지 기반 비즈니스 애플리케이션을 빌드하는 방법을 참조하세요.

기타 고려 사항

  • 모든 트랜잭션이 큐와 작업자를 거쳐 스토리지로 이동해야 하는 것은 아닙니다. 웹 프런트 엔드는 간단한 읽기/쓰기 작업을 직접 수행할 수 있습니다. 작업자는 리소스 집약적 작업 또는 장기 실행 워크플로를 위해 설계되었습니다. 경우에 따라 작업자가 전혀 필요하지 않을 수 있습니다.

  • App Service의 기본 제공 자동 크기 조정 기능을 사용하여 VM 인스턴스 수를 확장합니다. 애플리케이션의 부하가 예측 가능한 패턴을 따르는 경우 일정 기반 자동 크기 조정을 사용합니다. 부하를 예측할 수 없는 경우 메트릭 기반 자동 크기 조정 규칙을 사용합니다.

  • 웹앱과 함수 앱을 별도의 App Service 계획에 배치하는 것이 좋습니다. 이렇게 하면 독립적으로 크기를 조정할 수 있습니다.

  • 프로덕션 및 테스트에 별도의 App Service 계획을 사용합니다. 그렇지 않으면 프로덕션 및 테스트에 동일한 계획을 사용하는 경우 테스트가 프로덕션 VM에서 실행되고 있음을 의미합니다.

  • 배포 슬롯을 사용하여 배포를 관리합니다. 이 메서드를 사용하면 업데이트된 버전을 스테이징 슬롯에 배포한 다음 새 버전으로 교체할 수 있습니다. 또한 업데이트에 문제가 있는 경우 이전 버전으로 다시 교환할 수 있습니다.