Datadog Kubernetes Autoscaling は、Kubernetes リソースを継続的にモニターし、即時のスケーリング推奨事項と Kubernetes ワークロードの多次元オートスケーリングを提供します。Datadog のウェブインターフェースを通じて、または DatadogPodAutoscaler カスタムリソースを使用してオートスケーリングを展開できます。

仕組み

Datadog は、リアルタイムおよび過去の利用率メトリクスと既存の Datadog Agent からのイベントシグナルを使用して推奨事項を作成します。その後、これらの推奨事項を確認し、デプロイすることを選択できます。

デフォルトで、Datadog Kubernetes Autoscaling は推定された CPU およびメモリコスト値を使用して、節約の機会と影響の見積もりを示します。Kubernetes Autoscaling を Cloud Cost Management と併用して、正確なインスタンスタイプコストに基づくレポートを取得することもできます。

自動ワークロードスケーリングは、ワークロードレベルでスケーリング動作を定義する DatadogPodAutoscaler カスタムリソースによって実現されています。Datadog Cluster Agent は、このカスタムリソースのコントローラーとして機能します。

注: 各クラスターは、Datadog Kubernetes Autoscaling で最適化された最大 1000 のワークロードを持つことができます。

互換性

• ディストリビューション: この機能は、Datadog の サポートされている Kubernetes ディストリビューションすべてと互換性があります。
• ワークロードオートスケーリング: この機能は、Horizontal Pod Autoscaler (HPA) および Vertical Pod Autoscaler (VPA) の代替です。Datadog は、Datadog Kubernetes Autoscaling を有効にする際に、ワークロードから HPA または VPA を削除することを推奨します。これらのワークロードは、アプリケーション内で自動的に特定されます。 注: HPA および/または VPA を保持しながら、applyPolicy セクションの mode: Preview で DatadogPodAutoscaler を作成することにより、Datadog Kubernetes Autoscaling を試すことができます。

要件

• Remote Configuration は、組織レベルおよびターゲットクラスター内のエージェントの両方で有効にする必要があります。設定手順については、Remote Configuration を有効にするを参照してください。

• Helm、Datadog Agent 更新用。

• (Datadog Operator ユーザー向け) kubectl CLI、Datadog Agent 更新用。

• ライブオートスケーリングを使用している場合、Datadog は最新の Datadog Agent バージョンの使用を推奨します。これにより、最新の改善と最適化の利用が確保されます。スケーリングの推奨事項を利用するには、Kubernetes State Core の統合を有効にする必要があります。
  
  

  機能	最小 Agent バージョン
  アプリ内ワークロードスケーリングの推奨事項	7.50+
  ライブワークロードスケーリング	7.66.1+
  Argo Rollout の推奨事項とオートスケーリング	7.71+
  クラスターオートスケーリング (サインアップのプレビュー)	7.72+
  インプレースの垂直ポッドサイズ変更 (オプトイン)	7.78+
  クラスタープロファイルのアクティベーション、ワークロードラベル	7.78+
  クラスタープロファイルのアクティベーション、ネームスペースラベル	7.79+

• 以下のユーザー権限:

  • 組織管理 (Remote Configuration に必要)
  • API キーの書き込み (Remote Configuration に必要)
  • ワークロードスケーリングの書き込み
  • オートスケーリング管理

• (推奨) 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

使用方法

リソースを特定して適切なサイズに調整する

オートスケーリング概要ページは、プラットフォームチームが組織全体の Kubernetes リソースの節約機会を理解し、主要なクラスターやネームスペースに絞り込むための出発点を提供します。

セットアップページは、スケールする複数のワークロードを選択し、一括して最適化を管理するオプションを提供します。

クラスターのスケーリングビューは、クラスターごとの合計アイドル CPU、合計アイドルメモリ、およびコストに関する情報を提供します。

クラスターをクリックすると、詳細情報と推定節約額でソートされたクラスターのワークロードのテーブルが表示されます。個々のアプリケーションまたはサービスの所有者である場合は、ワークロードスケーリングリストビューから直接チームまたはサービス名でフィルタリングすることもできます。

これらのビューのいずれからでも、ワークロードの Optimize をクリックしてスケーリングの推奨事項を確認し、その後、ワークロードのオートスケーリングを有効にするへ進みます。

ワークロードのオートスケーリングを有効にする

最適化するワークロードを特定した後、その Scaling Recommendation を確認します。Configure Recommendation をクリックして、有効にする前に制約を追加するかターゲット利用率レベルを調整します。

ワークロードのオートスケーリングを有効にする方法は 3 つあります。現在のワークロードのデプロイ方法に合ったパスを選択してください。

パス A: Datadog UI

最も早い開始方法は、Datadog UI のセットアップページです。ウィザードは次の 5 つのステップを案内します。クラスターの選択、Agent と権限の要件の確認、インストール方法の選択、スケーリングテンプレートの選択、デプロイ。ウィザードで利用可能なテンプレート:

• コストを最適化する: 高い CPU 利用率目標、積極的なスケールダウン、最低レプリカフロア。ステートレスでコスト要件が厳しいワークロードに最適です。
• バランスを最適化する: 中程度の利用率目標、バランスの取れたスケールアップとスケールダウン。ほとんどのステートレスワークロードに最適です。
• パフォーマンスを最適化する: 保守的な利用率目標、遅いスケールダウン、高いレプリカフロア。ステートフルまたは重要なサービスに最適です。
• カスタマイズ: 上記のいずれかから開始し、CPU ターゲット、レプリカ、および安定化ウィンドウを自分で調整します。

セットアップウィザードは、単一のワークロードでオートスケーリングを試したり、推奨事項を実際に体験したり、小規模なワークロードのセットをオンボーディングするのに最適です。(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 は、autoscaling.datadoghq.com/profile ラベルの Deployment および StatefulSet リソース (および 7.79 以降では、それらを含むネームスペース) をモニターし、一致するワークロードごとに管理された DatadogPodAutoscaler を作成します。1 つのプロファイルは多くのワークロードに適用されますが、1 つのワークロードは依然として 1 つの DatadogPodAutoscaler にマッピングされます。

クラスタープロファイルとワークロードレベルのラベルは、Datadog Cluster Agent 7.78.0 以降を必要とします。ネームスペースレベルのアクティベーション (ネームスペースにラベルを付けてすべてのサポートされているワークロードをプロファイルにオプトインさせる) は、Datadog Cluster Agent 7.79.0 以降を必要とします。古い Cluster Agent はプロファイルラベルを無視します。

組み込みプロファイル

Cluster Agent には 3 つの組み込みプロファイルが用意されており、起動時にそれらが再作成されるため、使用するために 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) については、Path B: GitOps を使用して DatadogPodAutoscaler を直接作成します。

手動で推奨事項をデプロイする

オートスケーリングを有効にせずに Datadog の推奨事項を受け取りたい場合は、一度だけ手動で適用できます。Kubernetes のデプロイメントのためにリソースを構成する場合は、スケーリングの推奨事項で提案された値を使用します。Export Recommendation をクリックして、生成された kubectl patch コマンドを見ることもできます。Datadog は推奨事項を継続的に更新しますが、クラスターが変更されるのは再適用する場合のみです。

ワークロードを大規模に管理する

ワークロードがオートスケーリングされた後、2 日目の操作は DatadogPodAutoscaler リソースと Datadog UI を組み合わせて管理されます。

• **スケーリングテンプレートを変更します。**ワークロードの DatadogPodAutoscaler 仕様 (CPU ターゲット、レプリカの範囲、スケールアップおよびスケールダウンのルール) を直接編集するか、ワークロードスケーリングリストビューから別のテンプレートを選択します。変更内容は次回の調整時に反映されます。
• リソースを削除せずにオートスケーリングを一時停止します。applyPolicy.mode: Preview を設定して、コントローラーが推奨事項を適用するのを防ぎながら .status で推奨事項を表示し続けます。これは、評価中に HPA または VPA と一緒に実行する場合に便利です。
• **ロールアウトをモニターします。**ワークロードスケーリングリストビューは、各ワークロードの推奨事項、最後に適用されたアクション、および調整エラーのライブステータスを表示します。
• オートスケーリングをクリーンに削除します。DatadogPodAutoscaler リソースを削除してオートスケーリングを停止します。既存の Pod リソースは最後に適用された値のままであり、ワークロードは次回のロールアウトで親コントローラー (デプロイメント、StatefulSet など) が指定するものに戻ります。

リファレンス

垂直の推奨事項の計算方法

Datadog は、過去 8 日間のコンテナ使用データを分析することによって、CPU およびメモリの垂直スケーリング推奨事項を計算します。各リソースに使用される方法は、そのリソースのリクエストが制限と等しいかどうかに依存し、Kubernetes のサービス品質 (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 ワークロードのスケーリングブログ カスタムクエリスケーリングを使用して Kubernetes ワークロードを最適化するブログ DDOT ゲートウェイを使用して、OpenTelemetry パイプラインを一元管理するブログ Datadog Kubernetes Autoscaling を使用して、ワークロードのサイズを適切に調整し、コストを削減するブログ