# DynamoDB でのエラー処理
このセクションでは、ランタイムエラーとその処理方法について説明します。同時に、Amazon DynamoDB に特有のエラーメッセージとコードについて説明します。AWS のすべてのサービスに共通するエラーのリストについては、「[アクセス管理](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/CommonErrors.html)」を参照してください。
**Topics**
+ [エラーコンポーネント](#Programming.Errors.Components)
+ [トランザクションエラー](#Programming.Errors.TransactionalErrors)
+ [エラーメッセージおよびコード](#Programming.Errors.MessagesAndCodes)
+ [アプリケーションのエラー処理](#Programming.Errors.Handling)
+ [エラーの再試行とエクスポネンシャルバックオフ](#Programming.Errors.RetryAndBackoff)
+ [バッチオペレーションとエラー処理](#Programming.Errors.BatchOperations)
## エラーコンポーネント
プログラムがリクエストを送信すると、DynamoDB はその処理を実行するよう試みます。リクエストが成功した場合、DynamoDB はそのオペレーションが出力した結果とともに、 HTTP の成功ステータスコード (`200 OK`) を返します。
リクエストが正常に行われなかった場合、DynamoDB はエラーを返します。それぞれのエラーには、次の三つのコンポーネントがあります:
+ HTTP ステータスコード (`400` など)。
+ 例外の名前 (`ResourceNotFoundException` など)。
+ エラーメッセージ (`Requested resource not found: Table: tablename not found` など)。
AWS SDK によりアプリケーションにエラーが伝達されるため、適切なアクションを実行できます。たとえば、Java プログラムでは、 `try-catch` を処理する `ResourceNotFoundException` ロジックを記述できます。
AWS SDK を使用していない場合は、DynamoDB からの低レベルのレスポンスの内容を、ユーザー側で解析する必要があります。以下に、そのようなレスポンスの例を示します。
```
HTTP/1.1 400 Bad Request
x-amzn-RequestId: LDM6CJP8RMQ1FHKSC1RBVJFPNVV4KQNSO5AEMF66Q9ASUAAJG
Content-Type: application/x-amz-json-1.0
Content-Length: 240
Date: Thu, 15 Mar 2012 23:56:23 GMT
{"__type":"com.amazonaws.dynamodb.v20120810#ResourceNotFoundException",
"message":"Requested resource not found: Table: tablename not found"}
```
## トランザクションエラー
トランザクションエラーの詳細については、「[DynamoDB でのトランザクション競合の処理](transaction-apis.md#transaction-conflict-handling)」を参照してください。
## エラーメッセージおよびコード
以下に、DynamoDB によって返される例外のリストを、HTTP ステータスコードでグループ分けして示します。*再試行してもいいですか*が*はい*であれば、同じリクエストを再度送信できます。*再試行してもいいですか*が*いいえ*であれば、新しいリクエストを送信する前に、クライアント側で問題を修正する必要があります。
### HTTP ステータスコード 400
HTTP ステータスコード`400`は、認証の失敗、必須パラメータの欠落、またはテーブルにプロビジョニングされているスループットの超過などのリクエストに関連した問題があることを示しています。リクエストを再度送信する前に、アプリケーションで問題を修正する必要があります。
**AccessDeniedException **
メッセージ: *アクセスが拒否されました。*
クライアントがリクエストに正しく署名しませんでした。AWS SDK を使用している場合には、リクエストへの署名が自動的に実行されます。使用していない場合は、「*AWS 全般のリファレンス*」の「[署名バージョン 4 の署名プロセス](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html)」に進んでください。
再試行してもいいですか。いいえ
**ConditionalCheckFailedException**
メッセージ: *条件付きリクエストが失敗しました。*
false と評価された条件を指定しました。たとえば、項目に条件付き更新を実行しようとしたかもしれませんが、属性の実際の値は、条件の予期される値と一致しませんでした。
再試行してもいいですか。いいえ
**IncompleteSignatureException**
メッセージ: *リクエストの署名が AWS スタンダードに適合しません。*
リクエストの署名に、必要なすべての要素が含まれていませんでした。AWS SDK を使用している場合には、リクエストへの署名が自動的に実行されます。使用していない場合は、「*AWS 全般のリファレンス*」の「[署名バージョン 4 の署名プロセス](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html)」に進んでください。
再試行してもいいですか。いいえ
**ItemCollectionSizeLimitExceededException**
メッセージ: *コレクションサイズが超過しました。*
ローカルセカンダリインデックスがあるテーブルにおいて、同じパーティションキー値を持つ項目のグループが占めるサイズが、最大 10 GB の上限を超過しました。項目コレクションの詳細については、「[ローカルセカンダリインデックス内の項目コレクション](LSI.md#LSI.ItemCollections)」を参照してください。
再試行してもいいですか。はい
**LimitExceededException**
メッセージ: *特定の受信者に対するオペレーションが多すぎます。*
同時オペレーションのコントロールプレーンが多すぎます。`CREATING`、`DELETING`、または `UPDATING` の状態のテーブルやインデックスの累積数が、500 を超えることはできません。
再試行してもいいですか。はい
**MissingAuthenticationTokenException**
メッセージ: *リクエストには、有効な (登録済みメンバー) AWS アクセスキー ID が含まれている必要があります。*
リクエストに、必要な認可ヘッダーが含まれていないか、または正しい形式ではありません。「」を参照してください[DynamoDB 低レベル API](Programming.LowLevelAPI.md)
再試行してもいいですか。いいえ
**ProvisionedThroughputExceededException**
メッセージ: *1 つのテーブルまたは 1 つ以上のグローバルセカンダリインデックスで、プロビジョン済みスループットが、許容されている最大量を超えました。プロビジョンドスループットと消費スループットのパフォーマンスメトリクスを表示するには、「[Amazon CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch/home)」を参照してください。*
エラーには、スロットリングが発生した理由に関する特定のコンテキストを提供する `ThrottlingReason` フィールドのリストが含まれ、形式は `ResourceType+OperationType+LimitType` (例: `TableReadProvisionedThroughputExceeded`) と、影響を受けるリソースの ARN です。これにより、スロットリング対象のリソース (テーブルまたはインデックス)、スロットリングをトリガーしたオペレーションタイプ (読み取りまたは書き込み)、および超過した特定の制限 (この場合はプロビジョンドキャパシティ) を特定できます。スロットリングの問題の診断と解決の詳細については、「[スロットリングの診断](throttling-diagnosing-workflow.md)」を参照してください。
例: リクエストの頻度が多すぎます。DynamoDB 用の AWS SDK では、この例外を受け取ったリクエストを自動的に再試行します。リクエストは最終的に成功しますが、再試行キューが大きすぎて終了しない場合もあります。[エラーの再試行とエクスポネンシャルバックオフ](#Programming.Errors.RetryAndBackoff) を使用して、リクエストの頻度を少なくします。
再試行してもいいですか。はい
**ReplicatedWriteConflictException**
メッセージ: *このリクエスト内の 1 つ以上の項目が、別のリージョンのリクエストによって変更されています。*
例: マルチリージョンの強力な整合性 (MRSC) グローバルテーブル内の項目に対して書き込み操作がリクエストされましたが、現在別のリージョンのリクエストによって変更されています。
再試行してもいいですか。はい
**RequestLimitExceeded**
メッセージ: *スループットがアカウントの現在のスループット制限を超えています。制限の引き上げをリクエストするには、[https://aws.amazon.com/support](https://aws.amazon.com/support) で AWS サポートにお問い合わせください。*
エラーには、スロットリングが発生した理由に関する特定のコンテキストを提供する `ThrottlingReason` フィールドのリストが含まれ、形式は `ResourceType+OperationType+LimitType` (例: `TableWriteAccountLimitExceeded` または `IndexReadAccountLimitExceeded`) と、影響を受けるリソースの ARN です。これにより、スロットリング対象のリソース (テーブルまたはインデックス)、スロットリングをトリガーしたオペレーションタイプ (読み取りまたは書き込み)、アカウントレベルのサービスクォータを超えたことを確認できます。スロットリングの問題の診断と解決の詳細については、「[スロットリングの診断](throttling-diagnosing-workflow.md)」を参照してください。
例: オンデマンドリクエストの速度が、許容されているアカウントスループットを超えていて、これ以上テーブルをスケールできません。
再試行してもいいですか。はい
**ResourceInUseException**
メッセージ: *変更しようとしているリソースは使用中です。*
例: 既存のテーブルを再作成しようとしたか、`CREATING` 状態にあるテーブルを削除しようとしました。
再試行してもいいですか。いいえ
**ResourceNotFoundException **
メッセージ: *リクエストされたリソースは存在しません。*
例: リクエストされたテーブルが存在しないか、ごく初期の `CREATING` 状態にあります。
再試行してもいいですか。いいえ
**ThrottlingException**
メッセージ: *リクエストの速度が、許容されているスループットを超えています。*
この例外は、AmazonServiceException レスポンスとして、TROTTLING\$1EXCEPTION ステータスコードとともに返されます。この例外は、[コントロールプレーン](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html#HowItWorks.API.ControlPlane) API オペレーションの実行が速すぎる場合に返される可能性があります。
オンデマンドモードを使用するテーブルの場合、リクエストレートが高すぎると、[データプレーン](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html#HowItWorks.API.DataPlane) API オペレーションでこの例外が返されることがあります。オンデマンドスケーリングの詳細については、「[初期スループットとスケーリングのプロパティ](on-demand-capacity-mode.md#on-demand-capacity-mode-initial)」を参照してください。
エラーには、スロットリングが発生した理由に関する特定のコンテキストを提供する `ThrottlingReason` フィールドのリストが含まれ、形式は `ResourceType+OperationType+LimitType` (例: `TableReadKeyRangeThroughputExceeded` または `IndexWriteMaxOnDemandThroughputExceeded`) と、影響を受けるリソースの ARN です。この情報は、スロットリング対象のリソース (テーブルまたはインデックス)、スロットリングをトリガーしたオペレーションタイプ (読み取りまたは書き込み)、および超過した特定の制限 (パーティション制限またはオンデマンドの最大スループット) を特定するのに役立ちます。スロットリングの問題の診断と解決の詳細については、「[スロットリングの診断](throttling-diagnosing-workflow.md)」を参照してください。
再試行してもいいですか。はい
**UnrecognizedClientException**
メッセージ: *アクセスキー ID またはセキュリティトークンが無効です。*
リクエスト署名が間違っています。最も可能性の高い原因は、AWS アクセスキー ID またはシークレットキーが無効であることです。
再試行してもいいですか。はい
**ValidationException**
メッセージ: 発生した特定のエラーにより異なります
このエラーは、必須パラメータが指定されていない、値が範囲外である、データ型が一致しない、などいくつかの理由で発生します。エラーメッセージに、エラーを引き起こしたリクエストの特定部分に関する詳細が含まれています。
再試行してもいいですか。いいえ
### HTTP ステータスコード 5xx
HTTP ステータスコード `5xx` は、AWS で解決する必要のある問題を示しています。これは一時的なエラーかもしれず、その場合はリクエストを再試行することで成功する場合があります。それ以外の場合、サービスにオペレーション上の問題があるかどうかを確認するために、[AWS Service Health Dashboard](https://status.aws.amazon.com/) を参照してください。
詳細については、「[Amazon DynamoDB の HTTP 5xx エラーを解決する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/dynamodb-http-5xx-errors/)」を参照してください。
**InternalServerError (HTTP 500)**
DynamoDB はリクエストを処理できませんでした。
再試行してもいいですか。はい
項目の操作中に内部サーバーエラーが発生することがあります。これはテーブルの存続期間中に発生すると予想されます。失敗したリクエストは速やかに再試行できます。
書き込みオペレーションでステータスコード 500 を受け取った場合、オペレーションは成功した可能性も、失敗した可能性もあります。書き込みオペレーションが `TransactWriteItem` リクエストである場合、オペレーションを再試行できる状態です。書き込みオペレーションが単一項目の書き込み要求 (`PutItem`、`UpdateItem`、または `DeleteItem` など) である場合、アプリケーションはオペレーションを再試行する前に項目の状態を読み取り、[DynamoDB 条件式 CLI の例](Expressions.ConditionExpressions.md) を使用して、前のオペレーションが成功したか失敗したかにかかわらず、再試行後も項目が正しい状態のままであることを確認します。冪等性が書き込みオペレーションの要件である場合は、[`TransactWriteItem`](transaction-apis.md#transaction-apis-txwriteitems) を使用してください。これは、同じアクションを実行する複数の試行を明確にするために自動的に `ClientRequestToken` を指定することにより、冪等リクエストをサポートします。
**ServiceUnavailable (HTTP 503)**
DynamoDB は現在利用できません。(これは一時的な状態です。)
再試行してもいいですか。はい
## アプリケーションのエラー処理
アプリケーションをスムーズに実行するには、エラーを見つけ、エラーに対応するロジックを組み込む必要があります。一般的な方法には、`try-catch`ブロックや`if-then`ステートメントの使用などがあります。
AWS SDK は独自に再試行とエラーチェックを実行します。AWS SDK の使用中にエラーが発生した場合は、エラーコードと説明が問題のトラブルシューティングに役立ちます。
また、レスポンスに`Request ID`が表示されます。`Request ID` は、AWS サポートを使用して問題を診断することが必要な場合に便利です。
## エラーの再試行とエクスポネンシャルバックオフ
特定のリクエストの処理中には、DNS サーバー、スイッチ、ロードバランサーなど、ネットワーク上のさまざまなコンポーネントが原因でエラーが発生する可能性があります。ネットワーク環境でこれらのエラー応答を処理する通常の方法は、クライアントアプリケーションで再試行を実装することです。この手法により、アプリケーションの信頼性が向上します。
各 AWS SDK は、自動的に再試行ロジックを実装しています。必要に応じて再試行パラメータを変更できます。たとえば、エラーが発生したら再試行が許可されない、Fail-Fast 方式を要求する Java アプリケーションについて考えてみましょう。AWS SDK for Java では、`ClientConfiguration` クラスを使用して `maxErrorRetry` の値を `0` に設定することで、再試行を無効にできます。詳細については、AWS SDK ドキュメントのご使用のプログラミング言語の項目を参照してください。
AWS SDK を使用していない場合は、サーバーエラー (5xx) を受け取る元のリクエストを再試行する必要があります。ただし、クライアントエラー (4xx、`ThrottlingException` または `ProvisionedThroughputExceededException` 以外) は、再試行する前にリクエスト自体を修正して問題を解決する必要があることを示しています。特定のスロットリングシナリオに対処するための詳細な推奨事項については、「[DynamoDB スロットリングのトラブルシューティング](TroubleshootingThrottling.md)」セクションを参照してください。
簡単な再試行に加えて、各 AWS SDK はエクスポネンシャルバックオフアルゴリズムを実装し、フロー制御を改善します。エクスポネンシャルバックオフは、再試行間の待機時間を累進的に長くして、連続的なエラー応答を受信するという概念に基づいています。たとえば、1 回目の再試行の前に最大 50 ミリ秒、2 回目の前に最大 100 ミリ秒、3 回目の前に最大 200 ミリ秒のようになります。ただし 1 分を経過してもリクエストが成功しない場合は、問題の原因はリクエストの速度ではなく、プロビジョニングしたスループットをリクエストのサイズが超えたためである可能性があります。1 分程度で再試行が停止するように最大回数を設定します。リクエストが失敗した場合は、プロビジョニングされたスループットのオプションを調べてください。
**注記**
AWS SDK には自動再試行ロジックとエクスポネンシャルバックオフが実装されています。
ほとんどのエクスポネンシャルバックオフアルゴリズムは、連続した衝突を防ぐためにジッター (ランダム化された遅延) を使用します。この場合は、そうした衝突を回避しようとしていないので、乱数を使用する必要はありません。ただし、同時クライアントを使用する場合、ジッターはリクエストをより速く成功させるのに役立ちます。詳細については、「[エクスポネンシャルバックオフとジッター](http://www.awsarchitectureblog.com/2015/03/backoff.html)」に関するブログ投稿を参照してください。
## バッチオペレーションとエラー処理
DynamoDB の低レベル API では、読み込み/書き込みのバッチオペレーションがサポートされています。`BatchGetItem` は 1 つ以上のテーブルからの項目の読み込みを処理し、`BatchWriteItem` は、1 つ以上のテーブルでの項目の入力や削除を処理します。これらのバッチオペレーションは、DynamoDB のバッチではない他のオペレーションのラッパーとして実装されています。つまり、`BatchGetItem` は、バッチの項目ごとに `GetItem` を一度呼び出します。同様に、`BatchWriteItem` は、`DeleteItem` または `PutItem` を必要に応じてバッチの項目ごとに呼び出します。
バッチオペレーションではバッチの個々のリクエストのエラーが許容されます。たとえば、5 つの項目を読み込む `BatchGetItem` リクエストの場合を考えます。基礎となる `GetItem` リクエストの一部が失敗した場合でも、`BatchGetItem` オペレーション全体が失敗することはありません。ただし、5 つのオペレーションにすべて失敗する場合は、`BatchGetItem` 全体が失敗します。
バッチオペレーションでは、失敗した個々のリクエストについて情報が返されるため、問題を診断し、オペレーションを再試行できます。`BatchGetItem` の場合、問題のあるテーブルとプライマリキーがレスポンスの `UnprocessedKeys` 値で返されます。`BatchWriteItem` の場合、同様の情報は `UnprocessedItems` で返されます。
読み込みまたは書き込みの失敗の原因として最も可能性が高いのは、*スロットリング*です。`BatchGetItem` の場合、バッチリクエストの 1 つ以上のテーブルに、オペレーションをサポートするための十分なプロビジョンド読み込みキャパシティーがなくなります。`BatchWriteItem` の場合、1 つ以上のテーブルに、十分なプロビジョンド書き込みキャパシティーがなくなります。
DynamoDB によって未処理の項目が返された場合は、それらの項目に対してバッチオペレーションを再試行する必要があります。ただし、*エクスポネンシャルバックオフアルゴリズムを使用することを強くお勧めします*。すぐにバッチオペレーションを再試行した場合、基礎となる読み込みまたは書き込みリクエストはやはり、個々のテーブルに対する帯域幅調整により失敗することがあります。エクスポネンシャルバックオフアルゴリズムを使用してバッチオペレーションを遅らせた場合は、バッチの個々のリクエストが成功する可能性がはるかに高くなります。
**注記**
一部の AWS SDK では、未処理の項目の再試行を自動的に処理する高レベルのクライアントが提供されているため、この再試行ロジックを自分で実装する必要はありません。例えば、次のようになります。
**Java** – AWS SDK for Java v2 の [DynamoDB 拡張クライアント](DynamoDBEnhanced.md)と v1 の [DynamoDBMapper](DynamoDBMapper.md) はどちらも、バッチオペレーションを実行するときに未処理の項目を自動的に再試行します。
**Python** – boto3 Table リソース `batch_writer` は、バッチ書き込みオペレーションの未処理の項目の再試行を暗黙的に処理します。詳細については、「[テーブルリソース batch\$1writer の使用](programming-with-python.md#programming-with-python-batch-writer)」を参照してください。
この動作を提供しない低レベルのクライアントまたは SDK を使用している場合は、上記のように再試行ロジックを自分で実装する必要があります。