1

プロビジョニングの時間を短縮するために、専用の EMR クラスターを 5 つのインスタンスで維持することにしました (約 5 つ必要になると予想されます)。さらに必要な場合は、何らかの自動スケーリングを実装する必要があると考えています。

EMR にはまったく詳しくありません。自動スケーリングはサポートされていますか? ドキュメントでこれを見つけました：http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/emr-manage-resize.html

それは自動スケーリングを探す正しい場所ですか、それとも「サイズ変更」の意味を誤解していますか。EMR の利点の 1 つは「オンデマンド処理」であると読みましたが、インスタンス数を指定しなくても ec2 インスタンス間で負荷が分割されるため、ec2 インスタンスのスケーリングを独自に行っているという印象を受けます。 、つまり、自分自身を自動スケーリングする必要はありません。「オンデマンド処理」の意味を誤解していますか?

私が提供したサイズ変更リンクが私がやろうとしていることに対して適切である場合、サイズ変更のタイミングを決定した経験がある人はいますか? このドキュメントでは、サイズ変更のタイミングについてアラームを鳴らす方法などについては説明していません。通常の自動スケーリング サービスを使用しており、特定の条件に基づいてサイズを変更できますが、ここでは表示されません。

EMR の自動スケーリングが悪い考えであるかどうかはまだわかりません。(これを提供する Qubole のような企業全体が存在するため) または、EMR は必要なコンピューティング パワーを既に使用しているため、あまり役に立たないのでしょうか? EMR が実際に提供するものについてはあまり知らないので、混乱しているのかもしれません。

4

2 に答える 2

7

リンクしたページには、クラスター内のノードを手動またはプログラムで増やす方法が示されていました。EMR の自動スケーリングについて他に何も見つかりませんでした。

いくつかの事実が欠けていない限り、独自のスケーリング アルゴリズムとプロセスを考え出す必要があります。ジョブのバックログ、支払っている時間の単位、安価な「スポット」インスタンスの使用、複数のクラスターなどの要因を考慮している場合、これはおそらく簡単な作業ではありません。

クラスターのサイズが大きくなるだけでなく、ダウンサイジングもあります。EMR はタスク ノードに対してこれを (手動またはプログラムで) 許可しますが、コア ノードに対しては許可しないと述べています。AWS の機能を介してコア ノードを終了する必要があり、データを失うリスクがあります。ワークロードが時間の経過とともに増減する場合、コア ノードのダウンサイジングは、コストを低く抑えるのに役立ちます。

Qubole は、箱から出してこれらすべてを自動的に処理します。UI または API からジョブを実行すると、クラスターが開始、サイズ変更、またはサイズ変更されます。完了すると、クラスターが縮小または終了します。また、同時に最小数のノードを常に実行することもできます。また、Qubole ノードの起動時間は EMR よりも大幅に速いと聞いています。

これがお役に立てば幸いです。

于 2014-12-12T13:28:09.607 に答える