이 아키텍처의 핵심 구성 요소는 클라이언트 요청을 처리하는 웹 프런트 엔드와 리소스 집약적 작업, 장기 실행 워크플로 또는 일괄 처리 작업을 수행하는 작업자입니다. 웹 프런트 엔드는 메시지 큐를 통해 작업자와 통신합니다.
이 아키텍처에 공통적으로 통합되는 기타 구성 요소는 다음과 같습니다.
- 하나 이상의 데이터베이스
- 빠른 읽기를 위해 데이터베이스의 값을 저장하는 캐시
- 정적 콘텐츠를 제공하기 위한 CDN
- 원격 서비스(예: 전자 메일 또는 SMS 서비스) 종종 이러한 기능은 타사에서 제공합니다.
- 인증을 위한 ID 공급자
웹 및 작업자는 둘 다 상태 비저장입니다. 세션 상태는 분산된 캐시에 저장할 수 있습니다. 모든 장기 실행 작업은 작업자에 의해 비동기적으로 수행됩니다. 작업자는 큐의 메시지에 의해 트리거되거나, 일괄 처리 일정에 따라 실행될 수 있습니다. 작업자는 선택적 구성 요소입니다. 장기 실행 작업이 없는 경우 작업자를 생략할 수 있습니다.
프런트 엔드는 웹 API로 구성될 수 있습니다. 클라이언트 쪽에서 웹 API는 AJAX 호출을 하는 단일 페이지 애플리케이션 또는 네이티브 클라이언트 애플리케이션에서 사용될 수 있습니다.
이 아키텍처를 사용하는 경우
일반적으로 웹 큐 작업자 아키텍처는 관리되는 컴퓨팅 서비스(Azure App Service 또는 Azure Cloud Services)를 사용하여 구현됩니다.
다음과 같은 경우 이 아키텍처 스타일을 고려합니다.
- 비교적 간단한 도메인이 있는 애플리케이션
- 장기 실행 워크플로 또는 일괄 처리 작업을 일부 포함하는 애플리케이션
- IaaS(Infrastructure as a Service)가 아닌 관리되는 서비스를 사용하려는 경우
이점
- 이해하기 쉬운 비교적 간단한 아키텍처입니다.
- 쉽게 배포 및 관리할 수 있습니다.
- 문제가 명확히 구분됩니다.
- 프런트 엔드는 비동기 메시징을 사용하여 작업자에서 분리됩니다.
- 프런트 엔드 및 작업자 크기는 독립적으로 조정됩니다.
과제
- 주의깊게 디자인하지 않으면 프런트 엔드 및 작업자가 유지 관리 및 업데이트가 어려운 한 덩어리의 커다란 구성 요소로 변할 수 있습니다.
- 프런트 엔드 및 작업자가 데이터 스키마 또는 코드 모듈을 공유하는 경우 숨겨진 종속성이 있을 수 있습니다.
- 웹 프런트 엔드는 데이터베이스에 성공적으로 유지된 후 큐에 메시지를 내보내기 전에 오작동할 수 있습니다. 이로 인해 작업자가 논리의 해당 부분을 수행하지 않으므로 일관성 문제가 발생할 수 있습니다. 트랜잭션 아웃박스 패턴과 같은 기술을 사용하여 이 문제를 완화할 수 있지만, 나가는 메시지의 라우팅을 먼저 별도의 큐를 통해 "루프백"으로 변경해야 합니다. 이 기술에 대한 지원을 제공하는 라이브러리 중 하나는 NServiceBus 트랜잭션 세션입니다.
모범 사례
- 클라이언트에 잘 디자인된 API를 노출합니다. API 디자인 모범 사례를 참조하세요.
- 부하 변경을 처리하도록 자동으로 크기가 조정됩니다. 자동 크기 조정 모범 사례를 참조하세요.
- 반정적 데이터를 캐시합니다. 캐싱 모범 사례를 참조하세요.
- CDN을 사용하여 정적 콘텐츠를 호스트합니다. CDN 모범 사례를 참조하세요.
- 적절한 경우 polyglot 지속성을 사용합니다. [작업에 가장 적합한 데이터 저장소 사용][polyglot]을 참조하세요.
- 데이터를 분할하여 확장성을 향상시키고 경합을 줄여 성능을 최적화합니다. 데이터 분할 모범 사례를 참조하세요.
Azure App Service의 웹 큐 작업자
이 섹션에서는 Azure App Service를 사용하는 권장 웹 큐 작업자 아키텍처에 대해 설명합니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
워크플로
프런트 엔드는 Azure App Service 웹앱으로 구현되고, 작업자는 Azure Functions 앱으로 구현됩니다. 웹앱과 함수 앱은 둘 다 VM 인스턴스를 제공하는 App Service 요금제에 연결되어 있습니다.
메시지 큐에 대해 Azure Service Bus 또는 Azure Storage 큐를 사용할 수 있습니다. (이 다이어그램은 Azure Storage 큐를 보여 줍니다.)
Azure Cache for Redis는 낮은 대기 시간 액세스가 필요한 기타 데이터 및 세션 상태를 저장합니다.
Azure CDN은 이미지, CSS 또는 HTML과 같은 정적 콘텐츠를 캐시하는 데 사용됩니다.
스토리지의 경우, 애플리케이션의 요구에 가장 잘 맞는 스토리지 기술을 선택합니다. 여러 스토리지 기술(polyglot 지속성)을 사용할 수 있습니다. 이 아이디어를 설명하기 위해 이 다이어그램은 Azure SQL Database 및 Azure Cosmos DB를 보여 줍니다.
자세한 내용은 App Service 웹 애플리케이션 참조 아키텍처와 NServiceBus 및 Azure Service Bus로 메시지 기반 비즈니스 애플리케이션을 빌드하는 방법을 참조하세요.
기타 고려 사항
모든 트랜잭션이 큐 및 작업자를 거쳐 스토리지로 이동해야 하는 것은 아닙니다. 웹 프런트 엔드는 간단한 읽기/쓰기 작업을 직접 수행할 수 있습니다. 작업자는 리소스 집약적인 작업 또는 장기 실행 워크플로를 위해 디자인되었습니다. 경우에 따라 작업자가 전혀 필요하지 않을 수도 있습니다.
App Service의 기본 제공 자동 크기 조정 기능을 사용하여 VM 인스턴스 수를 스케일 아웃합니다. 애플리케이션의 부하가 예측 가능한 패턴을 따를 경우 일정 기반 자동 크기 조정을 사용합니다. 부하를 예측할 수 없는 경우 메트릭 기반 자동 크기 조정 규칙을 사용합니다.
웹앱 및 함수 앱을 별도의 App Service 요금제에 포함하는 것이 좋습니다. 이러한 방식으로 독립적으로 확장할 수 있습니다.
프로덕션 및 테스트에 대해 별도 App Service 계획을 사용합니다. 그렇지 않고 프로덕션 및 테스트에 동일한 계획을 사용하는 것은 프로덕션 VM에서 테스트를 실행하는 것을 의미합니다.
배포 슬롯을 사용하여 배포를 관리합니다. 이 방법을 사용하면 업데이트된 버전을 스테이징 슬롯에 배포한 다음, 새 버전으로 교체할 수 있습니다. 또한 업데이트에 문제가 발생하면 이전 버전으로 다시 교체할 수 있습니다.