すべてのプロダクト
Search

このプロダクト

    E-MapReduce:ノードグループの手動スケールイン

    ドキュメントセンター

    E-MapReduce:ノードグループの手動スケールイン

    最終更新日:Jun 21, 2026

    クラスターの負荷が長期間低い状態が続き、多くのクラスターリソースがアイドル状態の場合は、リソースの無駄を避けるために、コアノードグループまたはタスクノードグループのスケールインを検討してください。従量課金のタスクノードグループの場合、この操作はコンソールで実行できます。その他のタイプ (従量課金のコアノードグループ、サブスクリプションのタスクノードグループ、サブスクリプションのコアノードグループを含む) については、このトピックで説明する手順に従ってください。

    制限事項

    • クラスター内のコアノード数が HDFS レプリケーション係数と等しい場合、データ損失を防ぐため、コアノードをスケールインしないでください。

    • クラスターが 2 つのマスターノードを持つレガシー Hadoop 高可用性 (HA) クラスターの場合、emr-worker-1 ノードをデコミッションしないでください (レガシー HA クラスターでは、ZooKeeper は work-1 で実行されます)。

    重要な注意事項

    • このトピックの操作はすべて取り消しできません。デコミッションを開始すると、元の状態に戻すことはできません。

    • このトピックはベストプラクティスを示します。ジョブスケジューリングの失敗やデータセキュリティ上のリスクを回避するため、実行前にクラスターの実際の状況を慎重に評価してください。

    デコミッションするノードの選定方法

    ノードグループのスケールインは、そのグループ内のノードをデコミッションすることで実現します。クラスターサービスの負荷に基づいてノードを選定してください。このトピックでは、リソース使用率を確認し、デコミッション候補を特定する 2 つの方法を紹介します。

    方法 1： EMR コンソール チェックの監視

    1. Metric Monitoring ページで、YARN-Queues ダッシュボードの AvailableVCores メトリックを確認します。AvailableVCores が長時間高い値のままの場合、キューには多くのアイドル状態の vCore があるため、Core または Task ノードグループのスケールインを検討できます。

    2. Metric Monitoring ページで、Metric Monitoring ダッシュボードの Metric Monitoring メトリックを確認します。 ノードの Metric Monitoring が長時間高いままである場合、そのノードには利用可能なメモリが潤沢にあるため、解放を検討できます。

    説明

    ビジネス要件に応じて、他のメトリックも組み合わせて判断基準として使用できます。

    方法 2： YARN web UI

    1. キューのリソース使用状況を確認します。キューが一貫して容量をほとんど使用していない場合、コアノードグループまたはタスクノードグループのスケールインを検討してください。

      YARN ResourceManager の [Application Queues] ページで、各パーティション (DEFAULT_PARTITION や batch など) に割り当てられたメモリと vCore、および使用量を確認します。凡例の Capacity、Used、Max Capacity などのメトリックを使用して、キューリソースがアイドル状態かどうかを判断します。

    2. [Nodes] ページで Nodes Address で並べ替え、利用可能なメモリが最も多いノードを素早く特定します。これらのノードの解放を検討してください。

    重要

    クラスターがレガシー Hadoop クラスターの場合、次のケースでは特に注意してください：

    • クラスターが非 HA の場合、emr-worker-1 または emr-worker-2 をデコミッションしないでください。

    • クラスターが HA で、かつマスターノードが 2 台のみの場合、emr-worker-1 をデコミッションしないでください。

    手順 1： デコミッションするノード上のサービスの確認

    コアノードグループまたはタスクノードグループをスケールインするためにノードをデコミッションする前に、まず対象ノード上の関連コンポーネントサービスをデコミッションします。その後、ノードリソースを解放します。デプロイされているコンポーネントは、コンソールの Nodes ページで確認できます。

    [Node Management] ページで、対象のノードグループを展開し、対象ノードを見つけて、ノード行の右側にあるコンポーネント数のアイコン (例： 12 components) をクリックします。ポップアップにデプロイ済みコンポーネントと実行状態が表示されます。

    手順 2： ノードのコンポーネントサービスのデコミッション

    デコミッション予定のノードで次のサービスのいずれかが実行されている場合、ノードを解放する前に該当サービスをデコミッションしてください。実施しない場合、ジョブスケジューリングの失敗やデータセキュリティ上の問題が発生する可能性があります。

    YARN NodeManager のデコミッション

    1. YARN サービスのステータスページに移動します。

      1. E-MapReduce コンソールにログインします。

      2. 上部のメニューバーで、必要に応じてリージョンとリソースグループを選択します。

      3. [EMR on ECS] ページで、対象クラスターのアクション列のServicesをクリックします。

      4. Services ページで、YARN サービスセクションの Status をクリックします。

    2. 対象ノード上の NodeManager をデコミッションします。

      1. Components で、NodeManager の操作列の core_p0 > Unpublish をクリックします。

      2. ダイアログボックスで、Execution Scope > Specific Machineを選択し、Execution Reason を入力し、 OK をクリックします。

      3. 「確認」ダイアログボックスで、OK をクリックします。

    3. 右上隅のOperation Historyをクリックして、進捗を追跡します。

    HDFS DataNode のデコミッション

    1. SSH を使用してマスターノードにログインします。詳細については、「Log on to a cluster」をご参照ください。

    2. hdfs ユーザーに切り替え、アクティブな NameNode の数を確認します。

      sudo su - hdfs
hdfs haadmin -getAllServiceState

    3. 各 NameNode ホストに SSH 接続し、dfs.exclude ファイルを編集して、デコミッションするノードのホスト名を追加します。追加は 1 回につき 1 ノードのみにしてください。

      • レガシー Hadoop クラスター

        touch /etc/ecm/hadoop-conf/dfs.exclude
vim /etc/ecm/hadoop-conf/dfs.exclude

        vim で o を押して改行し、デコミッションする DataNode のホスト名を入力します。

        emr-worker-3.cluster-xxxxx
emr-worker-4.cluster-xxxxx

      • 非レガシー Hadoop クラスター

        touch /etc/taihao-apps/hdfs-conf/dfs.exclude
vim /etc/taihao-apps/hdfs-conf/dfs.exclude

        vim で、o を押して新しい行を開始し、デコミッションする DataNode のホスト名を入力します。

        core-1-3.c-0894dxxxxxxxxx
core-1-4.c-0894dxxxxxxxxx

    4. いずれかの NameNode ホストで hdfs ユーザーに切り替え、refresh コマンドを実行します。HDFS は自動的にデコミッションを開始します。

      sudo su - hdfs
hdfs dfsadmin -refreshNodes

    5. デコミッション結果を確認します。

      次のコマンドを実行して、デコミッションが完了したかどうかを確認します。

      hadoop dfsadmin -report

      指定ノードの Status が Decommissioned と表示されると、データが他のノードへ移行済みであり、デコミッションが完了しています。

    StarRocks のデコミッション

    1. クラスターにログインし、クライアントを使用して接続します。詳細については、「Quick Start」をご参照ください。

    2. DECOMMISSION メソッドを使用して BE をデコミッションするには、次のコマンドを実行します。

      ALTER SYSTEM DECOMMISSION backend "be_ip:be_heartbeat_service_port";

      お使いのクラスターに合わせて、次のパラメーターを置き換えます：

      • be_ip: Nodes ページで確認した、スケールインする BE の内部 IP アドレス。

      • be_heartbeat_service_port: デフォルトは 9050 です。show backends コマンドを使用して確認できます。

      デコミッションが遅い場合、DROP メソッドを使用して強制的にデコミッションできます。

      重要

      DROP メソッドを使用する場合、システムでデータが3重に保持されるようにしてください。

      ALTER SYSTEM DROP backend "be_ip:be_heartbeat_service_port";

    3. 次のコマンドを実行して、BE ステータスを監視します。

      show backends;
      MySQL [(none)]> show backends;
+----------+-----------------+------------+---------------+--------+----------+----------+---------------------+---------------------+-------+----------------------+------------------------+-----------+------------------+---------------+---------------+---------+---------+----------+--------+---------------+----------------------------------------------------+-------------------+-------------+----------+
| BackendId | Cluster         | IP         | HeartbeatPort | BePort | HttpPort | BrpcPort | LastStartTime       | LastHeartbeat       | Alive | SystemDecommissioned | ClusterDecommissioned | TabletNum | DataUsedCapacity | AvailCapacity | TotalCapacity | UsedPct | MaxDiskUsedPct | ErrMsg | Version       | Status                                             | DataTotalCapacity | DataUsedPct | CpuCores |
+----------+-----------------+------------+---------------+--------+----------+----------+---------------------+---------------------+-------+----------------------+------------------------+-----------+------------------+---------------+---------------+---------+---------+----------+--------+---------------+----------------------------------------------------+-------------------+-------------+----------+
| 10049    | default_cluster | 192.16xxx  | 9050          | 9060   | 18040    | 8060     | 2022-11-29 15:47:28 | 2022-11-29 16:09:48 | true  | true                 | false                 | 0         | .000             | 312.400 GB    | 312.978 GB    | 0.18 %  | 0.19 %         |        | 2.3.2-dbc89ae | {"xxxcessReportTabletsTime":"2022-11-29 16:09:28"} | 312.400 GB        | 0.00 %      | 4        |
| 10002    | default_cluster | 192.16xxx  | 9050          | 9060   | 18040    | 8060     | 2022-11-29 15:29:07 | 2022-11-29 16:09:48 | true  | false                | false                 | 10        | .000             | 312.399 GB    | 312.978 GB    | 0.19 %  | 0.19 %         |        | 2.3.2-dbc89ae | {"xxxcessReportTabletsTime":"2022-11-29 16:09:08"} | 312.399 GB        | 0.00 %      | 4        |
| 10003    | default_cluster | 192.16xxx  | 9050          | 9060   | 18040    | 8060     | 2022-11-29 15:29:07 | 2022-11-29 16:09:48 | true  | false                | false                 | 10        | .000             | 312.399 GB    | 312.978 GB    | 0.19 %  | 0.19 %         |        | 2.3.2-dbc89ae | {"xxxcessReportTabletsTime":"2022-11-29 16:09:07"} | 312.399 GB        | 0.00 %      | 4        |
| 10004    | default_cluster | 192.16xxx  | 9050          | 9060   | 18040    | 8060     | 2022-11-29 15:29:07 | 2022-11-29 16:09:48 | true  | false                | false                 | 10        | .000             | 312.399 GB    | 312.978 GB    | 0.19 %  | 0.19 %         |        | 2.3.2-dbc89ae | {"xxxcessReportTabletsTime":"2022-11-29 16:09:08"} | 312.399 GB        | 0.00 %      | 4        |
+----------+-----------------+------------+---------------+--------+----------+----------+---------------------+---------------------+-------+----------------------+------------------------+-----------+------------------+---------------+---------------+---------+---------+----------+--------+---------------+----------------------------------------------------+-------------------+-------------+----------+
4 rows in set (0.01 sec)

      SystemDecommissioned が true のノードはデコミッション中です。TabletNum が 0 になると、システムはメタデータをクリーンアップします。

      結果に BE ノードが表示されなくなった場合、デコミッションは成功です。

    HBase HRegionServer のデコミッション

    1. HBase サービスのステータスページに移動します。

      1. E-MapReduce コンソールにログインします。

      2. 上部のメニューバーで、必要に応じてリージョンとリソースグループを選択します。

      3. [EMR on ECS] ページで、対象クラスターの「操作」列のServices をクリックします。

      4. Services ページで、HBase サービスセクションの Status をクリックします。

    2. 対象ノード上の HRegionServer をデコミッションします。

      1. Components で、HRegionServer の「アクション」列にある STOP をクリックします。

      2. ダイアログボックスで、Execution Scope > Specific Machineを選択し、Execution Reasonを入力し、OKをクリックします。

      3. 「確認」ダイアログボックスで、OK をクリックします。

    3. 右上隅の[操作履歴]をクリックして、進捗状況を確認します。

    HBASE-HDFS DataNode のデコミッション

    1. SSH を使用してマスターノードにログインします。詳細については、「Log on to a cluster」をご参照ください。

    2. 次のコマンドを実行して hdfs ユーザーに切り替え、環境変数を設定します。

      sudo su - hdfs
export HADOOP_CONF_DIR=/etc/taihao-apps/hdfs-conf/namenode

    3. 次のコマンドを実行して、現在の NameNode 情報を確認します。

      hdfs dfsadmin -report

    4. 各 NameNode ホストに SSH 接続し、dfs.exclude ファイルを編集して、デコミッションするノードのホスト名を追加します。追加は 1 回につき 1 ノードのみにしてください。

      touch /etc/taihao-apps/hdfs-conf/dfs.exclude
vim /etc/taihao-apps/hdfs-conf/dfs.exclude

      vim で o を押して新しい行を開始し、デコミッションする DataNode のホスト名を入力します。

      core-1-3.c-0894dxxxxxxxxx
core-1-4.c-0894dxxxxxxxxx

    5. いずれかの NameNode ホストで hdfs ユーザーに切り替え、refresh コマンドを実行します。HDFS は自動的にデコミッションを開始します。

      sudo su - hdfs
export HADOOP_CONF_DIR=/etc/taihao-apps/hdfs-conf/namenode
hdfs dfsadmin -refreshNodes

    6. デコミッション結果を確認します。

      次のコマンドを実行して、デコミッションが完了したかどうかを確認します。

      hadoop dfsadmin -report

      指定ノードの Status が Decommissioned と表示されると、データが他のノードへ移行済みであり、デコミッションが完了しています。

      SmartData JindoStorageService の使用停止 (レガシー Hadoop クラスター)

      1. Go to the SmartData service status page.

        1. E-MapReduce コンソールにログインします。

        2. In the top menu bar, select the region and resource group as needed.

        3. On the EMR on ECS page, click [Services] in the Actions column of the target cluster.

        4. On the [Services] page, click [Status] in the SmartData service section.

      2. Decommission the JindoStorageService on the target node.

        1. In the [Components], click core_p0 > Unpublish in the Actions column for JindoStorageService.

        2. In the dialog box, select Execution Scope > Specific Machine, enter an [Execution Reason], and click [OK].

        3. In the confirmation dialog box, click [OK].

      3. Click [Operation History] in the upper-right corner to track progress.

    手順 3： デコミッション済みノードの解放

    重要

    クラスターのノードを管理するには、ECS コンソールにログインする必要があります。Resource Access Management (RAM) ユーザーの場合は、ECS の権限が必要です。AliyunECSFullAccess ポリシーを付与することを推奨します。

    1. ノード管理ページに移動します。

      1. E-MapReduce コンソールにログインします。

      2. 上部のメニューバーで、必要に応じてリージョンとリソースグループを選択します。

      3. [EMR on ECS]ページで、対象クラスターの Actions 列のNodesをクリックします。

    2. Nodes ページで、解放したいノードの ECS ID をクリックします。

      ECS コンソールにリダイレクトされます。

    3. ECS コンソールでインスタンスを解放します。詳細については、「Release instances」をご参照ください。

    関連ドキュメント

    • 従量課金およびスポットインスタンスのタスクノードグループをスケールインする方法については、「Scale in a cluster」をご参照ください。

    • クラスターのコンピュートリソースが不足している場合は、コアノードグループまたはタスクノードグループをスケールアウトします。詳細については、「Scale out a cluster」をご参照ください。

    • ビジネス要件に基づいてクラスターのコンピュートリソースを自動調整するには、ノードグループに対してマネージドまたはカスタムの Auto Scaling ルールを設定します。詳細については、「Auto Scaling」をご参照ください。