Azure HDInsight クラスターを自動的にスケール調整する

[アーティクル]
04/13/2023

Azure HDInsight の無料の自動スケーリング機能を使用すると、お客様が採用したクラスターのメトリックとスケーリングポリシーに基づいて、クラスター内のワーカーノードの数を自動的に増減できます。自動スケーリング機能は、パフォーマンスメトリックまたはスケールアップ操作やスケールダウン操作の定義されたスケジュールに基づいて、事前設定された制限内でノードの数をスケーリングすることで機能します。

しくみ

自動スケーリング機能では、スケーリングイベントをトリガーするために 2 種類の条件を使用します。さまざまなクラスターパフォーマンスメトリックのしきい値 ("負荷ベースのスケーリング" と呼ばれます) と、時間ベースのトリガー ("スケジュールベースのスケーリング" と呼ばれます) です。負荷ベースのスケーリングでは、ユーザーが設定した範囲内でクラスター内のノードの数が変更され、最適な CPU 使用率と最小のランニングコストが保証されます。スケジュールベースのスケーリングでは、スケールアップ操作やスケールダウン操作のスケジュールに基づいて、クラスター内のノードの数が変更されます。

次のビデオでは、自動スケーリングによって解決される課題の概要と、HDInsight を使用したコストの管理にそれがどのように役立つかについて説明します。

負荷ベースまたはスケジュールベースのスケーリングを選択する

スケジュールに基づくスケーリングは次のような場合に使用できます。

ジョブが固定されたスケジュールの予測可能な継続時間で実行されることが予想される場合、または 1 日のうちの特定の時間帯に使用頻度が低いことが予想される場合 (たとえば、業務時間後のテスト環境や開発環境、1 日の終わりのジョブなど)。

負荷ベースのスケーリングは次のような場合に使用できます。

ロードパターンが 1 日のうちで大きく変動し、予測不能である場合。たとえば、さまざまな要因に基づいてロードパターンのランダムな変動がある注文データ処理などです

クラスターのメトリック

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

メトリック	説明
保留中の CPU の合計	すべての保留中のコンテナーの実行を開始するために必要なコアの総数。
保留中のメモリの合計	すべての保留中のコンテナーの実行を開始するために必要なメモリの合計 (MB 単位)。
空き CPU の合計	アクティブなワーカーノード上のすべての未使用のコアの合計。
空きメモリの合計	アクティブなワーカーノード上の未使用のメモリの合計 (MB 単位)。
ノードごとの使用済みメモリ	ワーカーノード上の負荷。 10 GB のメモリが使用されているワーカーノードは、使用済みメモリが 2 GB のワーカーノードより多くの負荷がかかっていると見なされます。
ノードごとのアプリケーションマスターの数	ワーカーノード上で実行されているアプリケーションマスター (AM) コンテナーの数。 2 つの AM コンテナーをホストしているワーカーノードは、ホストしている AM コンテナーがないワーカーノードより重要であると見なされます。

上のメトリックは 60 秒ごとにチェックされます。自動スケーリングでは、これらのメトリックに基づいてスケールアップおよびスケールダウンの決定が行われます。

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

次の条件が検出されると、自動スケーリングによりスケーリング要求が発行されます。

スケールアップ	スケールダウン
保留中の CPU の合計が、空き CPU の合計を超えて 3-5 分以上が経過した。	保留中の CPU の合計が空き CPU の合計を下回って 3 分から 5 分以上が経過した。
保留中のメモリの合計が、空きメモリの合計を超えて 3-5 分以上が経過した。	保留中のメモリの合計が空きメモリの合計を下回って 3 分から 5 分以上が経過した。

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

スケールダウンの場合、自動スケーリングでは、いくつかのノードを削除する要求が発行されます。スケールダウンは、ノードあたりのアプリケーションマスター (AM) コンテナーの数に基づいて行われます。現在の CPU とメモリの要件にもです。また、サービスでは、現在のジョブの実行に基づいて、削除候補のノードも検出されます。スケールダウン操作では、最初にノードの使用が停止された後、クラスターから削除されます。

自動スケーリングのための Ambari DB のサイズ設定に関する考慮事項

自動スケーリングの利点を得るために、Ambari DB のサイズを正しく設定することをお勧めします。お客様は、正しい DB 層を使用し、大規模なクラスターに対してカスタム Ambari DB を使用する必要があります。データベースとヘッドノードのサイズ設定の推奨事項に関するページをお読みください。

クラスターの互換性

重要

Azure HDInsight 自動スケーリング機能は、Spark および Hadoop クラスター向けに 2019 年 11 月 7 日に一般提供され、プレビューバージョンの機能では利用できない機能強化が追加されました。 2019 年 11 月 7 日より前に Spark クラスターを作成済みで、クラスター上で自動スケーリング機能を使用する場合、推奨されるパスは、新しいクラスターを作成し、新しいクラスター上で自動スケーリングを有効にすることです。

Interactive Query (LLAP) の自動スケーリングは、2020 年 8 月 27 日に HDI 4.0 用に一般公開されました。自動スケーリングは、Spark、Hadoop、Interactive Query、およびクラスター上でのみ使用できます。

次の表では、自動スケーリング機能と互換性のあるクラスターの種類とバージョンについて説明します。

Version	Spark	Hive	Interactive Query	hbase	Kafka
HDInsight 4.0 (ESP なし)	はい	はい	はい*	いいえ	いいえ
HDInsight 4.0 (ESP あり)	はい	はい	はい*	いいえ	いいえ
HDInsight 5.0 (ESP なし)	はい	はい	はい*	いいえ	いいえ
HDInsight 5.0 (ESP あり)	はい	はい	はい*	いいえ	いいえ

* Interactive Query クラスターは、負荷ベースではなく、スケジュールベースのスケーリングの場合にのみ構成できます。

はじめに

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

負荷ベースのスケーリングで自動スケーリング機能を有効にするには、通常のクラスターの作成プロセスの一部として、次の手順を行います。

[構成と価格] タブで、 [自動スケーリングの有効化] チェックボックスをオンにします。
[Autoscale type](自動スケーリングの種類) で、 [Load-based](負荷ベース) を選択します。
次のプロパティに対して目的の値を入力します。
- [ワーカーノード] の初期の [Number of nodes](ノードの数) 。
- ワーカーノードの [最小] の数。
- ワーカーノードの [最大] の数。

ワーカーノードの初期の数には、最小数から最大数までの数を指定する必要があります。この値によって、クラスターが作成されるときのその初期サイズが定義されます。ワーカーノードの最小数は、3 以上に設定する必要がありますクラスターを 3 つ未満のノードにスケーリングすると、ファイルレプリケーションが不十分なためにセーフモードでスタックする場合があります。詳細については、「セーフモードでスタックする」を参照してください。

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

スケジュールベースのスケーリングで自動スケーリング機能を有効にするには、通常のクラスターの作成プロセスの一部として、次の手順を行います。

[Configuration + pricing](構成と価格) タブで、[自動スケーリングの有効化] チェックボックスをオンにします。
[ワーカーノード] の [Number of nodes](ノードの数) を入力します。これは、クラスターのスケールアップの制限を制御します。
[Autoscale type](自動スケーリングの種類) で、 [Schedule-based](スケジュールベース) オプションを選択ます。
[構成] を選択して [Autoscale configuration](自動スケーリングの構成) ウィンドウを開きます。
タイムゾーンを選択し、 [+ Add condition](+ 条件の追加) をクリックします
新しい条件を適用する曜日を選択します。
条件を有効にする時刻と、クラスターのスケーリング後のノード数を編集します。
必要に応じて、さらに条件を追加します。

ノードの数は、3 から条件追加前に入力したワーカーノードの最大数の間にする必要があります。

最後の作成手順

[ノードサイズ] の下のドロップダウンリストから VM を選択して、ワーカーノードの VM の種類を選択します。ノードの種類ごとに VM の種類を選択すると、クラスター全体の概算のコスト範囲を表示できるようになります。予算に合わせて VM の種類を調整します。

Enable worker node schedule-based autoscale node size.

サブスクリプションには、リージョンごとに容量のクォータがあります。ヘッドノードのコアの総数とワーカーノードの最大数の合計が容量のクォータを超えることはできません。ただし、このクォータはソフト制限です。それを簡単に増やすためのサポートチケットをいつでも作成できます。

注意

合計のコアクォータ制限を超えた場合は、"最大ノードがこのリージョン内の使用可能なコア数を超えました。別のリージョンを選択するか、またはサポートに連絡してクォータを増やしてください" というエラーメッセージが表示されます。

Azure portal を使用した HDInsight クラスターの作成に関する詳細については、「Azure Portal を使用した HDInsight の Linux ベースのクラスターの作成」を参照してください。

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

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

JSON スニペットに示すように、プロパティ minInstanceCount と maxInstanceCount で computeProfile>workernode セクションに autoscale ノードを追加することで、Azure Resource Manager テンプレートで負荷ベースの自動スケーリングを使用する HDInsight クラスターを作成できます。完全なリソースマネージャーテンプレートについては、負荷ベースの自動スケーリングを有効にして Spark クラスターをデプロイするクイックスタートテンプレートを参照してください。

{
  "name": "workernode",
  "targetInstanceCount": 4,
  "autoscale": {
      "capacity": {
          "minInstanceCount": 3,
          "maxInstanceCount": 10
      }
  },
  "hardwareProfile": {
      "vmSize": "Standard_D13_V2"
  },
  "osProfile": {
      "linuxOperatingSystemProfile": {
          "username": "[parameters('sshUserName')]",
          "password": "[parameters('sshPassword')]"
      }
  },
  "virtualNetworkProfile": null,
  "scriptActions": []
}

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

computeProfile>workernode セクションに autoscale ノードを追加することで、Azure Resource Manager テンプレートでスケジュールベースの自動スケーリングを使用する HDInsight クラスターを作成できます。 autoscale ノードには、timezone および変更が行われるタイミングが記述されている schedule がある recurrence が含まれます。完全な Resource Manager テンプレートについては、「Deploy Spark Cluster with schedule-based Autoscale Enabled」 (スケジュールベースの自動スケーリングを有効にして Spark クラスターをデプロイする) を参照してください。

{
  "autoscale": {
    "recurrence": {
      "timeZone": "Pacific Standard Time",
      "schedule": [
        {
          "days": [
            "Monday",
            "Tuesday",
            "Wednesday",
            "Thursday",
            "Friday"
          ],
          "timeAndCapacity": {
            "time": "11:00",
            "minInstanceCount": 10,
            "maxInstanceCount": 10
          }
        }
      ]
    }
  },
  "name": "workernode",
  "targetInstanceCount": 4
}

実行中のクラスターの自動スケーリングの有効化および無効化

Azure ポータルの使用

実行中のクラスターで自動スケーリングを有効にするには、 [設定] の [クラスターサイズ] を選択します。次に、 [自動スケーリングの有効化] を選択します。使用する自動スケーリングの種類を選択し、負荷ベースまたはスケジュールベースのスケーリングのオプションを入力します。最後に、 [保存] を選択します。

Enable worker node schedule-based autoscale running cluster.

REST API の使用

REST API を使用して、実行中のクラスターで自動スケーリングを有効または無効にするには、自動スケーリングエンドポイントに POST 要求を行います。

https://management.azure.com/subscriptions/{subscription Id}/resourceGroups/{resourceGroup Name}/providers/Microsoft.HDInsight/clusters/{CLUSTERNAME}/roles/workernode/autoscale?api-version=2018-06-01-preview

要求ペイロードでは適切なパラメーターを使用します。自動スケーリングを有効にするには、次の json ペイロードを使用できます。自動スケーリングを無効にするには、ペイロード {autoscale: null} を使用します。

{ "autoscale": { "capacity": { "minInstanceCount": 3, "maxInstanceCount": 5 } } }

すべてのペイロードパラメーターの完全な説明については、前のセクションの負荷ベースの自動スケーリングの有効化を参照してください。実行中のクラスターで自動スケーリングサービスを強制的に無効にすることはお勧めしません。

自動スケーリングアクティビティの監視

クラスターの状態

Azure portal に表示されるクラスターの状態は、自動スケーリングアクティビティの監視に役立ちます。

Enable worker node load-based autoscale cluster status.

表示される可能性があるすべてのクラスター状態メッセージを、次の一覧で説明します。

クラスターの状態	説明
実行中	クラスターは正常に動作しています。以前のすべての自動スケーリングアクティビティは、正常に完了しました。
更新中	クラスターの自動スケーリング構成は更新されています。
HDInsight 構成	クラスターのスケールアップまたはスケールダウン操作が進行中です。
更新エラー	自動スケーリング構成の更新中に HDInsight で問題が発生しました。お客様は、更新の再試行または自動スケーリングの無効化を選択できます。
エラー	クラスターに何らかの問題があり、使用できません。このクラスターを削除し、新しいクラスターを作成してください。

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

操作の履歴

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

[監視] で [メトリック] を選択します。その後、 [メトリックの追加] を選択し、 [メトリック] ドロップダウンボックスから [Number of Active Workers](アクティブなワーカーの数) を選択します。右上にあるボタンを選択して、時間の範囲を変更します。

Enable worker node schedule-based autoscale metric.

ベストプラクティス

スケールアップ操作およびスケールダウン操作の待ち時間について検討する

スケーリング操作全体が完了するまでに、10 分から 20 分かかる場合があります。カスタマイズしたスケジュールを設定する場合は、この遅延を考慮してください。たとえば、午前 9 時にクラスターサイズを 20 にする必要がある場合は、スケーリング操作が午前 9 時までに完了するように、スケジュールのトリガーを午前 8 時 30 分以前などの早い時刻に設定する必要があります。

スケールダウンを準備する

クラスターのスケールダウンプロセス中、自動スケーリングはターゲットサイズを満たすためにノードを使用停止にします。負荷ベースの自動スケーリングで、それらのノードでタスクが実行中の場合、自動スケーリングでは Spark および Hadoop クラスターに対するタスクが完了するまで待機します。各ワーカーノードは HDFS でのロールも果たすため、一時データは残りのワーカーノードに移動されます。残りのノードに、すべての一時データをホストするのに十分なスペースがあることを確認します。

Note

スケジュールに基づく自動スケーリングのスケールダウンの場合、正常な使用停止はサポートされていません。これにより、スケールダウン操作中にジョブが失敗する可能性があります。予想されるジョブスケジュールパターンに基づいてスケジュールを計画し、進行中のジョブが完了するための十分な時間を含めることをお勧めします。ジョブの失敗を回避するために、完了時刻の履歴の分布を確認してスケジュールを設定できます。

使用パターンに基づいてスケジュールベースの自動スケーリングを構成する

スケジュールベースの自動スケーリングを構成する場合、クラスターの使用パターンを把握しておく必要があります。 Grafana ダッシュボードは、クエリの負荷と実行スロットを理解するのに役立ちます。このダッシュボードから、利用可能な実行プログラムスロットと実行プログラムスロットの合計数を取得できます。

ここでは、必要なワーカーノードの数を見積もる方法を示します。変動するワークロードを処理するために、さらに 10% のバッファーを追加することをお勧めします。

使用される実行プログラムスロットの数 = 実行プログラムスロットの合計数 - 使用可能な実行プログラムスロットの合計数。

必要なワーカーノードの数 = 実際に使用される実行プログラムスロットの数 / (hive.llap.daemon.num.executors + hive.llap.daemon.task.scheduler.wait.queue.size)

*hive.llap.daemon.num.executors は構成可能であり、既定値は 4 です。

*hive.llap.daemon.task.scheduler.wait.queue.size は構成可能であり、既定値は 10 です。

カスタムスクリプトの操作

カスタムスクリプトアクションは、主にノード (つまり、HeadNode/WorkerNode) をカスタマイズするために使用されます。これにより、お客様が使用している特定のライブラリとツールを構成できます。一般的な使用例の 1 つは、クラスター上で実行されるジョブが、顧客が所有するサードパーティライブラリに対して何らかの依存関係がある可能性があり、ジョブが成功するにはそれをノードで使用できる必要がある場合です。現在、自動スケーリングでは、永続化されるカスタムスクリプトアクションがサポートされます。そのため、スケールアップ操作の一環として新しいノードがクラスターに追加されるたびに、これらの永続化されたスクリプトアクションが実行され、コンテナーまたはジョブがそれらに割り当てられることがポストされます。カスタムスクリプトアクションを使用すると、新しいノードをブートストラップするのに役立ちますが、スケールアップの全体的な待機時間が長くなり、スケジュールされたジョブに影響を与える可能性があるので、最小限に抑えることをお勧めします。

クラスターの最小サイズに注意する

クラスターを 3 つ未満のノードにスケールダウンしないでください。クラスターを 3 つ未満のノードにスケーリングすると、ファイルレプリケーションが不十分なためにセーフモードでスタックする場合があります。詳細については、「セーフモードでスタックする」を参照してください。

Microsoft Entra Domain Services とスケーリング操作

Microsoft Entra Domain Services マネージドドメインに参加している Enterprise セキュリティパッケージ (ESP) で HDInsight クラスターを使用する場合は、Microsoft Entra Domain Services の負荷を調整することをお勧めします。複雑なディレクトリ構造のスコープ付き同期では、スケーリング操作への影響を避けることをお勧めします。

ピーク時の使用状況シナリオに対する Hive 構成の同時実行クエリの最大合計数を設定する

Ambari では、Hive 構成の同時実行クエリの最大合計数は、自動スケーリングイベントによって変更されません。つまり Hive Server 2 Interactive Service では、Interactive Query デーモンの数が負荷やスケジュールに基づいてスケールアップまたはスケールダウンされた場合でも、任意の時点で指定された数の同時実行クエリのみを処理できます。一般的には、手動による介入を避けられるように、ピーク時の使用状況シナリオに合わせてこの構成を設定することをお勧めします。

ただし、ワーカーノードが少数しかなく、同時実行クエリの最大合計数の値が非常に高く構成されている場合に、Hive Server 2 の再起動エラーが発生することがあります。少なくとも、指定された数の Tez AM に対応できるワーカーノードの最小数が必要です (同時実行クエリの最大合計数の構成と同じ)。

制限事項

Interactive Query デーモン数

自動スケーリングが有効な Interactive Query クラスターの場合は、自動スケーリングのアップまたはダウンイベントによって、アクティブなワーカーノードの数に合わせて Interactive Query デーモンの数もスケールアップまたはスケールダウンされます。デーモンの数の変化は、Ambari の num_llap_nodes 構成には保持されません。 Hive サービスが手動で再起動された場合は、Ambari の構成に従って Interactive Query デーモンの数がリセットされます。

Interactive Query サービスが手動で再起動された場合、Advanced hive-interactive-env の下の num_llap_node 構成 (Hive Interactive Query デーモンを実行するために必要なノードの数) を手動で変更し、現在アクティブなワーカーノードの数と一致させる必要があります。 Interactive Query クラスターでは、スケジュールベースの自動スケーリングのみがサポートされます。

次のステップ

クラスターを手動でスケーリングするためのガイドラインについては、スケーリングのガイドラインに関するページをお読みください。