Azure Container Apps 및 Dapr을 사용하여 마이크로 서비스 배포
이 문서에서는 Azure Container Apps에서 10개의 마이크로 서비스가 있는 주문 관리 시스템을 실행하기 위한 솔루션을 설명합니다. 또한 이 솔루션은 Dapr(분산 애플리케이션 런타임) 및 Kubernetes KEDA(이벤트 기반 자동 크기 조정)를 사용한 이벤트 기반 크기 조정을 통해 마이크로 서비스 모범 사례를 사용합니다.
Dapr 및 Traefik은 해당 회사의 상표입니다. 이러한 상표를 사용한다고 해서 어떠한 보증도 암시되지 않습니다.
아키텍처
이 아키텍처의 PowerPoint 파일을 다운로드합니다.
데이터 흐름
이 솔루션은 가상의 Red Dog 주문 관리 시스템과 지원되는 Azure 인프라를 설명합니다. 아키텍처는 10개의 .NET Core 마이크로 서비스 애플리케이션을 호스트하는 단일 Container Apps 환경으로 구성됩니다. 이 솔루션은 Dapr SDK를 사용하여 게시-구독, 상태 및 바인딩 구성 요소를 통해 Azure 리소스와 통합합니다. 또한 이 서비스는 KEDA 크기 조정 규칙을 사용하여 이벤트 트리거 및 0으로 확장 시나리오를 기반으로 크기 조정을 허용합니다.
다음 데이터 흐름은 이전 다이어그램에 해당합니다.
Traefik: 사용자 요청을 UI에서 대화형 대시보드에 대한 회계 및 Makeline 서비스로 라우팅하는 기본 프록시입니다.
UI: Red Dog 주문 관리 시스템에 대한 실시간 주문 및 집계된 판매 데이터를 보여 주는 대시보드입니다.
가상 고객: 주문 서비스를 통해 주문하는 고객을 시뮬레이션하는 고객 시뮬레이션 프로그램입니다.
주문 서비스: 주문을 배치하고 관리하기 위한 만들기, 읽기, 업데이트 및 삭제 API입니다.
회계 서비스: 주문 데이터를 처리, 저장 및 집계하는 서비스입니다. 고객 주문을 UI에서 보여 주는 의미 있는 판매 메트릭으로 변환합니다.
영수증 서비스: 감사 및 기록 목적으로 주문 영수증을 생성하고 저장하는 보관 프로그램입니다.
로열티 서비스: 주문 지출을 기반으로 고객 보상 포인트를 추적하여 로열티 프로그램을 관리하는 서비스입니다.
Makeline 서비스: 이행되기를 기다리는 현재 주문의 큐를 관리하는 서비스입니다. 가상 작업자 서비스에 의한 주문 처리 및 완료를 추적합니다.
가상 작업자: 고객 주문 완료를 시뮬레이션하는 작업자 시뮬레이션 프로그램입니다.
| 서비스 | 수신 | Dapr 구성 요소 | KEDA 크기 조정 규칙 |
|---|---|---|---|
| Traefik | 외부 | Dapr을 사용할 수 없음 | HTTP(HTTP) |
| 사용자 인터페이스 (UI) | 내부 | Dapr을 사용할 수 없음 | HTTP(HTTP) |
| 가상 고객 | 없음 | 서비스 대 서비스 호출 | 해당 없음 |
| 주문 서비스 | 내부 | 게시-구독: Azure Service Bus | HTTP(HTTP) |
| 회계 서비스 | 내부 | 게시-구독: Service Bus | Service Bus 토픽 길이, HTTP |
| 영수증 서비스 | 내부 | 게시-구독: Service Bus 바인딩: Azure Blob Storage |
Service Bus 토픽 길이 |
| 로열티 서비스 | 내부 | 게시-구독: Service Bus 상태: Azure Cosmos DB |
Service Bus 토픽 길이 |
| Makeline 서비스 | 내부 | 게시-구독: Service Bus 상태: Azure Cache for Redis |
Service Bus 토픽 길이, HTTP |
| 가상 작업자 | 없음 | 서비스 대 서비스 호출 바인딩: Cron |
해당 없음 |
참고
컨테이너 앱에서 부트스트랩을 구현할 수도 있습니다. 그러나 이 서비스는 데이터베이스 만들기를 수행하기 위해 한 번 실행한 다음, Azure SQL Database에서 필요한 개체를 만든 후 0으로 확장합니다.
구성 요소
Application Insights 는 라이브 애플리케이션을 모니터링하고 성능 이상을 자동으로 검색하는 데 사용할 수 있는 확장 가능한 애플리케이션 성능 관리 서비스입니다. 이 아키텍처에서는 Azure Monitor에서 Application Insights를 사용하여 컨테이너 로그를 보고 마이크로 서비스에서 메트릭을 수집합니다.
Blob Storage 는 텍스트 또는 이진 파일과 같은 대량의 구조화되지 않은 데이터를 저장하기 위한 클라우드 기반 솔루션입니다. 이 아키텍처에서 영수증 서비스는 Dapr 출력 바인딩을 통해 Blob Storage를 사용하여 주문 영수증을 저장합니다.
Azure Cache for Redis는 확장 가능한 메모리 내 분산 관리 Redis Cache입니다. 이 아키텍처에서는 Makeline 서비스가 처리 중인 주문에 데이터를 저장하는 데 Dapr 상태 저장소 구성 요소로 사용됩니다.
Azure Cosmos DB 는 NoSQL, 다중 모델 관리형 데이터베이스 서비스입니다. 이 아키텍처에서는 고객의 충성도 데이터를 저장하는 로열티 서비스에 대한 Dapr 상태 저장소 구성 요소로 사용됩니다.
Azure Monitor는 Azure 인프라 환경에서 고객 콘텐츠 데이터를 수집, 분석 및 수행할 수 있는 통합 플랫폼입니다. 이 아키텍처에서는 Application Insights 와 함께 Azure Monitor를 사용하여 컨테이너 로그를 보고 마이크로 서비스에서 메트릭을 수집합니다.
Service Bus 는 큐 및 게시-구독 토픽이 있는 완전 관리형 엔터프라이즈 메시지 브로커입니다. 이 아키텍처에서는 Dapr 게시-구독 구성 요소 구현에 Service Bus를 사용합니다. 여러 서비스에서 이 구성 요소를 사용합니다. 주문 서비스는 버스에 메시지를 게시하고 Makeline, 회계, 로열티 및 영수증 서비스는 이러한 메시지를 구독합니다.
Container Apps 는 대규모로 최신 앱을 빌드하고 배포하는 데 사용되는 완전 관리형 서버리스 컨테이너 서비스입니다. 이 아키텍처에서는 Container Apps에서 10개의 마이크로 서비스를 모두 호스트하고 단일 Container Apps 환경에 배포합니다. 이 환경은 시스템 주변의 보안 경계 역할을 합니다.
SQL Database 는 클라우드용으로 빌드된 지능적이고 확장 가능한 관계형 데이터베이스 서비스입니다. 이 아키텍처에서는 Entity Framework Core 를 사용하여 데이터베이스와 인터페이스하는 회계 서비스의 데이터 저장소 역할을 합니다. 부트스트래퍼 서비스는 데이터베이스에서 SQL 테이블을 설정하는 역할을 담당합니다. 그런 다음 회계 서비스에 대한 연결을 설정하기 전에 한 번 실행됩니다.
Traefik는 마이크로 서비스를 쉽게 배포할 수 있게 해주는 선도적인 최신 역방향 프록시 및 부하 분산 장치입니다. 이 아키텍처에서는 Traefik의 동적 구성 기능을 사용하여 Vue.js 단일 페이지 애플리케이션인 UI에서 경로 기반 라우팅을 수행합니다. 또한 이 구성을 사용하면 테스트를 위해 백 엔드 서비스에 대한 직접 API 호출을 사용할 수 있습니다.
대안
이 아키텍처에서는 Traefik 프록시를 배포하여 Vue.js API에 대한 경로 기반 라우팅을 사용하도록 설정합니다. 이 용도로 사용할 수 있는 대체 오픈 소스 프록시가 많이 있습니다. 다른 두 가지 일반적인 프로젝트는 NGINX 및 HAProxy입니다.
SQL Database를 제외한 모든 Azure 인프라는 상호 운용성을 위해 Dapr 구성 요소를 사용합니다. Dapr의 한 가지 이점은 Container Apps 배포 구성을 변경하여 이러한 모든 구성 요소를 교환할 수 있다는 것입니다. 이 시나리오에서는 Service Bus, Azure Cosmos DB, Azure Cache for Redis 및 Blob Storage에서 사용 가능한 70개 이상의 Dapr 구성 요소 중 일부를 보여 줍니다. 대체 게시-구독 브로커, 상태 저장소 및 출력 바인딩 목록은 Dapr 문서에서 사용할 수 있습니다.
시나리오 정보
마이크로 서비스는 널리 채택된 아키텍처 스타일입니다. 확장성, 민첩성 및 독립적인 배포와 같은 이점을 제공합니다. 컨테이너를 메커니즘으로 사용하여 마이크로 서비스 애플리케이션을 배포한 다음 Kubernetes와 같은 컨테이너 오케스트레이터를 사용하여 작업을 단순화할 수 있습니다. 대규모 마이크로 서비스 아키텍처에는 여러 가지 요소를 고려해야 합니다. 일반적으로 인프라 플랫폼은 컨테이너 오케스트레이터와 같은 복잡한 기술을 잘 이해해야 합니다.
Container Apps 는 대규모로 최신 애플리케이션을 실행하기 위한 완전 관리형 서버리스 컨테이너 서비스입니다. 이를 통해 기본 플랫폼의 추상화를 통해 컨테이너화된 앱을 배포할 수 있습니다. 이 방법을 사용하면 복잡한 인프라를 관리할 필요가 없습니다.
이 아키텍처는 관리되는 버전의 Dapr과 Container Apps 통합을 사용합니다. Dapr은 개발자가 상태 관리 및 서비스 호출과 같은 분산 애플리케이션의 내재된 문제를 극복하는 데 도움이 되는 오픈 소스 프로젝트입니다.
Container Apps는 관리되는 버전의 KEDA도 제공합니다. KEDA를 사용하면 Service Bus 및 Azure Cache for Redis와 같은 외부 서비스에서 들어오는 이벤트에 따라 컨테이너 크기를 자동으로 조정할 수 있습니다.
더 많은 Azure 네트워킹 리소스를 만들지 않고 Container Apps에서 HTTPS 수신을 사용하도록 설정할 수도 있습니다. 트래픽 분할 시나리오도 허용하는 Envoy 프록시를 사용할 수 있습니다.
자세한 내용은 다른 Azure 컨테이너 옵션과 Container Apps 비교를 참조하세요.
이 문서에서는 Container Apps에서 10개의 마이크로 서비스가 있는 주문 관리 시스템을 실행하기 위한 솔루션을 설명합니다. 이 솔루션은 또한 Dapr을 통한 마이크로 서비스 모범 사례와 KEDA를 통한 이벤트 기반 확장을 사용합니다.
잠재적인 사용 사례
이 솔루션은 분산 시스템에 상태 비저장 및 상태 저장 마이크로 서비스를 사용하는 모든 조직에 적용됩니다. 이 솔루션은 주문 및 이행 시스템을 갖춘 소비자 패키지 상품 및 제조 업계에 가장 적합합니다.
다음 솔루션에는 유사한 디자인이 있습니다.
- AKS(Azure Kubernetes Service)의 마이크로 서비스 아키텍처
- Azure Functions의 마이크로 서비스 아키텍처
- 이벤트 기반 아키텍처
고려 사항
이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일련의 기본 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Well-Architected Framework를 참조하세요.
안정성
안정성은 애플리케이션이 고객에 대한 약정을 충족할 수 있도록 하는 데 도움이 됩니다. 자세한 내용은 안정성대한
Container Apps는 기본 인프라로 작동하는 Kubernetes 기반을 기반으로 합니다. 복원력 메커니즘은 문제가 있는 경우 컨테이너 또는 Pod를 모니터링하고 다시 시작하는 Kubernetes에 기본 제공됩니다. 복원력 메커니즘에는 각 컨테이너 앱의 여러 복제본에 트래픽을 분산하는 기본 제공 부하 분산 장치가 포함됩니다. 이러한 중복성을 통해 하나의 복제본을 사용할 수 없게 되더라도 시스템이 계속 작동할 수 있습니다.
안전
보안은 의도적인 공격 및 중요한 데이터 및 시스템의 오용에 대한 보증을 제공합니다. 자세한 내용은 보안성에 대한 디자인 검토 검사 목록을 참조하세요.
다음 목록에서는 다른 권장 사항 및 고려 사항과 함께 이 아키텍처에서 생략된 몇 가지 보안 기능을 간략하게 설명합니다.
이 아키텍처는 프라이빗 엔드포인트를 사용하지 않으므로 가상 네트워크에서 IP 주소를 할당하여 Azure 서비스에 대한 보다 안전하고 프라이빗 연결을 허용합니다. 프라이빗 엔드포인트를 사용하는 경우 공용 네트워크 액세스를 사용하지 않도록 설정할 수 있습니다. 이 방법은 Microsoft 백본에서 트래픽을 유지하고 보안 및 규정 준수를 향상시킵니다.
네트워크 활동을 지속적으로 모니터링하여 남용을 감지하고 방지해야 합니다. Azure Firewall 및 경로 테이블을 사용하여 이 방법을 달성할 수 있습니다. 경로 테이블을 사용하면 가상 네트워크를 벗어나는 트래픽이 먼저 방화벽을 통해 전달될 수 있습니다. 이 프로세스는 아키텍처가 데이터 반출 공격에 취약하지 않도록 하는 중요한 단계입니다.
WAF(웹 애플리케이션 방화벽)를 사용하여 일반적인 취약성으로부터 보호합니다. Azure Front Door 또는 Azure Application Gateway를 사용하여 이 아키텍처에서 WAF를 구현 합니다.
간편한 인증이라고 하는 Container Apps에 대한 기본 제공 인증 및 권한 부여 기능을 사용하는 것이 좋습니다. 간편한 인증은 ID 공급자를 웹앱에 통합하는 프로세스를 간소화합니다. 웹앱 외부에서 인증을 처리하므로 중요한 코드를 변경할 필요가 없습니다.
워크로드 ID에 관리 ID를 사용합니다. 관리 ID를 통해 개발자는 이러한 인증 자격 증명을 관리할 필요가 없습니다. 예를 들어 기본 아키텍처는 연결 문자열의 암호를 통해 SQL Server에 인증합니다. 가능하면 Microsoft Entra ID를 사용하여 Azure SQL Server에 인증합니다.
비용 최적화
비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 개선하는 방법에 중점을 둡니다. 자세한 내용은 비용 최적화대한
이 아키텍처의 서비스 비용을 예상하려면 Azure 가격 책정 계산기를 사용합니다.
운영 효율성
운영 우수성은 애플리케이션을 배포하고 프로덕션에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 Operational Excellence에 대한 디자인 검토 검사 목록을 참조하세요.
Azure Monitor 및 Application Insights를 사용하여 Container Apps를 모니터링할 수 있습니다. 포털에서 각 컨테이너 앱의 로그 창으로 이동한 다음, 다음 Kusto 쿼리를 실행하여 컨테이너 로그 를 볼 수 있습니다. 이 예는 Makeline 서비스 앱에 대한 로그를 보여 줍니다.
ContainerAppConsoleLogs_CL |
where ContainerAppName_s contains "make-line-service" |
project TimeGenerated, _timestamp_d, ContainerGroupName_s, Log_s |
order by _timestamp_d asc
Application Insights의 애플리케이션 맵은 서비스가 실시간으로 통신하는 방법도 보여 줍니다. 그런 다음 디버깅 시나리오에 사용할 수 있습니다. Application Insights 리소스 아래의 애플리케이션 맵으로 이동하여 다음 맵과 같은 항목을 봅니다.
자세한 내용은 Container Apps에서 앱 모니터링을 참조하세요.
성능 효율성
성능 효율성은 사용자 요구를 효율적으로 충족하기 위해 워크로드의 크기를 조정하는 기능을 의미합니다. 자세한 내용은 성능 효율성대한
이 솔루션은 이벤트 기반 크기 조정을 위해 Container Apps의 KEDA 구현에 크게 의존합니다. 가상 고객 서비스를 배포하면 지속적으로 주문이 발생합니다. 이 크기 조정으로 인해 주문 서비스가 HTTP KEDA 스케일러를 통해 확장됩니다. 주문 서비스가 서비스 버스에 주문을 게시하면 서비스 버스 KEDA 배율 조정기가 회계, 영수증, Makeline 및 로열티 서비스를 스케일 업합니다. UI 및 Traefik Container Apps는 더 많은 사용자가 대시보드에 액세스함에 따라 앱이 크기 조정되도록 HTTP KEDA 배율 조정기도 구성합니다.
가상 고객이 실행되고 있지 않으면 이 솔루션의 모든 마이크로 서비스는 가상 작업자 및 Makeline 서비스를 제외하고 0으로 크기가 조정됩니다. 가상 작업자는 주문 이행을 지속적으로 확인하므로 규모가 축소되지 않습니다. 자세한 내용은 Container Apps에서 크기 조정 규칙 설정을 참조하세요.
참가자
Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.
보안 주체 작성자:
- Alice Gibbons | 클라우드 네이티브 글로벌 블랙 벨트
기타 기여자:
- Lynn Orrell | 주요 솔루션 전문가(GBB)
- Kendall Roden | 선임 프로그램 관리자
LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.