AWS EMRのサイズ変更方法

Question

今日、AWS EMRの使用中にいくつか質問があります。

EMRは、クラスタのサイズを変更するための非常に簡単な方法を提供します。いくつかのノードを削除することは簡単です。

apache hadoopでは、slavesファイルを変更してノードの追加または削除を変更できます。しかし、私はを含むslavesファイルがEMRに入っていて、スレーブがどこにあるかを示す他の設定は見つかりません。

どのようにEMRがマスターノードで再起動処理を行わなくてもクラスタからノードを追加または削除する方法はありますか？

Answer 1

マスターとスレーブファイルは、start-all.sh、start-dfs.shなどのシェルスクリプトでのみ使用されます。これらのファイルは、hadoopの他の機能では使用されません。 hadoopクラスタの観点から、namenode、secondary namenode、workerノードがこれらのファイルによって定義されていない場所。 EMRは、クラスタを起動するためのシェルスクリプトを使用していません。 core-site.xml内のfs.default.nameまたはfs.defaultFSは、namenodeホストを定義します。この構成で始まるすべてのデータノードは、ネームノードに報告され、クラスタに追加されます。同様に、resourcemanagerホストは、すべてのノードのyarn-site.xmlに定義されています。

新しいノードを追加するためにクラスタ内のプロセスを再起動する必要はありません。一旦データノードが立ち上がると、それはネームノードに報告され、このようにしてノードはHDFSに寄与する。同様に、ノードマネージャが起動すると、クラスターのリソースマネージャーに報告し、処理層に寄与します。

EMRには、3種類のノードがあります。

• EMRクラスタのマスターノード
• コアノード
• タスクノード

マスタノードは一つだけであろう。このノードは、名前ノードと、ResourceManager、HBase Masterなどのすべてのマスターサービスを持つノードです。

コアノードは、データノードとノードマネージャがあることを意味するストレージと処理能力を持つノードです。コアノードの数を増やすことはできますが、データが失われるため、コアノードを減らすことはできません。

タスクノードは、処理能力しか持たないノードです。これは基本的に一時的な負荷に対応するためのものです。これにはノードマネージャしかありません。このノードに関連付けられているデータノードはありません。タスクノードの数を増減できます。

クラスタのサイズを変更する際に、既存のクラスタに障害が発生することはありません。 start-all.sh、stop-all.shなどのスクリプトは、EMRで呼び出されません。個々のサービスを開始し、クラスタを起動します。したがって、マスターファイルとスレーブファイルのエントリは考慮されません。

Answer 2

AWSコンソールでクラスタを展開/縮小することができます。

クラスタのサイズを変更するには、resizeオプションを使用します。

「タスク」ノードをコンソールに追加することもできます。

Answer 3

AWS EMRでオートスケーリングを使用すると、クラスタ上のノードでスケールアウトしてスケールすることができます。スケールアウトアクションは、Cloudwatchメトリック（YARNMemoryAvailablePercentageおよびContainerPendingRatio）を使用してトリガーできます。あなたが詳細については、このブログを参照することができ

"AutoScalingPolicy": 
{ 
"Constraints": 
    { 
    "MinCapacity": 10, 
    "MaxCapacity": 50 
    }, 

"Rules": 
[ 
    {"Name": "Compute-scale-up", 
    "Description": "Scale out based on ContainerPending Mterics", 
    "Action": 
    { 
    "SimpleScalingPolicyConfiguration": 
     {"AdjustmentType": "CHANGE_IN_CAPACITY", 
     "ScalingAdjustment": 1, 
     "CoolDown":0} 
    }, 
    "Trigger": 
    {"CloudWatchAlarmDefinition": 
     {"AlarmNamePrefix": "compute-scale-up", 
     "ComparisonOperator": "GREATER_THAN_OR_EQUAL", 
     "EvaluationPeriods": 3, 
     "MetricName": "ContainerPending", 
     "Namespace": "AWS/ElasticMapReduce", 
     "Period": 300, 
     "Statistic": "AVERAGE", 
     "Threshold": 10, 
     "Unit": "COUNT", 
     "Dimensions": 
     [ 
      {"Key": "JobFlowId", 
      "Value": "${emr:cluster_id}"} 
     ] 
     } 
    } 
    }, 
    {"Name": "Compute-scale-down", 
    "Description": "Scale in", 
    "Action": 
    { 
     "SimpleScalingPolicyConfiguration": 
     {"AdjustmentType": "CHANGE_IN_CAPACITY", 
     "ScalingAdjustment": -1, 
     "CoolDown":300} 
    }, 
    "Trigger": 
    {"CloudWatchAlarmDefinition": 
     {"AlarmNamePrefix": "compute-scale-down", 
     "ComparisonOperator": "GREATER_THAN_OR_EQUAL", 
     "EvaluationPeriods": 3, 
     "MetricName": "MemoryAvailableMB", 
     "Namespace": "AWS/ElasticMapReduce", 
     "Period": 300, 
     "Statistic": "AVERAGE", 
     "Threshold": 24000, 
     "Unit": "COUNT", 
     "Dimensions": 
     [ 
      {"Key": "JobFlowId", 
      "Value": "${emr:cluster_id}"} 
     ] 
     } 
    } 
    } 
] 
} 

以下のサンプル・ポリシーhttps://aws.amazon.com/blogs/big-data/dynamically-scale-applications-on-amazon-emr-with-auto-scaling/