AZURE에 AWS EDW(이벤트 기반 워크플로) 워크로드 배포

이 문서에서는 AWS EDW 워크로드를 Azure에 배포합니다.

az login 명령을 사용하여 Azure에 로그인합니다.
```
az login
```
Azure 계정에 여러 구독이 있는 경우 올바른 구독을 선택해야 합니다. az account list 명령을 사용하여 구독의 이름과 ID를 나열합니다.
```
az account list --query "[].{id: id, name:name }" --output table
```
az account set 명령을 사용하여 특정 구독을 선택합니다.
```
az account set --subscription $subscriptionId
```

EDW 워크로드 배포 스크립트

deployment/environmentVariables.sh 파일의 환경 변수를 검토한 다음 deploy.sh의 deployment/infra/ 디렉터리에서 스크립트를 사용하여 Azure에 애플리케이션을 배포합니다.

스크립트는 먼저 모든 필수 구성 요소 도구가 설치되어 있는지 확인합니다. 그렇지 않으면 스크립트가 종료되고 누락된 필수 구성 요소를 알려주는 오류 메시지가 표시됩니다. 이 경우 필수 구성 요소를 검토하고 누락된 도구를 설치한 다음 스크립트를 다시 실행합니다. AKS용 노드 NAP(자동 프로비전) 기능 플래그를 Azure 구독에 등록해야 합니다. 아직 등록되지 않은 경우 스크립트는 Azure CLI 명령을 실행하여 기능 플래그를 등록합니다.

스크립트는 deploy.state 디렉터리에 있는 deployment 파일에 배포 상태를 기록합니다. 이 파일을 사용하여 앱을 배포할 때 환경 변수를 설정할 수 있습니다.

스크립트가 워크플로에 대한 인프라를 구성하기 위해 명령을 실행하면 각 명령이 성공적으로 실행되는지 확인합니다. 문제가 발생하면 오류 메시지가 표시되고 실행이 중지됩니다.

스크립트가 실행되면 로그를 표시합니다. 다음 명령을 사용하여 로그 정보 출력을 리디렉션하고 install.log 디렉터리의 logs 파일에 저장하여 로그를 유지할 수 있습니다.

mkdir ./logs
./deployment/infra/deploy.sh | tee ./logs/install.log

자세한 내용은 ./deployment/infra/deploy.sh의 스크립트를 참조하세요.

워크로드 리소스

배포 스크립트는 다음 Azure 리소스를 만듭니다.

Azure 리소스 그룹: 배포 스크립트에서 만든 리소스를 저장하는 Azure 리소스 그룹입니다.
Azure Storage 계정: 생산자 앱에서 메시지를 보내고 소비자 앱에서 읽는 큐와 소비자 앱이 처리된 메시지를 저장하는 테이블을 포함하는 Azure Storage 계정입니다.
Azure 컨테이너 레지스트리: 컨테이너 레지스트리는 리팩터링된 소비자 앱 코드를 배포하는 컨테이너에 대한 리포지토리를 제공합니다.
AKS(Azure Kubernetes Service) 클러스터: AKS 클러스터는 소비자 앱 컨테이너에 대한 Kubernetes 오케스트레이션을 제공하며 다음 기능을 사용하도록 설정합니다.
- NAP(노드 자동 프로비전): AKS에서 Karpenter 노드 자동 크기 조정기의 구현입니다.
- Kubernetes KEDA(이벤트 기반 자동 크기 조정): KEDA는 지정된 큐 깊이 임계값을 초과하는 것과 같은 이벤트에 따라 Pod 크기 조정을 사용하도록 설정합니다.
- 워크로드 ID: 향상된 보안을 위해 역할 기반 액세스 정책을 Pod ID에 연결할 수 있습니다.
- 연결된 Azure 컨테이너 레지스트리: 이 기능을 사용하면 AKS 클러스터가 지정된 ACR 인스턴스의 리포지토리에서 이미지를 끌어올 수 있습니다.
애플리케이션 및 시스템 노드 풀: 또한 스크립트는 애플리케이션 Pod가 시스템 노드 풀에서 예약되지 않도록 하는 테인트가 있는 AKS 클러스터에 애플리케이션 및 시스템 노드 풀을 만듭니다.
AKS 클러스터 관리 ID: 스크립트는 이 관리 ID에 acrPull 역할을 할당하여 이미지를 끌어와 연결된 Azure 컨테이너 레지스트리에 쉽게 액세스할 수 있도록 합니다.
워크로드 ID: 스크립트는 스토리지 큐 데이터 기여자 및 스토리지 테이블 데이터 기여자 역할을 할당하여 소비자 앱 컨테이너가 배포된 Pod의 ID로 사용되는 Kubernetes 서비스 계정과 연결된 이 관리 ID에 대한 RBAC(역할 기반 액세스 제어) 액세스를 제공합니다.
두 개의 페더레이션된 자격 증명: 한 자격 증명을 사용하면 관리 ID가 Pod ID를 구현할 수 있고, 다른 자격 증명은 KEDA 운영자 서비스 계정에 사용되어 Pod 자동 크기 조정을 제어하는 데 필요한 메트릭을 수집하기 위해 KEDA 스케일러에 대한 액세스를 제공합니다.

배포 유효성 검사 및 워크로드 실행

배포 스크립트가 완료되면 AKS 클러스터에 워크로드를 배포할 수 있습니다.

다음 명령을 사용하여 ./deployment/environmentVariables.sh 환경 변수를 수집하고 업데이트하기 위한 원본을 설정합니다.
```
source ./deployment/environmentVariables.sh
```

배포에서 만든 리소스의 이름에 대한 환경 변수를 설정하려면 ./deployment/deploy.state 파일의 정보가 필요합니다. 다음 cat 명령을 사용하여 파일의 내용을 표시합니다.

cat ./deployment/deploy.state

출력에는 다음 변수가 표시됩니다.

SUFFIX=
RESOURCE_GROUP=
AZURE_STORAGE_ACCOUNT_NAME=
AZURE_QUEUE_NAME=
AZURE_COSMOSDB_TABLE=
AZURE_CONTAINER_REGISTRY_NAME=
AKS_MANAGED_IDENTITY_NAME=
AKS_CLUSTER_NAME=
WORKLOAD_MANAGED_IDENTITY_NAME=
SERVICE_ACCOUNT=
FEDERATED_IDENTITY_CREDENTIAL_NAME=
KEDA_SERVICE_ACCT_CRED_NAME=

다음 명령을 사용하여 배포 스크립트에서 만든 Azure 리소스의 이름에 대한 파일을 읽고 환경 변수를 만듭니다.
```
while IFS= read -r; line do \
echo "export $line" \
export $line; \
done < ./deployment/deploy.state
```
az aks get-credentials 명령을 사용하여 AKS 클러스터 자격 증명을 가져옵니다.
```
az aks get-credentials --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER_NAME
```
kube-system 명령을 사용하여 AKS 클러스터의 kubectl get 네임스페이스에서 KEDA 연산자 Pod가 실행되고 있는지 확인합니다.
```
kubectl get pods --namespace kube-system | grep keda
```
출력은 다음 예제 출력과 비슷하게 표시됩니다.

시뮬레이션된 로드 생성

이제 생산자 앱을 사용하여 시뮬레이션된 부하를 생성하여 큐를 메시지로 채웁니다.

별도의 터미널 창에서 프로젝트 디렉터리로 이동합니다.
이전 섹션의 단계를 사용하여 환경 변수를 설정합니다. 1. 다음 명령을 사용하여 생산자 앱을 실행합니다.
```
python3 ./app/keda/aqs-producer.py
```
앱이 메시지 보내기를 시작하면 다른 터미널 창으로 다시 전환합니다.

다음 명령을 사용하여 AKS 클러스터에 소비자 앱 컨테이너를 배포합니다.

chmod +x ./deployment/keda/deploy-keda-app-workload-id.sh
./deployment/keda/deploy-keda-app-workload-id.sh

배포 스크립트(deploy-keda-app-workload-id.sh)는 애플리케이션 매니페스트 YAML 사양에 대한 템플릿을 수행하여 환경 변수를 Pod에 전달합니다. 이 스크립트에서 발췌한 다음을 검토합니다.

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: $AQS_TARGET_DEPLOYMENT
  namespace: $AQS_TARGET_NAMESPACE
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aqs-reader
  template:
    metadata:
      labels:
        app: aqs-reader
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: $SERVICE_ACCOUNT
      containers:
      - name: keda-queue-reader
        image: ${AZURE_CONTAINER_REGISTRY_NAME}.azurecr.io/aws2azure/aqs-consumer
        imagePullPolicy: Always
        env:
        - name: AZURE_QUEUE_NAME
          value: $AZURE_QUEUE_NAME
        - name: AZURE_STORAGE_ACCOUNT_NAME
          value: $AZURE_STORAGE_ACCOUNT_NAME
        - name: AZURE_TABLE_NAME
          value: $AZURE_TABLE_NAME
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
EOF

azure.workload.identity/use 섹션의 spec/template 레이블은 배포에 대한 Pod 템플릿입니다. 레이블을 true(으)로 설정하면 워크로드 ID를 사용하고 있음을 지정합니다. 포드의 serviceAccountName 사양에서 워크로드 ID와 연결할 Kubernetes 서비스 계정을 지정합니다. Pod 사양에는 프라이빗 리포지토리의 이미지에 대한 참조가 포함되어 있지만 지정된 imagePullSecret이(가) 없습니다.

kubectl get 명령을 사용하여 스크립트가 성공적으로 실행되었는지 확인합니다.
```
kubectl get pods --namespace $AQS_TARGET_NAMESPACE
```
출력에 단일 Pod가 표시됩니다.
Karpenter 노드 풀이 만들어졌는지 확인합니다. kubectl get nodepool 명령을 사용하여 이 작업을 수행합니다. 명령 응답은 다음과 같습니다.

kubectl describe nodepool 명령을 사용하여 기본 노드 풀이 Karpenter 노드 풀인지 확인합니다. 명령 응답에서 노드 풀이 Karpenter 노드 풀인지 확인할 수 있습니다. 다음과 유사한 결과가 표시됩니다.

k9s를 사용하여 Pod 및 노드에 대한 스케일 아웃 모니터링

다양한 도구를 사용하여 Azure Portal 및 k9s를 포함하여 AKS에 배포된 앱의 작업을 확인할 수 있습니다. k9s에 대한 자세한 내용은 k9s 개요를 참조하세요.

k9s 설치 개요에서 사용자 환경에 적합한 지침을 사용하여 AKS 클러스터에 k9s를 설치합니다.
두 개의 창을 생성하는데, 하나는 Pod 보기가 있고 다른 하나는 AQS_TARGET_NAMESPACE 환경 변수(기본값은 aqs-demo)에 지정한 네임스페이스의 노드 보기가 있는 창을 만들고 각 창에서 k9s를 시작합니다.

다음과 비슷한 내용이 표시됩니다.
소비자 앱 컨테이너가 AKS 클러스터에 설치되어 실행 중인지 확인한 후 ScaledObject을(를) 설치하고 크기 조정된 개체 설치 스크립트(keda-scaleobject-workload-id.sh)를 실행하여 Pod 자동 크기 조정에 KEDA에서 사용하는 인증을 트리거합니다. 다음 명령을 사용합니다.
```
chmod +x ./deployment/keda/keda-scaleobject-workload-id.sh
./deployment/keda/keda-scaleobject-workload-id.sh
```
또한 스크립트는 필요한 경우 환경 변수를 삽입하는 템플릿을 수행합니다. 이 스크립트에서 발췌한 다음을 검토합니다.
```
cat <<EOF | kubectl apply -f -
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: aws2az-queue-scaleobj
  namespace: ${AQS_TARGET_NAMESPACE}
spec:
  scaleTargetRef:
    name: ${AQS_TARGET_DEPLOYMENT}     #K8s deployement to target
  minReplicaCount: 0  # We don't want pods if the queue is empty nginx-deployment
  maxReplicaCount: 15 # We don't want to have more than 15 replicas
  pollingInterval: 30 # How frequently we should go for metrics (in seconds)
  cooldownPeriod:  10 # How many seconds should we wait for downscale
  triggers:
  - type: azure-queue
    authenticationRef:
      name: keda-az-credentials
    metadata:
      queueName: ${AZURE_QUEUE_NAME}
      accountName: ${AZURE_STORAGE_ACCOUNT_NAME}
      queueLength: '5'
      activationQueueLength: '20' # threshold for when the scaler is active
      cloud: AzurePublicCloud
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-az-credentials
  namespace: $AQS_TARGET_NAMESPACE
spec:
  podIdentity:
    provider: azure-workload
    identityId: '${workloadManagedIdentityClientId}'
EOF
```
매니페스트는 크기 조정된 개체가 인증에 Pod ID를 사용하고 있음을 KEDA에 지정하는 TriggerAuthentication 개체와 워크로드 ID로 사용되는 관리 ID를 참조하는 identityID 속성의 두 가지 리소스를 설명합니다.

크기 조정된 개체가 올바르게 설치되고 KEDA에서 크기 조정 임계값이 초과되었음을 감지하면 Pod 예약을 시작합니다. k9s를 사용하는 경우 다음과 같이 표시됩니다.

생산자가 충분한 메시지로 큐를 채우도록 허용하는 경우 KEDA는 제공할 노드보다 더 많은 Pod를 예약해야 할 수 있습니다. 이를 수용하기 위해 Karpenter가 시작되어 노드 예약을 시작합니다. k9s를 사용하는 경우 다음과 같이 표시됩니다.

이 두 이미지에서 이름이 포함된 노드 수가 aks-default 노드 수가 1개에서 3개로 증가했는지 확인합니다. 생산자 앱이 큐에 메시지를 배치하는 것을 중지하면 결국 소비자는 큐 깊이를 임계값 아래로 줄이고 KEDA와 Karpenter가 모두 확장됩니다. k9s를 사용하는 경우 다음과 같이 표시됩니다.
마지막으로 다음과 같이 kubectl get events 명령을 사용하여 Karpenter 자동 크기 조정 작업을 볼 수 있습니다.