이제 이 워크로드와 관련된 AWS와 Azure 간의 몇 가지 주요 플랫폼 차이점을 이해했으므로 워크플로 아키텍처를 살펴보고 AKS에서 작동하도록 변경할 수 있습니다.
AWS 워크로드 아키텍처
AWS 워크로드는 경쟁 소비자 디자인 패턴의 기본 예입니다. AWS 구현은 Kubernetes, KEDA(Kubernetes 이벤트 기반 자동 크기 조정) 및 Karpenter를 사용하여 이벤트 중심 워크플로의 규모와 비용을 관리하기 위한 참조 아키텍처입니다.
생산자 앱은 큐에 메시지를 보내 로드를 생성하고, Kubernetes Pod에서 실행되는 소비자 앱은 메시지를 처리하고 결과를 데이터베이스에 기록합니다. KEDA는 생산자 큐에 대한 선언적 바인딩을 통해 Pod 자동 크기 조정을 관리하고, Karpenter는 비용을 최적화하기에 충분한 컴퓨팅으로 노드 자동 크기 조정을 관리합니다. 큐 및 데이터베이스에 대한 인증은 OAuth 기반 서비스 계정 토큰 볼륨 프로젝션을 사용합니다.
워크로드는 소비자가 Amazon SQS(Simple Queue Service)에서 메시지를 읽고 처리된 메시지를 Amazon DynamoDB 테이블에 저장하도록 오케스트레이션하는 AWS EKS 클러스터로 구성됩니다. 생산자 앱은 메시지를 생성하여 Amazon SQS 큐에 추가합니다. KEDA와 Karpenter는 소비자에게 사용되는 EKS 노드 및 Pod 수를 동적으로 크기 조정합니다.
다음 다이어그램은 AWS의 EDW 워크로드 아키텍처를 나타냅니다.
AWS 서비스를 Azure 서비스에 매핑
최소 변경으로 Azure에서 AWS 워크로드를 다시 만들려면 각 AWS 서비스에 대해 동등한 Azure를 사용하고 인증 방법을 원본과 비슷하게 유지합니다. 이 예에는 Azure Service Bus 또는 Azure Event Hubs의 유용한 기능이 필요하지 않습니다. 대신 Azure Queue Storage를 사용하여 작업을 큐에 추가하고 Azure Table Storage를 사용하여 결과를 저장할 수 있습니다.
다음 표에는 서비스 매핑이 요약되어 있습니다.
| 서비스 매핑 | AWS 서비스 | Azure 서비스 |
|---|---|---|
| 대기 중 | Simple Queue Service | Azure Queue Storage |
| 지속성 | DynamoDB(SQL 없음) | Azure Table Storage |
| 오케스트레이션 | EKS(Elastic Kubernetes Service) | AKS(Azure Kubernetes Service) |
| ID | AWS IAM | Microsoft Entra |
Azure 워크로드 아키텍처
다음 다이어그램은 AWS-Azure 서비스 매핑을 사용하는 Azure EDW 워크로드의 아키텍처를 나타냅니다.
컴퓨팅 옵션
비용 고려 사항과 가능한 노드 제거에 대한 복원력에 따라 다양한 형식의 컴퓨팅 중에서 선택할 수 있습니다.
AWS에서는 주문형 컴퓨팅(비용이 높지만 제거 위험 없음) 또는 스폿 인스턴스(비용이 낮지만 제거 위험 있음) 중에서 선택할 수 있습니다. AKS에서는 워크로드 요구 사항에 따라 주문형 노드 풀 또는 스폿 노드 풀을 선택할 수 있습니다.
다음 단계
참가자
Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 원래 그것을 썼다:
- Ken Kilty | 수석 TPM
- Russell de Pina | 수석 TPM
- Jenny Hayes | 선임 콘텐츠 개발자
- Carol Smith | 선임 콘텐츠 개발자
- Erin Schaffer | 콘텐츠 개발자 2