이 아키텍처의 핵심 구성 요소는 클라이언트 요청을 처리하는 웹 프런트 엔드 및 리소스 집약적 작업, 장기 실행 워크플로 또는 일괄 처리 작업을 수행하는 작업자 입니다. 웹 프런트 엔드는 메시지 큐를 통해 작업자와 통신합니다.
웹-큐-워커 아키텍처를 보여주는 논리적 다이어그램입니다.
다음 구성 요소는 일반적으로 이 아키텍처에 통합됩니다.
하나 이상의 데이터베이스
빠른 읽기를 위해 데이터베이스의 값을 저장하는 캐시
정적 콘텐츠를 제공하는 콘텐츠 배달 네트워크
Microsoft 이외의 서비스 공급자가 일반적으로 제공하는 이메일 또는 SMS(짧은 메시지 서비스)와 같은 원격 서비스
인증을 위한 ID 공급자
웹 및 작업자는 모두 상태 비 상태이며 세션 상태는 분산 캐시에 저장할 수 있습니다. 작업자는 장기 실행 작업을 비동기적으로 처리합니다. 큐의 메시지는 작업자를 시작하거나 일정에서 일괄 처리를 위해 실행할 수 있습니다. 애플리케이션에 장기 실행 작업이 없는 경우 작업자는 선택 사항입니다.
프런트 엔드에는 웹 API가 포함될 수 있습니다. 단일 페이지 애플리케이션은 AJAX 호출을 통해 웹 API를 사용하거나 네이티브 클라이언트 애플리케이션에서 직접 사용할 수 있습니다.
이 아키텍처를 사용하는 경우
웹-큐-워커 아키텍처는 일반적으로 관리형 컴퓨팅 서비스인 Azure App Service 또는 Azure Kubernetes Service를 사용하여 구현됩니다.
다음 사용 사례에 대해 이 아키텍처를 고려합니다.
비교적 간단한 도메인이 있는 애플리케이션
장기 실행 워크플로 또는 일괄 처리 작업이 있는 애플리케이션
IaaS(Infrastructure as a Service)보다 관리되는 서비스를 선호하는 시나리오
혜택
간단하고 따라하기 쉬운 아키텍처
최소한의 노력으로 배포 및 관리
책임의 명확한 분리
비동기 메시징을 통해 프런트 엔드 및 작업자 분리
프론트엔드 및 워커의 독립적인 스케일링
과제들
신중하게 설계하지 않으면 프런트 엔드와 작업자가 유지 관리 및 업데이트하기 어려운 큰 모놀리식 구성 요소가 될 수 있습니다.
프런트 엔드와 작업자가 데이터 스키마 또는 코드 모듈을 공유하는 경우 숨겨진 종속성이 있을 수 있습니다.
웹 프런트 엔드는 데이터베이스에 유지한 후 큐에 메시지를 보내기 전에 실패할 수 있으며, 이로 인해 작업자가 논리의 일부를 수행하지 않기 때문에 일관성 문제가 발생합니다. 이 문제를 완화하려면 나가는 메시지를 라우팅하여 먼저 별도의 큐로 되돌리는 트랜잭션 아웃박스 패턴과 같은 기술을 사용할 수 있습니다. NServiceBus 트랜잭션 세션 라이브러리는 이 기술을 지원합니다.
모범 사례
잘 디자인된 API를 클라이언트에 노출합니다. 자세한 내용은 API 디자인 모범 사례를 참조하세요.
부하 변경을 처리하도록 자동으로 크기를 조정합니다. 자세한 내용은 자동 크기 조정 모범 사례를 참조하세요.
반정적 데이터를 캐시합니다. 자세한 내용은 캐싱 모범 사례를 참조하세요.
콘텐츠 배달 네트워크를 사용하여 정적 콘텐츠를 호스트합니다. 자세한 내용은 콘텐츠 배달 네트워크 모범 사례를 참조하세요.
적절한 경우 폴리글롯 퍼시스턴스를 사용합니다. 자세한 내용은 데이터 모델 이해를 참조하세요.
데이터를 분할하여 확장성을 개선하고 경합을 줄이며 성능을 최적화합니다. 자세한 내용은 데이터 분할 모범 사례를 참조하세요.
App Service의 웹-큐-워커
이 섹션에서는 App Service를 사용하는 권장 웹-대기열-작업자 아키텍처을 소개합니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
워크플로
프런트 엔드는 App Service 웹앱으로 구현되고 작업자는 Azure Functions 앱으로 구현됩니다. 웹앱과 Functions 앱은 모두 VM(가상 머신) 인스턴스를 제공하는 App Service 계획과 연결됩니다.
메시지 큐에 Azure Service Bus 또는 Azure Storage 큐를 사용할 수 있습니다. 이전 다이어그램에서는 Storage 큐를 사용합니다.
Azure Managed Redis 는 짧은 대기 시간 액세스가 필요한 세션 상태 및 기타 데이터를 저장합니다.
Azure Content Delivery Network 는 이미지, CSS 또는 HTML과 같은 정적 콘텐츠를 캐시하는 데 사용됩니다.
스토리지의 경우 애플리케이션의 요구에 가장 적합한 기술을 선택합니다. 다각형 지속성이라고 하는 이 방법은 동일한 시스템의 여러 스토리지 기술을 사용하여 다양한 요구 사항을 충족합니다. 이 아이디어를 설명하기 위해 다이어그램은 Azure SQL Database 와 Azure Cosmos DB를 모두 보여 줍니다.
자세한 내용은 기본적인 고가용성 영역 중복 웹 애플리케이션 및 NServiceBus 및 Service Bus를 사용하여 메시지 기반 비즈니스 애플리케이션 빌드를 참조하세요.
기타 고려 사항
모든 트랜잭션이 큐와 작업자를 거쳐 스토리지로 이동해야 하는 것은 아닙니다. 웹 프런트 엔드는 간단한 읽기 및 쓰기 작업을 직접 수행할 수 있습니다. 작업자는 리소스 집약적 작업 또는 장기 실행 워크플로를 위해 설계되었습니다. 경우에 따라 작업자가 전혀 필요하지 않을 수 있습니다.
컴퓨팅 플랫폼의 기본 제공 자동 크기 조정 기능을 사용하여 인스턴스 수를 확장합니다. 애플리케이션의 부하가 예측 가능한 패턴을 따르는 경우 일정 기반 자동 크기 조정을 사용합니다. 부하를 예측할 수 없는 경우 메트릭 기반 자동 크기 조정을 사용합니다.
독립적으로 확장할 수 있도록 웹앱과 Functions 앱을 별도의 App Service 계획에 배치하는 것이 좋습니다.
프로덕션 및 테스트에 별도의 App Service 계획을 사용합니다.
배포 슬롯을 사용하여 배포를 관리합니다. 이 메서드를 사용하면 업데이트된 버전을 스테이징 슬롯에 배포한 다음 새 버전으로 교체할 수 있습니다. 또한 업데이트 중에 문제가 있는 경우 이전 버전으로 다시 교환할 수 있습니다.