Amazon EMR 再構成を使用してクラスターをその場で変更する

長期にわたって稼働する Amazon EMR クラスターを使用している開発者またはデータサイエンティストであれば、急激に変化するワークロードに直面します。これらの変化では、クラスターで最適に実行するために、異なるアプリケーションの構成をしばしば必要とします。

再構成機能を使用して、EMR クラスターを実行するときに、構成を変更することができるようになりました。EMR リリース emr-5.21.0 から、この機能を使用すると、新しいクラスターを作成せずに、または各ノードに SSH で手動で接続せずに、構成を変更できるようになりました。

この記事では、次のトピックについて取り上げます。

再構成の使用
インスタンスグループの状態、構成バージョン、イベント
再構成例の使用事例
再構成の利点

再構成の使用

以下のタスクは、EMR release emr-5.21.0 で更新されます。

再構成の提出
構成の変更
構成レベルの定義

再構成の提出

EMR コンソール、SDK、または AWS CLI を通じて認識を送信できます。詳細については、認識の送信と追加情報を参照してください。.

構成の変更

再構成を送信するときに、クラスターに適用する構成のすべてを含まなければなりません。更新のみがこれらの項目に適用され、ほかのすべてを削除します。構成を変更すると、EMR コンソールはまた前のクラスター構成も追跡します。

構成レベルの定義

アプリケーションのクラスターレベルとインスタンスグループレベルの構成を定義します。クラスターを作成するため、クラスターレベルの構成を提供します。これらの構成は、クラスターが開始し実行中となった後で追加された場合でも、その後自動的にすべてのインスタンスグループに適用されます。構成が開始した後で、クラスターレベルの構成を変更できません。しかし、再構成リクエストを通じて、インスタンスグループレベルでこれらの構成を補足またはオーバーライドできます。インスタンスグループの再構成要求を送信するたびに、これらの新しいインスタンスグループレベルの構成は継承されたクラスターレベルの構成よりも優先されます。

インスタンスグループでクラスタレベルとインスタンスグループレベルの設定がどのように連携して機能するかをよりよく理解するために、EMRコンソールで簡単なデモを見てください。

[構成] タブで、[フィルター] ドロップダウンリストのインスタンスグループを選択します。該当するインスタンスグループの構成表に移動します。構成表の [ソース] 列は、構成のレベルを示します。

このクラスターは、次のクラスターレベルの構成セットで始まります。

[
  {
    "Classification": "core-site",
    "Properties": {
      "Key-A": "Value-1",
      "Key-B": "Value-2"
    }
  }
]

コンソールでご覧のとおり、インスタンスグループ ig-Y4E3MN8C4YBP は自動的にクラスターレベルの構成セットを継承します。ここで、次の通り、インスタンスグループを再構成します。

[
  {
    "Classification": "core-site",
    "Properties": {
      "Key-A": "Value-a",
      "Key-C": "Value-3"
    }
  }
]

リクエストが処理されると、構成「Key-A」の値はインスタンスグループレベルの構成によってオーバーライドされ、「Value-1」から「Value-a」に変わります。対照的に、構成「Key-B」の値は変更されないままになります。しばらくの間、リクエストは新しい補足構成「Key-C」を導入します。コンソールの構成表には、常にこの種のわずかな変更が表示されます。

クラスターレベルとインスタンスグループレベルの構成をカスタマイズする方法の詳細については、「クラスター作成時の設定の指定」を参照してください。

インスタンスグループの状態、構成バージョン、イベント

再構成リクエストの状態は、インスタンスグループの状態遷移、構成バージョンの増加、および CloudWatch イベントに表示されます。それぞれが再構成リクエストを見逃さないようにする方法を理解してください。

インスタンスグループの状態: インスタンスグループは、再構成要求を受け取ると、RUNNING 状態から RECONFIGURING 状態に移行します。RECONFIGURING 状態は、再構成プロセスの開始を示します。プロセスが完了して新しい設定が有効になると、インスタンスグループは RUNNING 状態に戻ります。次に、アプリケーションの Web UI またはアプリケーション固有のコマンドを使用して設定を確認できます。
構成バージョン: 送信した再設定要求ごとに、新しいバージョン番号で区別された新しい設定セットが確立されます。構成バージョンは 0 から始まり、新しい構成セットを送信するたびに 1 ずつ増えます。各インスタンスグループはそれぞれの構成バージョン番号を維持します。バージョン番号は、異なるインスタンスグループを再構成する回数に応じて増えます。
イベント:EMR は Amazon CloudWatch イベントとしてそれぞれの再構成リクエストに対する状態を投稿します。これらのイベントは、リクエストが送信され、再構成操作が開始し、それが完了する正確な時刻をリストします。追跡しやすくするために、各リクエストは関連付けられた構成バージョンと共に投稿されます。たとえば、次のイベントフローは、EMR がインスタンスグループで一般的な再構成要求を実行する方法を示しています:

再構成操作のEMRイベントとインスタンスグループの状態遷移の一覧については、『EMR管理ガイド』を参照してください

再構成例の使用事例

以下にいくつかの再構成操作の使用事例を挙げます。

HDFS ブロックサイズの再構成
容量スケジューラ―キューの構成

HDFS ブロックサイズの再構成

変動するワークロードに対応できます。これらの変更は、クラスターの存続期間を通じて新しいアプリケーション構成を要求する可能性があります。

たとえば、長く実行しているクラスタ―のワークロードとファイルサイズが増加したとします。現在のクラスターを置き換えずに、この成長を説明したいと思います。

よりパフォーマンスを向上させるために HDFS サイズを増やすために、新しい再構成機能を利用します。HDFS NameNode はクラスターの各データブロックをトラッキングします。このブロックサイズを大きくすると、NameNode によって監視されるブロック数が減るため、HDFS のパフォーマンスが向上する可能性があります。さらに、この機能は必要なマッパーの数を減らすことによってジョブのパフォーマンスを向上させます。

HDFS ブロックサイズをデフォルト 128 GB から 256 GB を増やすには、同じノードを実行するマスタインスタンスグループに再構成リクエストを送信します。

$ aws emr modify-instance-groups --cli-input-json file://reconfiguration.json

reconfiguration.json ファイルの例は次の通りです。

reconfiguration.json:
{
  "ClusterId": "j-MyClusterID",
  "InstanceGroups":[
  {
    "InstanceGroupId": "ig-MyMasterId",
    "Configurations": [
    {
      "Classification": "hdfs-site",
      "Properties": {
        "dfs.blocksize": "256m"
      },
    "Configurations": []
    }]
  }]
}

次に、EMR 再構成プロセスは、「dfs.blocksize」パラメータを hdfs-size.xml ファイル内の指定された「256 m」の値に変更します。再構成プロセスはまた、自動的に NameNodeを再開して、新しい構成をピックアップします。クラスターに追加された新しいブロックは、自動的に 256 MB の新しいデフォルトブロックサイズを使用します。既存のブロックにこのデフォルトを適用する場合は、次の手順に従ってください。

ブロックを新しいロケーションにコピーします。
元を削除します。
ブロックを元の場所にコピーして戻します。

復元されたブロックは、新しいデフォルトブロックサイズを選択します。NameNode は、短い再起動時間中にアクティブでなくなります。

容量スケジューラ―キューの構成

異なる Hadoop ジョブの間でのクラスターリソース共有方法を変更しますか? 実行中のクラスターで YARN CapacityScheduler 構成を変更します。別の組織で管理している大きな共有クラスターで新しいキューを追加しますか? 異なるキューの間で容量の割り当てを変更して、変化するワークロードに合わせますか?

EMR 再構成機能を使用して、再構成リクエストをマスタノードに送信することにより変更を行います。新しい構成は、数分居ないにキューに適用されます。マスタノードにログインしたり、設定ファイルを直接更新したり、手動でキューを更新したりする必要はありません。

EMR クラスタではデフォルトによって単一キューを伴います。 2 つの追加のキュー、アルファ、ベータを作成し、クラスターの合計リソース容量の各 30％をそれぞれのキューに割り当てます。該当の変更を行うために、再構成リクエストを送信するサンプルコマンドは以下の通りです。

$ aws emr modify-instance-groups --cli-input-json file://reconfiguration.json

reconfiguration.json ファイルの例は次の通りです。

reconfiguration.json:
{
   "ClusterId":"j-MyClusterID",
   "InstanceGroups":[
      {
         "InstanceGroupId":"ig-MyMasterId",
         "Configurations":[
            {
               "Classification":"capacity-scheduler",
               "Properties":{
                  "yarn.scheduler.capacity.root.queues":"default,alpha,beta",
                  "yarn.scheduler.capacity.root.default.capacity":"40",
                  "yarn.scheduler.capacity.root.default.accessible-node-labels.CORE.capacity":"40",
                  "yarn.scheduler.capacity.root.alpha.capacity":"30",
                  "yarn.scheduler.capacity.root.alpha.accessible-node-labels":"*",
                  "yarn.scheduler.capacity.root.alpha.accessible-node-labels.CORE.capacity":"30",
                  "yarn.scheduler.capacity.root.beta.capacity":"30",
                  "yarn.scheduler.capacity.root.beta.accessible-node-labels":"*",
                  "yarn.scheduler.capacity.root.beta.accessible-node-labels.CORE.capacity":"30"
               },
               "Configurations":[]
            }
         ]
      }
   ]
}

両方のキューで「*」ラベルにアクセスすることができ、それぞれがコアノードというラベルにアクセスできます。さらに、すべてのキューの容量の合計は 100 と等しくなければなりません。デフォルトキューの容量は、40％減ります。

最終的に、コアラベルへの各キューのアクセスの容量はキュー自体の容量と一致します。つまり、コア区画は残りのクラスターと同じ割合でキューの間を分割します。

このステップを完了した後で、YARN ResourceManager Web UI に進み、変更が行われたことを確認します。

EMR 再構成の利点

以下は EMR 再構成の利点です。

ローリング再構成プロセス
再構成の失敗と復帰

ローリング再構成プロセス

EMR 再構成の主な利点の 1 つは、ローリング再構成プロセスです。ドキュメントから抜粋:

「Amazon EMR はタスクとコアインスタンスグループのインスタンスを再構成するための「ローリング」プロセスに従っています。インスタンスグループのインスタンスの 10 パーセントのみが同時に変更されて再開されます。このプロセスは完了までに長い時間がかかりますが、実行中のクラスタでの潜在的なアプリケーションの障害の確率を減らします。」

ローリング再構成は、コアノードの 90% が再構成中に実行し続けることにより、HDFS ダウンタイムに対して保護します。EMR の YARN ではさらに、NodeManager の復元を有効にしています。NodeManager は再構成が再開した後で実行中のコンテナを復元します。

コンテナが常にアクティブであるため、一部の MapReduce ジョブは再構成プロセス中に正常に実行し続けることができます。しかし、すべてのアプリケーションが再起動の後に復元するとは限りません。たとえば、YARN の Spark (EMR デフォルト) では、NodeManager の再起動の後にエグゼキュータの問題やジョブの障害が発生する可能性があります。

本番稼働中の再構成の前に、安全環境で行う計画にしている再構成のタイプでアプリケーションをテストします。

最終的に、ローリング再構成プロセスでは、インスタンスグループの構成状態の一時的な不一致が生じる場合があります。不一致が生じる一方で、一部のインスタンスは古い構成をもっている一方で、ほかのインスタンスは新しくリクエストしたものをもっている場合があります。クラスターを再構成するとき、この状況で考えられる副作用を考えてください。

再構成の失敗と復帰

EMR はまた再構成の失敗からインスタンスグループを復元することもできます。

新しい構成を有効にするために、EMR は再構成されたアプリケーションを再開し、それらが再構成操作が完了したことを宣言する前に実行されていることを確認します。

しかし、任意のノードでアプリケーションが正常に再起動されない場合、再構成操作は失敗し、インスタンスグループは引き続き、RECONFIGURING 状態のままになります。このような失敗は、問題のある構成値によってもたらされます。たとえば、「yarn.resourcemanager.scheduler.address」の無効なアドレスは、YARN ResourceManager が再起動を失敗させる恐れがあります。

かかる状況で、EMR は構成の復帰を自動的にトリガーします。復帰はインスタンスグループで設定した前の作業構成を再適用します。復帰は復帰が完了するとすぐに、インスタンスグループを RUNNING 状態に戻します。したがって、インスタンスグループは機能状態に戻り、クラスターのアプリケーションの可用性を維持します。ローリング再構成はプロセス中、継続します。

前の作業構成が再適用された後でアプリケーションが起動しない場合、EMR はインスタンスグループをさらに再構成を試みるのではなく、ARRESTED 状態にします。インスタンスグループを ARRESTED 状態から解放するには、新しい再構成リクエストを送信します。

まとめ

この記事では、新しい EMR クラスター再構成機能を使用して実行中のクラスターにインスタンスグループを構成する方法の基礎を示します。再構成リクエストを送信することの追加のセマンティクス、重要な構成レベルの概念、および再構成追跡方法の方法について説明しました。また、実際の再構成の例をいくつか示し、再構成の2つの便利な機能について説明しました。

新しいクラスターの再構成機能を試してみて、皆様の経験についてのコメントを私たちにお寄せください。

著者について

Brandon Scheller は、Amazon EMR のソフトウェア開発エンジニアです。Hadoop エコシステムのアプリケーション開発や、オープンソースコミュニティとの連携に情熱を注いでいます。余暇にはカスケード山地で登山を楽しんでいます。

Junyang Li は Amazon EMR のソフトウェア開発エンジニアです。 EMR の最先端機能に取り組み、オープンソースプロジェクトにも携わっています。作業のほかに、彼女はアートやクラフト、運動や旅行を楽しんでいます。

Amazon Web Services ブログ