CloudWatch で EMR イベントをセットアップするタイミング - Amazon EMR

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

CloudWatch で EMR イベントをセットアップするタイミング

DescribeCluster、DescribeStDescribeStep、ListClusters などの一部のポーリング API では、CouldWatch イベントを設定すると、変更に対する応答時間が短縮され、サービスクォータが解放されます。たとえば、ステップが完了したりクラスターが終了したりするなど、クラスターの状態が変化したときに実行するように Lambda 関数が設定されている場合、そのトリガーを使用して、次のポーリングを待つのではなく、ワークフローで次のアクションを開始できます。それ以外の場合は、専用 Amazon EC2 インスタンスまたは Lambda 関数が EMR API の変更を常にポーリングしている場合、コンピューティングリソースを浪費するだけでなく、サービスクォータに達する可能性があります。

次に、イベント駆動型アーキテクチャに移行することでメリットが得られるケースをいくつか示します。

ケース 1: ステップ完了のためのDescribeCluster API呼び出しを使用したEMR ポーリング

例 ステップ完了のためのDescribeCluster API呼び出しを使用したEMR ポーリング

一般的なパターンは、実行中のクラスターにステップを送信し、Amazon EMR にそのステップに関するステータスをポーリングすることです。通常は DescribeCluster API または DescribeStep API を使用します。このタスクは、の Amazon EMR Step Status Change イベントに接続することで、最小限の遅延で実行することもできます。

このイベントには、ペイロードに次の情報が含まれます。

{ "version": "0", "id": "999cccaa-eaaa-0000-1111-123456789012", "detail-type": "EMR Step Status Change", "source": "aws.emr", "account": "123456789012", "time": "2016-12-16T20:53:09Z", "region": "us-east-1", "resources": [], "detail": { "severity": "ERROR", "actionOnFailure": "CONTINUE", "stepId": "s-ZYXWVUTSRQPON", "name": "CustomJAR", "clusterId": "j-123456789ABCD", "state": "FAILED", "message": "Step s-ZYXWVUTSRQPON (CustomJAR) in Amazon EMR cluster j-123456789ABCD (Development Cluster) failed at 2016-12-16 20:53 UTC." } }

詳細マップでは、Lambda 関数が「状態」、「stepId」、または「ClusterId」を解析して、関連する情報を検索できます。

ケース 2: ワークフローを実行するための使用可能なクラスターの EMR のポーリング

例 ワークフローを実行するための使用可能なクラスターの EMR のポーリング

複数のクラスターを実行する顧客のパターンは、クラスターが利用可能になったらすぐにワークフローを実行することです。実行中のクラスターが多数あり、待機中のクラスターでワークフローを実行する必要がある場合、使用可能なクラスターの DescribeCluster または ListClusters API 呼び出しを使用して EMR をポーリングするパターンがあります。クラスターがステップの準備ができているかどうかを知る際の遅延を減らすもう 1 つの方法は、で Amazon EMR クラスターの状態変更イベントを処理することです。

このイベントには、ペイロードに次の情報が含まれます。

{ "version": "0", "id": "999cccaa-eaaa-0000-1111-123456789012", "detail-type": "EMR Cluster State Change", "source": "aws.emr", "account": "123456789012", "time": "2016-12-16T20:43:05Z", "region": "us-east-1", "resources": [], "detail": { "severity": "INFO", "stateChangeReason": "{\"code\":\"\"}", "name": "Development Cluster", "clusterId": "j-123456789ABCD", "state": "WAITING", "message": "Amazon EMR cluster j-123456789ABCD ..." } }

このイベントでは、ステータスが WAITING に変わるとすぐに、待機中のワークフローをクラスターに送信するように Lambda 関数を設定できます。

ケース 3: クラスタ終了のための EMR のポーリング

例 クラスタ終了のための EMR のポーリング

多数の EMR クラスターを実行しているお客様の一般的なパターンは、Amazon EMR に終了したクラスターをポーリングして、作業が送信されないようにすることです。このパターンは、DescribeCluster および ListClusters API 呼び出しを使用するか、の Amazon EMR クラスターの状態変更イベントを使用して実装できます。

クラスターの終了時に、放出されるイベントは次の例のようになります。

{ "version": "0", "id": "1234abb0-f87e-1234-b7b6-000000123456", "detail-type": "EMR Cluster State Change", "source": "aws.emr", "account": "123456789012", "time": "2016-12-16T21:00:23Z", "region": "us-east-1", "resources": [], "detail": { "severity": "INFO", "stateChangeReason": "{\"code\":\"USER_REQUEST\",\"message\":\"Terminated by user request\"}", "name": "Development Cluster", "clusterId": "j-123456789ABCD", "state": "TERMINATED", "message": "Amazon EMR Cluster jj-123456789ABCD (Development Cluster) has terminated at 2016-12-16 21:00 UTC with a reason of USER_REQUEST." } }

ペイロードの「詳細」セクションには、処理可能な ClusterID と状態が含まれます。