DynamoDB での Amazon EMR オペレーションのパフォーマンスの最適化 - Amazon EMR
プロビジョニングされた読み込み容量単位読み込みパーセントの設定書き込みパーセントの設定再試行間隔の設定マップタスクの数並列データリクエスト処理間隔スループットの超過の回避[Request time] (リクエストタイム)時間ベースのテーブルアーカイブされたデータ

DynamoDB での Amazon EMR オペレーションのパフォーマンスの最適化

DynamoDB テーブルでの Amazon EMR の操作は読み込み操作としてカウントされ、テーブルのプロビジョニング済みスループットの設定が適用されます。Amazon EMR は独自のロジックを実装して、DynamoDB テーブルの負荷を分散させ、プロビジョニング済みスループットを超過する可能性を最小限に抑えようとします。Amazon EMR はそれぞれの Hive クエリの最後に、プロビジョニング済みスループットを超過した回数など、クエリの処理に使用されたクラスターに関する情報を返します。この情報とともに、DynamoDB スループットに関する CloudWatch メトリクスを使用すると、以降のリクエストで DynamoDB テーブルの負荷をより適切に管理することができます。

DynamoDB テーブルを操作する際に Hive クエリのパフォーマンスに影響を与える要因を次に示します。

プロビジョニングされた読み込み容量単位

DynamoDB テーブルに対して Hive クエリを実行する際には、十分な量の読み込み容量単位をプロビジョニングしておく必要があります。

たとえば、DynamoDB テーブルに対して 100 ユニットの読み込みキャパシティーをプロビジョニングしているとします。この場合、1 秒間に 100 の読み込み（409,600 バイト）を実行できます。そのテーブルに 20 GB（21,474,836,480 バイト）のデータが含まれており、Hive クエリがフルテーブルスキャンを実行する場合、クエリの実行にかかる時間は次のように見積もられます。

21,474,836,480 / 409,600 = 52,429 秒 = 14.56 時間

必要な時間を短縮するには、ソース DynamoDB テーブルで読み込みキャパシティーユニットを調整する以外に方法はありません。Amazon EMR クラスターにノードをさらに追加しても、時間は短縮されません。

Hive 出力では、1 つ以上のマッパープロセスが終了すると、完了のパーセンテージが更新されます。プロビジョニングされた読み込みキャパシティーが小さく設定された大きな DynamoDB テーブルでは、完了のパーセンテージ出力が長時間更新されない場合があります。上記のような場合、ジョブは数時間にわたって 0% 完了として表示されます。ジョブの進行状況の詳細なステータスについては、Amazon EMR コンソールに移動してください。ここで、個別のマッパータスクのステータスおよびデータ読み込みの統計を表示できます。

また、マスターノードの Hadoop インターフェイスにログオンし、Hadoop 統計を表示することもできます。ここには、個別のマップタスクのステータスおよびいくつかのデータ読み込み統計が表示されます。詳細については、「Amazon EMR 管理ガイド」の「マスターノードでホストされているウェブインターフェイス」を参照してください。

読み込みパーセントの設定

デフォルトでは、Amazon EMR は現在のプロビジョニング済みスループットに基づいて、DynamoDB テーブルに対するリクエスト負荷を管理します。ただし、プロビジョニング済みスループットを超過した応答を多数含むジョブに関する情報を Amazon EMR が返す場合は、Hive テーブルを設定する際に、dynamodb.throughput.read.percent パラメータを使用してデフォルトの読み込みレートを調整することができます。読み込みパーセントパラメータの設定の詳細については、「Hive のオプション」を参照してください。

書き込みパーセントの設定

デフォルトでは、Amazon EMR は現在のプロビジョニング済みスループットに基づいて、DynamoDB テーブルに対するリクエスト負荷を管理します。ただし、プロビジョニング済みスループットを超過した応答を多数含むジョブに関する情報を Amazon EMR が返す場合は、Hive テーブルを設定する際に、dynamodb.throughput.write.percent パラメータを使用してデフォルトの書き込みレートを調整することができます。書き込みパーセントパラメータの設定の詳細については、「Hive のオプション」を参照してください。

再試行間隔の設定

デフォルトでは、Hive クエリが 2 分以内 (デフォルトの再試行間隔) に結果を返さない場合、Amazon EMR はこのクエリを再実行します。この間隔は、Hive クエリの実行時に dynamodb.retry.duration パラメータを設定することによって調整できます。書き込みパーセントパラメータの設定の詳細については、「Hive のオプション」を参照してください。

マップタスクの数

DynamoDB に格納されているデータのエクスポートおよびクエリ実行のリクエストを処理するために Hadoop が起動するマッパーデーモンは、最大読み込みレート (毎秒 1 MiB) を上限値として、使用される読み込みキャパシティーを制限します。DynamoDB で追加のプロビジョニング済みスループットを使用できる場合は、マッパーデーモンの数を増やせば、Hive エクスポートおよびクエリオペレーションのパフォーマンスを向上させることができます。そのためには、クラスター内の EC2 インスタンスの数を増やすか、または各 EC2 インスタンスで実行されているマッパーデーモンの数を増やします。

クラスター内の EC2 インスタンスの数を増やすには、現在のクラスターを停止し、より多くの EC2 インスタンスとともに再起動します。Amazon EMRコンソールからクラスターを起動する場合は、[Configure EC2 Instances] (EC2 インスタンスの設定) ダイアログボックスで EC2 インスタンスの数を指定します。または、CLI からクラスターを起動する場合は ‑‑num-instances オプションを使用します。

インスタンスで実行されるマップタスクの数は、EC2 インスタンスタイプによって異なります。サポートされる EC2 インスタンスタイプ、および各タイプで提供されるマッパーの数の詳細については、タスクの設定 を参照してください。そこには、サポートされる設定ごとに "タスクの設定" セクションがあります。

マッパーデーモンの数を増やすもう 1 つの方法としては、Hadoop の mapreduce.tasktracker.map.tasks.maximum 設定パラメータをより大きい値に変更します。この場合は、EC2 インスタンスの数またはサイズを大きくせずにマッパーの数を増やすことができるので、コストを削減できるという利点があります。欠点としては、この値を大きく設定しすぎると、クラスター内の EC2 インスタンスがメモリ不足になる可能性があります。mapreduce.tasktracker.map.tasks.maximum を設定するには、クラスターを起動し、mapreduce.tasktracker.map.tasks.maximum の値を mapred-site 設定分類のプロパティとして指定します。これは次の例で示されます。詳細については、「アプリケーションの設定」を参照してください。

{
    "configurations": [
    {
        "classification": "mapred-site",
        "properties": {
            "mapred.tasktracker.map.tasks.maximum": "10"
        }
    }
    ]
}

並列データリクエスト

複数のユーザーまたは複数のアプリケーションから単一のテーブルに複数のデータリクエストが行われると、プロビジョニング済み読み込みスループットが減少し、パフォーマンス速度が低下します。

処理間隔

DynamoDB におけるデータの整合性は、各ノードで実行される読み込み/書き込みオペレーションの順序に影響を受けます。Hive クエリの進行中に、別のアプリケーションが DynamoDB テーブルに新しいデータをロードしたり、既存のデータの変更や削除を行ったりする場合があります。この場合、クエリの実行中にデータに対して行われた変更は Hive クエリの結果に反映されないことがあります。

スループットの超過の回避

DynamoDB に対して Hive クエリを実行する際には、プロビジョニング済みスループットを超過しないように注意してください。超過すると、アプリケーションによる DynamoDB::Get の呼び出しに必要な容量が不足してしまいます。この状態が発生しないようにするには、Amazon CloudWatch でログの確認およびメトリクスのモニタリングを行うことで、アプリケーションによる DynamoDB::Get の呼び出し時に読み込み量とスロットリングを定期的にモニタリングする必要があります。

[Request time] (リクエストタイム)

DynamoDB テーブルの需要が低いタイミングでテーブルにアクセスするように、Hive クエリをスケジューリングすると、パフォーマンスを向上させられます。たとえば、アプリケーションのほとんどのユーザーがサンフランシスコに住んでいる場合、大部分のユーザーが睡眠中で DynamoDB データベースを更新していない毎朝 4 時 (PST) にデータをエクスポートするように選択することができます。

時間ベースのテーブル

データが一連の時間ベースの DynamoDB テーブル (たとえば、1 日あたり 1 つのテーブル) として構成されている場合は、テーブルが非アクティブになったときにデータをエクスポートできます。この手法を使用すると、データを Amazon S3 に継続的にバックアップできます。

アーカイブされたデータ

DynamoDB に格納されているデータに対して多数の Hive クエリを実行する予定であり、アーカイブされたデータがアプリケーションで許容される場合は、データを HDFS または Amazon S3 にエクスポートし、DynamoDB の代わりにデータのコピーに対して Hive クエリを実行することができます。これにより、読み込みオペレーションおよびプロビジョニング済みスループットを過度に使用せずに済みます。