Amazon EMR リリース 5.30.0

• Amazon EMR 7.x リリースのアプリケーションバージョン

• Amazon EMR 6.x リリースのアプリケーションバージョン

• Amazon EMR 5.x リリースのアプリケーションバージョン

• Amazon EMR 4.x リリースのアプリケーションバージョン

アップグレード

• AWS SDK for Java をバージョン 1.11.759 にアップグレードしました

• Amazon SageMaker Spark SDK をバージョン 1.3.0 にアップグレードしました

• EMR Record Server をバージョン 1.6.0 にアップグレードしました

• Flink をバージョン 1.10.0 にアップグレードしました

• Ganglia をバージョン 3.7.2 にアップグレードしました

• HBase をバージョン 1.4.13 にアップグレードしました

• Hudi をバージョン 0.5.2 (incubating) にアップグレードしました

• Hue をバージョン 4.6.0 にアップグレードしました

• JupyterHub をバージョン 1.1.0 にアップグレードしました

• Livy をバージョン 0.7.0 (incubating) にアップグレードしました

• Oozie をバージョン 5.2.0 にアップグレードしました

• Presto をバージョン 0.232 にアップグレードしました

• Spark をバージョン 2.4.5 にアップグレードしました

• コネクタとドライバーをアップグレードしました: Amazon Glue Connector 1.12.0、Amazon Kinesis Connector 3.5.0、EMR DynamoDB Connector 4.14.0

新機能

• EMR Notebooks - 5.30.0 を使用して作成された EMR クラスターで使用する場合、EMR ノートブックカーネルはクラスター上で実行されます。これにより、ノートブックのパフォーマンスが向上し、カーネルをインストールおよびカスタマイズすることができます。また、クラスターのプライマリノードに Python ライブラリをインストールすることもできます。詳細については、「EMR 管理ガイド」の「カーネルとライブラリのインストールと使用」を参照してください。

• マネージドスケーリング - Amazon EMR バージョン 5.30.0 以降では、EMR マネージドスケーリングを有効にすることで、ワークロードに応じてクラスター内のインスタンスやユニットの数を自動的に増減できます。Amazon EMR は引き続きクラスターのメトリクスを評価し、クラスターのコストと速度を最適化するためのスケーリングを決定します。詳細については、「Amazon EMR 管理ガイド」の「クラスターリソースのスケーリング」を参照してください。

• Amazon S3 に保存されているログファイルの暗号化 - Amazon EMR バージョン 5.30.0 以降では、Amazon S3 に保存されているログファイルを AWS KMS カスタマー管理キーで暗号化することができます。詳細については、「Amazon EMR 管理ガイド」の「Amazon S3 に保存されているログファイルの暗号化」を参照してください。

• Amazon Linux 2 のサポート - EMR バージョン 5.30.0 以降では、EMR は Amazon Linux 2 OS を使用します。新しいカスタム AMI (Amazon マシンイメージ) は、Amazon Linux 2 AMI に基づいている必要があります。詳細については、「カスタム AMI の使用」を参照してください。

• Presto Graceful Auto Scale - 5.30.0 を使用する EMR クラスターでは、オートスケーリングのタイムアウト期間を設定することで、Presto タスクの実行が終了するまで待ってからノードの使用を停止できます。詳細については、「グレースフルな廃止による Presto Auto Scaling の使用」を参照してください。

• 新しい割り当て戦略オプションを使用したフリートインスタンスの作成 — EMR バージョン 5.12.1 以降では、新しい割り当て戦略オプションを使用できます。これにより、クラスターのプロビジョニングにかかる時間が短縮され、スポット割り当てがより正確になり、スポットインスタンスの中断が低減します。デフォルト以外の EMR サービスロールを更新する必要があります。「インスタンスフリートを構成する」を参照してください。

• sudo systemctl stop コマンドと sudo systemctl start コマンド — Amazon Linux 2 OS を使用する EMR バージョン 5.30.0 以降では、EMR は sudo systemctl stop コマンドおよび sudo systemctl start コマンドを使用してサービスを再起動します。詳細については、「Amazon EMR でサービスを再起動するにはどうすればよいですか?」を参照してください。

変更、機能強化、解決した問題

• EMR バージョン 5.30.0 では、デフォルトで Ganglia がインストールされません。クラスターの作成時に、Ganglia を明示的に選択してインストールできます。

• Spark パフォーマンスの最適化。

• Presto パフォーマンスの最適化。

• Python 3 は、Amazon EMR バージョン 5.30.0 以降ではデフォルトです。

• プライベートサブネット内のサービスアクセス用のデフォルトのマネージドセキュリティグループが更新され、複数の新しいルールが追加されました。サービスアクセスにカスタムセキュリティグループを使用している場合は、同じルールをデフォルトのマネージドセキュリティグループとして含める必要があります。詳細については、「サービスアクセスの Amazon EMR マネージドセキュリティグループ (プライベートサブネット)」を参照してください。Amazon EMR でカスタムサービスロールを使用する場合は、ec2:describeSecurityGroups にアクセス許可を付与して、セキュリティグループが正常に作成されたかどうかを EMR で検証できるようにする必要があります。EMR_DefaultRole を使用する場合、このアクセス許可はデフォルトのマネージドポリシーに既に含まれています。

既知の問題

• 古い AL2 で「最大オープンファイル」の上限が低い [新しいリリースで修正済み]。Amazon EMR リリース emr-5.30.x、emr-5.31.0、emr-5.32.0、emr-6.0.0、emr-6.1.0、および emr-6.2.0 は、古いバージョンの Amazon Linux 2 (AL2) に基づいており、デフォルトの AMI を使用して Amazon EMR クラスターを作成する場合に「最大オープンファイル」の ulimit 設定が低くなります。Amazon EMR リリース 5.30.1、5.30.2、5.31.1、5.32.1、6.0.1、6.1.1、6.2.1、5.33.0、6.3.0 以降には、「最大オープンファイル」設定が高くなった永続的な修正が含まれています。オープンファイルの上限が低いリリースでは、Spark ジョブを送信するときに「Too many open files」というエラーが発生します。影響を受けるリリースでは、Amazon EMR のデフォルト AMI の「最大オープンファイル」はデフォルトの ulimit 設定 4096 になっており、最新の Amazon Linux 2 AMI の上限 65536 ファイルよりも低くなっています。「最大オープンファイル」の ulimit 設定が低い場合、Spark ドライバーとエグゼキュータが 4096 を超えるファイルを開こうとすると、Spark ジョブが失敗します。この問題を解決するために、Amazon EMR には、クラスターの作成時に ulimit 設定を調整するブートストラップアクション (BA) スクリプトが用意されています。

  この問題の永続的な修正がない古い Amazon EMR バージョンを使用している場合は、以下の回避策を使用すると、instance-controller ulimit を最大の 65536 ファイルに明示的に設定できます。

  コマンドラインから ulimit を明示的に設定する

  1. /etc/systemd/system/instance-controller.service を編集して、Service セクションに次のパラメータを追加します。

     LimitNOFILE=65536

     LimitNPROC=65536

  2. InstanceController を再起動します。

     $ sudo systemctl daemon-reload

     $ sudo systemctl restart instance-controller

  ブートストラップアクション (BA) を使用して ulimit を設定する

  ブートストラップアクション (BA) スクリプトを使用して、クラスター作成時にインスタンスコントローラーの ulimit を 65536 ファイルに設定することもできます。

  #!/bin/bash
  for user in hadoop spark hive; do
  sudo tee /etc/security/limits.d/$user.conf << EOF
  $user - nofile 65536
  $user - nproc 65536
  EOF
  done
  for proc in instancecontroller logpusher; do
  sudo mkdir -p /etc/systemd/system/$proc.service.d/
  sudo tee /etc/systemd/system/$proc.service.d/override.conf << EOF
  [Service]
  LimitNOFILE=65536
  LimitNPROC=65536
  EOF
  pid=$(pgrep -f aws157.$proc.Main)
  sudo prlimit --pid $pid --nofile=65535:65535 --nproc=65535:65535
  done
  sudo systemctl daemon-reload

• マネージドスケーリング

  Presto がインストールされていない 5.30.0 クラスターおよび 5.30.1 クラスターでマネージドスケーリング操作を実行すると、特にスケールダウン操作の後にすぐ、スケールアップ操作が実行されたときに、アプリケーション障害が発生するか、ユニフォームインスタンスグループまたはインスタンスフリートが ARRESTED 状態のままになる場合があります。

  回避策として、ジョブに Presto が必要ない場合でも、Amazon EMR リリース 5.30.0 および 5.30.1 を使用してクラスターを作成するときに、インストールするアプリケーションとして Presto を選択します。

• 複数のプライマリノードと Kerberos 認証を使用するクラスターの既知の問題

  Amazon EMR リリース 5.20.0 以降で複数のプライマリノードと Kerberos 認証を使用してクラスターを実行すると、クラスターをしばらく実行した後で、スケールダウンやステップの送信などのクラスターオペレーションに問題が発生する可能性があります。期間は、定義した Kerberos チケットの有効期間によって異なります。スケールダウンの問題は、自動スケールダウンリクエストと送信した明示的なスケールダウンリクエストの両方に影響します。その他のクラスターオペレーションも影響を受ける可能性があります。

  回避方法:

  • 複数のプライマリノードを持つ EMR クラスターのリードプライマリノードに hadoop ユーザーとして SSH 接続します。

  • 次のコマンドを実行して hadoop ユーザーの Kerberos チケットを更新します。

    kinit -kt <keytab_file> <principal>

    通常、キータブファイルは /etc/hadoop.keytab にあります。プリンシパルの形式は hadoop/<hostname>@<REALM> です。

  注記

  この回避策は、Kerberos チケットが有効になっている期間、効果があります。この期間はデフォルトで 10 時間ですが、Kerberos の設定で構成できます。Kerberos チケットの有効期限が切れたら、上記のコマンドを再実行する必要があります。

• Hue 4.6.0 のデフォルトのデータベースエンジンは SQLite であり、外部データベースで Hue を使用しようとすると、SQLite が原因で問題が発生します。これを修正するには、hue-ini 設定分類の engine を mysql に設定します。この問題は、Amazon EMR バージョン 5.30.1 で修正されています。

• Hive パーティション場所の形式設定で Spark を使用して Amazon S3 のデータを読み取り、Amazon EMR リリース 5.30.0 から 5.36.0、および 6.2.0 から 6.9.0 で Spark を実行すると、クラスターがデータを正しく読み取れなくなる問題が発生する可能性があります。これは、パーティションに以下の特徴がすべて当てはまる場合に発生する可能性があります。

  • 同じテーブルから 2 つ以上のパーティションがスキャンされます。

  • 少なくとも 1 つのパーティションディレクトリパスが、少なくとも 1 つの他のパーティションディレクトリパスのプレフィックスです。例えば、s3://bucket/table/p=a は s3://bucket/table/p=a b のプレフィックスです。

  • 他のパーティションディレクトリのプレフィックスに続く最初の文字が、/ 文字 (U+002F) より小さい UTF-8 値を持ちます。例えば、s3://bucket/table/p=a b の a と b の間にあるスペース文字 (U+0020) はこのカテゴリに該当します。非制御文字は他にも 14 個あることに注意してください: !"#$%&‘()*+,-。詳細については、「UTF-8 encoding table and Unicode characters」を参照してください。

  この問題の回避策として、spark-defaults 分類の spark.sql.sources.fastS3PartitionDiscovery.enabled 設定を false にセットします。