Amazon EMR のよくある質問

Amazon EMRは、Apache Spark、Apache Hive、Prestoなどのオープンソースフレームワークを使用して、データ処理、対話型分析、機械学習を行う業界をリードするクラウドビッグデータプラットフォームです。EMR では、従来のオンプレミスソリューションの半分以下のコスト、標準的な Apache Spark の 1.7 倍以上の速さで、ペタバイト規模の分析を実行できます。

Amazon EMR を使えば、コンピューティング容量やオープンソースアプリケーションの管理を心配することなく、データの変換や分析に集中でき、コストも節約できます。EMR を使用すると、Amazon EC2 で必要なだけの容量を即座にプロビジョニングし、変化するコンピューティング需要を管理するスケーリングルールを設定できます。CloudWatch アラートを設定して、インフラストラクチャの変更の通知を受け取り、すばやく対応することができます。Kubernetes を使用する場合、EMR を使用して、ワークロードを Amazon EKS クラスターに送信することもできます。EC2 または EKS のどちらを使用しても、分析速度を上げ、時間とお金の両方を節約する EMR の最適化ランタイムからメリットを得ます。

Amazon EC2、Amazon Elastic Kubernetes Service (EKS)、またはオンプレミスのAWS Outpostsを使用して、ワークロードをEMRにデプロイできます。EMR コンソール、API、SDK または CLI を使ってワークロードを実行して管理し、Amazon Managed Workflows for Apache Airflow (MWAA) または AWS Step Functions を使用して調整することができます。インタラクティブな体験には、EMR Studio や SageMaker Studio を使用できます。

Amazon EMRにサインアップするには、Amazon EMRの詳細ページ http://aws.amazon.com/emr にある「今すぐサインアップ」ボタンをクリックしてください。Amazon EMRにアクセスするには、Amazon EC2とAmazon S3にサインアップしている必要があります。これらのサービスにまだサインアップしていない場合は、Amazon EMRのサインアッププロセス中にサインアップするよう促されます。サインアップの後、Amazon EMR ドキュメントを参照してください。こちらには、サービスを活用するためのベストプラクティスとなる当社の開始方法のガイドが含まれます。

サービスレベルアグリーメントを参照してください。

これらの記事とチュートリアルにあるサンプルコードを確認してください。EMR Studio を使用する場合、ノートブックの例一式を使用して、機能を確認できます。

Amazon EMR Studio にある R、Python、Scala、PySpark で記述されたデータエンジニアリングおよびデータサイエンスアプリケーションを簡単に開発、視覚化、デバッグできます。例えば、Eclipse、Spyder、PyCharm、またはRStudioを使用してデスクトップ上でデータ処理ジョブを開発し、それをAmazon EMRで実行することもできます。さらに、新しいクラスターを起動するときにソフトウェア設定で JupyterHub または Zeppelin を選択し、1 つ以上のインスタンスを使用して Amazon EMR でアプリケーションを開発できます。

コマンドラインツールやAPIは、クラスタの実行をプログラムで開始して進行状況を監視したり、クラスタ周りに追加のカスタム機能（複数の処理ステップを持つシーケンス、スケジューリング、ワークフロー、監視など）を作成したり、他のAmazon EMRのユーザー向けに付加価値のあるツールやアプリケーションを構築したりすることができます。対照的に、AWSマネジメントコンソールは、ウェブブラウザから直接クラスタを起動および監視するための使いやすいグラフィカルインターフェースを提供します。

はい。ジョブが実行中になっている場合、AddJobFlowSteps API を使って、オプションでステップを追加することができます。AddJobFlowSteps API は、現在のステップシーケンスの終わりに新しいステップを追加します。クラスターやデバッグで条件付きロジックを実装するために、この API を使用したい場合があるかもしれません。

Amazon SNS に登録して、クラスターが終了したときに SNS トピックに投稿されるようにすることができます。AWSマネジメントコンソールでクラスタの進行状況を確認することもできますし、コマンドライン、SDK、またはAPIを使用してクラスタのステータスを取得することもできます。

はい。すべてのステップが完了したときに、自動終了フラグをオンにすることでクラスタを自動的に終了させることができます。

Amazon EMR 5.30.0 以降、Amazon EMR 6.x シリーズは、Amazon Linux 2 に基づいています。別の方法として、Amazon Linux 2 を基に作成したカスタム AMI を指定することもできます。こうすることで、事実上どのようなアプリケーションにも、高度な事前設定を実行できます。詳細については、カスタム AMI の使用を参照してください。

はい。 お客様のクラスターにサードパーティのソフトウェアパッケージをインストールするには、ブートストラップアクションを使用することです。また、Hadoop 分散キャッシュメカニズムを使用して、静的にコンパイルした実行可能ファイルをアップロードすることもできます。EMR 6.x は Hadoop 3 をサポートしており、これにより YARN NodeManager はコンテナを EMR クラスターのホスト上で直接起動するか、または Docker コンテナ内で起動することができます。詳細については、ドキュメントをご覧ください。

クラスタに関する情報を収集して何が問題だったのかを判断するのに役立つ、いくつかのツールがあります。Amazon EMR Studio を使用する場合は、Spark UI や YARN Timeline Service のようなツールを起動して、デバッグを簡素化できます。Amazon EMR コンソールから、Apache Spark、Tez UI、YARN タイムラインサーバーの永続的なアプリケーションユーザーインターフェイスへのクラスター外アクセス、いくつかのクラスター内アプリケーションユーザーインターフェイス、そしてすべての YARN アプリケーションの Amazon EMR コンソールでのアプリケーション履歴の概要ビューを取得できます。SSH を使用してマスターノードに接続し、ウェブインターフェイスを介してクラスターインスタンスを確認することもできます。詳細については、ドキュメントを参照してください。

EMR Studioは、データサイエンティストやデータエンジニアがR、Python、Scala、PySparkで書かれたデータエンジニアリングおよびデータサイエンスアプリケーションを開発、可視化、デバッグするのを簡単にする統合開発環境（IDE）です。

EMR Studio は、フルマネージド型のアプリケーションで、シングルサインオン、フルマネージド型の Jupyter Notebooks、インフラストラクチャの自動プロビジョニングなどの機能がそなわっています。また、AWS コンソールもしくはクラスターにログインする必要なく、ジョブをデバッグすることも可能です。データサイエンティストとアナリストは、カスタムのカーネルやライブラリのインストール、および、GitHub や BitBucket などのコードリポジトリを使用した同僚との共同作業が行えます。あるいは、スケジュールしたワークフローの内部で、パラメータ化されたノートブックを実行するために、Apache Airflow、AWS Step Functions、および Apache Airflow 用の Amazon マネージドワークフローなどのオーケストレーションサービスを使用できます。 Amazon MWAA を使用して、Amazon EMR ノートブックでの分析ジョブのオーケストレーションについて学ぶことができます。EMR Studio カーネルとアプリケーションは EMR クラスターで実行されるため、パフォーマンス最適化 Apache Spark 用 Amazon EMR ランタイムを使用して、分散データ処理の恩恵を享受できます。管理者は、アナリストが既存のEMRクラスター上でアプリケーションを実行したり、EMR用の事前定義されたAWS CloudFormationテンプレートを使用して新しいクラスターを作成したりできるように、EMR Studioを設定できます。

EMR Studioを使用すると、AWSコンソールにログインせずに、企業の認証情報で完全管理されたJupyterノートブックに直接ログインでき、ノートブックを数秒で起動し、サンプルノートブックで導入を受け、データ探索を行うことができます。また、ノートブックからカスタムのカーネルや Python のライブラリをロードすれば、環境をカスタマイズできます。EMR Studio カーネルとアプリケーションは EMR クラスターで実行されるため、パフォーマンス最適化 Apache Spark 用 Amazon EMR ランタイムを使用して、分散データ処理の恩恵を享受できます。同僚との共同作業のためには、GitHub や他のレポジトリ経由でノートブックを共有します。ノートブックを継続的インテグレーションおよびデプロイパイプラインとして直接実行することもできます。ノートブックには、さまざまなパラメータ値を渡すことが可能です。また、ノートブックをチェーンしたり、Apache Airflow のようなワークフローオーケストレーションサービスを使用して、ノートブックをスケジュールされたワークフローの中に統合したりできます。さらに、Spark UIやYARN Timelineサービスなどのネイティブアプリケーションインターフェースを使用して、できるだけ少ないクリックでクラスターやジョブのデバッグを行うことができます。

相違点は大きく 5 つあります。

1. EMR Studio の使用には AWS マネジメントコンソールへのアクセスは必要ありません。EMR Studio のホスティングは、AWS マネジメントコンソールの外部で行われています。これは、データサイエンティストやデータエンジニアに対し、AWS マネジメントコンソールへのアクセス権を付与しない場合に便利です。

2. EMR Studio へのログインには、AWS IAM アイデンティティセンター (AWS SSO の後継) を使用して、ID プロバイダーから提供される、企業内の認証情報を使用できます。 

3. EMR Studio により、ノートブックファーストな作業環境が実現します。EMR Studio カーネルとアプリケーションは EMR クラスターで実行されるため、パフォーマンス最適化 Apache Spark 用 Amazon EMR ランタイムを使用して、分散データ処理の恩恵を享受できます。クラスタでコードを実行するのは、ノートブックを既存のクラスタに接続するか、新しいクラスタを作成するだけで簡単です。

4. EMR Studio では、シンプルなユーザーインターフェースを使用しながら、ハードウェア構成を抽象化することができます。例えば、一度セットアップしたクラスターテンプレートを、新たに他のクラスターを開始する際にも使用できます。 

5. EMR Studioは、可能な限り少ないクリックでネイティブアプリケーションのユーザーインターフェースにアクセスできる、簡略化されたデバッグ体験を提供します。

EMR Studio と SageMaker Studio の両方を Amazon EMR で使用できます。EMR Studio は、R、Python、Scala、PySpark で記述されたデータエンジニアリングおよびデータサイエンスアプリケーションを簡単に開発、視覚化、デバッグできるようにした統合開発環境 (IDE) を提供します。Amazon SageMaker Studio では、機械学習に関するすべての開発手順を実行できる、一元的な、ウェブベースのビジュアルインターフェイスが提供されます。SageMaker Studio をご利用のお客様には、モデルの構築、トレーニング、デプロイに必要な各ステップにおいて、完全なアクセスと管理の手法、ならびに可視性が提供されます。データを素早くアップロードしたり、新しいノートブックを作成したり、モデルをトレーニングおよびチューニングしたり、実験を調整するためにステップ間を行き来したり、結果を比較したり、モデルを本番環境にデプロイしたり、すべて一つの場所で行えるため、作業効率が大幅に向上します。 

まず、管理者が EMR Studio をセットアップする必要があります。管理者からAmazon EMR Studio用のユニークなサインオンURLを受け取ったら、会社の認証情報を使って直接Studioにログインすることができます。

いいえ。管理者が EMR Studio をセットアップし、アクセス用の URL を発行した後は、作業チームは企業での認証情報を使用して EMR Studio にログインできるようになります。AWS マネジメントコンソールには、一切ログインする必要はありません。EMR Studioでは、チームは管理者によって設定されたタスクを実行したり、リソースにアクセスしたりすることができます。

IAM アイデンティティセンター (AWS SSO の後継) は、EMR Studio のシングルサインオンサービスプロバイダーです。AWS IAM によりサポートされている ID プロバイダーの一覧は、こちらのドキュメントでご確認いただけます。

WorkSpace は、Jupyter ノートブックを整理するために使用します。WorkSpace 内にあるすべてのノートブックは、Amazon S3 の同一のロケーションに保存され、同じクラスター上で実行されます。また、WorkSpace 内のすべてのノートブックには、GitHub などのコードレポジトリからリンクすることもできます。ワークスペースはクラスターに接続する前に作成して設定することができますが、ノートブックを実行する前にクラスターに接続する必要があります。

はい。クラスターにアタッチしない状態でも、WorkSpace を作成したりオープンしたりできます。実行しようとするときのみ、それらの WorkSpace をクラスターに接続する必要が生じます。EMR Studio カーネルとアプリケーションは EMR クラスターで実行されます。したがって、パフォーマンスに最適化された Apache Spark 用 の Amazon EMR ランタイムを使用することで、分散データ処理のメリットを得られます。

すべての Spark クエリは EMR クラスター上で実行されるため、Spark アプリケーションが使用するすべてのランタイムライブラリをクラスターにインストールする必要があります。ノートブックセル内でノートブックに範囲が制限されたライブラリを簡単にインストールできます。クラスターのマスターノードには、ノートブックのセル内で、またはSSHでマスターノードに接続している間に、Jupyter NotebookのカーネルやPythonライブラリをインストールすることもできます。詳細については、ドキュメントを参照してください。さらに、クラスターを作成するときに、ブートストラップアクションやカスタムAMIを使用して必要なライブラリをインストールすることができます。詳細については、Amazon EMR 管理ガイドで「追加のソフトウェアをインストールするためのブートストラップアクションの作成」および「カスタム AMI の使用」を参照してください。

ワークスペースとワークスペース内のノートブックファイルは、ワークスペース作成時に指定した Amazon S3 の場所に、定期的に ipynb ファイル形式で自動保存されます。ノートブックファイルには、Amazon EMR Studio のノートブックと同じ名前が付いています。

Git ベースのリポジトリを Amazon EMR Studio ノートブックに関連付けて、バージョン管理された環境でノートブックを保存できます。

EMR Studio を使用すると、Amazon Elastic Compute Cloud (Amazon EC2) 上で実行されている Amazon EMR や、Amazon Elastic Kubernetes Service (Amazon EKS) 上の Amazon EMR でノートブックコードを実行できます。ノートブックのアタッチは、既存または新規のクラスターの両方で可能です。EMR Studio では、EMR クラスターを作成する方法は 2 通りあります：AWS サービスカタログを通じて事前設定されたクラスター テンプレートを使ってクラスターを作成する方法、またはクラスター名、インスタンス数、インスタンスの種類を指定してクラスターを作成する方法です。

はい、以下の要領で行えます。まず WorkSpace を開き、左側にある [EMR クラスター] アイコンをクリックします。次に、[デタッチ] ボタンをクリックし、[クラスターを選択] のドロップダウンリストからクラスターを選択します。その後に [アタッチ] ボタンをクリックします。

EMR Studio の左側にある [WorkSpace] タブを開くと、ご自身や、同じ AWS アカウントの他のユーザーが作成した WorkSpace を、表示することができます。

各 EMR studio には、他の AWS のサービスとの相互運用のためにアクセス許可が必要です。EMR Studios に所望のアクセス許可を付与するためには、管理者が、提供されたポリシーを使用しながら、EMR Studio のサービスロールを作成する必要があります。同時に管理者は、EMR Studio レベルのアクセス許可を定義するために、ユーザーロールも指定します。AWS IAM アイデンティティセンター (AWS SSO の後継) から EMR Studio にユーザーやグループを追加する場合、管理者は、セッションポリシーをそのユーザーもしくはグループに割り当てることで、きめの細かいアクセスコントロールを適用することができます。セッションポリシーは、複数のIAMロールを作成する必要なく、管理者がユーザーの権限を細かく調整するのに役立ちます。セッションポリシーに関する詳細については、AWS Identity and Access Management ユーザーガイドのポリシーとアクセス許可を参照してください。

はい。高可用性 (マルチマスター) クラスター、Kerberos 対応のクラスター、および AWS Lake Formation クラスターは、現在サポートされていません。

Amazon EMR Studio は、追加料金なしでご利用いただけます。EMR Studio を使用する場合、Amazon Simple Storage Service ストレージおよび Amazon EMR クラスターに適用される料金が適用されます。価格設定オプションと詳細については、Amazon EMR の価格設定を参照してください。

新規のお客様には、EMR Notebooks ではなく、Amazon EMR Studio を使用することをお勧めいたします。EMR Notebooks は、Jupyter Notebook に基づくマネージド環境を提供し、データサイエンティスト、アナリスト、および開発者が EMR クラスターを使用してデータを準備して可視化し、同業者と共同作業を行い、アプリケーションを構築して、インタラクティブな分析を実行できるようにします。新規のお客様には EMR Studio をお勧めしますが、互換性のために EMR Notebooks がサポートされています。

EMRノートブックを使用して、Apache Sparkアプリケーションを構築したり、EMRクラスタ上でインタラクティブなクエリを簡単に実行することができます。複数のユーザーが、コンソールから直接サーバーレスノートブックを作成し、それらを既存の共有 EMR クラスターにアタッチするか、クラスターをコンソールから直接プロビジョニングして、Spark を使った実験を直ちに開始することが可能です。ノートブックをデタッチした後、それらを新しいクラスターにアタッチし直すこともできます。ノートブックは自動で S3 バケットに保存され、保存されたノートブックをコンソールから取得して作業を再開することができます。EMR ノートブックには、Anaconda レジストリにあるライブラリがあらかじめ同梱されているため、これらのライブラリをノートブックコードにインポートして使用し、それらを使ってデータの操作と結果の可視化を行うことが可能になります。さらに、EMRノートブックにはSparkジョブの進行状況を監視したり、ノートブック内からコードをデバッグしたりするための統合されたSparkモニタリング機能があります。

EMR ノートブックの使用を開始するには、EMR コンソールを開き、ナビゲーションペインで [Notebooks] を選択します。そこから、[ノートブックの作成] 選択します。ノートブックの名前を入力して、EMR クラスターを選択 (または新規クラスターを即時に作成)、次にノートブックが使用するサービスロールを提供して、ノートブックファイルを保存する S3 バケットを選択した後、[ノートブックの作成] をクリックします。ノートブックのステータスが準備完了になったら、[オープン] をクリックしてノートブックエディタを起動します。

EMR Notebooks は、EMR のリリース 5.18.0 以降を実行する EMR クラスターにアタッチできます。

EMR Notebooks は、追加料金なしでご利用いただけます。アカウント内でアタッチされた EMR クラスターについては、通常通りに課金されます。お使いのクラスターの料金設定に関する詳細については、https://aws.amazon.com/emr/pricing/ をご覧ください 

Amazon EMR では、いくつかの方法でクラスターにデータを格納できます。最も一般的な方法では、まずデータを Amazon S3 にアップロードし、Amazon EMR の組み込み済み機能を使用しながら、そのデータをクラスターに移動します。Hadoop の分散キャッシュ機能を使用して、分散ファイルシステムからローカルファイルシステムにファイルを転送することができます。詳細については、ドキュメントを参照してください。あるいは、オンプレミスからクラウドへのデータ移行を行う場合は、AWSのクラウドデータ移行サービスのいずれかを利用することができます。

Hadoopのシステムログおよびユーザーログは、クラスタを作成する際に指定したAmazon S3バケットに保存されます。永続アプリケーションの UIは、クラスター外で実行されています。Spark History Server、Tez UI および YARN タイムラインサーバーのログは、アプリケーション終了後、30 日間参照することができます。

今回、ログは Amazon S3 に移動されるため、Amazon EMR はそれらの圧縮を行いません。

Q: ログは圧縮されますか?

はい。AWS Direct Connect を使用して、AWS へのプライベートな専用のネットワーク接続を確立できます。データの規模が大きい場合は、AWS Import/Export を使用します。詳細については、ドキュメントをご覧ください。

いいえ。クラスターおよび入力データはそれぞれ異なっているため、当社はお客様のジョブに要する時間を見積もることはできません。

Amazon EMR の料金は予測がしやすくシンプル: 1 秒ごとに課金され、最小課金時間は 1 分となっています。請求額は、AWS Pricing Calculatorを使用して見積ることができます。Amazon EC2 を含め、その他のアマゾン ウェブ サービスの使用料金は、Amazon EMR とは別に請求されます。

Amazon EMR に関する課金は、クラスターでステップを実行する準備ができた時点から開始されます。クラスターのシャットダウンをリクエストすると、Amazon EMR への課金は終了します。Amazon EC2 が課金を開始と終了するタイミングの詳細については、Amazon EC2 の請求に関するよくある質問を参照してください。

請求とコスト管理コンソールで、これらの使用量を追跡できます。

AWS マネジメントコンソールで、各クラスターには正規化インスタンス時間の欄があります。ここにはクラスターが使用したコンピューティング時間の概数が切り上げて表示されます。

正規化インスタンス時間は、m1.smallの1時間の使用が1時間の正規化された計算時間に相当するという基準に基づく計算時間です。各インスタンスファミリーでの異なるサイズ、および、それらに対応した 1 時間ごとの正規化ファクターの一覧は、こちらのドキュメントでご確認いただけます。

例えば、10ノードのr3.8xlargeクラスターを1時間稼働させた場合、コンソールに表示される正規化インスタンス時間の合計は640になります（10（ノード数）× 64（正規化係数）× 1（クラスターの稼働時間）＝640）。

これは概算値であり、請求目的で使用されるものではありません。請求の対象となる Amazon EMR の使用量については、請求とコスト管理コンソールをご覧ください。

はい。Amazon EMR は、オンデマンド、スポット、リザーブドの各インスタンスをシームレスにサポートしています。Amazon EC2 リザーブドインスタンスの詳細については、ここをクリックしてください。Amazon EC2 スポットインスタンスの詳細については、ここをクリックしてください。Amazon EC2 のキャパシティー予約については、ここをクリックしてください。

別途記載がない限り、表示される料金には付加価値税、売上税など、一切の税金等および関税は含まれません。日本の居住者であるお客様が AWS サービスをご利用になった場合には、料金とあわせて別途消費税をご請求させていただきます。詳細はこちら。 

Amazon EMR は、インスタンスを 2 つの Amazon EC2 セキュリティグループで開始します。1 つはマスターであり、もう 1 つは別のクラスターノードです。マスターセキュリティグループには通信用に開いたポートがあり、これを使ってサービスを行っています。また SSH ポートが開いており、起動時に指定されたキーを使用して、SSH をインスタンスに対して許可することができます。別のノードは別のセキュリティグループで開始します。これらはマスターのインスタンスとのやりとりのみを許可します。デフォルトでは、両セキュリティグループ共に、他のお客様に所属する Amazon EC2 インスタンスなど、外部ソースからのアクセスを許可しないように設定されています。お客様のアカウント内にセキュリティグループが存在するため、標準 EC2 ツールまたはダッシュボードを使用して、それらの再設定を行うことができます。EC2 セキュリティグループの詳細については、ここをクリックしてください。さらに、例外リストに追加しないポートでパブリックアクセスが許可されるルールがある場合、クラスターの作成を防ぐために使用する各リージョンで Amazon EMR ブロックパブリックアクセスを設定できます。

Amazon S3は、保存されたデータが不正アクセスから保護されるよう、認証機能を提供しています。データをアップロード中のお客様が他者を指定しない限り、そのお客様のみがデータにアクセスすることができます。Amazon EMR のお客様は、安全な送信のために HTTPS プロトコルを使用して、Amazon S3 にデータを送信することもできます。さらに、Amazon EMR は常に HTTPS を使用して、Amazon S3 と Amazon EC2 の間でデータのやりとりを行います。セキュリティを強化するために、顧客は Amazon S3 にデータをアップロードする前に、任意の一般的なデータ暗号化ツールを使用して入力データを暗号化することができます。その後、Amazon EMR が Amazon S3 からデータを取得する際に、クラスタの最初に復号化のステップを追加する必要があります。

はい。AWS CloudTrail は、アカウントに対する AWS API コールを記録し、ログファイルを配信するウェブサービスです。CloudTrailによって生成されるAWSのAPIコール履歴は、セキュリティ分析、リソースの変更追跡、およびコンプライアンス監査を可能にします。CloudTrail の詳細については、AWS CloudTrail の詳細ページを参照してください。CloudTrail を有効にするには、CloudTrail の AWS マネジメントコンソールにアクセスしてください。

デフォルトでは、Amazon EMR アプリケーションプロセスは他の AWS サービスを呼び出すときに EC2 インスタンスプロファイルを使用します。マルチテナントクラスターの場合、Amazon EMR は、Amazon S3 データへのユーザーアクセスを管理するための 3 つのオプションを提供します。

1. AWS Lake Formation との統合により、AWS Lake Formationできめ細かな認可ポリシーを定義および管理して、AWS Glue データカタログのデータベース、テーブル、列にアクセスできます。インタラクティブな EMR Spark ワークロードのために Amazon EMR Notebooks および Apache Zeppelin を通じて送信されるジョブに認可ポリシーを強制適用し、監査イベントを AWS CloudTrail に送信できます。この統合を有効にすることで、セキュリティアサーションマークアップ言語（SAML）2.0 に対応した企業のアイデンティティシステムから、EMR ノートブックや Apache Zeppelin へのフェデレーテッドシングルサインオンも有効になります。

2. Apache Ranger とのネイティブ統合により、新規または既存の Apache Ranger サーバーをセットアップして、ユーザーが Hive Metastore 経由で Amazon S3 データのデータベース、テーブル、列にアクセスするためのきめ細かい認可ポリシーを定義および管理できます。Apache Ranger は、Hadoop プラットフォーム全体の包括的なデータセキュリティを有効化、モニタリング、および管理するオープンソースツールです。
   
   このネイティブ統合により、Apache Ranger Policy Admin サーバーで 3 種類の認可ポリシーを定義できます。Hiveではテーブル、カラム、行レベルの認可を設定でき、Sparkではテーブルおよびカラムレベルの認可を設定でき、Amazon S3ではプレフィックスおよびオブジェクトレベルの認可を設定できます。Amazon EMR は、対応する Apache Ranger プラグインをクラスターに自動的にインストールして構成します。これらの Ranger プラグインは Policy Admin サーバーとの間で認可ポリシーを同期し、データアクセスコントロールを強制適用して、監査イベントを Amazon CloudWatch Logs に送信します。

3. Amazon EMR User Role Mapper を使用すると、AWS IAM 許可を活用して AWS リソースへのアクセスを管理できます。ユーザー (またはグループ) とカスタム IAM ロール間のマッピングを作成できます。ユーザーまたはグループは、カスタム IAM ロールによって許可されたデータにのみアクセスできます。この機能は現在、AWS ラボを通じてご使用いただけます。

Amazon EMR は、同一の Amazon EC2 アベイラビリティーゾーン内において付与される 1 クラスターのためにすべてのノードを起動します。同一のゾーン内でクラスターを実行することにより、ジョブフローのパフォーマンスが改善されます。デフォルトでは、Amazon EMR はクラスターを実行するために最も利用性の高いリソースを持つアベイラビリティーゾーンを選択するようになっています。ただし必要ならば、別のアベイラビリティーゾーンを指定することもできます。また、割り当てを最も低価格のオンデマンドインスタンス、最適なスポット容量、またはオンデマンド容量予約を使用するように最適化するオプションもあります。

サポートされる Amazon EMR AWS リージョンのリストについては、すべての AWS グローバルインフラストラクチャの AWS リージョン表を参照してください。

EMRは、ロサンゼルスのAWSローカルゾーンでクラスタを起動することをサポートしています。US West（オレゴン）リージョンのEMRを使用して、ロサンゼルスのAWSローカルゾーンに関連付けられたサブネットにクラスターを起動できます。

通常、クラスターを作成する場合、お客様のデータが存在しているリージョンを選択する必要があります。

はい、できます。データを 1 つのリージョンから他のリージョンへ転送する場合、回線料金が課金されます。回線料金情報については、EC2 詳細ページの料金セクションを参照してください。

AWS GovCloud (米国) リージョンは米国政府関連機関とその顧客向けに設計されています。このリージョンは US ITAR の要件に準拠しています。GovCloud では、EMR はスポットインスタンスとデバッグ有効化機能をサポートしません。また、EMR マネジメントコンソールも、GovCloud では現在ご利用いただけません。

Amazon EC2 での Amazon EMR

Amazon EKS での Amazon EMR

Amazon EMR on AWS Outposts

打ち上げ

管理しています

タグ付け

クラスターとは、Amazon Elastic Compute Cloud（Amazon EC2）インスタンスの集合です。クラスターの各インスタンスはノードと呼ばれ、ノードタイプと呼ばれるクラスター内で役割を持っています。また、Amazon EMR は、ノードタイプごとに異なるソフトウェアコンポーネントをインストールして、Apache Hadoop などの分散アプリケーションで各ノードに役割を与えます。どのクラスターもすべて、「j-」で始まる一意の識別子を持っています。

Amazon EMR クラスターには、3 タイプのノードがあります:

1. マスターノード: ソフトウェアコンポーネントを実行してクラスターを管理し、他のノード間にあるデータやタスクの分散を調整して処理するノード。マスターノードは、タスクのステータスを追跡し、クラスターの状態を監視します。各クラスターにはマスターノードがあり、マスターノードだけで、単一ノードクラスターを作成することができます。

2. コアノード: タスクを実行し、クラスターの Hadoop Distributed File System (HDFS) にデータを格納するソフトウェアコンポーネントを備えたノード。マルチノードクラスターには、最低 1 つのコアノードがあります。

3. タスクノード: タスクを実行するのみの、HDFS にデータを保存しないソフトウェアコンポーネントを備えたノード。タスクノードはオプションです。

クラスタステップは、ユーザーが定義する処理単位であり、データを操作する1つのアルゴリズムにおおよそ対応します。ステップとは、Java jar として、または Java、Ruby、Perl、Python、PHP、R、もしくは C++ で書かれたストリーミングプログラムとして実装された Hadoop MapReduce アプリケーションです。例えば、文書内で単語が出現する頻度を数え、その出現回数でソートして出力するには、最初のステップとして各単語の出現回数をカウントするMapReduceアプリケーションを実行し、次のステップとしてそのカウントに基づいて最初のステップの出力をソートするMapReduceアプリケーションを実行します。

STARTING – クラスターは EC2 インスタンスを設定しすることから開始されます。
BOOTSTRAPPING – クラスターでブートストラップアクションを実行します。
RUNNING – クラスターの 1 ステップが現在実行中です。
WAITING – クラスターは現在アクティブですが、実行中のステップがありません。
TERMINATING – クラスターはシャットダウンの途中です。
TERMINATED – クラスターは正常にシャットダウンされました。
TERMINATED_WITH_ERRORS - クラスターはエラーによりシャットダウンされました。

PENDING – ステップが実行待ちの状態です。

RUNNING – ステップが現在実行中です。

COMPLETED – ステップが正しく完了しています。

CANCELLED – ステップが実行前にキャンセルされています。前のステップが失敗しているか、またはクラスターが実行可能となる前に終了したためです。

FAILED – ステップを実行中に失敗しました。

AWS マネジメントコンソールを通じて、簡単なクラスター申請フォームに記入することでクラスターを起動できます。申請フォームでは、クラスター名、入力データの Amazon S3 内の場所、処理アプリケーション、希望するデータの出力場所、および使用したい Amazon EC2 インスタンスの数とタイプを指定します。オプションで、クラスターログファイルと SSH キーを保存する場所を指定して、稼働中にクラスターにログインできます。あるいは、RunJobFlow API またはコマンドラインツールの [Create] コマンドを使用して、クラスターを起動できます。EMR Studio を使ったクラスター起動については、上記の EMR Studio のセクションをご覧ください。

いつでも、クラスタを選択して「終了」ボタンをクリックすることで、AWS マネジメントコンソールからクラスタを終了することができます。あるいは、TerminateJobFlows API を使用することができます。実行中のクラスターを終了すると、Amazon S3 に保存されていない結果はすべて失われ、すべての Amazon EC2 インスタンスがシャットダウンされます。

クラスターは好きな数だけ開始できます。インスタンスの数は、使用しているクラスター全体で最大 20 に制限されています。さらに多くのインスタンスが必要な場合は、Amazon EC2 インスタンス申請フォームをご記入ください。お客様の Amazon EC2 上限数が引き上げられると、その上限値が Amazon EMR クラスターに自動的に適用されます。

まず、お客様は、入力データとデータ処理アプリケーションを Amazon S3 にアップロードします。その後 Amazon EMR は、お客様に指定されたいくつかの Amazon EC2 インスタンスを起動します。サービスは、S3 の URI スキームを使用して、起動された Amazon EC2 インスタンスに Amazon S3 からの入力データをプルしながら、クラスターの実行を開始します。クラスターが完了すると、Amazon EMR は出力データを Amazon S3 に転送し、そこでデータを取得したり、別のクラスターで入力として使用したりすることができます。

Amazon EMR は Hadoop データ処理エンジンを使用して、MapReduce プログラミングモデルで実行される計算を行うことができます。お客様は、map() および reduce() 関数に関するアルゴリズムを実装します。1 つのマスターと複数の他のノードから構成された、お客様が指定する数の Amazon EC2 インスタンスをサービスが開始します。Amazon EMR はこれらのインスタンス上で Hadoop ソフトウェアを実行します。マスターノードは入力データをブロックに分割し、ブロックの処理を別のノードに分配します。その後各ノードは、それに配分されたデータ上でマップ関数を実行し、中間データを生成します。中間データは並び替えられて分割され、ノードでローカルにリデューサー関数を適用するプロセスへと送信されます。最終的に、reducer タスクからの出力がファイル中で収集されます。単一の「クラスター」は、このようなMapReduceステップの一連の処理を含むことがあります。

各リージョンで利用可能なインスタンスタイプと料金の最新の詳細については、EMR 料金表のページを参照してください。

クラスタを実行する時間は、クラスタの種類、入力データの量、クラスタに選択するAmazon EC2インスタンスの数と種類など、いくつかの要因によって異なります。

はい。3 つのマスターノードがある EMR クラスター (バージョン 5.23 以降) を起動して、YARN Resource Manager、HDFS Name Node、Spark、Hive、Ganglia などのアプリケーションの高可用性を向上させることができます。プライマリマスターノードに障害が発生した場合、または Resource Manager や Name Node などの重要なプロセスがクラッシュした場合、Amazon EMR は自動的にスタンバイマスターノードにフェイルオーバーします。マスターノードが単一障害点となることはないため、長寿命の EMR クラスターを中断することなく実行できます。フェイルオーバーが発生した場合、Amazon EMR は障害が発生したマスターノードを同じ構成およびブートストラップアクションを持つ新しいマスターノードに自動的に置き換えます。 

はい。Amazon EMR はノードの障害に対して耐障害性を備えており、ノードが失敗した場合でもジョブの実行を継続します。また、Amazon EMR は、コアノードに障害が発生した場合に新しいノードをプロビジョニングします。しかし、クラスタ内のすべてのノードが失われた場合、Amazon EMR はノードを置き換えることはありません。

はい。SSH をクラスターノード上に配置して、Hadoop コマンドをそこから直接実行することができます。特定のノードにSSHで接続する必要がある場合は、まずマスターノードにSSH接続し、その後目的のノードにSSH接続する必要があります。

Bootstrap Actionsは、Amazon EMRの機能で、クラスターの実行前にユーザーがカスタムセットアップを実行できる方法を提供します。ブートストラップアクションは、クラスタを実行する前にソフトウェアをインストールしたり、インスタンスを構成したりするために使用できます。EMR のデベロッパーガイドで、ブートストラップアクションに関する詳細な説明がご覧になれます。

クラスタインスタンスにすでにインストールされている任意の言語（Bash、Perl、Python、Ruby、C++、Javaなど）で、Bootstrap Action スクリプトを作成できます。いくつかの利用可能な、あらかじめ定義されたブートストラップアクションがあります。記述されたスクリプトは、Amazon S3 にアップロードする必要があります。クラスターの開始時には、このスクリプトのロケーションを参照します。ブートストラップアクションの使用方法の詳細については、デベロッパーガイドを参照してください。

Elastic MapReduce デフォルト Hadoop 設定はほとんどのワークロードに適しています。ただし、クラスター特有のメモリと処理の要件により、設定の調整が必要な場合があります。例えば、クラスタータスクがメモリを大量に使用する場合、コア別に使うタスクの数を減らしてジョブ追跡のヒープサイズを減らすことができます。この場合、あらかじめ設定されているブートストラップアクションを使って、クラスターの開始を設定します。設定の詳細と使用方法については、開発者ガイドのメモリを大量に使用するブートストラップアクションをご覧ください。クラスターの設定を任意の値にカスタマイズできる別の定義済みブートストラップアクションも利用できます。使い方については、開発者ガイドの Hadoop ブートストラップアクションの設定をご覧ください。

はい。ノードには次の 2 種類があります。(1) Hadoop Distributed File System (HDFS) と Hadoop タスクの実行を使ってデータをホストする「コアノード」と (2) Hadoop タスクでのみ実行される「タスクノード」です。クラスターの実行中に、コアノードの数を増やしたり、タスクノードの数を増減したりすることができます。これは、API、Java SDK、またはコマンドラインクライアントで実行します。実行中のクラスターのサイズを変更する方法の詳細については、デベロッパーガイドで実行中のクラスターのサイズ変更のセクションを参照してください。また、EMR マネージドスケーリングをご使用いただくこともできます。

コアノードは HDFS に永続データをホストしており、削除できないため、クラスターが完了するまで必要な容量のためにコアノードを確保しておく必要があります。タスクノードは、追加または削除することができ、HDFS を含んでいません。このノードは、一時的にのみ使用される容量に適しています。タスクインスタンスフリートをスポットインスタンスで起動すれば、コストを最小化しながら容量を増やすことも可能です。

実行中のクラスターのノードの数を変更する状況はいくつかあります。クラスターの処理速度が予測より遅い場合、またはタイミング要件が変更されたときに、コアノードの数を増やしてクラスターのパフォーマンスを高めることができます。クラスターの段階によって必要な容量が異なる場合は、少ない数のコアノードから始めた後に、タスクノードの数を増減させながら、クラスターでのそれぞれの容量要件に合わせ調整します。 また、EMR マネージドスケーリングをご使用いただくこともできます。

はい。あらかじめ定義されたステップをワークフローに含めて、異なる容量ニーズがあるステップ間のクラスターのサイズを自動的に調整するようにできます。すべてのステップは順次実行されます。これにより、指定のクラスターステップを実行するノードの数を設定することができます。

EMR CLIで、すべてのIAMユーザーから見える新しいクラスターを作成するには、クラスター作成時に--visible-to-all-usersフラグを追加します。例: elastic-mapreduce --create --visible-to-all-users。マネジメントコンソールで、クラスターの作成ウィザードの [詳細オプション] ペインにある [Visible to all IAM Users] を選択します。

既存のクラスターをすべての IAM ユーザーに表示されるようにするには、EMR CLI を使用する必要があります。--set-visible-to-all-users を使用し、クラスター ID を指定します例: elastic-mapreduce --set-visible-to-all-users true --jobflow j-xxxxxxx。これは、クラスターの作成者のみ行うことができます。

詳細については、EMR デベロッパーガイドの、ユーザー許可の設定のセクションをご覧ください。

アクティブな Amazon EMR クラスターにタグを付けることができます。Amazon EMR クラスターは Amazon EC2 インスタンスで構成され、Amazon EMR クラスターに付けられたタグはそのクラスター内のアクティブなすべての Amazon EC2 インスタンスに反映されます。終了したクラスターや、アクティブなクラスターの一部であった終了した Amazon EC2 インスタンスには、タグを追加、編集、削除することはできません。

いいえ、Amazon EMR では、タグによるリソースベースのアクセス許可をサポートしていません。ただし、Amazon EC2 インスタンスに反映されたタグが通常の Amazon EC2 タグと同様に動作することに注意する必要があります。したがって、Amazon EC2 の IAM ポリシーは、ポリシーの条件に一致する場合、Amazon EMR から伝播されたタグに対して作用します。

Amazon EMR クラスターには最大 10 個のタグを付けることができます。

はい、Amazon EMR はクラスターに付けられたタグをそのクラスターを構成する EC2 インスタンスに反映します。Amazon EMR クラスターにタグを付けた場合、そのタグは関連する Amazon EC2 インスタンスにも表示されます。同様に、Amazon EMR クラスターからタグを削除した場合、そのタグは関連する Amazon EC2 インスタンスからも削除されます。ただし、Amazon EC2 用に IAM ポリシーを使用していて、Amazon EMR のタグ付け機能を使用する場合は、Amazon EC2 タグ付け API、CreateTags および DeleteTags を使用するアクセス許可が付与されていることを確認する必要があります。

AWS 請求レポートで使用したいタグをここで選択します。次に、結合されたリソースのコストを確認するには、同じタグキーの値を持つリソースに基づいて請求情報を整理できます。

Amazon EMR クラスターに関連する Amazon EC2 インスタンスには、2 つのシステムタグが付けられています。

• aws:elasticmapreduce:instance-group-role=CORE

  • Key = instance-group role ; Value = [CORE or TASK];

• aws:elasticmapreduce:job-flow-id=j-12345678

  • Key = job-flow-id ; Value = [JobFlowID]

はい、Amazon EMR クラスターに属する Amazon EC2 インスタンスに対して、タグを直接追加したり削除したりすることができます。しかし、そのようにすることはお勧めできません。その理由は、Amazon EMR のタグ付けシステムは関連する Amazon EC2 インスタンスで直接行った変更と同期しないためです。Amazon EMR クラスターのタグは、クラスターとそれに関連付けられた Amazon EC2 インスタンスに正しいタグが付与されるように、Amazon EMR コンソール、CLI、または API から追加および削除することを推奨します。

Amazon EMR Serverless は、クラスタの設定、管理、スケーリングを行うことなく、Apache Spark や Apache Hive などのビッグデータフレームワークを実行できる、Amazon EMR の新しいデプロイメントオプションです。

データエンジニア、アナリスト、サイエンティストは、EMR Serverless を使用して、Apache Spark や Apache Hive などのオープンソースフレームワークを使ったアプリケーションを構築できます。これらのフレームワークを使用して、データの変換、インタラクティブな SQL クエリの実行、機械学習ワークロードの実行が可能です。

EMR Studio、AWS CLI、またはAPIを使用して、ジョブの提出、ジョブの状態追跡、EMR Serverlessで実行するデータパイプラインの構築を行うことができます。EMR Studio を使い始めるには、AWS マネジメントコンソールにサインインし、Analytics カテゴリの下にある Amazon EMR に移動し、Amazon EMR Serverless を選択してください。AWS マネジメントコンソールの指示に従って、 Analytics カテゴリの下にある Amazon EMR に移動し、Amazon EMR Serverless を選択します。 開始方法のガイドの指示に従い、EMR Serverless アプリケーションを作成し、ジョブを送信します。CLI を使用してアプリケーションを起動し、ジョブを送信するには、AWS CLI でアプリケーションと対話するページを参照することができます。また、GitHub リポジトリで EMR Serverless の例とサンプルコードを見つけることができます。

EMR Serverless は現在、Apache Spark と Apache Hive のエンジンをサポートしています。Apache Presto や Apache Flink などの追加フレームワークのサポートが必要な場合は、emr-feedback@amazon.com までリクエストをお送りください。

EMR Serverless は、アジアパシフィック (ムンバイ)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (ストックホルム)、南米 (サンパウロ)、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、および米国西部 (オレゴン) の各 AWS リージョンで利用できます。

Amazon EMR は、EC2 ベースのクラスター、EKS クラスター、Outposts、または Serverless 上でアプリケーションを実行するオプションを提供します。EC2 クラスター上の EMR は、アプリケーションの実行に関して最大限の制御と柔軟性を必要とするお客様に適しています。EC2 クラスター上の EMR では、アプリケーション固有のパフォーマンスニーズに合わせて EC2 インスタンスタイプを選択し、Linux AMI のカスタマイズ、EC2 インスタンス設定のカスタマイズ、オープンソースフレームワークのカスタマイズと拡張、および追加のカスタムソフトウェアのクラスターインスタンスへのインストールを行うことができます。EKS での Amazon EMR は、アプリケーション間でクラスターを管理するために EKS を標準化したいお客様や、同じクラスターでオープンソースのフレームワークの異なるバージョンを使用したいお客様に適しています。AWS Outposts での Amazon EMR は、Outpost 内で、よりデータセンターに近い場所で EMR を実行したいお客様向けです。EMR Serverless は、クラスターの管理や運用を避け、オープンソースのフレームワークを使ってアプリケーションを実行したいお客様に適しています。

EMR Serverlessは、EMRリリースラベル6.6以降をサポートしています。EMR Serverless を使用すると、他の EMR 展開オプションでも利用できるパフォーマンス最適化済みの EMR ランタイムと同じものを利用でき、標準のオープンソースフレームワークと 100% API 互換です。

BilledResourcesUtilizationは、ジョブのために事前に初期化された容量が使用された期間のみを考慮し、そのような容量のアイドル時間は考慮しません。

ワーカーのランタイムが 60 秒未満の場合、BilledResourceUtilization は 60 秒としてカウントされますが、TotalResourceUtilization では最も近い秒に切り上げられます。さらに、BilledResourceUtilization では、20 GB の空きストレージが計算から除外されます。

Amazon EMR Serverless では、オープンソースの分析フレームワークを使用する 1 つまたは複数の EMR Serverless アプリケーションを作成することができます。アプリケーションを作成するには、次の属性を指定する必要があります。1) 使用したいオープンソースフレームワークバージョンの Amazon EMR リリースバージョン、2) アプリケーションで使用したい特定の分析エンジン (Apache Spark 3.1 または Apache Hive 3.0 など)。アプリケーションを作成した後は、データ処理ジョブやアプリケーションへのインタラクティブなリクエストを実行し始めることができます。

EMR サーバーレスアプリケーションは、内部的にワーカーを使用してワークロードを実行します。ジョブが送信されると、EMR Serverless はそのジョブに必要なリソースをコンピューティングし、ワーカーをスケジュールします。EMR Serverless はワークロードをタスクに分解し、オープンソースのフレームワークでワーカーをプロビジョニングしてセットアップし、ジョブが完了したらワーカーをデコミッションします。EMR Serverless は、ジョブの各段階で必要となるワークロードと並列性に応じてワーカーを自動的にスケールアップまたはダウンさせるため、ワークロードの実行に必要なワーカーの数を見積もる必要がありません。これらのワーカーのデフォルトのサイズは、アプリケーションの種類と Amazon EMR のリリースバージョンに基づきます。ジョブ実行のスケジューリング時に、これらのサイズをオーバーライドすることができます。

EMR Serverless を使用すると、同時実行するワーカーの最小数と最大数、およびワーカーの vCPU とメモリの構成を指定できます。コストを管理するために、アプリケーションのリソースの最大容量制限を設定することもできます。

次のいずれかを行う場合、複数のアプリケーションを作成することを検討してください。

1. 異なるオープンソースフレームワークを使用する

2. 異なるユースケースに異なるバージョンのオープンソースフレームワークを使用する

3. あるバージョンから別のバージョンにアップグレードする際の A/B テストの実施する

4. テストシナリオと本番シナリオのために、別々の論理環境を維持する

5. 独立したコスト管理と使用状況の追跡が可能な、異なるチーム用の別々の論理環境を提供する

6. 異なるラインオブビジネスアプリケーションを分離する

はい、EMR Studio または update-application API/CLI コールを使用して、初期容量、最大容量制限、ネットワーク構成などのアプリケーションプロパティを変更できます。

ワーカーを事前に初期化していない EMR Serverless アプリケーションは、必要なリソースを決定してプロビジョニングするのに最大で 120 秒かかります。EMR Serverless は、ワーカーを数秒で初期化して応答できるようにするオプション機能を提供し、アプリケーションのためのワーカーのオンコールプールを効果的に作成します。この機能は事前初期化容量と呼ばれ、アプリケーションの initial-capacity パラメータを設定することでアプリケーションごとに設定することができます。

事前初期化容量では、ジョブをすぐに開始できるため、時間的制約のあるジョブの実装に最適です。EMR Serverless アプリケーションの起動時に、事前に初期化するワーカーの数を指定できます。その後、ユーザーがジョブを送信すると、事前に初期化したワーカーを使用してジョブをすぐに開始することができます。ジョブが事前初期化を選択した数以上のワーカーを必要とする場合、EMR Serverless は自動的にワーカーを追加します (指定した最大同時実行数を上限とします)。ジョブが終了すると、EMR Serverless は自動的に指定した事前に初期化したワーカーのメンテナンスに戻されます。ワーカーは、15 分間アイドル状態が続くと自動的にシャットダウンします。updateApplication API または EMR Studio を使用して、アプリケーションのデフォルトのアイドルタイムアウトを変更することができます。

EMR Studio、SDK/CLI、または当社のApache Airflowコネクタを使用して、EMRサーバーレスジョブを送信および管理できます。

PySpark の場合、virtualenv を使用して Python の依存関係をパッケージ化し、--archives オプションでアーカイブファイルを渡せば、ジョブ実行中にワーカーが依存関係を使用できるようになります。Scala や Java の場合は、依存関係を jar としてパッケージ化し、Amazon S3 にアップロードして、EMR Serverless のジョブ実行時に --jars または --packages オプションを使用して渡すことができます。

EMR Serverless は、Java ベースの UDF をサポートしています。jar としてパッケージ化し、S3 にアップロードして、Spark や HiveQL のスクリプトで使用することができます。

詳しくはサポート対象ワーカー設定をご参照ください。

はい、EMR Studio から、または cancelJobRun API/CLI を呼び出して、実行中の EMR Serverless ジョブをキャンセルすることができます。

EMR Serverless でジョブを送信する際に、適切なストレージオプションを選択することで、ワーカーに追加のストレージを追加できます。EMR Serverless は、次の 2 つのエフェメラルストレージオプションを提供しています。

• 標準ストレージ: このオプションには、デフォルトでワーカーあたり 20 GB のエフェメラルストレージが含まれています。ジョブの送信中にこの設定をカスタマイズして、ストレージ容量をワーカーあたり 20 GB から最大 200 GB に増やすことができます。

• シャッフル最適化ディスクストレージ: このオプションは、シャッフル集約型ワークロードに最適化されたエフェメラルストレージをワーカーあたり最大 2 TB 提供します。

EMR Serverless のコードサンプルは、GitHub リポジトリでご覧いただけます。

EMR Serverless には、オンデマンドワーカーと事前初期化ワーカーの 2 つのオプションがワーカーに提供されます。

オンデマンドワーカーは、ジョブに必要な場合にのみ起動され、ジョブが完了すると自動的にリリースされます。これにより、使用したリソースに対してのみ支払いが発生し、アイドル状態のキャパシティに追加コストがかからないため、コストを節約できます。オンデマンドワーカーはワークロードに基づいてアプリケーションをスケールアップまたはスケールダウンするので、リソースの過剰や不足を心配する必要はありません。

事前初期化ワーカーは、ワーカーが数秒で応答できるようにしておくことができるオプション機能です。これにより、アプリケーションのワーカーのウォームプールが効果的に作成され、ジョブを即座に開始できるため、反復的なアプリケーションや時間に制約のあるジョブに最適です。

はい。EMR Serverless アプリケーションを複数の AZ にわたって構成できます。複数の AZ を設定するプロセスは、使用するワーカーのタイプによって異なります。

オンデマンドワーカーのみを使用する場合、EMR Serverless はデフォルトでジョブを複数の AZ に分散しますが、各ジョブは 1 つの AZ でのみ実行されます。サブネットを AZ に関連付けることで、どの AZ を使用するかを選択できます。AZ に障害が発生した場合、EMR Serverless は自動的に別の正常な AZ でジョブを実行します。

事前初期化ワーカーを使用する場合、EMR Serverless は指定したサブネットから正常な AZ を選択します。応募を停止するまで、ジョブはその AZ に送信されます。AZ に障害が発生した場合は、アプリケーションを再起動して別の正常な AZ に切り替えることができます。

VPC接続なしで設定された場合、EMR Serverlessは同じリージョン内の特定のAWSリソースにのみアクセスできます。考慮事項をご覧ください。別のリージョンの AWS リソースや AWS 以外のリソースにアクセスするには、VPC アクセスと NAT ゲートウェイを設定して、AWS リソースのパブリックエンドポイントにルーティングする必要があります。

Amazon EMR のサーバーレスアプリケーションおよびジョブレベルのメトリクスは、30 秒ごとに Amazon CloudWatch に公開されます。

EMR Studio から、実行中または完了した EMR Serverless ジョブを選択し、Spark UI または Tez UI ボタンをクリックして起動できます。

はい、Amazon EMR Serverless アプリケーションを設定して、ご自身の VPC 内のリソースにアクセスすることができます。詳しくはドキュメントの VPC アクセスの設定セクションをご覧ください。 

各 EMR Serverless アプリケーションは、他のアプリケーションから分離され、安全な Amazon VPC 上で実行されます。

Amazon EMR Serverless では、アカウントあたりの最大同時 vCPU 数という新しいサービスクォータを導入します。この vCPU ベースのクォータにより、アプリケーションがリージョン内でスケールアップできる vCPU の合計最大数を設定できます。既存のアプリケーションレベルのワーカーベースのクォータ (最大アクティブワーカー数) は、2023 年 2 月 1 日にサポートが終了します。

AWS Service Quotas 管理コンソールでクォータの増加を表示、管理、リクエストできます。詳細については、サービスクォータユーザーガイドの「クォータの増加のリクエスト」を参照してください。

EMR Serverlessは2つのコスト管理を提供します - 1/ アカウントごとの最大同時vCPU数のクォータが、アカウント内のリージョン内のすべてのEMR Serverlessアプリケーションに適用されます。2/ MaximumCapacityパラメーターは、特定の EMR サーバーレスアプリケーションの vCPU を制限します。リージョン内のすべてのアプリケーションで使用される最大同時vCPU数を制限するにはvCPUベースのクォータを使用し、特定のアプリケーションで使用されるリソースを制限するにはmaximumCapacityプロパティを使用する必要があります。例えば、5つのアプリケーションがあり、それぞれのアプリケーションが最大で1000 vCPUまでスケールできる場合、各アプリケーションの maximumCapacity プロパティを1000 vCPUに設定し、アカウントレベルのvCPUベースのクォータを 5 * 1000 = 5000 vCPU に設定します。

アカウントレベルの vCPU クォータを超えると、EMR Serverless では新しいキャパシティのプロビジョニングを停止します。クォータを超えた後に新しいアプリケーションを作成しようとすると、アプリケーションの作成に失敗し、次のエラーメッセージが表示されます。「アカウントあたりの最大同時 vCPU サービスクォータを超えているため、アプリケーションを作成できませんでした。AWS Service Quotas コンソールを使用してサービスクォータを表示および管理できます」 クォータを超えた後に新しいジョブを送信すると、ジョブは失敗し、次のエラーメッセージが表示されます。「アカウントあたりの最大同時 vCPU サービスクォータを超えたため、ジョブが失敗しました。AWS Service Quotas コンソールを使用してサービスクォータを表示および管理できます」 詳細については、ドキュメントをご覧ください。

Amazon EMR Serverless がコスト削減に貢献する方法は 3 つあります。まず、クラスターの管理、安全確保、スケーリングといった運用上のオーバーヘッドが発生しません。2 つ目は、EMR Serverless がジョブの処理段階ごとにワーカーを自動的にスケールアップし、不要になったらスケールダウンすることです。ワーカーの実行を開始してから終了するまでに使用した vCPU、メモリ、およびストレージリソースの合計に対して課金が行われ、最小 1 分単位で最も近い秒に切り上げられます。例えば、ジョブの処理に最初の 10 分間は 10 人のワーカー、次の 5 分間は 50 人のワーカーが必要な場合があります。きめ細かい自動スケーリングでは、10 分間で 10 人のワーカー、5 分間で 50 人のワーカーにかかるコストのみが発生します。その結果、使用率の低いリソースにお金を払う必要がなくなります。3 つ目に、EMR Serverless には、Apache Spark と Apache Hive、および Presto のためにパフォーマンスが最適化された Amazon EMR ランタイムが含まれています。Amazon EMRのランタイムはAPI互換性があり、標準のオープンソース分析エンジンよりも2倍以上高速なため、ジョブの実行が速く、計算コストも抑えられます。

現在の EC2 クラスター上の EMR の使用率に依存します。EC2 オンデマンドインスタンスを使用して EMR クラスターを実行している場合、現在のクラスター使用率が 70% 未満であれば、EMR Serverless の方が総保有コスト (TCO) を低く抑えることができます。EC2 Savings Plans を使用している場合、現在のクラスター使用率が 50% 未満であれば、EMR Serverless はより低い TCO を提供します。そして、EC2スポットインスタンスを使用する場合、EC2上のAmazon EMRおよびEKS上のAmazon EMRは引き続きコスト効率が高くなります。

はい、ジョブ終了後にワーカーを停止しない場合、事前に初期化したワーカーに課金されます。

PySparkでは、virtualenvを使ってPythonの依存関係をパッケージ化し、--archivesオプションを使ってアーカイブファイルを渡すことで、ジョブ実行中にワーカーがその依存関係を使用できるようにできます。Scala や Java の場合は、依存関係を jar としてパッケージ化し、Amazon S3 にアップロードして、EMR Serverless のジョブ実行時に --jars または --packages オプションを使用して渡すことができます。

PySpark の場合、virtualenv を使用して Python の依存関係をパッケージ化し、--archives オプションでアーカイブファイルを渡せば、ジョブ実行中にワーカーが依存関係を使用できるようになります。Scala や Java の場合は、依存関係を jar としてパッケージ化し、Amazon S3 にアップロードして、EMR Serverless のジョブ実行時に --jars または --packages オプションを使用して渡すことができます。

Amazon EMR Serverless は Apache Spark ワークロードのローカルストレージプロビジョニングを排除し、データ処理コストを最大 20% 削減し、ディスク容量の制約によるジョブの失敗を防ぎます。EMR Serverlessは、インフラストラクチャに関する決定を必要とせずに、シャッフルなどの中間データ操作を自動的に処理します。中間データを計算ワーカーとは独立して自動的に処理することにより、この最適化により、Sparkの動的リソース割り当て（DRA）は、処理に不要になった時点で計算リソースを解放できるようになり、単に一時的なローカルデータを保持するために実行し続ける必要がなくなります。この自動強化により、大規模な集計、結合、ソート中心の分析などの幅広い変換ワークロードに対して柔軟性が向上し、計算リソースをジョブの各ステージで動的にスケールアップおよびスケールダウンでき、ローカルに保存されたデータに制約されることがなくなります。

EMR バージョン 7.12 以降を使用する際に、単にオプトインするだけです。Spark ジョブは、設定を行わなくても自動的に最適化された中間データ処理の恩恵を受けられます。Spark Live UI を使用してジョブをリアルタイムで監視したり、Spark History Server で完了したジョブの詳細なシャッフルやステージごとのスピルメトリクスを確認したりすることができます。

中間データはジョブの実行中にのみ保存され、ジョブの完了時に自動的に削除されるため、ジョブのライフサイクルを超えてデータが残ることはありません。

この自動最適化は、複数の保護層を通じて、EMR Serverless と同じエンタープライズレベルのセキュリティ基準を維持します。すべてのデータは、EMR Serverless アプリケーションと中間データ処理レイヤー間の転送中、および一時的に保存される際の静止状態の両方で、AWS 管理の暗号化キーを使用して暗号化されます。この機能は、中間データを名前空間内のジョブ固有の識別子の下で保存することで、厳格なデータの分離とアクセス制御を実現し、データが特定のジョブでのみアクセス可能であることを保証します。既存の EMR Serverless のアクセス制御と権限は引き続き適用されるため、テーブルや Lake Formation のポリシーで管理されているデータは引き続き完全に保護されます。 セキュリティを強化するために、EMR Serverless は、ジョブの実行ロールではなく、サービス所有のロールを使用して中間データの処理を行い、権限の昇格や不正なクロスアカウントアクセスを防ぎます。セキュリティチェックが失敗すると、ジョブはただちに停止し、データが常に保護されたままであることを確認します。