Amazon Managed Service for Prometheus 메트릭을 활용해 KEDA로 쿠버네티스 워크로드 오토스케일링하기

Amazon Elastic Kubernetes Service (Amazon EKS) 에서 호스팅되는 애플리케이션의 인기가 높아짐에 따라 트래픽 및 로드 증가를 효율적으로 처리하는 것이 주요 과제가 되고 있습니다. 기존에는 인스턴스를 더 추가하여 애플리케이션을 수동으로 확장해야 했지만, 이러한 접근 방식은 시간이 많이 걸리고 비효율적이며 오버프로비저닝 혹은 언더프로비저닝이 발생하기 쉽습니다. 이보다 더 나은 해결책은 오토스케일링을 활용하여 실시간 수요 시그널을 기반으로 애플리케이션 인스턴스를 오토스케일링하는 것입니다. Kubernetes Event-driven Autoscaling (KEDA) 은 쿠버네티스를 위한 오토스케일링 툴입니다. KEDA를 사용하면 메트릭, 이벤트 및 대기열, 데이터베이스 또는 모니터링 시스템과 같은 소스를 활용한 커스텀 시작 옵션을 기반으로 워크로드를 확장할 수 있습니다. 이를 통해 할당된 리소스를 애플리케이션 로드 요구 사항에 정확히 일치시킬 수 있습니다.

Amazon Managed Service for Prometheus는 주요 메트릭이 안전하게 저장되는 Amazon EKS 클러스터를 위한 Prometheus 호환 메트릭 모니터링 솔루션을 제공합니다. Amazon Managed Service for Prometheus를 활용하고 일부 애플리케이션 및 비즈니스 메트릭을 공개하여 KEDA 오토스케일링 결정을 내릴 수 있습니다. 이 블로그 포스팅에서는 KEDA 및 Amazon EKS의 Amazon Managed Service for Prometheus를 사용한 오토스케일링 방법을 소개합니다. Amazon Managed Service for Prometheus 서비스의 초당 요청 수 (RPS) 메트릭을 기반으로 샘플 애플리케이션 Deployment를 확장하도록 KEDA를 구성할 것입니다. 이를 통해 프로덕션 워크로드 수요를 처리할 수 있는 완벽한 규모의 오토스케일링이 가능합니다. 이 가이드를 따르면 KEDA와 Amazon Managed Service for Prometheus의 통합을 활용하여 자체 Amazon EKS 워크로드에 유연한 오토스케일링을 추가할 수 있습니다. 여기서는 Amazon Managed Grafana를 Amazon Managed Service for Prometheus 와 함께 사용하여 모니터링 및 분석을 수행할 수 있습니다. 사용자는 애플리케이션 메트릭을 시각화하여 오토스케일링 패턴에 대한 통찰력을 얻고 이를 비즈니스 이벤트와 연관시킬 수 있습니다.

사전 요구 사항

이 연습을 위해서는 다음과 같은 리소스와 도구가 필요합니다.

솔루션 개요

이 솔루션은 자동화된 오토스케일링 파이프라인을 생성하기 위한 오픈소스 소프트웨어와 AWS의 통합을 보여줍니다. Amazon EKS 클러스터는 배포 및 오케스트레이션을 위한 관리형 쿠버네티스 환경을 제공합니다. AWS Distro for Open Telemetry (ADOT) 은 Amazon Managed Service for Prometheus에서 메트릭을 수집하고 사용자 지정 애플리케이션 메트릭을 수집하는 데 사용됩니다. 이벤트 기반 오토스케일링을 지원하기 위해 Amazon EKS 클러스터에 KEDA를 설치합니다. KEDA를 사용하면 Prometheus의 메트릭 스트림을 기반으로 오토스케일링 규칙을 생성할 수 있습니다. 마지막으로, Amazon Managed Grafana는 Amazon Managed Service for Prometheus의 오토스케일링 메트릭을 시각화하는 사전 구축된 대시보드를 제공합니다. 이를 통해 부하가 증가함에 따라 KEDA가 마이크로서비스를 적절히 오토스케일링 하고 있는지 확인 할 수 있습니다.

다음 아키텍처 다이어그램과 같이 아래의 구성 요소들이 통합 되어 있습니다:

KEDA 구성 요소는 Amazon EKS 클러스터에 배포되어 이벤트 기반(event-driven), 메트릭 기반(metric-based) 확장을 위한 플랫폼을 구성합니다.
ADOT는 샘플 앱에서 Amazon Managed Service for Prometheus의 요청 속도(request rate) 및 지연 시간(latency)과 같은 메트릭을 스크랩하도록 구성되어 있습니다.
KEDA ScaledObject 구성은 마이크로서비스 배포를 위한 Prometheus 메트릭 스트림을 기반으로 오토스케일링 규칙을 정의합니다.
앱에 부하 트래픽을 생성합니다. 트래픽이 증가함에 따라 Amazon Managed Grafana 대시보드를 사용합니다.
KEDA는 Prometheus 메트릭을 활용하여 수요에 맞게 Pod를 자동으로 확장합니다.
Amazon Managed Grafana를 사용하여 Amazon Managed Service for Prometheus의 다양한 메트릭을 모니터링할 수 있습니다.

그림 1.아키텍처 다이어그램

다음 다이어그램과 같이 오토스케일링의 흐름은 다음과 같이 작동합니다. 먼저, 최종 사용자는 Kubernetes에서 실행되는 마이크로서비스 애플리케이션에 요청을 보냅니다. 이 애플리케이션 워크로드는 시간이 지남에 따라 변동될 수 있습니다. 각 마이크로서비스 Pod에는 Amazon Distro for OpenTelemetry (ADOT) 에이전트가 사이드카로 구성되어 있습니다. ADOT은 요청 속도, 지연 시간, 오류율 등의 메트릭을 수집하여 Amazon Managed Service for Prometheus로 전송합니다. 이 서비스는 large-scale, high-cardinality 메트릭에 최적화 된 관리형 시계열 데이터베이스로, 높은 가용성과 탄력적 기능을 제공합니다. KEDA는 정의된 일정한 간격으로 Prometheus에서 커스텀 애플리케이션 메트릭을 쿼리합니다. 이 간격은 KEDA가 오토스케일링을 위해 Prometheus에서 커스텀 애플리케이션 메트릭을 가져오는 일관된 시간 주기를 의미합니다.

KEDA는 메트릭 데이터를 기반으로 Pod의 스케일 아웃/인의 필요성을 판단하고, Horizontal Pod Autoscaler (HPA) 와 상호 작용하여 오토스케일링 합니다. HPA 컨트롤러는 KEDA가 지정한 파드 복제본 수에 따라 워크로드 구성에 맞춰 Pod를 생성하거나 종료함으로써 자동화된 스케일 업/다운 기능을 제공합니다. 요약하자면, ADOT, Amazon Managed Service for Prometheus, KEDA 그리고 HPA가 함께 작동하여 Kubernetes 마이크로서비스에 대한 모니터링과 함께 메트릭 기반 오토스케일링을 가능하게 합니다.

그림 2.시퀀스 다이어그램

Amazon EKS, Amazon Managed Service for Prometheus, Amazon Managed Grafana와 같은 매니지드 서비스를 KEDA 및 HPA 같은 오픈 소스 구성 요소와 결합하여 실시간 메트릭에 따라 애플리케이션 확장을 자동화할 수 있었습니다. 이는 사용률 메트릭을 기반으로 프로덕션 애플리케이션을 스케일링할 수 있는 유연하고 클라우드 네이티브한 아키텍처를 제공합니다. 같은 모델을 사용하여 Prometheus와 KEDA의 통합을 통해 CPU, 메모리 또는 애플리케이션별 메트릭과 같은 메트릭을 활용한 스케일링도 가능합니다.

1단계: 환경 변수 및 아티팩트 설정

export EKS_CLUSTER=KEDA-AMP 
export AWS_REGION=us-east-1 
export ACCOUNT_ID=`aws sts get-caller-identity |jq -r ".Account"`

다음과 같이 이 저장소에서 필요한 아티팩트를 가져옵니다.

git clone https://github.com/aws-samples/keda-amp-scaling.git 
cd keda-amp-sampling

2단계: Amazon EKS 클러스터 생성

eksctl 명령줄 도구를 사용하여 Amazon EKS 클러스터를 생성할 수 있습니다. eksctl 명령줄 도구를 사용하면 다음과 같이 합리적인 기본값으로 기본 클러스터 생성을 시작할 수 있습니다.

eksctl create cluster -f eks-cluster-config.yaml

또는 AWS Management Console은 EKS 클러스터 생성 프로세스를 안내하는 그래픽 인터페이스를 제공합니다.

AWS CloudFormation이나 Terraform과 같은 Infrastructure as Code (IaC) 도구를 사용하면 모든 리소스를 코드를 통해 자동화하고 관리할 수 있습니다. 이를 통해 버전 관리, 재사용, 그리고 프로덕션 수준의 배포를 위한 CI/CD 파이프라인과의 통합이 가능합니다. 여러 환경과 계정에 걸쳐 관리 용이성(manageability)과 반복 가능성(repeatability)을 확보하기 위해서는 IaC 모범 사례를 따르는 것이 권장 됩니다.

3단계: KEDA 배포

‘helm upgrade —install’ 명령은 쿠버네티스 클러스터에 Kubernetes Event-driven Autoscaling (KEDA) 컴포넌트를 설치하는 데 사용됩니다.

helm repo add kedacore https://kedacore.github.io/charts 
helm upgrade --install keda kedacore/keda --version 2.13.1 -n keda --create-namespace

이 설치는 kedacore 리포지토리의 공식 KEDA Helm 차트 (버전 2.13.1) 를 사용하며, ‘keda’라는 릴리즈 이름으로 ‘keda’ 네임스페이스에 설치됩니다. Helm 차트에는 KEDA의 사용자 지정 리소스 정의, RBAC 구성 요소, Prometheus 메트릭 어댑터, 그리고 KEDA 컨트롤러 Pod를 배포하기 위한 매니페스트가 포함되어 있습니다. 이는 대부분의 사용 사례에 적합한 기본 설정으로 실행됩니다. 필요에 따라 구성을 사용자 정의 할 수 있습니다. Helm을 사용하면 배포, 버전 관리, 업그레이드, 롤백 등 KEDA 배포 수명 주기를 관리할 수 있습니다.

4단계: 프로메테우스 워크스페이스를 위한 아마존 매니지드 서비스 생성

‘aws amp create-workspace’ 명령은 지정된 AWS 리전에 ‘AMP-KEDA’라는 별칭(alias)으로 Amazon Managed Service for Prometheus 워크스페이스를 생성합니다. 이 워크스페이스는 Prometheus 메트릭과 대시보드를 저장할 수 있는 격리된 환경을 제공합니다. 워크스페이스는 기본 설정으로 생성되며, 필요한 경우 추가로 사용자 지정할 수 있습니다. 이 명령은 ‘ws-1f649a35-5f44-4744-885e-95a4844cba68’와 같은 형식의 새로 생성된 워크스페이스 ID를 반환합니다. 이 ID는 애플리케이션에서 워크스페이스로 메트릭 데이터를 전송하거나, 다른 서비스가 해당 데이터에 접근할 수 있도록 허용하는 데 필요합니다.

aws amp create-workspace --alias AMP-KEDA --region $AWS_REGION 
AMP_WS_ID=`aws amp list-workspaces | jq -r ".workspaces[0].workspaceId"`

5단계: Amazon Managed Grafana 워크스페이스 생성

AWS CLI를 사용하여 Amazon Managed Grafana 워크스페이스를 생성할 때는 먼저 IAM 역할을 생성해야 합니다. 이 역할은 워크스페이스에 할당되며 IAM 권한은 모든 AWS 데이터 소스에 액세스하는 데 사용됩니다.

aws iam create-role --role-name grafana-role \ --assume-role-policy-document file://grafana_trust_policy.json

다음으로, AWS Single Sign-On (AWS SSO) 을 인증에 사용하고, 앞서 생성한 IAM 역할을 사용하도록 설정한 Amazon Managed Grafana 워크스페이스를 생성합니다. 작업 공간을 생성하는 데에는 다음 명령어를 참고할 수 있습니다.

RESULT=$(aws grafana create-workspace \
    --account-access-type="CURRENT_ACCOUNT" \
    --authentication-providers "SSO" \
    --permission-type "CUSTOMER_MANAGED" \
    --workspace-name "AMP-KEDA" \
    --workspace-role-arn "grafana-role")
    
export AMG_WS_ID=$(jq -r .workspace.id <<< $RESULT)

6단계: Amazon Managed Service for Prometheus를 사용한 KEDA 확장의 synthetic test

설정이 완료되었으니, synthetic test를 수행하겠습니다. 이를 위해 nginx 이미지의 쿠버네티스 Deployment를 배포해보도록 하겠습니다. 이렇게 하면 nginx 이미지의 단일 Pod가 실행됩니다.

kubectl create deploy nginx-scaledobj --image=nginxinc/nginx-unprivileged

그런 다음 KEDA ScaledObject를 배포합니다. 아래의 구성 스니펫에서 볼 수 있듯, ScaledObject는 상수 값 100을 반환하는 커스텀 메트릭 벡터 (100) 를 쿼리합니다. 임계값을 25로 설정하면, 쿼리 결과/임계값 = Pod 4개로 Deployment가 확장됩니다.

triggers:
  - type: prometheus
     metadata:
        serverAddress: https://aps-workspaces.$AWS_REGION.amazonaws.com/workspaces/$AMP_WS_ID
        metricName: s0-prometheus
        threshold: "25"
        query: vector(100)

HPA를 확인해보면, 대상 메트릭이 25/25 (평균) 으로 replica가 4개로 스케일링 된 것을 확인할 수 있습니다.

kubectl get hpa 
NAME                       REFERENCE                    TARGETS        MINPODS   MAXPODS   REPLICAS   AGE
keda-hpa-nginx-scaledobj   Deployment/nginx-scaledobj   25/25 (avg)    1         30        4          4m18s

이 스케일링 이벤트는 KEDA 컨트롤러 로그에서도 확인할 수 있습니다.

2024-02-14T01:46:25Z    INFO    Initializing Scaling logic according to ScaledObject Specification    {"controller": "scaledobject", "controllerGroup": "keda.sh", "controllerKind": "ScaledObject", "ScaledObject": {"name":"nginx-scaledobj","namespace":"default"}, "namespace": "default", "name": "nginx-scaledobj", "reconcileID": "04b8918a-8c7e-4212-aa15-b339bc6ce667"}
2024-02-14T01:46:25Z    INFO    Reconciling ScaledObject    {"controller": "scaledobject", "controllerGroup": "keda.sh", "controllerKind": "ScaledObject", "ScaledObject": {"name":"nginx-scaledobj","namespace":"default"}, "namespace": "default", "name": "nginx-scaledobj", "reconcileID": "70e17ffb-8d85-43b3-8df0-70e502b28719"}
2024-02-14T01:46:25Z    INFO    Detected resource targeted for scaling    {"controller": "scaledobject", "controllerGroup": "keda.sh", "controllerKind": "ScaledObject", "ScaledObject": {"name":"nginx-scaledobj","namespace":"default"}, "namespace": "default", "name": "nginx-scaledobj", "reconcileID": "70e17ffb-8d85-43b3-8df0-70e502b28719", "resource": "apps/v1.Deployment", "name": "nginx-scaledobj"}

마지막으로, Pod 상태를 확인하면 이제 4개의 nginx Pod가 실행 중임을 확인할 수 있습니다.

kubectl get pods
nginx-scaledobj-dd6c4d5f6-hzkt8   1/1     Running   0               10s
nginx-scaledobj-dd6c4d5f6-k5z7h   1/1     Running   0               10s
nginx-scaledobj-dd6c4d5f6-tfngt   1/1     Running   0               10s
nginx-scaledobj-dd6c4d5f6-whxh7   1/1     Running   0               3m43s

7단계: Amazon Managed Service for Prometheus를 이용한 KEDA 애플리케이션 확장 테스트

아키텍처 다이어그램을 기반으로 KEDA를 사용한 애플리케이션 확장에 대해 다시 살펴보겠습니다. 먼저 ADOT collector 설정을 배포합니다.

eksctl create iamserviceaccount --name adot-collector --cluster $EKS_CLUSTER --attach-policy-arn arn:aws:iam::aws:policy/AmazonPrometheusRemoteWriteAccess --approve 
export REMOTE_WRITE_URL="https://aps-workspaces.$AWS_REGION.amazonaws.com/workspaces/$AMP_WS_ID/api/v1/remote_write"

이제 수집 설정이 된 매니페스트 파일 amp-eks-adot-prometheus-daemonset.yaml을 활용하여 Envoy 메트릭을 추출하는 ADOT collector를 배포합니다. 이렇게 ADOT Deployment를 배포하여 Pod에서 메트릭을 수집할 수 있습니다.

sed -i bak -e  "s|AWSREGION|${REGION}|g" amp-eks-adot-prometheus-daemonset.yaml
sed -i bak -e  "s|REMOTE_WRITE_URL|${REMOTE_WRITE_URL}|g" amp-eks-adot-prometheus-daemonset.yaml
kubectl apply -f amp-eks-adot-prometheus-daemonset.yaml

설정이 완료되면 샘플 애플리케이션을 배포합니다.

kubectl apply -f keda-app.yaml

샘플 애플리케이션을 배포하면, frontend 애플리케이션, checkout 애플리케이션 및 downstream 애플리케이션이 배포됩니다. 해당 샘플 앱은 퍼블릭 AWS observability repository를 기반으로 합니다. 또한, 해당 샘플 애플리케이션은 연관된 Service들도 생성합니다.

kubectl get deployments
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
downstream   1/1     1            1           77s
frontend     1/1     1            1           77s
checkout     0/0     1            1           77s

kubectl get service
NAME          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
downstream    ClusterIP   10.100.214.180   <none>        80/TCP    118s
frontend      ClusterIP   10.100.207.248   <none>        80/TCP    118s
kubernetes    ClusterIP   10.100.0.1       <none>        443/TCP   21d

앞서 설정에서 ho11y_total을 포함한 메트릭을 Amazon Managed Service for Prometheus 로 전송하도록 구성하였습니다. 해당 메트릭은 frontend 호출 시 증가합니다. ScaledObject를 생성하여 KEDA로 이벤트 기반(event-driven) 확장을 확인해 보겠습니다.

kubectl apply -f keda-so-hpa.yaml

아래 ScaledObject 코드 스니펫에서 ho11y_total 쿼리를 30초의 속도로 실행하며, 샘플 임계값은 0.25로 설정되어 있습니다. 즉, 0.25의 임계값을 가진 ho11y_total 메트릭을 30초마다 조회합니다.

triggers:
    - type: prometheus
      metadata:
        serverAddress: https://aps-workspaces.$AWS_REGION.amazonaws.com/workspaces/$AMP_WS_ID
        metricName: requests_rate
        identityOwner: operator
        threshold: '0.25'
        query: rate(ho11y_total[30s])

다음과 같이 frontend 애플리케이션에 부하를 추가합니다. 기본 전제는 다음과 같습니다. frontend에서 더 많은 요청을 받으면 KEDA가 ho11y_total 메트릭을 기반으로 checkout 애플리케이션의 Pod를 늘려야하고, 부하 테스트가 종료되면 다시 줄여야합니다.

frontend_pod=`kubectl get pod --no-headers -l app=frontend -o 
     jsonpath='{.items[*].metadata.name}'`
loop_counter=0
while [ $loop_counter -le 300 ] ; do kubectl exec -it $frontend_pod — 
   curl downstream.default.svc.cluster.local; echo ; loop_counter=$[$loop_counter+1];done

일정 시간이 지나면 RPS 부하 테스트를 기반으로 checkout Pod가 증가합니다. 부하 테스트가 종료되면 Pod 수가 감소합니다. HPA 이벤트를 확인하면 이러한 스케일링 동작을 확인할 수 있습니다.

kubectl get hpa -w
NAME               REFERENCE       TARGETS MINPODS MAXPODS REPLICAS
keda-hpa-ho11y-hpa Deployment/checkout 445/250m (avg) 1 100 3 
keda-hpa-ho11y-hpa Deployment/checkout 640/250m (avg) 1 100 5 
keda-hpa-ho11y-hpa Deployment/checkout 500/250m (avg) 1 100 4 
keda-hpa-ho11y-hpa Deployment/checkout 320/250m (avg) 1 100 2 
keda-hpa-ho11y-hpa Deployment/checkout 100/250m (avg) 1 100 1

또한, 이러한 스케일링 이벤트는 Amazon Managed Grafana에서 ho11y_total/[30s]/0.25 메트릭을 활용해 시각화할 수 있으며, Pod가 0에서 5로 증가했다가 다시 감소되었음을 확인할 수 있습니다.

그림 3. Grafana 시각화

요약하면, Prometheus로 전송되는 애플리케이션 메트릭을 기반으로 KEDA를 활용한 이벤트 기반 오토스케일링이 제대로 작동함을 검증했습니다.

리소스 정리

다음 명령을 사용하여 이 포스팅에서 생성된 리소스를 삭제합니다.

aws grafana delete-workspace --workspace-id $AMG_WS_ID
aws iam delete-role --role-name grafana-role
aws amp delete-workspace --workspace-id $AMP_WS_ID
eksctl delete cluster $EKS_CLUSTER

결론

이번 포스팅에서는 KEDA와 Amazon Managed Service for Prometheus를 활용하여 Amazon EKS의 애플리케이션을 오토스케일링하는 솔루션을 살펴보았습니다. AWS 관리형 서비스와 오픈소스 소프트웨어를 통합하여 애플리케이션의 성능 메트릭에 맞춘 오토스케일링 솔루션을 구현했습니다. 주요 구성 요소로는 쿠버네티스 인프라를 구성하기 위한 Amazon EKS, 메트릭 기반 스케일링 로직을 위한 KEDA, 메트릭 백엔드로 사용되는 Amazon Managed Service for Prometheus, 메트릭 수집을 위한 ADOT, 시각화를 위한 Amazon Managed Grafana이 활용되었습니다. 이 서비스들을 조합하여 애플리케이션 워크로드에 따라 동적으로 리소스를 할당하는 폐쇄 루프 시스템을 구성했습니다.

샘플 마이크로서비스에 부하를 생성하고 KEDA가 이에 반응하여 자동으로 파드를 증가/감소시키는 것을 Grafana 차트를 통해 관찰했습니다. 이는 애플리케이션 요구사항에 맞춘 메트릭 기반의 리소스 최적화 접근 방식을 보여줍니다. 이번 예제에서는 요청 빈도에 초점을 맞추었지만, 이 프레임워크는 CPU, 지연 시간, 오류 코드 등 모든 사용자 정의 메트릭과 함께 작동할 수 있습니다. 조직들이 클라우드 비용과 성능을 최적화하고자 하기 때문에, 사용량 신호를 기반으로 한 리소스 프로비저닝 자동화는 핵심입니다. KEDA와 Amazon Managed Service for Prometheus를 통합하는 것은 Prometheus 메트릭을 활용해 EKS에서 이벤트 기반 오토스케일링을 구현하는 방법을 제공합니다.

AWS Observability에 대해 자세히 알아보려면 다음 내용을 참조하세요.

AWS 기술 블로그