Datadog Kubernetes Autoscaling은 Kubernetes 리소스를 지속적으로 모니터링하여 즉각적인 스케일링 권장 사항과 Kubernetes 워크로드의 다차원 자동 확장 기능을 제공합니다. Datadog 웹 인터페이스 또는 DatadogPodAutoscaler 사용자 지정 리소스를 사용하여 자동 확장을 배포할 수 있습니다.

작동 방식

Datadog은 기존 Datadog Agent에서 수집되는 실시간 및 과거 사용률 메트릭, 이벤트 신호를 활용하여 권장 사항을 생성합니다. 사용자는 이러한 권장 사항을 검토한 후 적용 여부를 선택할 수 있습니다.

기본적으로 Datadog Kubernetes Autoscaling은 추정 CPU 및 메모리 비용 값을 사용하여 비용 절감 기회와 예상 효과를 표시합니다. 또한 Cloud Cost Management와 함께 Kubernetes Autoscaling을 사용하여 실제 인스턴스 유형 비용을 기반으로 한 보고서를 받을 수 있습니다.

자동 워크로드 스케일링은 워크로드별 스케일링 동작을 정의하는 DatadogPodAutoscaler 사용자 지정 리소스를 기반으로 동작합니다. Datadog Cluster Agent는 이 사용자 지정 리소스의 컨트롤러 역할을 합니다.

참고: 각 클러스터에서는 최대 1,000개의 워크로드에 대해 Datadog Kubernetes Autoscaling 최적화를 적용할 수 있습니다.

호환성

• 배포판: 이 기능은 Datadog이 지원하는 모든 Kubernetes 배포판과 호환됩니다.
• 워크로드 자동 확장: 이 기능은 Horizontal Pod Autoscaler(HPA) 및 Vertical Pod Autoscaler(VPA)의 대안입니다. Datadog은 워크로드 최적화를 위해 Datadog Kubernetes Autoscaling을 활성화할 때 기존 HPA 또는 VPA를 제거할 것을 권장합니다. 이러한 워크로드는 애플리케이션에서 자동으로 식별됩니다. 참고: applyPolicy 섹션에서 mode: Preview가 포함된 DatadogPodAutoscaler를 생성하면 HPA 및/또는 VPA를 유지한 상태로 Datadog Kubernetes Autoscaling을 시험해 볼 수 있습니다.

요구 사항

• Remote Configuration이 조직 수준과 대상 클러스터의 Agent 모두에서 활성화되어 있어야 합니다. 설정 방법은 Remote Configuration 활성화를 참조하세요.

• Datadog Agent 업데이트를 위한 Helm.

• (Datadog Operator 사용자용) Datadog Agent 업데이트를 위한 kubectl CLI.

• 실시간 자동 확장을 사용하는 경우 Datadog은 최신 Datadog Agent 버전 사용을 권장합니다. 이를 통해 최신 개선 사항과 최적화를 활용할 수 있습니다. 스케일링 권장 사항을 사용하려면 Kubernetes State Core 통합이 활성화되어 있어야 합니다.
  
  

  기능	최소 Agent 버전
  앱 내 워크로드 스케일링 권장 사항	7.50+
  실시간 워크로드 스케일링	7.66.1+
  Argo Rollout 권장 사항 및 자동 확장	7.71+
  클러스터 자동 확장(미리보기 신청)	7.72+
  인플레이스 수직 포드 크기 조정(옵트인)	7.78+
  클러스터 프로필 활성화, 워크로드 레이블	7.78+
  클러스터 프로필 활성화, 네임스페이스 레이블	7.79+

• 다음 사용자 권한 필요:

  • Org Management(Remote Configuration에 필요)
  • API Keys Write(Remote Configuration에 필요)
  • Workload Scaling Write
  • Autoscaling Manage

• (권장) Linux 커널 v5.19 이상 및 cgroup v2

설정

helm upgrade datadog-operator datadog/datadog-operator

spec:
  features:
    autoscaling:
      workload:
        enabled: true
    eventCollection:
      unbundleEvents: true
  override:
    clusterAgent:
      env:
        - name: DD_AUTOSCALING_FAILOVER_ENABLED
          value: "true"
    nodeAgent:
      env:
        - name: DD_AUTOSCALING_FAILOVER_ENABLED
          value: "true"

...
spec:
  features:
    admissionController:
      enabled: true
...

kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml

datadog:
  autoscaling:
    workload:
      enabled: true
  kubernetesEvents:
    unbundleEvents: true

...
clusterAgent:
  admissionController:
    enabled: true
...

helm repo update

helm upgrade -f datadog-values.yaml <RELEASE_NAME> datadog/datadog

유휴 비용 및 절감 효과 추정

  (cpu_capacity - max(cpu_usage, cpu_requests)) * core_rate_per_hour
+ (mem_capacity - max(mem_usage, mem_requests)) * memory_rate_per_hour

  (max(cpu_usage, cpu_requests) - cpu_usage) * core_rate_per_hour
+ (max(mem_usage, mem_requests) - mem_usage) * memory_rate_per_hour

사용 방법

적정 규모 조정 대상 리소스 식별

Autoscaling Summary 페이지는 플랫폼 팀이 조직 전체의 Kubernetes 리소스 절감 기회를 파악하고 주요 클러스터 및 네임스페이스로 범위를 좁힐 수 있는 시작점 역할을 합니다.

Setup 페이지에서는 여러 워크로드를 선택하여 확장을 적용하고 최적화를 일괄 관리할 수 있습니다.

Cluster Scaling 보기에서는 클러스터별 총 유휴 CPU, 총 유휴 메모리 및 비용 정보를 제공합니다.

클러스터를 클릭하면 예상 절감액 기준으로 정렬된 워크로드 표와 함께 상세 정보를 확인할 수 있습니다. 개별 애플리케이션 또는 서비스 소유자인 경우 Workload Scaling 목록 보기에서 팀 또는 서비스 이름으로 직접 필터링할 수도 있습니다.

이러한 보기 중 어느 곳에서든 워크로드의 Optimize를 클릭하여 확장 권장 사항을 확인한 후 워크로드에 Autoscaling 활성화 단계로 진행합니다.

워크로드에 Autoscaling 활성화

최적화할 워크로드를 식별한 후 해당 워크로드의 Scaling Recommendation을 검토합니다. 활성화 전에 Configure Recommendation을 클릭하여 제약 조건을 추가하거나 목표 사용률을 조정할 수 있습니다.

워크로드에 Autoscaling을 활성화하는 방법은 세 가지입니다. 현재 워크로드 배포 방식에 맞는 경로를 선택하세요.

경로 A: Datadog UI

가장 빠르게 시작하는 방법은 Datadog UI의 Setup 페이지를 사용하는 것입니다. 설정 마법사는 다섯 단계인 클러스터 선택, Agent 및 권한 요구 사항 확인, 설치 방법 선택, 확장 템플릿 선택, 배포를 안내합니다. 마법사에서 사용할 수 있는 템플릿:

• 비용 최적화: 높은 CPU 사용률 목표, 공격적인 축소, 가장 낮은 최소 복제본 수. 비용에 민감한 상태 비저장형 워크로드에 적합합니다.
• 균형 최적화: 중간 수준의 사용률 목표, 균형 잡힌 확장 및 축소, 대부분의 상태 비저장형 워크로드에 적합합니다.
• 성능 최적화: 보수적인 사용률 목표, 느린 축소, 더 높은 최소 복제본 수. 상태 저장형 또는 중요한 서비스에 가장 적합합니다.
• 사용자 지정: 위 템플릿 중 하나를 기반으로 시작한 후 CPU 목표, 복제본 수 및 안정화 기간을 직접 조정합니다.

설정 마법사는 단일 워크로드에서 Autoscaling을 시험해 보거나, 권장 사항을 직접 검토하거나, 소규모 워크로드 집합을 온보딩하는 데 적합합니다. (Workload Scaling Write 및 Autoscaling Manage 권한 필요)

경로 B: GitOps

DatadogPodAutoscaler 사용자 지정 리소스를 정의하여 워크로드를 대상으로 지정한 후, kubectl apply, Helm, ArgoCD, Terraform 또는 기타 GitOps 도구 등 현재 사용 중인 Kubernetes 매니페스트 배포 도구를 통해 적용합니다. 매니페스트 작성 방식은 배포 메커니즘과 관계없이 동일합니다. 비용 최적화, 균형 잡힌 확장, 수직 확장 전용 리사이징, 사용자 지정 쿼리 기반 수평 확장을 위한 즉시 수정 가능한 예제를 보려면 아래의 예제 구성을 참조하세요.

도구별 가이드는 다음을 참조하세요.

• ArgoCD로 DatadogPodAutoscaler 관리
• Terraform으로 DatadogPodAutoscaler 관리

DatadogPodAutoscaler 예제 구성

다음 예시는 다양한 확장 전략에 대한 일반적인 DatadogPodAutoscaler 구성을 보여줍니다. 이를 시작점으로 사용하고 워크로드 요구 사항에 맞게 값을 조정하세요. UI에서 템플릿을 선택하려면 위의 경로 A를 따르세요.

apiVersion: datadoghq.com/v1alpha2
kind: DatadogPodAutoscaler
metadata:
    name: <WORKLOAD_NAME>
    namespace: <NAMESPACE>
spec:
    targetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: <WORKLOAD_NAME>
    owner: Local
    applyPolicy:
        mode: Apply
        scaleDown:
            rules:
                # Aggressive: allow 50% reduction every 2 minutes
                - periodSeconds: 120
                  type: Percent
                  value: 50
            stabilizationWindowSeconds: 300
        scaleUp:
            rules:
                - periodSeconds: 120
                  type: Percent
                  value: 50
            stabilizationWindowSeconds: 300
        update:
            strategy: Auto
    constraints:
        maxReplicas: 100
        # Allow scaling down to 1 replica for maximum savings
        minReplicas: 1
    objectives:
        # High utilization target to maximize cost efficiency
        - type: PodResource
          podResource:
            name: cpu
            value:
                type: Utilization
                utilization: 85

apiVersion: datadoghq.com/v1alpha2
kind: DatadogPodAutoscaler
metadata:
    name: <WORKLOAD_NAME>
    namespace: <NAMESPACE>
spec:
    targetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: <WORKLOAD_NAME>
    owner: Local
    applyPolicy:
        mode: Apply
        scaleDown:
            rules:
                # Conservative: allow only 20% reduction every 20 minutes
                - periodSeconds: 1200
                  type: Percent
                  value: 20
            stabilizationWindowSeconds: 600
        scaleUp:
            rules:
                - periodSeconds: 120
                  type: Percent
                  value: 50
            stabilizationWindowSeconds: 600
        update:
            strategy: Auto
    constraints:
        maxReplicas: 100
        # Maintain at least 2 replicas for availability
        minReplicas: 2
    objectives:
        # Moderate utilization target balances cost and performance
        - type: PodResource
          podResource:
            name: cpu
            value:
                type: Utilization
                utilization: 70

apiVersion: datadoghq.com/v1alpha2
kind: DatadogPodAutoscaler
metadata:
    name: <WORKLOAD_NAME>
    namespace: <NAMESPACE>
spec:
    targetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: <WORKLOAD_NAME>
    owner: Local
    applyPolicy:
        mode: Apply
        # Horizontal scaling disabled; only vertical resizing
        scaleDown:
            strategy: Disabled
        scaleUp:
            strategy: Disabled
        update:
            strategy: Auto
    constraints:
        maxReplicas: 100

apiVersion: datadoghq.com/v1alpha2
kind: DatadogPodAutoscaler
metadata:
    name: <WORKLOAD_NAME>
    namespace: <NAMESPACE>
spec:
    targetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: <WORKLOAD_NAME>
    owner: Local
    applyPolicy:
        mode: Apply
        scaleDown:
            rules:
                - periodSeconds: 1200
                  type: Percent
                  value: 20
            stabilizationWindowSeconds: 600
        scaleUp:
            rules:
                - periodSeconds: 120
                  type: Percent
                  value: 50
            stabilizationWindowSeconds: 600
        # Vertical updates disabled — horizontal only
        update:
            strategy: Disabled
    constraints:
        maxReplicas: 100
        minReplicas: 2
    objectives:
        - type: CustomQuery
          customQuery:
            # Replace with your own Datadog metric query
            request:
                formula: usage
                queries:
                    - name: usage
                      source: Metrics
                      metrics:
                        query: avg:redis.info.latency_ms{kube_cluster_name:<CLUSTER_NAME>,kube_namespace:<NAMESPACE>,kube_deployment:<WORKLOAD_NAME>}
            value:
                type: AbsoluteValue
                absoluteValue: 500M
            window: 5m0s
    fallback:
        horizontal:
            # With custom queries, local fallback is not activated by default
            enabled: false
            # Direction can be ScaleUp, ScaleDown or All
            direction: ScaleUp
            # When using custom queries, a CPU or Memory fallback objective is required
            objectives:
                - type: PodResource
                  podResource:
                    name: cpu
                    value:
                        type: Utilization
                        utilization: 70
            triggers:
                staleRecommendationThresholdSeconds: 600

클러스터 프로필

DatadogPodAutoscalerClusterProfile은 DatadogPodAutoscaler 템플릿을 보관하는 클러스터 범위 리소스입니다. Cluster Agent는 Deployment 및 StatefulSet 리소스(7.79 이상에서는 해당 리소스가 포함된 네임스페이스 포함)의 autoscaling.datadoghq.com/profile 레이블을 감시하고, 일치하는 각 워크로드에 대해 관리형 DatadogPodAutoscaler를 생성합니다. 하나의 프로필은 여러 워크로드에 적용될 수 있지만 하나의 워크로드는 여전히 하나의 DatadogPodAutoscaler에만 매핑됩니다.

클러스터 프로필과 워크로드 수준 레이블 기능은 Datadog Cluster Agent 7.78.0 이상이 필요합니다. 네임스페이스 수준 활성화(네임스페이스에 레이블을 지정하여 해당 네임스페이스 내의 모든 지원 워크로드를 프로필에 포함)는 Datadog Cluster Agent 7.79.0 이상이 필요합니다. 이보다 이전 버전의 Cluster Agent는 프로필 레이블을 무시합니다.

기본 제공 프로필

Cluster Agent에는 세 가지 기본 제공 프로필이 포함되어 있으며, 시작 시 자동으로 다시 생성됩니다. 따라서 사용자가 CRD YAML을 별도로 관리할 필요가 없습니다. 프로필 이름은 예약되어 있습니다.

단일 워크로드에서 프로필을 활성화하려면 워크로드의 metadata.labels에 레이블을 추가하세요.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: production
  labels:
    autoscaling.datadoghq.com/profile: datadog-optimize-balance
spec:
  # ...rest of the Deployment spec

네임스페이스 내의 모든 지원 워크로드에 프로필을 활성화하려면 네임스페이스에 레이블을 추가하세요(Cluster Agent 7.79.0 이상 필요).

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    autoscaling.datadoghq.com/profile: datadog-optimize-balance

사용자 지정 프로필

기본 제공 프로필 중 어느 것도 원하는 확장 정책과 일치하지 않는 경우 DatadogPodAutoscalerClusterProfile을 작성하세요. 프로필은 클러스터 범위 리소스이므로 --namespace 플래그 없이 적용하거나 구성 저장소의 클러스터 수준 계층에 배치해야 합니다.

apiVersion: datadoghq.com/v1alpha2
kind: DatadogPodAutoscalerClusterProfile
metadata:
  name: cost-optimized-strict-floor
spec:
  template:
    applyPolicy:
      mode: Apply
      scaleUp:
        stabilizationWindowSeconds: 300
        rules:
          - type: Percent
            value: 50
            periodSeconds: 120
      scaleDown:
        stabilizationWindowSeconds: 300
        rules:
          - type: Percent
            value: 50
            periodSeconds: 120
    constraints:
      minReplicas: 1
    objectives:
      - type: PodResource
        podResource:
          name: cpu
          value:
            type: Utilization
            utilization: 85

동일한 레이블을 사용하여 워크로드 또는 네임스페이스에서 사용자 지정 프로필을 참조할 수 있습니다.

metadata:
  labels:
    autoscaling.datadoghq.com/profile: cost-optimized-strict-floor

템플릿 본문은 DatadogPodAutoscaler 사양에서 사용할 수 있는 필드를 모두 지원하지만 targetRef는 제외됩니다(각 워크로드에 대해 Cluster Agent가 자동으로 채워 넣음). spec.template 아래에 사용할 수 있는 전체 필드 목록은 앞서 소개한 예제 구성을 참조하세요.

활성화 우선순위

Cluster Agent 7.79.0 이상에서는 네임스페이스 수준 활성화, excluded 옵트아웃 및 이들 간의 우선순위 규칙이 추가되었습니다. Cluster Agent 7.78.0에서는 워크로드 수준 레이블만 읽기 때문에 네임스페이스 또는 excluded 값과 관련된 아래 규칙은 적용되지 않습니다.

• 워크로드 레이블이 네임스페이스 레이블보다 우선합니다. 네임스페이스가 autoscaling.datadoghq.com/profile=ns-profile로 레이블 지정되고 해당 내부 워크로드가 autoscaling.datadoghq.com/profile=workload-profile로 레이블 지정된 경우, 해당 워크로드는 workload-profile을 사용합니다.

• excluded을 사용하여 제외할 수 있습니다. 네임스페이스에 레이블이 지정되어 있을 때 특정 워크로드를 제외하려면 해당 워크로드에 autoscaling.datadoghq.com/profile: excluded를 설정하세요. 이는 자동 확장이 적용된 네임스페이스 내에 존재하는 상태 저장형 워크로드 또는 중요한 워크로드에 유용합니다.

  apiVersion: apps/v1
  kind: StatefulSet
  metadata:
    name: payments-ledger
    namespace: production
    labels:
      autoscaling.datadoghq.com/profile: excluded
  

• 알 수 없는 프로필 이름은 무시됩니다. 워크로드 또는 네임스페이스가 존재하지 않는 프로필을 참조하는 경우 Cluster Agent는 관리형 DatadogPodAutoscaler를 생성하지 않으며 오류도 보고하지 않습니다. 이후 해당 이름의 프로필이 생성되면 조정 과정에서 자동으로 할당이 적용됩니다.

• 조정은 자동으로 수행됩니다. 레이블을 추가, 변경 또는 제거하면 몇 초 내에 관리형 DatadogPodAutoscaler에 반영됩니다.

지원되는 워크로드 유형

프로필 활성화는 Deployment 및 StatefulSet을 지원합니다. 그 외 유형(예: Argo Rollout)의 경우 경로 B: GitOps를 사용하여 DatadogPodAutoscaler를 직접 작성하세요.

권장 사항 수동 배포

Autoscaling을 활성화하지 않고 Datadog의 권장 사항만 사용하려는 경우, 해당 권장 사항을 일회성으로 직접 적용할 수 있습니다. Kubernetes 배포의 리소스를 구성할 때 스케일링 권장 사항에서 제안하는 값을 사용하세요. 또한 Export Recommendation을 클릭하면 생성된 kubectl patch 명령을 확인할 수 있습니다. Datadog은 계속해서 권장 사항을 갱신하지만, 클러스터는 사용자가 다시 적용할 때만 변경됩니다.

대규모 워크로드 관리

워크로드에 Autoscaling이 적용된 후에는 DatadogPodAutoscaler 리소스와 Datadog UI를 함께 사용하여 2일차 운영 작업을 수행합니다.

• 스케일링 템플릿 변경 워크로드의 DatadogPodAutoscaler 사양(CPU 목표, 복제본 범위, 확장 및 축소 규칙)을 직접 편집하거나 Workload Scaling 목록 보기에서 다른 템플릿을 선택할 수 있습니다. 변경 사항은 다음 조정 시 적용됩니다.
• 리소스를 삭제하지 않고 Autoscaling 일시 중지. applyPolicy.mode: Preview를 설정하면 .status에서 권장 사항은 계속 표시되지만 컨트롤러가 이를 적용하지 않게 됩니다. 이는 평가 단계에서 HPA 또는 VPA와 함께 사용할 때 유용합니다.
• 배포 상태 모니터링. Workload Scaling 목록 보기에서는 각 워크로드에 대한 권장 사항의 현재 상태, 마지막으로 적용된 작업 및 조정 오류를 확인할 수 있습니다.
• 깔끔하게 Autoscaling 제거. Autoscaling을 중지하려면 DatadogPodAutoscaler 리소스를 삭제하세요. 기존 포드 리소스는 마지막으로 적용된 값을 유지하며, 다음 롤아웃 시 워크로드는 상위 컨트롤러(Deployment, StatefulSet 등)에 정의된 설정으로 되돌아갑니다.

참조

수직 확장 권장 사항 계산 방식

Datadog은 최근 8일간의 컨테이너 사용량 데이터를 분석하여 CPU 및 메모리에 대한 수직 확장 권장 사항을 계산합니다. 각 리소스에 적용되는 계산 방식은 해당 리소스의 요청과 제한 값이 동일한지 여부에 따라 달라지며, 이는 Kubernetes Quality of Service(QoS) 클래스 개념을 따릅니다. CPU와 메모리는 독립적으로 평가됩니다. 따라서 하나의 워크로드는 CPU에 대해 Burstable 방식을 사용하고 메모리에 대해서는 Guaranteed 방식을 사용할 수 있으며, 그 반대도 가능합니다.

메모리 권장 사항

Burstable(메모리 요청이 메모리 제한보다 작은 경우):

Guaranteed(메모리 요청과 제한이 동일한 경우):

참고: 피크 메모리 추적은 8일의 조회 기간 동안 존재했던 모든 컨테이너에서 기록된 최고 메모리 사용량을 반영합니다. 즉, 컨테이너가 해당 기간 이전에 시작되었더라도 시작 시점의 피크 사용량과 같은 값이 권장 사항 계산에 포함됩니다.

CPU 권장 사항

Burstable(CPU 요청이 CPU 제한보다 작은 경우):

Guaranteed(CPU 요청과 CPU 제한이 동일한 경우):

주요 설계 원칙

• 8일 조회 기간: 모든 권장 사항은 지난 8일간의 사용량 데이터를 고려합니다. 이를 통해 주간 트래픽 패턴을 포착할 수 있을 만큼 충분한 이력을 확보하면서도 변화에 신속하게 대응할 수 있습니다.
• 감소 가중치: Burstable 클래스의 요청 권장 사항(CPU 또는 메모리)의 경우 오래된 샘플에는 더 낮은 가중치가 적용됩니다. 따라서 권장 사항이 최근 사용량 변화에 더 빠르게 적응할 수 있습니다.
• 안전 여유분: 모든 권장 사항에는 예상치 못한 사용량 급증에 대비하기 위해 실제 관측 사용량보다 5~10% 높은 여유분이 포함됩니다.
• OOMKill 대응: 메모리가 Guaranteed 클래스(요청 = 제한)이고 OOMKill이 발생한 경우, 반복적인 메모리 부족 오류 가능성을 줄이기 위해 20% 증가분이 적용됩니다.
• Guaranteed 클래스 유지: 리소스의 요청과 제한이 동일한 경우 Datadog은 두 값 모두에 대해 보다 보수적인(제한 기준) 계산 방식을 사용하여 권장 사항이 요청과 제한 사이의 간격을 새롭게 만들지 않도록 보장합니다.

추가 자료

추가 유용한 문서, 링크 및 기사:

Kubernetes 리소스 활용설명서 Datadog 역할 권한설명서 Remote Configuration설명서 사용자 지정 메트릭을 활용한 Kubernetes 워크로드 확장블로그 Custom Query Scaling을 사용한 Kubernetes 워크로드 최적화블로그 DDOT 게이트웨이를 통해 OpenTelemetry 파이프라인을 중앙에서 관리 및 제어블로그 Datadog Kubernetes Autoscaling으로 워크로드 규모를 적정화하고 비용 절감블로그