翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Keyspaces (Apache Cassandra 向け) のトラブルシューティング
このガイドでは、Amazon Keyspaces (Apache Cassandra 向け) の使用時のさまざまなシナリオを取り上げ、問題のトラブルシューティング手順を説明します。一般的なエラー、接続の問題、キャパシティ管理の問題、データ定義言語 (DDL) エラーの解決に関する情報を紹介します。
+ **一般的なエラー**
+ `NoNodeAvailableException`、`NoHostAvailableException`、`AllNodesFailedException` など、上位の例外をトラブルシューティングする。
+ Java ドライバー例外の根本原因のエラーを特定する。
+ 再試行ポリシーを実装し、接続を正しく設定する。
+ **接続の問題**
+ `cqlsh` または Apache Cassandra クライアントドライバーを使用した Amazon Keyspaces エンドポイントへの接続時に起きるエラーを解決する。
+ VPC エンドポイント接続、Cassandra-stress 接続、IAM 設定のエラーをトラブルシューティングする。
+ データインポート中の接続損失に対処する。
+ **キャパシティ管理エラー**
+ テーブル、パーティション、接続に関連するキャパシティ不足エラーを把握し、解決する。
+ 関連する Amazon Keyspaces メトリクスを Amazon CloudWatch Logs でモニタリングする。
+ 接続とスループットを最適化してパフォーマンスを向上させる。
+ **データ定義言語 (DDL) エラー**
+ キースペースとテーブルの作成時、アクセス時、または復元時のエラーをトラブルシューティングする。
+ カスタムの Time to Live (TTL) 設定、列の制限、範囲の削除に関連する障害に対処する。
+ 大量の削除ワークロードに関する考慮事項。
IAM アクセスに関するトラブルシューティングガイダンスについては、「[Amazon Keyspaces のアイデンティティとアクセスに関するトラブルシューティング](security_iam_troubleshoot.md)」を参照してください。セキュリティに関する詳しいベストプラクティスについては、「[Amazon Keyspaces のセキュリティベストプラクティス](best-practices-security.md)」を参照してください。
**Topics**
+ [一般的なエラー](troubleshooting.general.md)
+ [接続エラー](troubleshooting.connecting.md)
+ [キャパシティ管理エラー](troubleshooting.serverless.md)
+ [データ定義言語エラー](troubleshooting.cql.md)
# Amazon Keyspaces の一般的なエラーのトラブルシューティング
一般的なエラーが発生していませんか。以下は、一般的なシナリオとその解決方法です。
## 一般的なエラー
次のいずれかの上位の例外が発生している場合、さまざまな原因が考えられます。
+ `NoNodeAvailableException`
+ `NoHostAvailableException`
+ `AllNodesFailedException`
これらはクライアントドライバーが生成する例外であり、コントロール接続の確立時や、読み取り/書き込み/準備/実行/バッチリクエストの実行時に発生する可能性があります。
コントロール接続の確立中にエラーが起きた場合は、アプリケーションで指定されたすべての接続先に到達できないということです。読み取り/書き込み/準備/実行クエリの実行中にエラーが起きれば、それは、そのリクエストが再試行回数をすべて使い果たしたということです。デフォルトの再試行ポリシーを使用している場合、再試行のたびに別のノードで試行されます。
### 上位の Java ドライバー例外の根本原因のエラーを特定する方法
これらの一般的なエラーは、接続に問題がある場合や、読み取り/書き込み/準備/実行のオペレーションの実行時に発生することがあります。分散型システムでは一時的な障害が想定されるため、リクエストを再試行することで対処する必要があります。接続エラーの発生時に、Java ドライバーは自動では再試行しません。そのため、アプリケーションでドライバー接続を確立する際は、再試行ポリシーを実装することを推奨します。接続のベストプラクティスの詳細については、「[サーバーレス環境のクライアントドライバー接続を最適化する](connections.md)」を参照してください。
デフォルトでは、Java ドライバーはすべてのリクエストに対して `idempotence` (べき等性) を false に設定します。つまり、読み取り/書き込み/準備のリクエストが失敗しても、Java ドライバーは自動的には再試行しません。`idempotence` を `true` に設定して、リクエストが失敗した場合は再試行するようにドライバーに指示する方法は、いくつかあります。ここでは、Java アプリケーションで単一のリクエストに対してプログラムでべき等性を設定する一例を紹介します。
```
Statement s = new SimpleStatement("SELECT * FROM my_table WHERE id = 1");
s.setIdempotent(true);
```
または、次の例に示すように、Java アプリケーション全体のデフォルトのべき等性をプログラムで設定できます。
```
// Make all statements idempotent by default:
cluster.getConfiguration().getQueryOptions().setDefaultIdempotence(true);
//Set the default idempotency to true in your Cassandra configuration
basic.request.default-idempotence = true
```
また、アプリケーションレベルで再試行ポリシーを作成する方法もお勧めします。この場合、アプリケーションで `NoNodeAvailableException` をキャッチしてリクエストを再試行する必要があります。再試行は 10 回行い、エクスポネンシャルバックオフを使用して、10 ミリ秒から始めて最長 100 ミリ秒まで延ばし、すべての再試行の合計時間を 1 秒に収めることを推奨します。
もう 1 つの選択肢は、Java ドライバー接続の確立時に Amazon Keyspaces のエクスポネンシャルバックオフ再試行ポリシーを適用することです。このポリシーは [Github](https://github.com/aws-samples/amazon-keyspaces-java-driver-helpers/blob/main/src/main/java/com/aws/ssa/keyspaces/retry/AmazonKeyspacesExponentialRetryPolicy.java) で公開されています。
デフォルトの再試行ポリシーを使用する場合は、複数のノードへの接続が確立されていることを確認してください。それには、Amazon Keyspaces で次のクエリを使用します。
```
SELECT * FROM system.peers;
```
このクエリの応答が空の場合、Amazon Keyspaces で単一のノードを使用しているということです。デフォルトの再試行ポリシーを使用している場合、再試行は行われません。デフォルトの再試行は必ず別のノードで行われるためです。VPC エンドポイントを介した接続の確立の詳細については、「[Amazon Keyspaces の VPC エンドポイント経由接続の設定方法](connections.md#connections.VPCendpoints)」を参照してください。
Datastax 4.x Cassandra ドライバーを使用して Amazon Keyspaces への接続を確立する方法を説明したステップバイステップのチュートリアルについては、「[Apache Cassandra 用の 4.x DataStax Java ドライバーと SigV4 認証プラグインを使用して Amazon Keyspaces に接続するためのステップバイステップのチュートリアル](using_java_driver.md#java_tutorial.SigV4)」を参照してください。
# Amazon Keyspaces の接続エラーのトラブルシューティング
接続に問題がありませんか。以下は、一般的なシナリオとその解決方法です。
## Amazon Keyspaces エンドポイントへの接続中のエラー
接続が失敗し、接続エラーが発生すると、さまざまなエラーメッセージが表示される可能性があります。次のセクションでは、最も一般的なシナリオを取り上げます。
**Topics**
+ [cqlsh を使用して Amazon Keyspaces に接続できない](#troubleshooting.connection.cqlsh)
+ [Cassandra クライアントドライバーを使用して Amazon Keyspaces に接続することができない](#troubleshooting.connection.driver)
### cqlsh を使用して Amazon Keyspaces に接続できない
**cqlsh を使用して Amazon Keyspaces エンドポイントに接続しようとすると、`Connection error` が発生して接続が失敗します。**
cqlsh が正しく設定されていない場合、Amazon Keyspaces テーブルに接続しようとすると接続は失敗します。次のセクションでは、cqlsh を使用して接続の確立を試みた時に接続エラーが発生するという最も一般的な設定問題の例を示します。
**注記**
VPC から Amazon Keyspaces に接続しようとする場合は、追加のアクセス権限が必要です。VPC エンドポイントを使用して接続を正常に設定するには、[チュートリアル: インターフェイス VPC エンドポイントを使用して Amazon Keyspaces に接続する](vpc-endpoints-tutorial.md) の手順に従ってください。
**cqlsh を使って Amazon Keyspaces に接続しようとすると、接続の `timed out` エラーが発生します。**
これは正しいポートを指定しなかった場合に発生する可能性がある問題で、発生した場合は次のエラーが表示されます。
```
# cqlsh cassandra.us-east-1.amazonaws.com 9140 -u "USERNAME" -p "PASSWORD" --ssl
Connection error: ('Unable to connect to any servers', {'3.234.248.199': error(None, "Tried connecting to [('3.234.248.199', 9140)]. Last error: timed out")})
```
この問題を解決するには、接続にポート 9142 を使用しているか確認してください。
**cqlsh を使ってAmazon Keyspaces に接続しようとすると、`Name or service not known` というエラーが発生します。**
これは、使用しているエンドポイントのスペルが間違っている場合、またはそのエンドポイントが存在しない場合に発生する可能性がある問題です。以下は、エンドポイント名のスペルが間違っている場合の例です。
```
# cqlsh cassandra.us-east-1.amazon.com 9142 -u "USERNAME" -p "PASSWORD" --ssl
Traceback (most recent call last):
File "/usr/bin/cqlsh.py", line 2458, in >module>
main(*read_options(sys.argv[1:], os.environ))
File "/usr/bin/cqlsh.py", line 2436, in main
encoding=options.encoding)
File "/usr/bin/cqlsh.py", line 484, in __init__
load_balancing_policy=WhiteListRoundRobinPolicy([self.hostname]),
File "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.11.0-bb96859b.zip/cassandra-driver-3.11.0-bb96859b/cassandra/policies.py", line 417, in __init__
socket.gaierror: [Errno -2] Name or service not known
```
パブリックエンドポイントを使用して接続している場合、この問題を解決するには、[Amazon Keyspaces のサービスエンドポイント](programmatic.endpoints.md) から使用可能なエンドポイントを選択し、そのエンドポイントの名前に問題がないことを確認してください。VPC エンドポイントを使用して接続する場合は、cqlsh 設定の VPC エンドポイント情報が正しいことを確認してください。
**cqlsh を使用して Amazon Keyspaces に接続しようとすると、`OperationTimedOut` というエラーが発生します。**
Amazon Keyspaces では、接続時の強力なセキュリティを確保するために、SSL を有効にする必要があります。SSL パラメータが見つからない場合は、次のエラーが表示されることがあります。
```
# cqlsh cassandra.us-east-1.amazonaws.com -u "USERNAME" -p "PASSWORD"
Connection error: ('Unable to connect to any servers', {'3.234.248.192': OperationTimedOut('errors=Timed out creating connection (5 seconds), last_host=None',)})
#
```
この問題を解決するには、cqlsh 接続コマンドに次のフラグを追加してください。
```
--ssl
```
**cqlsh を使用して Amazon Keyspaces に接続しようとすると、`SSL transport factory requires a valid certfile to be specified` というエラーが発生します。**
この場合、SSL/TLS 証明書へのパスが欠落しているため、次のエラーが発生します。
```
# cat .cassandra/cqlshrc
[connection]
port = 9142
factory = cqlshlib.ssl.ssl_transport_factory
#
# cqlsh cassandra.us-east-1.amazonaws.com -u "USERNAME" -p "PASSWORD" --ssl
Validation is enabled; SSL transport factory requires a valid certfile to be specified. Please provide path to the certfile in [ssl] section as 'certfile' option in /root/.cassandra/cqlshrc (or use [certfiles] section) or set SSL_CERTFILE environment variable.
#
```
この問題を解決するには、コンピュータの certfile へのパスを追加します。詳細については、「[TLS の `cqlsh` 接続を手動で設定する方法](programmatic.cqlsh.md#encrypt_using_tls)」を参照してください。
```
certfile = path_to_file/keyspaces-bundle.pem
```
**cqlsh を使用して Amazon Keyspaces に接続しようとすると、`No such file or directory` というエラーが発生します。**
これは、コンピュータの証明書ファイルへのパスが間違っている場合に発生する可能性がある問題で、発生した場合は次のエラーが表示されます。
```
# cat .cassandra/cqlshrc
[connection]
port = 9142
factory = cqlshlib.ssl.ssl_transport_factory
[ssl]
validate = true
certfile = /root/wrong_path/keyspaces-bundle.pem
#
# cqlsh cassandra.us-east-1.amazonaws.com -u "USERNAME" -p "PASSWORD" --ssl
Connection error: ('Unable to connect to any servers', {'3.234.248.192': IOError(2, 'No such file or directory')})
#
```
この問題を解決するには、コンピュータの certfile へのパスが正しいか確認してください。詳細については、「[TLS の `cqlsh` 接続を手動で設定する方法](programmatic.cqlsh.md#encrypt_using_tls)」を参照してください。
**cqlsh を使用して Amazon Keyspaces に接続しようとすると、`[X509] PEM lib` というエラーが発生します。**
これは、SSL/TLS 証明書`pem`ファイルが有効でない場合、次のエラーが発生する可能性があります。
```
# cqlsh cassandra.us-east-1.amazonaws.com -u "USERNAME" -p "PASSWORD" --ssl
Connection error: ('Unable to connect to any servers', {'3.234.248.241': error(185090057, u"Tried connecting to [('3.234.248.241', 9142)]. Last error: [X509] PEM lib (_ssl.c:3063)")})
#
```
この問題を解決するには、必要なデジタル証明書をダウンロードしていることを確認してください。詳細については、「[TLS の `cqlsh` 接続を手動で設定する方法](programmatic.cqlsh.md#encrypt_using_tls)」を参照してください。
**cqlsh を使用して Amazon Keyspaces に接続しようとすると、`unknown` SSL というエラーが発生します。**
これは、SSL/TLS 証明書`pem`ファイルが空の場合に発生する可能性があり、次のエラーが発生します。
```
# cqlsh cassandra.us-east-1.amazonaws.com -u "USERNAME" -p "PASSWORD" --ssl
Connection error: ('Unable to connect to any servers', {'3.234.248.220': error(0, u"Tried connecting to [('3.234.248.220', 9142)]. Last error: unknown error (_ssl.c:3063)")})
#
```
この問題を解決するには、必要なデジタル証明書をダウンロードしていることを確認してください。これを確認するには、次のトピックのステップを使用します[TLS の `cqlsh` 接続を手動で設定する方法](programmatic.cqlsh.md#encrypt_using_tls)。
**cqlsh を使用して Amazon Keyspaces に接続しようとすると、`SSL: CERTIFICATE_VERIFY_FAILED` というエラーが発生します。**
これは SSL/TLS 証明書ファイルを検証できなかった場合に発生する可能性がある問題で、発生した場合は次のエラーが表示されます。
```
Connection error: ('Unable to connect to any servers', {'3.234.248.223': error(1, u"Tried connecting to [('3.234.248.223', 9142)]. Last error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:727)")})
```
この問題を解決するには、必要なデジタル証明書をダウンロードしていることを確認してください。これを確認するには、次のトピックのステップを使用します[TLS の `cqlsh` 接続を手動で設定する方法](programmatic.cqlsh.md#encrypt_using_tls)。
**cqlsh を使用して Amazon Keyspaces に接続しようとすると、`Last error: timed out` というエラーが発生します。**
これは、Amazon EC2 セキュリティグループで Amazon Keyspaces のアウトバウンドルールを設定しなかった場合に発生する可能性がある問題で、発生した場合は次のエラーが表示されます。
```
# cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "USERNAME" -p "PASSWORD" --ssl
Connection error: ('Unable to connect to any servers', {'3.234.248.206': error(None, "Tried connecting to [('3.234.248.206', 9142)]. Last error: timed out")})
#
```
この問題の原因が ではなく Amazon EC2 インスタンスの設定であることを確認するには`cqlsh`、 を使用してキースペースへの接続を試みます。たとえば AWS CLI、次のコマンドを使用します。
```
aws keyspaces list-tables --keyspace-name 'my_keyspace'
```
このコマンドもタイムアウトする場合は、Amazon EC2 インスタンスが正しく設定されていません。
Amazon Keyspaces にアクセスするための十分なアクセス許可があることを確認するには、 AWS CloudShell を使用して に接続できます`cqlsh`。これで接続が確立される場合は、Amazon EC2 インスタンスの設定が必要です。
この問題を解決するには、Amazon Keyspaces への接続を許可するアウトバウンドルールが Amazon EC2 インスタンスにあるかどうかを確認します。ない場合は、EC2 インスタンスの新しいセキュリティグループを作成し、Amazon Keyspaces リソースへのアウトバウンドトラフィックを許可するルールを追加する必要があります。Amazon Keyspaces へのトラフィックを許可するようにアウトバウンドルールを更新するには、**[タイプ]** ドロップダウンメニューから **[CQLSH/CASSANDRA]** を選択してください。
アウトバウンドトラフィックルールを追加した新しいセキュリティグループを作成したら、そのグループをインスタンスに追加する必要があります。インスタンスを選択し、**[アクション]**、**[セキュリティ]**、**[セキュリティグループを変更]** の順に選択します。アウトバウンドルール付きの新しいセキュリティグループを追加しますが、デフォルトのグループも引き続き使用可能にしておいてください。
EC2 アウトバウンドルールの表示方法と編集方法の詳細については、「Amazon EC2 ユーザーガイド」の「[セキュリティグループへのルールの追加](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule)」を参照してください。
**cqlsh を使用して Amazon Keyspaces に接続しようとすると、`Unauthorized` というエラーが発生します。**
これは、IAM ユーザーポリシーで Amazon Keyspaces のアクセス許可が欠如している場合に発生する可能性がある問題で、発生した場合は次のエラーが表示されます。
```
# cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "testuser-at-12345678910" -p "PASSWORD" --ssl
Connection error: ('Unable to connect to any servers', {'3.234.248.241': AuthenticationFailed('Failed to authenticate to 3.234.248.241: Error from server: code=2100 [Unauthorized] message="User arn:aws:iam::12345678910:user/testuser has no permissions."',)})
#
```
この問題を解決するには、IAM ユーザー `testuser-at-12345678910` が Amazon Keyspaces へのアクセス許可を取得しているか確認してください。Amazon Keyspaces へのアクセスを許可する IAM ポリシーの例については、「[Amazon Keyspaces のアイデンティティベースポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。
IAM アクセスに関するトラブルシューティングガイダンスについては、「[Amazon Keyspaces のアイデンティティとアクセスに関するトラブルシューティング](security_iam_troubleshoot.md)」を参照してください。
**cqlsh を使用して Amazon Keyspaces に接続しようとすると、`Bad credentials` というエラーが発生します。**
これは、ユーザー名またはパスワードが間違っている場合に発生する可能性がある問題で、発生した場合は次のエラーが表示されます。
```
# cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "USERNAME" -p "PASSWORD" --ssl
Connection error: ('Unable to connect to any servers', {'3.234.248.248': AuthenticationFailed('Failed to authenticate to 3.234.248.248: Error from server: code=0100 [Bad credentials] message="Provided username USERNAME and/or password are incorrect"',)})
#
```
この問題を解決するには、コードの *USERNAME* (ユーザー名) と *PASSWORD* (パスワード) が、[サービス固有の認証情報](programmatic.credentials.ssc.md)を生成したときに取得したユーザー名とパスワードと一致しているか確認してください。
**重要**
cqlsh を使用して接続を試みると引き続きエラーが表示される場合は、`--debug` オプションでコマンドを再実行し、 サポートへの連絡時に詳細な出力を含めてください。
### Cassandra クライアントドライバーを使用して Amazon Keyspaces に接続することができない
次のセクションでは、Cassandra クライアントドライバーとの接続時に発生する最も一般的なエラーを示します。
**DataStax Java ドライバーを使用して Amazon Keyspaces テーブルに接続しようとすると、`NodeUnavailableException` というエラーが発生します。**
リクエストの試行に使用した接続が切断されると、次のエラーが発生します。
```
[com.datastax.oss.driver.api.core.NodeUnavailableException: No connection was available to Node(endPoint=vpce-22ff22f2f22222fff-aa1bb234.cassandra.us-west-2.vpce.amazonaws.com/11.1.1111.222:9142, hostId=1a23456b-c77d-8888-9d99-146cb22d6ef6, hashCode=123ca4567)]
```
この問題を解決するには、ハートビート値を確認し、値が 30 秒よりも長い場合は短くします。
```
advanced.heartbeat.interval = 30 seconds
```
次に、関連するタイムアウトを確認し、値が 5 秒以上に設定されていることを確認します。
```
advanced.connection.init-query-timeout = 5 seconds
```
**ドライバーと SigV4 プラグインを使用して Amazon Keyspaces に接続しようとすると、`AttributeError` というエラーが発生します。**
認証情報が正しく設定されていない場合は、次のエラーが発生します。
```
cassandra.cluster.NoHostAvailable: (‘Unable to connect to any servers’,
{‘44.234.22.154:9142’: AttributeError(“‘NoneType’ object has no attribute ‘access_key’“)})
```
この問題を解決するには、SigV4 プラグインの使用時に IAM ユーザーまたはロールに関連付けられた認証情報を渡すことになっているか確認します。SigV4 プラグインには次の認証情報が必要です。
+ `AWS_ACCESS_KEY_ID` – IAM ユーザーまたはロールに関連付けられた AWS アクセスキーを指定します。
+ `AWS_SECRET_ACCESS_KEY` - アクセスキーに関連付けられるシークレットキーを指定します。これは、基本的にアクセスキーの「パスワード」です。
アクセスキーと SigV4 プラグインの詳細については、「[Amazon Keyspaces の AWS 認証情報の作成と設定](access.credentials.md)」を参照してください。
**ドライバーを使用して Amazon Keyspaces テーブルに接続しようとすると、`PartialCredentialsError` というエラーが発生します。**
`AWS_SECRET_ACCESS_KEY` が欠落している場合、次のエラーが発生する可能性があります。
```
cassandra.cluster.NoHostAvailable: (‘Unable to connect to any servers’, {‘44.234.22.153:9142’:
PartialCredentialsError(‘Partial credentials found in config-file, missing: aws_secret_access_key’)})
```
この問題を解決するには、SigV4 プラグインを使用する場合に `AWS_ACCESS_KEY_ID` と `AWS_SECRET_ACCESS_KEY` の両方を渡すことになっているか確認してください。アクセスキーと SigV4 プラグインの詳細については、「[Amazon Keyspaces の AWS 認証情報の作成と設定](access.credentials.md)」を参照してください。
**ドライバーを使用して Amazon Keyspaces テーブルに接続しようとすると、`Invalid signature` というエラーが発生します。**
署名に必要なコンポーネントのいずれかが誤っているか、セッションに対して正しく定義されていないことが原因として考えられます。
+ `AWS_ACCESS_KEY_ID`
+ `AWS_SECRET_ACCESS_KEY`
+ `AWS_DEFAULT_REGION`
次のエラーは、無効なアクセスキーの例です。
```
cassandra.cluster.NoHostAvailable: (‘Unable to connect to any servers’, {‘11.234.11.234:9142’:
AuthenticationFailed(‘Failed to authenticate to 11.234.11.234:9142: Error from server: code=0100
[Bad credentials] message=“Authentication failure: Invalid signature”’)})
```
この問題を解決するには、SigV4 プラグインが Amazon Keyspaces にアクセスするようにアクセスキーと が正しく設定 AWS リージョン されていることを確認します。アクセスキーと SigV4 プラグインの詳細については、「[Amazon Keyspaces の AWS 認証情報の作成と設定](access.credentials.md)」を参照してください。
#### VPC エンドポイント接続が正しく機能しない
**VPC エンドポイントを使用して Amazon Keyspaces に接続しようとすると、トークンマップエラーが発生するか、スループットが低下します。**
これは、VPC エンドポイント接続が正しく設定されていない場合に発生する可能性があります。
この問題を解決するには、以下の設定の詳細を確認してください。Amazon Keyspaces 用のインターフェイス VPC エンドポイントを介して接続を設定する方法に関する詳しいチュートリアルについては、「[チュートリアル: インターフェイス VPC エンドポイントを使用して Amazon Keyspaces に接続する](vpc-endpoints-tutorial.md)」を参照してください。
1. Amazon Keyspaces への接続に使用する IAM エンティティに、次の例に示すようにユーザーテーブルへの読み取り/書き込みアクセス権と、システムテーブルへの読み取りアクセス権があることを確認します。
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"cassandra:Select",
"cassandra:Modify"
],
"Resource":[
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/mytable",
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
]
}
]
}
```
1. Amazon Keyspaces への接続に使用する IAM エンティティに、次の例に示すように、Amazon EC2 インスタンスの VPC エンドポイント情報にアクセスするために必要な読み取り許可があることを確認します。
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"ListVPCEndpoints",
"Effect":"Allow",
"Action":[
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcEndpoints"
],
"Resource":"*"
}
]
}
```
**注記**
管理ポリシー `AmazonKeyspacesReadOnlyAccess_v2` と `AmazonKeyspacesFullAccess` には、Amazon Keyspaces が Amazon EC2 インスタンスにアクセスして、使用可能なインターフェイス VPC エンドポイントに関する情報を読み取るためのアクセス権限が設定されています。
VPC エンドポイントの詳細については、「[Amazon Keyspaces 用インターフェイス VPC エンドポイントの使用](vpc-endpoints.md#using-interface-vpc-endpoints)」を参照してください。
1. Java ドライバーの SSL 設定が、この例のようにホスト名の検証を false に設定していることを確認します。
```
hostname-validation = false
```
エージェント設定の詳細については、「[ステップ 2: ドライバーを設定する](using_java_driver.md#java_tutorial.driverconfiguration)」を参照してください。
1. VPC エンドポイントが正しく設定されていることを確認するには、VPC *内*から次のステートメントを実行します。
**注記**
ローカルの開発者環境や Amazon Keyspaces CQL エディタを使用してこの設定を確認することはできません。これらはパブリックエンドポイントを使用するためです。
```
SELECT peer FROM system.peers;
```
出力はこの例のようになります。VPC のセットアップと AWS リージョンに応じて、IPv4 ネットワークから接続するときに、プライベート IPv4 アドレスを持つ 2～6 個のノードを返します。
```
peer
---------------
192.0.2.0.15
192.0.2.0.24
192.0.2.0.13
192.0.2.0.7
192.0.2.0.8
(5 rows)
```
#### `cassandra-stress` を使用して接続することができない
**`cassandra-stress` コマンドを使用して Amazon Keyspaces に接続しようとすると、`SSL context` というエラーが発生します。**
これは、Amazon Keyspaces に接続しようとしたのに trustStore が正しく設定されていない場合に発生します。Amazon Keyspaces では、クライアントとの安全な接続を確保するために Transport Layer Security (TLS) を使用する必要があります。
この場合は次のエラーが表示されます。
```
Error creating the initializing the SSL Context
```
この問題を解決するには、このトピック [[開始する前に]](using_java_driver.md#using_java_driver.BeforeYouBegin) の指示に従って trustStore をセットアップしてください。
trustStore の設定が完了すると、次のコマンドを使用して接続できるようになります。
```
./cassandra-stress user profile=./profile.yaml n=100 "ops(insert=1,select=1)" cl=LOCAL_QUORUM -node "cassandra.eu-north-1.amazonaws.com" -port native=9142 -transport ssl-alg="PKIX" truststore="./cassandra_truststore.jks" truststore-password="trustStore_pw" -mode native cql3 user="user_name" password="password"
```
#### IAM アイデンティティを使用して接続することができない
**IAM アイデンティティを使用して Amazon Keyspaces に接続しようとすると、`Unauthorized` というエラーが発生します。**
これは、ポリシーを実装せず、ユーザーに必要なアクセス許可を付与していない状態で、IAM アイデンティティ (IAM ユーザーなど) を使用して Amazon Keyspaces テーブルに接続しようとした場合に発生する問題です。
この場合は次のエラーが表示されます。
```
Connection error: ('Unable to connect to any servers', {'3.234.248.202': AuthenticationFailed('Failed to authenticate to 3.234.248.202:
Error from server: code=2100 [Unauthorized] message="User arn:aws:iam::1234567890123:user/testuser has no permissions."',)})
```
この問題を解決するには、IAM ユーザーのアクセス許可を確認してください。ほとんどのドライバーで接続が構築されるときにシステムのキースペース/テーブルが読み取られるため、標準的なドライバーで接続する場合には、最低条件として、ユーザーはそのシステムテーブルへの `SELECT` アクセス権を取得しておく必要があります。
例えば、Amazon Keyspaces システムおよびユーザーテーブルへのアクセスを許可する IAM ポリシーについては、「[Amazon Keyspaces テーブルへのアクセス](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-access-one-table)」を参照してください。
IAM に特化したトラブルシューティングセクションを確認するには、「[Amazon Keyspaces のアイデンティティとアクセスに関するトラブルシューティング](security_iam_troubleshoot.md)」を参照してください。
#### cqlsh を使ってデータをインポートしようとすると、Amazon Keyspaces テーブルへの接続が失われる
**cqlsh を使用して Amazon Keyspaces にデータをアップロードしようとすると、接続エラーが発生します。**
サーバーから cqlsh クライアントに何らかの種類のエラーが 3 回連続で送信されると、Amazon Keyspaces への接続が失敗します。cqlsh クライアントで処理が失敗すると、次のメッセージが表示されます。
```
Failed to import 1 rows: NoHostAvailable - , will retry later, attempt 3 of 100
```
このエラーを解決するには、インポートするデータが Amazon Keyspaces のテーブルスキーマと一致していることを確認する必要があります。インポートファイルで解析エラーが発生していないか確認してください。INSERT ステートメントを使用してエラーを切り離すことで、1 行のデータの使用を試すことができます。
クライアントにより接続の再確立が自動的に試行されます。
# Amazon Keyspaces のキャパシティ管理エラーのトラブルシューティング
サーバーレスキャパシティに関して問題がありますか。以下は、一般的なシナリオとその解決方法です。
## サーバーレス容量エラー
このセクションでは、サーバーレスキャパシティ管理に関連するエラーの認識方法と解決方法について説明します。例えば、アプリケーションがプロビジョンドスループット性能を超えると、キャパシティ不足イベントが発生することがあります。
Apache Cassandra は、ノード群で実行するように設計されたクラスタベースのソフトウェアであるため、スループットキャパシティなどのサーバーレス機能に関連する例外メッセージはありません。ほとんどのドライバーでは Apache Cassandra で利用可能なエラーコードしか認識されないため、Amazon Keyspaces では、互換性を維持するために同一のエラーコードセットを使用します。
基盤となるキャパシティイベントに Cassandra エラーをマッピングする場合には、Amazon CloudWatch を使用して関連する Amazon Keyspaces メトリクスを監視することができます。クライアント側のエラーを発生させるキャパシティ不足イベントは、イベントの原因となっているリソースに基づいて、次の 3 つのグループに分類できます。
+ **テーブル** – テーブルに対して **[Provisioned]** (プロビジョンド) キャパシティモードを選択した場合に、アプリケーションがプロビジョンドスループットを超えると、キャパシティ不足エラーが発生する可能性があります。詳細については、「[Amazon Keyspaces で読み取り/書き込みのキャパシティモードを設定する](ReadWriteCapacityMode.md)」を参照してください。
+ **パーティション** — 指定されたパーティションのトラフィックが 3,000 RCU または 1,000 WCU を超えると、キャパシティ不足イベントが発生する可能性があります。ベストプラクティスとして、パーティション間でトラフィックを均一に分散させることをお勧めします。詳細については、「[データモデリングのベストプラクティス: データモデル設計時の推奨事項](data-modeling.md)」を参照してください。
+ **接続** — 接続 1 つあたりの 1 秒あたりの最大オペレーション数のクォータを超えると、スループットが不十分になる可能性があります。スループットを高めるために、ドライバーによる接続を設定する際に、デフォルト接続の数を増やすことができます。
Amazon Keyspaces で接続を設定する方法については、「[Amazon Keyspaces で接続を設定する方法](connections.md#connections.howtoconfigure)」を参照してください。VPC エンドポイントを利用した接続の最適化の詳細については、「[Amazon Keyspaces の VPC エンドポイント経由接続の設定方法](connections.md#connections.VPCendpoints)」を参照してください。
クライアント側エラーを返すキャパシティ不足イベントの原因となっているリソースを特定するために、Amazon Keyspaces コンソールでダッシュボードを確認できます。デフォルトでは、コンソールには、テーブルの **[Capacity]** (キャパシティ) の **[Capacity and related metrics]** (キャパシティと関連メトリクス) セクションに、最も一般的なキャパシティとトラフィックに関する CloudWatch メトリクスの集約ビューがあります。
Amazon CloudWatch を使用して独自のダッシュボードを作成するには、次の Amazon Keyspaces メトリクスを確認します。
+ `PerConnectionRequestRateExceeded` — 接続ごとのリクエストレートのクォータを超える Amazon Keyspaces へのリクエスト。Amazon Keyspaces への各クライアント接続は、1 秒あたり最大 3000 の CQL リクエストに対応できます。複数の接続を作成すれば、1 秒あたり 3000 を超えるリクエストを実行できます。
+ `ReadThrottleEvents` — テーブルの読み取りキャパシティを超える Amazon Keyspaces へのリクエスト。
+ `StoragePartitionThroughputCapacityExceeded` — パーティションのスループットキャパシティを超える Amazon Keyspaces ストレージパーティションへのリクエスト。Amazon Keyspaces ストレージパーティションは、最大 1000 WCU/WRU/秒および最大 3000 RCU/RRU/秒に対応できます。これらの例外を軽減するために、データモデルを確認して、読み取り/書き込みトラフィックをより多くのパーティションに分散させることをお勧めします。
+ `WriteThrottleEvents` — テーブルの書き込みキャパシティを超える Amazon Keyspaces へのリクエスト。
CloudWatch の詳細については、「[Amazon CloudWatch による Amazon Keyspaces のモニタリング](monitoring-cloudwatch.md)」を参照してください。Amazon Keyspaces で利用可能なすべての CloudWatch メトリクスの一覧については、「[Amazon Keyspaces のメトリクスとディメンション](metrics-dimensions.md)」を参照してください。
**注記**
Amazon Keyspaces でよく見られるすべてのメトリクスを表示したカスタムダッシュボードの使用を開始する場合、[AWS サンプル](https://github.com/aws-samples/amazon-keyspaces-cloudwatch-cloudformation-templates) リポジトリの GitHub で使用できるようにあらかじめ構築されている CloudWatch テンプレートを使用できます。
**Topics**
+ [クライアント側エラー](#troubleshooting.serverless.clientside)
+ [データインポート中の書き込みタイムアウトエラー](#troubleshooting.serverless.writetimeout)
+ [キースペースまたはテーブルのストレージサイズ](#troubleshooting.serverless.storagesize)
### クライアントドライバーから `NoHostAvailable` というキャパシティ不足エラーが送られてくる
**テーブルに対して `Read_Timeout` または `Write_Timeout` という例外が表示されています。**
キャパシティが不足している Amazon Keyspaces テーブルに対して書き込みや読み取りを繰り返し試みると、ドライバー固有のクライアント側エラーが発生する可能性があります。
CloudWatch を使用して、プロビジョンドスループットメトリクス、実際のスループットメトリクス、テーブルのキャパシティ不足イベントを監視してください。例えば、十分なスループットキャパシティがない読み取りリクエストは、`Read_Timeout` 例外が発生して失敗し、`ReadThrottleEvents` メトリクスに投稿されます。十分なスループットキャパシティがない書き込みリクエストは、`Write_Timeout` 例外が発生して失敗し、`WriteThrottleEvents` メトリクスに投稿されます。これらのメトリクスの詳細については、「[Amazon Keyspaces のメトリクスとディメンション](metrics-dimensions.md)」を参照してください。
この問題を解決するには、以下のオプションのいずれかを検討してください。
+ テーブルの*プロビジョンドスループット*を増やす。これは、アプリケーションにより消費されるスループットキャパシティの最大量です。詳細については、「[読み取りキャパシティユニットと書き込みキャパシティユニット](ReadWriteCapacityMode.Provisioned.md#ReadWriteCapacityMode.Provisioned.Units)」を参照してください。
+ オートスケーリングを使用してサービスによってスループットキャパシティが管理されるようにします。詳細については、「[Amazon Keyspaces 自動スケーリングでスループットキャパシティを自動的に管理する](autoscaling.md)」を参照してください。
+ テーブルに対して **[On-demand]** (オンデマンド) キャパシティモードを選択します。詳細については、「[オンデマンドキャパシティモードを設定する](ReadWriteCapacityMode.OnDemand.md)」を参照してください。
アカウントのデフォルトのキャパシティクォータを増やす必要がある場合は、「[Amazon Keyspaces (Apache Cassandra 向け) のクォータ](quotas.md)」を参照してください。
**パーティションキャパシティの超過に関連するエラーが表示されています。**
`StoragePartitionThroughputCapacityExceeded` エラーが表示される場合は、パーティションのキャパシティが一時的に超過しています。この場合、アダプティブキャパシティまたはオンデマンドキャパシティによって自動的に処理される可能性があります。これらのエラーを軽減するために、データモデルを見直し、読み取り/書き込みトラフィックをより多くのパーティションに分散させることをお勧めします。Amazon Keyspaces ストレージパーティションは、最大 1000 WCU/WRU/秒、最大 3000 RCU/RRU/秒に対応できます。データモデルを改良して読み取り/書き込みトラフィックをより多くのパーティションに分散させる方法の詳細については、「[データモデリングのベストプラクティス: データモデル設計時の推奨事項](data-modeling.md)」を参照してください。
`Write_Timeout` 例外は、同じ論理パーティションに静的データと非静的データを含める同時書き込みオペレーションのレートが上昇した場合にも発生する可能性があります。トラフィックにおいて、同じ論理パーティション内に静的データと非静的データを含める複数の同時書き込みオペレーションが実行されることが予想される場合、静的データと非静的データを別々に書き込むことをお勧めします。データを別々に書き込むと、スループットコストの最適化にも役立ちます。
**接続リクエストレートの超過に関連するエラーが表示されています。**
`PerConnectionRequestRateExceeded` が表示される場合は、次のいずれかが原因です。
+ セッションごとに設定された接続数が不足している可能性があります。
+ VPC エンドポイントのアクセス許可が正しく設定されていないと、使用可能なピアよりも接続数が少なくなる可能性があります。VPC エンドポイントポリシーの詳細については、「[Amazon Keyspaces 用インターフェイス VPC エンドポイントの使用](vpc-endpoints.md#using-interface-vpc-endpoints)」を参照してください。
+ 4.x ドライバーを使用している場合は、ホスト名の検証が有効になっているかどうかを確認してください。ドライバーでは、デフォルトで TLS ホスト名の検証が有効になっています。この設定により、Amazon Keyspaces がシングルノードクラスターとしてドライバーに表示されます。ホスト名の検証をオフにすることをお勧めします。
接続とスループットが最適化されるように、次のベストプラクティスに従うことをお勧めします。
+ **CQL クエリのスループットチューニングを設定します。**
Amazon Keyspaces は、TCP 接続 1 つにつき 1 秒あたり最大 3,000 の CQL クエリに対応していますが、ドライバーが確立できる接続数に制限はありません。
ほとんどのオープンソース Cassandra ドライバーで、Cassandra への接続プールが確立され、その接続プールでクエリのロードバランスが行われます。Amazon Keyspaces では 9 つのピア IP アドレスをドライバーに開示します。ほとんどのドライバーのデフォルト動作は、各ピア IP アドレスに対して 1 つの接続を確立することです。したがって、デフォルト設定を使用するドライバーの最大 CQL クエリスループットは、1 秒あたり 27,000 CQL クエリになります。
この数を増やすには、ドライバーが接続プールで維持している IP アドレスあたりの接続数を増やすことをお勧めします。例えば、IP アドレスあたりの最大接続数を 2 に設定すると、ドライバーの最大スループットが 1 秒あたり 54,000 CQL クエリの 2 倍になります。
+ **単一ノード接続を最適化します。**
ほとんどのオープンソース Cassandra ドライバーでは、デフォルトで、セッションの確立時に `system.peers` テーブルでアドバタイズされた各 IP アドレスへに対して、1 つ以上の接続が確立されます。ただし、設定によっては、ドライバーにより単一の Amazon Keyspaces IP アドレスに接続されることがあります。これは、ドライバーにより、ピアノードの SSL ホスト名の検証が試行されている場合や (DataStax Java ドライバーなど)、VPC エンドポイントを通じて接続されている場合に発生します。
複数の IP アドレスに接続するドライバーと同じ可用性とパフォーマンスを確保するには、次の操作の実行をお勧めします。
+ 希望するクライアントのスループットに応じて、各 IP の接続数を 9 以上に増やす。
+ 同じノードに対して再試行が実行されるようにするカスタム再試行ポリシーを作成します。詳細については、以下を参照してください。
[Amazon Keyspaces で接続の再試行ポリシーを設定する方法](connections.md#connections.retry-policies).
+ VPC エンドポイントを使用する場合は、Amazon Keyspaces への接続に使用する IAM エンティティに、エンドポイントとネットワークインターフェイスの情報について VPC をクエリするためのアクセス許可を付与します。これにより、ロードバランシングが改善され、読み取り/書き込みスループットが向上します 詳細については、「[インターフェイス VPC エンドポイント情報を含む `system.peers` テーブルエントリの入力](vpc-endpoints.md#system_peers)」を参照してください。
### データのインポート中に書き込みタイムアウトエラーが表示される
**`cqlsh` `COPY` コマンドを使用してデータをアップロードしているときに、タイムアウトエラーが表示されます。**
```
Failed to import 1 rows: WriteTimeout - Error from server: code=1100 [Coordinator node timed out waiting for replica nodes' responses]
message="Operation timed out - received only 0 responses." info={'received_responses': 0, 'required_responses': 2, 'write_type': 'SIMPLE', 'consistency':
'LOCAL_QUORUM'}, will retry later, attempt 1 of 100
```
Amazon Keyspaces では、スループットキャパシティ不足により書き込みリクエストが失敗した場合に、`ReadTimeout` 例外と `WriteTimeout` 例外を使用してその失敗が示されます。キャパシティ不足の例外を診断するために、Amazon Keyspaces は Amazon CloudWatch で次のメトリクスを公開しています。
+ `WriteThrottleEvents`
+ `ReadThrottledEvents`
+ `StoragePartitionThroughputCapacityExceeded`
データロード中に発生したキャパシティ不足エラーを解決するには、ワーカーあたりの書き込みレートまたは総取り込みレートを引き下げ、行のアップロードを再試行してください。詳細については、「[ステップ 4: `cqlsh COPY FROM` を設定する](bulk-upload-config.md)」を参照してください。より堅牢なデータアップロードオプションについては、DSBulk の使用を検討してください。DSBulk は [GitHub リポジトリ](https://github.com/datastax/dsbulk)から入手できます。手順については、「[チュートリアル: DSBulk を使用した Amazon Keyspaces へのデータのロード](dsbulk-upload.md)」を参照してください。
### キースペースまたはテーブルの実際のストレージサイズが表示されない
**キースペースまたはテーブルの実際のストレージサイズが表示されません。**
テーブルのストレージサイズの詳細については、「[テーブルレベルでコストを評価する](CostOptimization_TableLevelCostAnalysis.md)」を参照してください。テーブル内の行サイズを計算することから始めて、ストレージサイズを見積もることもできます。行サイズの計算に関する詳しい手順については、「[Amazon Keyspaces で行のサイズを推定する](calculating-row-size.md)」を参照してください。
# Amazon Keyspaces のデータ定義言語エラーのトラブルシューティング
リソースの作成に問題がありますか。以下は、一般的なシナリオとその解決方法です。
## データ定義言語エラー
Amazon Keyspaces では、キースペースとテーブルの非同期的な作成や削除など、データ定義言語 (DDL) オペレーションが同期なしで実行されます。アプリケーションの準備が整っていない時点でアプリケーションによりリソースの使用が試行されると、そのオペレーションは失敗します。
で新しいキースペースとテーブルの作成ステータスをモニタリングできます。これは AWS マネジメントコンソール、キースペースまたはテーブルが保留中またはアクティブであることを示します。システムスキーマテーブルのクエリを実行して、新しいキースペースまたはテーブルの作成ステータスをプログラムにより監視することもできます。キースペースまたはテーブルは、使用可能な状態になると、システムスキーマに表示されます。
**注記**
を使用してキースペースの作成を最適化するには CloudFormation、このユーティリティを使用して CQL スクリプトを CloudFormation テンプレートに変換します。このツールは [GitHub リポジトリ](https://github.com/aws/amazon-keyspaces-cql-to-cfn-converter)から入手できます。
**Topics**
+ [キースペース作成エラー](#troubleshooting.cql.keyspace)
+ [テーブル作成エラー](#troubleshooting.cql.table)
+ [Amazon Keyspaces ポイントインタイムリカバリ (PITR、point-in-time recovery) を使用してテーブルを復元することができない](#troubleshooting.cql.pitr)
+ [INSERT/UPDATE を使用してカスタム有効期限 (TTL) 設定を編集しようとすると、オペレーションが失敗する](#troubleshooting.cql.ttl)
+ [列数の超過](#troubleshooting.cql.upload)
+ [削除範囲エラー](#troubleshooting.cql.rangedelete)
### 新しいキースペースを作成したが、表示またはアクセスできない
**新しいキースペースへのアクセスを試行しているアプリケーションからエラーが送られてきた。**
非同期的作成中である新規の Amazon Keyspaces キースペースにアクセスしようとすると、エラーが発生します。以下にエラーの例を示します。
```
InvalidRequest: Error from server: code=2200 [Invalid query] message="unconfigured keyspace mykeyspace"
```
新しいキースペースが使用可能な状態になるタイミングをチェックするための推奨設計パターンとは、Amazon Keyspaces のシステムスキーマテーブル (system\$1schema\$1mcs.\$1) のポーリングです。
詳細については、「[Amazon Keyspaces でキースペースの作成ステータスを確認する](keyspaces-create.md)」を参照してください。
### 新しいテーブルを作成したが、表示またはアクセスできない
**新しいテーブルへのアクセスを試行しているアプリケーションからエラーが送られてきました。**
非同期的作成中である新規の Amazon Keyspaces テーブルにアクセスしようとすると、エラーが発生します。例えば、まだ使用できる状態ではないテーブルをクエリしようとすると失敗して `unconfigured table` というエラーが表示されます。
```
InvalidRequest: Error from server: code=2200 [Invalid query] message="unconfigured table mykeyspace.mytable"
```
`sync_table()` でテーブルを表示しようとすると失敗して `KeyError` が表示されます。
```
KeyError: 'mytable'
```
新しいテーブルが使用可能な状態になるタイミングをチェックするための推奨設計パターンとは、Amazon Keyspaces のシステムスキーマテーブル (system\$1schema\$1mcs.\$1) のポーリングです。
これは作成中のテーブルの出力例です。
```
user-at-123@cqlsh:system_schema_mcs> select table_name,status from system_schema_mcs.tables where keyspace_name='example_keyspace' and table_name='example_table';
table_name | status
------------+----------
example_table | CREATING
(1 rows)
```
これはアクティブなテーブルの出力例です。
```
user-at-123@cqlsh:system_schema_mcs> select table_name,status from system_schema_mcs.tables where keyspace_name='example_keyspace' and table_name='example_table';
table_name | status
------------+----------
example_table | ACTIVE
(1 rows)
```
詳細については、「[Amazon Keyspaces でテーブルの作成ステータスを確認する](tables-create.md)」を参照してください。
### Amazon Keyspaces ポイントインタイムリカバリ (PITR、point-in-time recovery) を使用してテーブルを復元することができない
ポイントインタイムリカバリ (PITR) を使用して Amazon Keyspaces テーブルの復元を試みた際に、復元プロセスが開始しても正常に完了しない場合は、この特定のテーブルの復元プロセスに必要なアクセス許可の一部が設定されていない可能性があります。
Amazon Keyspaces では、ユーザーアクセス許可に加えて、復元プロセス中にプリンシパルに代わってアクションを実行するためのアクセス許可が必要になる場合があります。これは、テーブルがカスタマーマネージドキーで暗号化されている場合や、着信トラフィックを制限する IAM ポリシーを使用している場合です。
例えば、IAM ポリシーで条件キーを使用してソーストラフィックを特定のエンドポイントまたは IP 範囲に制限している場合、復元オペレーションは失敗します。プリンシパルの代わりに Amazon Keyspaces によってテーブルの復元オペレーションが実行されるようにするには、IAM ポリシーに `aws:ViaAWSService` グローバル条件キーを追加する必要があります。
テーブルを復元するためのアクセス許可の詳細については、「[Amazon Keyspaces PITR のテーブル復元用の IAM アクセス許可を設定する](howitworks_restore_permissions.md)」を参照してください。
### INSERT/UPDATE を使用してカスタム有効期限 (TTL) 設定を編集しようとすると、オペレーションが失敗する
カスタム TTL 値を挿入または更新しようとすると、次のエラーが発生してオペレーションが失敗することがあります。
```
TTL is not yet supported.
```
`INSERT` または `UPDATE` のオペレーションを使用して行または列のカスタム TTL 値を指定するには、まずそのテーブルの TTL を有効にする必要があります。`ttl` カスタムプロパティを使用すればテーブルの TTL を有効にすることができます。
テーブルのカスタム TTL 設定を有効にする方法の詳細については、「[カスタムの有効期限 (TTL) でテーブルを更新する](TTL-how-to-enable-custom-alter.md)」を参照してください。
### Amazon Keyspaces テーブルにデータをアップロードしようとすると、列数の超過に関するエラーが発生する
**データをアップロードしていて、同時に更新できる列数を超過した。**
このエラーは、テーブルスキーマが最大サイズの 350 KB を超えた場合に発生します。詳細については、「[Amazon Keyspaces (Apache Cassandra 向け) のクォータ](quotas.md)」を参照してください。
### Amazon Keyspaces テーブルのデータを削除しようとすると、その範囲のために削除が失敗する
**パーティションキーでデータを削除しようとすると、削除範囲エラーが表示されます。**
このエラーは、1 回の削除オペレーションで 1,000 行以上を削除しようとしたときに発生します。
```
Range delete requests are limited by the amount of items that can be deleted in a single range.
```
詳細については、「[範囲削除](functional-differences.md#functional-differences.range-delete)」を参照してください。
1 つのパーティション内で 1,000 行以上を削除する場合は、次のオプションを検討してください。
+ パーティションごとの削除 — パーティションの大部分が 1,000 行未満の場合は、パーティションごとにデータを削除できます。パーティションに含まれている行が 1,000 行以上である場合は、代わりにクラスタリング列ごとに削除してください。
+ クラスタリング列ごとの削除 — モデルに複数のクラスタリング列が含まれている場合、列階層を使用して複数の行を削除できます。クラスタリング列はネスト構造であり、最上位の列に対してオペレーションを行うことで、多くの行を削除できます。
+ 行ごとの削除 — 行を繰り返し処理し、そのフルプライマリキーで各行を削除できます (パーティション列とクラスタリング列)。
+ ベストプラクティスとして、パーティション間での行の分割を検討してください。Amazon Keyspaces では、テーブルパーティション間でスループットを分散させることをお勧めします。これにより、物理リソース間でデータとアクセスが均等に分散され、最高のスループットが得られます。詳細については、「[データモデリングのベストプラクティス: データモデル設計時の推奨事項](data-modeling.md)」を参照してください。
高いワークロードに対して削除オペレーションを計画する場合は、次の推奨事項も考慮してください。
+ Amazon Keyspaces では、パーティションに含めることができる行数は事実上無制限です。これにより、従来の Cassandra ガイダンスである 100 MB よりも「広く」パーティションのスケールを調整できます。時系列や台帳については、時間の経過とともにデータをギガバイト単位で増加させることは珍しくありません。
+ Amazon Keyspaces では、高いワークロードの削除オペレーションを実行する必要がある場合に考慮すべき圧縮戦略やトゥームストーンはありません。読み取りパフォーマンスに影響を与えることなく、必要な数のデータを削除できます。