次の方法で共有

HDInsight on AKS クラスターの自動スケーリング

  • [アーティクル]

Note

Azure HDInsight on AKS は 2025 年 1 月 31 日に廃止されます。 2025 年 1 月 31 日より前に、ワークロードを Microsoft Fabric または同等の Azure 製品に移行することで、ワークロードの突然の終了を回避する必要があります。 サブスクリプション上に残っているクラスターは停止され、ホストから削除されることになります。

提供終了日までは基本サポートのみを利用できます。

重要

現在、この機能はプレビュー段階にあります。 ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用されるその他の法律条項については、「Microsoft Azure プレビューの追加の使用条件」に記載されています。 この特定のプレビューについては、「Microsoft HDInsight on AKS のプレビュー情報」を参照してください。 質問や機能の提案については、詳細を記載した要求を AskHDInsight で送信してください。また、その他の更新情報については、Azure HDInsight コミュニティのフォローをお願いいたします。

ジョブのパフォーマンスを満たし、コストを事前に管理するためのクラスターのサイズ設定は、常に難しく、判断が困難です。 クラウド上にデータ レイクハウスを構築する有益な利点の 1 つは柔軟性です。つまり、自動スケーリング機能を使用して、手元のリソースの使用率を最大化します。 Kubernetes を使用した自動スケーリングは、コスト最適化エコシステムを確立するための 1 つの鍵です。 どの企業でも使用パターンが変動すると、クラスターの負荷が時間の経過とともに変化し、クラスターのプロビジョニング不足 (パフォーマンス低下) または過剰プロビジョニング (アイドル状態のリソースによる不要なコスト) につながる可能性があります。

HDInsight on AKS で提供されている自動スケーリング機能を使用すると、クラスター内のワーカー ノードの数を自動的に増減できます。 自動スケーリングは、顧客が使用するクラスター メトリックとスケーリング ポリシーを使用します。

この機能は、次を使用することがあるミッション クリティカルなワークロードに適しています。

  • ハイ パフォーマンスとスケーリングに SLA を必要とする可変または予測不可能なトラフィック パターン。または
  • クラスターでジョブを正常に実行するために必要なワーカー ノードを使用可能にするための事前に定義されたスケジュール。

HDInsight on AKS クラスターを使用した自動スケーリングを使用すると、クラスターのコスト効率と Azure の柔軟性が向上します。

自動スケーリングを使用すると、顧客はワークロードに影響を与えずにクラスターをスケールダウンできます。 これは、正常な使用停止や冷却期間などの高度な機能を使用することで可能になっています。 これらの機能により、ユーザーは、クラスターの現在の負荷に基づいてノードの追加と削除に関する情報に基づいた選択を行うことができます。

動作方法

この機能は、クラスターのメトリック、またはスケールアップやスケールダウン操作の定義済みスケジュールに基づいて、事前設定された制限内でノードの数をスケーリングすることで動作します。 自動スケーリング イベントをトリガーする条件には、さまざまなクラスター パフォーマンス メトリックのしきい値ベースのトリガー (負荷ベースのスケーリングと呼ばれます) と、時間ベースのトリガー (スケジュールベースのスケーリングと呼ばれます) の 2 種類があります。

負荷ベースのスケーリングでは、ユーザーが設定した範囲内でクラスター内のノードの数が変更され、最適な CPU 使用率と最小のランニング コストが保証されます。

スケジュール ベースのスケーリングでは、スケールアップ操作やスケールダウン操作のスケジュールに基づいて、クラスター内のノードの数が変更されます。

Note

自動スケーリングでは、既存のクラスターの SKU の種類の変更はサポートされていません。

クラスターの互換性

自動スケーリング機能と互換性があるクラスターの種類と、どれが使用可能または対応予定であるかを次の表に示します。

ワークロード 負荷ベース スケジュールベース
Flink 計画済み はい
Trino 可** 可**
Spark 可** 可**

**正常な使用停止を構成可能。

スケーリング方法

  • スケジュールベースのスケーリング:

    • ジョブが固定されたスケジュールで予測可能な期間実行されることが予想されるか、1 日のうちの特定の時間帯に使用頻度が低いことが予想されるとき (業務時間後のテストおよび開発環境、1 日の終わりのジョブなど)。

      スケジュールベースのスケーリングを選択する方法を示すスクリーンショット。

  • 負荷ベースのスケーリング:

    • 負荷パターンが 1 日の間に大きく予測不能に変動するとき (さまざまな要因に基づいて負荷パターンがランダムに変動する注文データ処理など)。

      負荷ベースのスケーリングを選択する方法を示すスクリーンショット。

      新しい [Configure scale rule] (スケーリング ルールの構成) オプションを使用して、スケーリング ルールをカスタマイズできるようになりました。

      負荷ベースのスケーリングでスケール ルールを構成する方法を示すスクリーンショット。

      負荷ベースのスケーリングのスケール ルールを構成する際にルールを追加する方法を示すスクリーンショット。

      ヒント

      • ルールのスケールアップは、1 つ以上のルールがトリガーされたときに優先されます。 クラスターのプロビジョニング不足を示唆しているスケールアップ対象のルールが 1 つのみの場合でも、クラスターはスケールアップを試みます。 スケールダウンを実行するには、ルールのスケールアップ ルールがトリガーされないことが必要です。

負荷ベースのスケール条件

自動スケーリングがスケーリング要求を発行するのは、次の条件が検出されたときです

スケールアップ スケールダウン
割り当てられたコアが、5 分のポーリング間隔 (1 分のチェック期間) で 80% を超えている 割り当てられたコアが、5 分のポーリング間隔 (1 分のチェック期間) で 20% 以下である

  • スケールアップの場合、自動スケーリングは、必要な数のノードを追加するスケールアップ要求を発行します。 スケールアップは、現在の CPU とメモリの要件を満たすために必要な新しいワーカー ノード数に基づいて行われます。 この値は、設定されているワーカー ノードの最大数に制限されます。

  • スケールダウンの場合、自動スケーリングは、いくつかのノードを削除する要求を発行します。 スケールダウンの考慮事項には、ノードあたりのポッド数、現在の CPU とメモリの要件、ワーカー ノードが含まれます。これらは、現在のジョブの実行に基づく削除の候補です。 スケールダウン操作では、最初にノードの使用が停止された後、クラスターから削除されます。

    重要

    自動スケーリング ルール エンジンは、システム メモリを最適化するために、30 分ごとに古いイベントを予防的にフラッシュします。 その結果、スケーリング ルールの間隔には 30 分という上限が存在します。 スケーリング アクションの一貫性と信頼性の高いトリガーを確保するには、スケーリング ルールの間隔を制限より小さい値に必ず設定する必要があります。 このガイドラインに従うことで、システム リソースを効果的に管理しながら、スムーズで効率的なスケーリング プロセスを保証できます。

クラスターのメトリック

自動スケーリングはクラスターを継続的に監視し、負荷ベースの自動スケーリング用に次のメトリックを収集します。

スケーリングの目的で使用できるクラスターのメトリック

メトリック 説明
使用可能なコアの割合 クラスター内のコアの合計数と比較した、クラスターで使用可能なコアの合計数。
使用可能なメモリの割合 クラスター内のメモリの合計量と比較した、クラスターで使用可能なメモリの合計 (MB 単位)。
割り当てられたコアの割合 クラスター内のコアの合計数と比較した、クラスターに割り当てられたコアの合計数。
割り当てられたメモリの割合 クラスター内のメモリの合計量と比較した、クラスターに割り当てられたメモリの量。

既定では、上記のメトリックは 300 秒ごとにチェックされます。これは、自動スケーリングのカスタマイズ オプションを使用してポーリング間隔をカスタマイズするときにも構成できます。 自動スケーリングでは、これらのメトリックに基づいてスケールアップやスケールダウンの決定が行われます。

Note

既定では、自動スケーリングは、Apache Spark 用 YARN の既定のリソース計算ツールを使用します。 負荷ベースのスケーリングは、Apache Spark クラスターで使用できます。

正常な使用停止

企業には、自動スケーリングを使用してペタバイト規模を実現し、不要になったときにリソースを正常に使用停止する方法が必要です。 このようなシナリオでは、正常な使用停止機能が便利です。

正常な使用停止を使用すると、自動スケーリングによってワーカー ノードの使用停止がトリガーされた後でも、ジョブを完了できます。 この機能を使用すると、ジョブが完了するまでノードのプロビジョニング状態を継続できます。

  • Trino: ワーカーは、正常な使用停止が既定で有効になっています。 コーディネーターは、終了されるワーカーをクラスターから削除する前に、構成された期間、そのワーカーがタスクを完了するのを許可します。 タイムアウトは、ネイティブの Trino パラメーター shutdown.grace-period を使用するか、Azure portal のサービス構成ページで構成できます。

  • Apache Spark: スケールダウンは、クラスター内の実行中のジョブに影響する/を停止する可能性があります。 Azure portal で正常な使用停止設定を有効にすると、YARN ノードの正常な使用停止が組み込まれ、ワーカー ノードで進行中の作業が完了してから、ノードが HDInsight on AKS クラスターから削除されるようになります。

クールダウン期間

継続的なスケールアップ操作を回避するために、自動スケーリング エンジンは構成可能な間隔を待機してから、新たな一連のスケールアップ操作を開始します。 既定値は 180 秒に設定されています

Note

  • カスタム スケーリング ルールでは、トリガー間隔が 30 分を超えるルール トリガーはありません。 自動スケーリング イベントが発生した後で、新たなスケーリング ポリシーを適用するまでの待機時間。
  • クラスター メトリックをリセットできるように、クールダウン期間はポリシー間隔より長くする必要があります。

はじめに

  1. 自動スケーリングを機能させるためには、左側のペインの IAM を使用して、所有者または共同作成者アクセス許可をクラスター レベルで MSI (クラスターの作成時に使用) に割り当てる必要があります。

  2. ロールの割り当てを追加する方法については、次の図および示した手順を参照してください

    ロールの割り当ての追加方法を示すスクリーンショット。

  3. [ロールの割り当ての追加] を選択します。

    1. 割り当ての種類: 特権管理者ロール
    2. ロール: 所有者または共同作成者
    3. メンバー: マネージド ID を選択し、クラスターの作成フェーズ中に与えられたユーザー割り当てマネージド ID を選択します。
    4. ロールを割り当てます。

スケジュールベースの自動スケーリングでクラスターを作成する

  1. クラスター プールが作成されたら、(クラスターの種類で) 目的のワークロードを使用して新しいクラスターを作成し、通常のクラスター作成プロセスの一環であるその他の手順を完了します。

  2. [構成] タブで、[自動スケーリング] トグルを有効にします。

  3. [スケジュールベース] の自動スケーリングを選択します

  4. タイムゾーンを選択し、[+ ルールの追加] をクリックします

  5. 新しい条件を適用する曜日を選択します。

  6. 条件を有効にする時刻と、クラスターのスケーリング後のノード数を編集します。

    スケジュールベースの自動スケーリングを開始する方法を示すスクリーンショット。

    Note

    • 自動スケーリングを機能させるには、ユーザーにクラスター MSI の "所有者" または "共同作成者" ロールが必要です。
    • 既定値は、クラスターが作成されるときに、その初期サイズを定義します。
    • 2 つのスケジュールの差は、既定で 30 分に設定されます。
    • 時刻値は 24 時間形式に従います
    • 連続期間が日をまたがって 24 時間を超える場合は、日をまたがって自動スケーリング スケジュールを設定する必要があります。自動スケーリングは、23:59 は 00:00 (同じノード数の場合) であり、2 日間にわたる 22:00 から 23:59 と 00:00 から 02:00 は、22:00 から 02:00 であると想定します。
    • 既定では、スケジュールは協定世界時 (UTC) で設定されます。 使用可能なドロップダウンで、ローカル タイム ゾーンに対応するタイム ゾーンにいつでも更新できます。 夏時間に従うタイム ゾーンでは、スケジュールが自動的に調整されません。それに応じたスケジュールの更新を管理する必要があります。

負荷ベースの自動スケーリングでクラスターを作成する

  1. クラスター プールが作成されたら、(クラスターの種類で) 目的のワークロードを使用して新しいクラスターを作成し、通常のクラスター作成プロセスの一環であるその他の手順を完了します。

  2. [構成] タブで、[自動スケーリング] トグルを有効にします。

  3. [負荷ベース] の自動スケーリングを選択します

  4. ワークロードの種類に基づいて、[Graceful decommission timeout] (正常な使用停止のタイムアウト) と [Cool down period] (クールダウン期間) を追加するオプションがあります

  5. 最小と最大のノードを選択し、必要に応じてスケール ルールを構成して、ニーズに合わせて自動スケーリングをカスタマイズします。

    負荷ベースの自動スケーリングを開始する方法を示すスクリーンショット。

    ヒント

    • サブスクリプションには、リージョンごとに容量のクォータがあります。 ヘッド ノードのコアの総数とワーカー ノードの最大数の合計が容量のクォータを超えることはできません。 ただし、このクォータはソフト制限です。それを簡単に増やすためのサポート チケットをいつでも作成できます。
    • コア クォータの合計制限を超えると、The maximum node count you can select is {maxCount} due to the remaining quota in the selected subscription ({remaining} cores) というエラー メッセージが表示されます。
    • ルールのスケールアップは、1 つ以上のルールがトリガーされたときに優先されます。 クラスターのプロビジョニング不足を示唆しているスケールアップ対象のルールが 1 つのみの場合でも、クラスターはスケールアップを試みます。 スケールダウンを実行するには、ルールのスケールアップ ルールがトリガーされないことが必要です。
    • パブリック プレビューでは、AKS 上の HDInsight は、クラスター内で最大 500 ノードをサポートします。

Resource Manager テンプレートでクラスターを作成する

スケジュールベースの自動スケーリング

clusterProfile -> autoscaleProfile セクションに自動スケーリングを追加することで、Azure Resource Manager テンプレートを使用してスケジュールベースの自動スケーリング付きの HDInsight on AKS クラスターを作成できます。

自動スケーリング ノードには、変更が行われるタイミングを記述するタイムゾーンとスケジュールを持つ繰り返しが含まれています。 完全な Resource Manager テンプレートについては、サンプルの JSON を参照してください

{
  "autoscaleProfile": {
    "enabled": true,
    "autoscaleType": "ScheduleBased",
    "gracefulDecommissionTimeout": 60,
    "scheduleBasedConfig": {
      "schedules": [
        {
          "days": [
            "Monday",
            "Tuesday",
            "Wednesday"
          ],
          "startTime": "09:00",
          "endTime": "10:00",
          "count": 2
        },
        {
          "days": [
            "Sunday",
            "Saturday"
          ],
          "startTime": "12:00",
          "endTime": "22:00",
          "count": 5
        },
        {
          "days": [
            "Monday",
            "Tuesday",
            "Wednesday",
            "Thursday",
            "Friday"
          ],
          "startTime": "22:00",
          "endTime": "23:59",
          "count": 6
        },
        {
          "days": [
            "Monday",
            "Tuesday",
            "Wednesday",
            "Thursday",
            "Friday"
          ],
          "startTime": "00:00",
          "endTime": "05:00",
          "count": 6
        }
      ],
      "timeZone": "UTC",
      "defaultCount": 110
    }
  }
}

ヒント

  • スケーリング操作の失敗を回避するために、ARM デプロイを使用して競合しないスケジュールを設定する必要があります。

負荷ベースの自動スケーリング

clusterProfile -> autoscaleProfile セクションに自動スケーリングを追加することで、Azure Resource Manager テンプレートを使用して負荷ベースの自動スケーリング付きの HDInsight on AKS クラスターを作成できます。

自動スケーリング ノードに含まれる内容は次のとおりです。

  • ポーリング間隔、クールダウン期間、
  • 正常な使用停止、
  • 最小と最大のノード、
  • 標準的なしきい値規則、
  • 変更が行われるタイミングを記述するスケーリング メトリック。

完全な Resource Manager テンプレートについては、次のサンプルの JSON を参照してください

  {
  "autoscaleProfile": {
    "enabled": true,
    "autoscaleType": "LoadBased",
    "gracefulDecommissionTimeout": 60,
    "loadBasedConfig": {
      "minNodes": 2,
      "maxNodes": 157,
      "pollInterval": 300,
      "cooldownPeriod": 180,
      "scalingRules": [
        {
          "actionType": "scaleup",
          "comparisonRule": {
            "threshold": 80,
            "operator": " greaterThanOrEqual"
          },
          "evaluationCount": 1,
          "scalingMetric": "allocatedCoresPercentage"
        },
        {
          "actionType": "scaledown",
          "comparisonRule": {
            "threshold": 20,
            "operator": " lessThanOrEqual"
          },
          "evaluationCount": 1,
          "scalingMetric": "allocatedCoresPercentage"
        }
      ]
    }
  }
}

REST API を使用して

REST API を使用して、実行中のクラスターに対する自動スケーリングの有効と無効を切り替えるには、自動スケーリング エンドポイントに次のように PATCH 要求を行います。https://management.azure.com/subscriptions/{{USER_SUB}}/resourceGroups/{{USER_RG}}/providers/Microsoft.HDInsight/clusterpools/{{CLUSTER_POOL_NAME}}/clusters/{{CLUSTER_NAME}}?api-version={{HILO_API_VERSION}}

  • 要求ペイロードでは適切なパラメーターを使用します。 JSON ペイロードを使用して、自動スケーリングを有効にできます。
  • 自動スケーリングを無効にするには、ペイロード (autoscaleProfile: null) を使用するか、フラグ (enabled、false) を使用します。
  • リファレンスについては、上記の手順で言及した JSON サンプルを参照してください。

実行中のクラスターの自動スケーリングを一時停止する

自動スケーリングに一時停止機能が導入されました。 これで、Azure portal を使用して、実行中のクラスターの自動スケーリングを一時停止できます。 自動スケーリングの一時停止と再開を選択する方法を以下の図に示します

自動スケーリングを一時停止する方法を示すスクリーンショット。

自動スケーリング操作は、再開したくなったら、再開できます。

自動スケーリングを再開する方法を示すスクリーンショット。

ヒント

複数のスケジュールを構成していて、自動スケーリングを一時停止しているときは、次のスケジュールがトリガーされません。 ノードが使用停止状態であっても、ノード数は同じままです。

自動スケーリング構成をコピーする

Azure portal を使用して、クラスター プール全体にわたって形状が同じクラスターに対して同じ自動スケーリング構成をコピーできるようになりました。この機能を使用して、同じ構成をエクスポートまたはインポートできます。

自動スケーリングから構成をエクスポートまたはインポートする方法を示すスクリーンショット。

自動スケーリング アクティビティを監視する

クラスターの状態

Azure portal に一覧表示されるクラスターの状態は、自動スケーリング アクティビティの監視に役立ちます。 表示される可能性があるすべてのクラスターのステータス メッセージについて、次の一覧で説明します。

クラスターの状態 説明
Succeeded クラスターは正常に動作しています。 これまでのすべての自動スケーリング アクティビティが、正常に完了しています。
承諾済 クラスター操作 (スケールアップなど) が受け付けけられ、操作が完了するのを待っています。
Failed これは、何らかの理由で現在の操作が失敗したことを意味し、クラスターが機能していない可能性があります。
取り消し済み 現在の操作は取り消されています。

クラスターの状態を示すスクリーンショット。

クラスター内の現在のノード数を表示するには、クラスターの [概要] ページにある [クラスター サイズ] グラフに移動します。

クラスター サイズを示すスクリーンショット。

操作の履歴

クラスター メトリックの一部として、クラスターのスケールアップおよびスケールダウンの履歴を表示できます。 また、過去の 1 日、1 週間、またはその他の期間中のすべてのスケーリング アクションを一覧表示することもできます。

アクティビティ ログ上のクラスターの操作履歴を示すスクリーンショット。

その他のリソース

手動スケーリング - Azure HDInsight on AKS