翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Keyspaces (Apache Cassandra 向け) でのサーバーレスリソースの管理
Amazon Keyspaces (Apache Cassandra 向け) はサーバーレスです。クラスター内のノードを介してワークロードのストレージリソースとコンピューティングリソースのデプロイ、管理、保守を行う代わりに、Amazon Keyspaces では、ストレージリソースと読み取り/書き込みスループットリソースをテーブルに直接割り当てます。
Amazon Keyspaces では、テーブルに保存されているデータに基づいてストレージが自動的にプロビジョニングされます。データの書き込み、更新、削除に従い、ストレージがスケールアップおよびスケールダウンされ、使用したストレージの分だけ料金を支払います。可用性を高めるため、データは複数の[アベイラビリティーゾーン](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)にレプリケートされます。Amazon Keyspaces では、テーブルサイズの継続的監視によりストレージ料金が決定されます。Amazon Keyspaces における課金対象のデータサイズの詳しい計算方法については、「[Amazon Keyspaces で行のサイズを推定する](calculating-row-size.md)」を参照してください。
この章では、Amazon Keyspaces でのリソース管理の主な側面を取り上げます。
+ **行サイズを推定する** – Amazon Keyspaces でエンコード後の行サイズを推定するには、パーティションキーのメタデータ、クラスタリング列のメタデータ、列の識別子、データ型、行のメタデータなどの要素を考慮します。エンコード後の行サイズは、請求、クォータ管理、プロビジョニングするスループットキャパシティのプランニングに使用されます。
+ **キャパシティ消費量を推定する** – 範囲クエリ、限定クエリ、テーブルスキャン、軽量トランザクション、静的列、マルチリージョンテーブルなど、一般的なシナリオにおける読み取りと書き込みのキャパシティ消費量を推定する方法の例を紹介します。Amazon CloudWatch を使用して、実際のキャパシティ使用率をモニタリングできます。CloudWatch によるモニタリングの詳細については、「[Amazon CloudWatch による Amazon Keyspaces のモニタリング](monitoring-cloudwatch.md)」を参照してください。
+ **読み取り/書き込みキャパシティモードを設定する** – テーブルへの読み取りと書き込みを処理するためのキャパシティモードを次の 2 つから選択できます。
+ **オンデマンドモード (デフォルト)** – 読み取りおよび書き込みのスループットに対し、リクエストごとに支払います。Amazon Keyspaces は、これまでに到達実績のあるトラフィックレベルまでは、キャパシティを瞬時にスケールアップできます。
+ **プロビジョンドモード** – 読み取りおよび書き込みに必要なキャパシティユニット数を事前に指定しておきます。このモードでは、予測可能なスループットパフォーマンスを維持できます。
+ **自動スケーリングでスループットキャパシティを管理する** – プロビジョンドモードのテーブルの場合、自動スケーリングを有効にして、実際のアプリケーショントラフィックに基づいてスループットキャパシティを自動調整できます。Amazon Keyspaces はターゲット追跡を使用して、プロビジョニングされたキャパシティを増減し、指定された目標使用率を維持します。
+ **バーストキャパシティを効果的に使用する** – Amazon Keyspaces は、トラフィックの急増に対応するために未使用のスループットの一部を予約して、バーストキャパシティを確保します。このおかげで、プロビジョニング済みのスループットを超える一時的なアクティビティの急増にも柔軟に対応できます。
キャパシティエラーのトラブルシューティングについては、「[サーバーレス容量エラー](troubleshooting.serverless.md#troubleshooting-serverless)」を参照してください。
**Topics**
+ [Amazon Keyspaces で行のサイズを推定する](calculating-row-size.md)
+ [Amazon Keyspaces で読み取り/書き込みスループットのキャパシティ消費量を推定する](capacity-examples.md)
+ [Amazon Keyspaces で読み取り/書き込みのキャパシティモードを設定する](ReadWriteCapacityMode.md)
+ [Amazon Keyspaces 自動スケーリングでスループットキャパシティを自動的に管理する](autoscaling.md)
+ [Amazon Keyspaces でバーストキャパシティを効果的に使用する](throughput-bursting.md)
# Amazon Keyspaces で行のサイズを推定する
Amazon Keyspaces は、1 桁ミリ秒の読み取りおよび書き込みパフォーマンスを提供し、複数の AWS アベイラビリティーゾーンにデータを永続的に保存するフルマネージドストレージを提供します。Amazon Keyspaces では、効率的なデータアクセスと高可用性をサポートするために、すべての行とプライマリキー列にメタデータをアタッチします。
このトピックでは、Amazon Keyspaces のエンコードされた行サイズを推定する方法について詳しく説明します。エンコードされた行サイズは、請求額とクォータの使用量を計算するときに使用されます。テーブルのプロビジョンドスループットキャパシティ要件を推定するときに、エンコードされた行サイズを使用することもできます。
Amazon Keyspaces 内のエンコードされた行サイズを計算するには、次のガイドラインを使用します。
**Topics**
+ [エンコードされた列のサイズを推定する](#calculating-row-size-columns)
+ [データ型に基づいてデータ値のエンコードされたサイズを推定する](#calculating-row-size-data-types)
+ [Amazon Keyspaces 機能が行サイズに与える影響を考慮する](#calculating-row-size-features)
+ [行のエンコードされたサイズを計算する適切な式を選択する](#calculating-row-size-formula)
+ [行サイズ計算の例](#calculating-row-size-example)
## エンコードされた列のサイズを推定する
このセクションでは、Amazon Keyspaces のエンコードされた列のサイズを推定する方法を示します。
+ **通常の列** – プライマリキー、クラスタリング列、または列ではない通常の`STATIC`列の場合、[データ型](cql.elements.md#cql.data-types)に基づいてセルデータの raw サイズを使用し、必要なメタデータを追加します。Amazon Keyspaces がデータ型値とメタデータを保存する方法におけるデータ型といくつかの主な違いを次のセクションに示します。
+ **パーティションキー列** – パーティションキーには最大 2048 バイトのデータを含めることができます。パーティションキーの各キー列には、最大 3 バイトのメタデータが必要です。行のサイズを計算するときには、各パーティションキー列で上限である 3 バイトのメタデータが使用されていることを想定しておくべきです。
+ **クラスタリング列** – クラスタリング列には最大 850 バイトのデータを保存できます。データ値のサイズに加えて、各クラスタリング列のメタデータにはデータ値サイズの最大 20% が必要です。行のサイズを計算するときには、5 バイトのクラスタリング列データ値ごとに 1 バイトのメタデータを追加する必要があります。
**注記**
効率的なクエリと組み込みインデックス作成をサポートするために、Amazon Keyspaces は各パーティションキーとクラスタリングキー列のデータ値を 2 回保存します。
+ **列名** – 各列名に必要なスペースは、列識別子を使用して保存され、列に保存されている各データ値に追加されます。列識別子の格納値は、テーブル内の列の総数によって異なります。
+ 1 ～ 62 カラム: 1 バイト
+ 63 ～ 124 カラム: 2 バイト
+ 125 ～ 186 カラム: 3 バイト
62 列を追加するごとに 1 バイトを追加します。Amazon Keyspaces では、1 つの `INSERT` または `UPDATE` ステートメントで最大 225 個の標準列を変更できることに注意してください。詳細については、「[Amazon Keyspaces サービスクォータ](quotas.md#table)」を参照してください。
## データ型に基づいてデータ値のエンコードされたサイズを推定する
このセクションでは、Amazon Keyspaces のさまざまなデータ型のエンコードされたサイズを推定する方法を示します。
+ **文字列型** – Cassandra `ASCII`、`TEXT`、および `VARCHAR`文字列データ型はすべて、UTF-8 バイナリエンコーディングで Unicode を使用して Amazon Keyspaces に保存されます。Amazon Keyspaces 文字列のサイズは、UTF-8 でエンコードされたバイト数と同じです。
+ **数値型** – Cassandra `INT`、`BIGINT`、`SMALLINT`、`TINYINT`、および `VARINT` データ型は、最大 38 桁の有効数字を持つ可変長のデータ値として Amazon Keyspaces に保存されます。先頭と末尾の 0 は切り捨てられます。これらのデータ型のサイズはいずれも、有効数字 2 桁あたり約 1 バイト\$11 バイトです。
+ **Blob タイプ** – Amazon Keyspaces `BLOB`の は、値の raw バイト長で保存されます。
+ **ブール型** – `Boolean`値のサイズまたは`Null`値は 1 バイトです。
+ **コレクションタイプ** – コンテンツに関係なく、 `LIST`や などのコレクションデータ型を保存する列には 3 バイトのメタデータ`MAP`が必要です。`LIST` または `MAP` のサイズは、(列 ID) \$1 合計 (入れ子要素のサイズ) \$1 (3 バイト) です。空の `LIST` または `MAP` のサイズは (列 ID) \$1 (3 バイト) です。個々の `LIST` または `MAP` 要素にはそれぞれ、余分な 1 バイトが必要です。
+ **ユーザー定義型** – [ユーザー定義型 (UDT) ](udts.md)では、その内容に関係なく、メタデータに 3 バイトが必要です。UDT 要素ごとに、Amazon Keyspaces には追加の 1 バイトのメタデータが必要です。
UDT のエンコードされたサイズを計算するには、UDT のフィールド`field value`の `field name`と から始めます。
+ **フィールド名** – 最上位 UDT の各フィールド名は、識別子を使用して保存されます。識別子のストレージ値は、最上位 UDT のフィールドの総数に依存し、1～3 バイトの間で異なる場合があります。
+ 1～62 フィールド: 1 バイト
+ 63～124 フィールド: 2 バイト
+ 125 – 最大フィールド: 3 バイト
+ **フィールド値** – 最上位 UDT のフィールド値を保存するために必要なバイト数は、保存されるデータ型によって異なります。
+ **スカラーデータ型** – ストレージに必要なバイト数は、通常の列に保存されているのと同じデータ型と同じです。
+ **フローズン UDT** – フローズンネストされた UDT ごとに、ネストされた UDT のサイズは CQL バイナリプロトコルと同じです。ネストされた UDT の場合、各フィールド (空のフィールドを含む) に 4 バイトが保存され、保存されたフィールドの値はフィールド値の CQL バイナリプロトコルシリアル化形式です。
+ **フリーズコレクション**:
+ **LIST** と **SET** – ネストされたフリーズ`LIST`または の場合`SET`、コレクションの各要素に 4 バイトとコレクションの値の CQL バイナリプロトコルシリアル化形式が保存されます。
+ **MAP** – ネストされたフリーズされた の場合`MAP`、各キーと値のペアには次のストレージ要件があります。
+ キーごとに 4 バイトを割り当て、キーの CQL バイナリプロトコルシリアル化形式を追加します。
+ 値ごとに 4 バイトを割り当て、値の CQL バイナリプロトコルシリアル化形式を追加します。
+ **FROZEN キーワード** – フリーズコレクション内にネストされたフリーズコレクションの場合、Amazon Keyspaces はメタデータに追加のバイトを必要としません。
+ **STATIC キーワード** – `STATIC`列データは最大行サイズ 1 MB にはカウントされません。静的列のデータサイズを計算するには、「[Amazon Keyspaces で各論理パーティションの静的列サイズを計算する](static-columns-estimate.md)」を参照してください。
## Amazon Keyspaces 機能が行サイズに与える影響を考慮する
このセクションでは、Amazon Keyspaces の機能が行のエンコードされたサイズにどのように影響するかを示します。
+ **クライアント側のタイムスタンプ** – 機能をオンにすると、クライアント側のタイムスタンプは各行の各列に保存されます。これらのタイムスタンプで約 20 ～ 40 バイト (データによって異なります) が使用され、行のストレージとスループットのコストに影響します。クライアント側のタイムスタンプの詳細については、「」を参照してください[Amazon Keyspaces でのクライアント側のタイムスタンプ](client-side-timestamps.md)。
+ **Time to Live (TTL)** – この機能がオンになっている場合、TTL メタデータは行に対して約 8 バイトかかります。さらに、TTL メタデータは各行の各列に保存されます。TTL メタデータは、スカラーデータ型またはフリーズコレクションを保存する列ごとに約 8 バイトかかります。列にフリーズされていないコレクションデータ型が保存されている場合、コレクションの各要素について、TTL にはメタデータに約 8 バイトの追加が必要です。TTL が有効になっているときにコレクションデータ型を保存する列の場合、次の式を使用できます。
```
total encoded size of column = (column id) + sum (nested elements + collection metadata (1 byte) + TTL metadata (8 bytes)) + collection column metadata (3 bytes)
```
TTL メタデータは、行のストレージとスループットのコストに影響します。TTL の詳細については、「[Amazon Keyspaces (Apache Cassandra 向け) で有効期限 (TTL) を使用してデータを期限切れにする](TTL.md)」を参照してください。
## 行のエンコードされたサイズを計算する適切な式を選択する
このセクションでは、Amazon Keyspaces 内のデータ行のストレージまたは容量スループット要件を推定するために使用できるさまざまな式を示します。
データの行の合計エンコードサイズは、目標に基づいて、次のいずれかの式に基づいて推定できます。
+ **スループットキャパシティ** – 行のエンコードされたサイズを推定して、必要な読み取り/書き込みリクエストユニット (RRUs/WRUs) または読み取り/書き込みキャパシティユニット (RCUs/WCUs) を評価します。
```
total encoded size of row = partition key columns + clustering columns + regular columns
```
+ **ストレージサイズ** – を予測する行のエンコードされたサイズを推定するには`BillableTableSizeInBytes`、行のストレージに必要なメタデータを追加します。
```
total encoded size of row = partition key columns + clustering columns + regular columns + row metadata (100 bytes)
```
**重要**
列 ID、パーティションキーメタデータ、クラスタリング列メタデータ、クライアント側のタイムスタンプ、TTL、行メタデータなどのすべての列メタデータは、最大行サイズ 1 MB にカウントされます。
## 行サイズ計算の例
すべての列が整数型であるテーブルの例を考えてみましょう。テーブルには、パーティションキー列が 2 つ、クラスタリング列が 2 つ、通常の列が 1 つあります。このテーブルには 5 つの列があるため、列名識別子に必要なスペースは 1 バイトです。
```
CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, primary key((pk_col1, pk_col2),ck_col1, ck_col2));
```
この例では、次のステートメントに示すように、テーブルに行を書き込むときにデータのサイズを計算します。
```
INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, ck_col1, ck_col2, reg_col1) values(1,2,3,4,5);
```
この書き込みオペレーションに必要な合計バイト数を見積もるために、次のステップを使用します。
1. 列に保存されているデータ型のバイトとメタデータバイトを追加して、パーティションキー列のサイズを計算します。この計算をすべてのパーティションキー列に対して繰り返します。
1. パーティションキー (pk\$1col1) の最初の列のサイズを計算します。
```
(2 bytes for the integer data type) x 2 + 1 byte for the column id + 3 bytes for partition key metadata = 8 bytes
```
1. パーティションキー (pk\$1col2) の 2 番目の列のサイズを計算します。
```
(2 bytes for the integer data type) x 2 + 1 byte for the column id + 3 bytes for partition key metadata = 8 bytes
```
1. 両方の列を足して、パーティションキー列の合計サイズを見積もります。
```
8 bytes + 8 bytes = 16 bytes for the partition key columns
```
1. 列に保存されているデータ型のバイトとメタデータのバイトを足して、クラスタリング列のサイズを計算します。すべてのクラスタリング列に対してこの計算を繰り返します。
1. クラスタリング列 (ck\$1col1) の最初の列のサイズを計算します。
```
(2 bytes for the integer data type) x 2 + 20% of the data value (2 bytes) for clustering column metadata + 1 byte for the column id = 6 bytes
```
1. クラスタリング列 (ck\$1col2) の 2 番目の列のサイズを計算します。
```
(2 bytes for the integer data type) x 2 + 20% of the data value (2 bytes) for clustering column metadata + 1 byte for the column id = 6 bytes
```
1. 両方の列を足して、クラスタリング列の合計サイズを見積もります。
```
6 bytes + 6 bytes = 12 bytes for the clustering columns
```
1. 通常の列のサイズを足します。この例では、1 バイトが必要で列 ID が 1 バイトが必要で、余分な 1 バイトが必要です。
1. 最後に、エンコードされた行の合計サイズを取得するには、すべての列のバイト数を合計します。ストレージの請求可能なサイズを見積もるには、行メタデータに 100 バイトを追加します。
```
16 bytes for the partition key columns + 12 bytes for clustering columns + 3 bytes for the regular column + 100 bytes for row metadata = 131 bytes.
```
Amazon CloudWatch でサーバーレスリソースをモニタリングする方法については、「[Amazon CloudWatch による Amazon Keyspaces のモニタリング](monitoring-cloudwatch.md)」を参照してください。
# Amazon Keyspaces で読み取り/書き込みスループットのキャパシティ消費量を推定する
Amazon Keyspaces でデータを読み書きした際に、クエリで消費される読み取り/書き込みリクエストユニット (RRU/WRU) または読み取り/書き込みキャパシティユニット (RCU/WCU) の量は、Amazon Keyspaces がそのクエリを実行するために処理しなければならないデータの総量によって決まります。場合によっては、クライアントに返されるデータが、Amazon Keyspaces がクエリを処理するために読み取る必要があるデータの一部に過ぎないこともあります。条件付き書き込みの場合、条件チェックが失敗に終わったとしても、書き込みキャパシティは消費されます。
リクエストのために処理されるデータの総量を推定するには、行のエンコード後のサイズと、行の合計数を考慮する必要があります。このトピックでは、一般的なシナリオとアクセスパターンの例をいくつか取り上げ、Amazon Keyspaces がクエリを処理する方法と、それがキャパシティ消費量にどのように影響するかを説明します。これらの例を参考にして実際のテーブルのキャパシティ要件を見積もり、Amazon CloudWatch を使用して、該当するユースケースの読み取りおよび書き込みのキャパシティ消費状況を観察できます。
Amazon Keyspaces でエンコード後の行サイズを計算する方法については、「[Amazon Keyspaces で行のサイズを推定する](calculating-row-size.md)」を参照してください。
**Topics**
+ [Amazon Keyspaces で範囲クエリのキャパシティ消費量を推定する](range_queries.md)
+ [限定クエリの読み取りキャパシティ消費量を推定する](limit_queries.md)
+ [テーブルスキャンの読み取りキャパシティ消費量を推定する](table_scans.md)
+ [Amazon Keyspaces で軽量トランザクションのキャパシティ消費量を推定する](lightweight_transactions.md)
+ [Amazon Keyspaces の静的列のキャパシティ消費量を推定する](static-columns.md)
+ [Amazon Keyspaces でマルチリージョンテーブルのキャパシティを推定およびプロビジョニングする](tables-multi-region-capacity.md)
+ [Amazon CloudWatch を使用して Amazon Keyspaces の読み取りと書き込みのキャパシティ消費量を推定する](estimate_consumption_cw.md)
# Amazon Keyspaces で範囲クエリのキャパシティ消費量を推定する
範囲クエリの読み取りキャパシティの消費量を調べるために、次のサンプルテーブルを使用します。このテーブルはオンデマンドキャパシティモードを使用しています。
```
pk1 | pk2 | pk3 | ck1 | ck2 | ck3 | value
-----+-----+-----+-----+-----+-----+-------
a | b | 1 | a | b | 50 |
a | b | 1 | a | b | 60 | value_1
a | b | 1 | a | b | 70 |
```
このテーブルに対して、次のクエリを実行します。
```
SELECT * FROM amazon_keyspaces.example_table_1 WHERE pk1='a' AND pk2='b' AND pk3=1 AND ck1='a' AND ck2='b' AND ck3 > 50 AND ck3 < 70;
```
クエリから次の結果セットが返されます。Amazon Keyspaces が実行する読み取りオペレーションでは、`LOCAL_QUORUM` 整合性モードで 2 RRU が消費されます。
```
pk1 | pk2 | pk3 | ck1 | ck2 | ck3 | value
-----+-----+-----+-----+-----+-----+-------
a | b | 1 | a | b | 60 | value_1
```
Amazon Keyspaces はこのクエリを処理するため、2 RRU を消費して `ck3=60` と `ck3=70` の値を含む行を評価します。ただし、Amazon Keyspaces が返すのは、クエリに指定されている `WHERE` 条件が true である行、つまり値が `ck3=60` の行だけです。クエリで指定された範囲を評価するために、範囲の上限に一致する行 (この例では `ck3 = 70`) を読み取りますが、その行を結果では返しません。読み取りキャパシティの消費量は、返されたデータではなく、クエリの処理時に読み取られたデータに基づきます。
# 限定クエリの読み取りキャパシティ消費量を推定する
`LIMIT` 句を使用したクエリを処理する際、Amazon Keyspaces はクエリで指定された条件と一致するデータを探すために、最大ページサイズまでの行数を読み取ります。最初のページで `LIMIT` 値を満たす十分なデータが見つからない場合、1 回以上のページ分割呼び出しが必要になることがあります。次のページの読み取りを続行するには、ページ分割トークンを使用できます。デフォルトのページサイズは 1 MB です。`LIMIT` 句の使用時に読み取りキャパシティの消費量を減らすには、ページサイズを小さくします。ページ分割の詳細については、「[Amazon Keyspaces で結果のページを分割する](paginating-results.md)」を参照してください。
例として、次のクエリを見てみましょう。
```
SELECT * FROM my_table WHERE partition_key=1234 LIMIT 1;
```
ページサイズが設定されていない場合、Amazon Keyspaces は 1 行しか返さないとしても 1 MB 分のデータを読み取ります。Amazon Keyspaces に 1 行だけ読み取らせるには、このクエリでページサイズを 1 に設定します。その場合、Amazon Keyspaces は 1 行のみを読み取ります。ただし、Time-to-Live の設定やクライアント側のタイムスタンプに基づいて期限切れになった行がないことが前提です。
`PAGE SIZE` パラメータは、Amazon Keyspaces がクライアントに返す行数ではなく、リクエストごとにディスクから Amazon Keyspaces がスキャンする行数を決定します。Amazon Keyspaces は、指定したフィルターを適用します。たとえば、非キー列では不等式、ディスク上のデータをスキャン`LIMIT`した後では などです。を明示的に設定しない場合`PAGE SIZE`、Amazon Keyspaces はフィルターを適用する前に最大 1MB のデータを読み取ります。例えば、 を指定`LIMIT 1`せずに を使用している場合`PAGE SIZE`、Amazon Keyspaces は limit 句を適用して 1 行のみを返します。
オーバーリードを回避するには、 を減らし`PAGE SIZE`て、フェッチごとに Amazon Keyspaces がスキャンする行数を減らします。例えば、クエリ`LIMIT 5`で を定義した場合、Amazon Keyspaces がページ分割された呼び出しごとに 5～10 行のみをスキャンするように、 `PAGE SIZE`を 5～10 の値に設定します。この数を変更して、フェッチの数を減らすことができます。ページサイズより大きい制限の場合、Amazon Keyspaces は合計結果数をページ分割状態で維持します。`LIMIT` が 10,000 行の場合、Amazon Keyspaces はこれらの結果をそれぞれ 5,000 行の 2 ページで取得できます。1MB の制限は、設定されたページサイズの上限です。
# テーブルスキャンの読み取りキャパシティ消費量を推定する
`ALLOW FILTERING` オプションを使用したクエリなど、結果的にテーブルのフルスキャンが実行されるクエリも、結果として返されるデータ量よりも読み取り処理量の方が多いクエリの例です。なお、読み取りキャパシティの消費量は、返されたデータではなく、読み取られたデータに基づきます。
テーブルスキャンの例として、次のオンデマンドキャパシティモードのサンプルテーブルを使用します。
```
pk | ck | value
---+----+---------
pk | 10 |
pk | 20 | value_1
pk | 30 |
```
Amazon Keyspaces でオンデマンドキャパシティモードのテーブルを作成した場合、デフォルトのパーティション数は 4 です。このサンプルテーブルでは、すべてのデータが 1 つのパーティションに保存され、残り 3 つのパーティションは空です。
このテーブルに対して、次のクエリを実行します。
```
SELECT * from amazon_keyspaces.example_table_2;
```
このクエリの結果、テーブルスキャンが実行されます。Amazon Keyspaces がテーブルの 4 つのパーティションをすべてスキャンし、`LOCAL_QUORUM` 整合性モードで 6 RRU を消費します。まず、Amazon Keyspaces は 3 RRU を消費して、`pk=‘pk’` である 3 つの行を読み取ります。次に、さらに 3 RRU を消費して、テーブルの 3 つの空パーティションをスキャンします。このクエリではテーブルスキャンが行われるため、データが空のパーティションも含め、テーブルのすべてのパーティションがスキャンされます。
# Amazon Keyspaces で軽量トランザクションのキャパシティ消費量を推定する
軽量トランザクション (LWT) では、テーブルのデータに対して条件付きの書き込みオペレーションを実行できます。条件付きの更新オペレーションは、現在の状態を評価する条件に基づいてレコードを挿入、更新、削除する場合に便利です。
Amazon Keyspaces では、すべての書き込みオペレーションで LOCAL\$1QUORUM 整合性が必要であり、LWT の使用に追加料金はかかりません。LWTs の違いは、LWT 条件チェックの結果が の場合`FALSE`、Amazon Keyspaces は書き込みキャパシティーユニット (WCUs) または書き込みリクエストユニット (WRUs。消費WCUs/WRUsの数は、行のサイズによって異なります。
たとえば、行サイズが 2 KB の場合、失敗した条件付き書き込みは 2 つの WCUs/WRUs。行がテーブルに現在存在しない場合、オペレーションは 1 つの WCUs/WRUs。
条件チェックの失敗の原因となったリクエストの数を確認するには、CloudWatch で `ConditionalCheckFailed`メトリクスをモニタリングできます。
## Time to Live (TTL) を使用したテーブルの LWT コストの見積もり
LWTs では、クライアント側のタイムスタンプを使用しない TTL で設定されたテーブルに対して、追加の読み込みキャパシティーユニット (RCUs) または読み込みリクエストユニット (RRUs) が必要になる場合があります。`IF EXISTS` または `IF NOT EXISTS`キーワード条件チェックの結果を で使用すると`FALSE`、次のキャパシティユニットが消費されます。
+ RCUs/RRUs 行が存在する場合、消費される RCUs/RRUs は既存の行のサイズに基づきます。
+ RCUs/RRUs 行が存在しない場合、単一の RCU/RRU が消費されます。
評価された条件が書き込みオペレーションに成功した場合、WCUs/WRUsは新しい行のサイズに基づいて消費されます。
# Amazon Keyspaces の静的列のキャパシティ消費量を推定する
クラスター化列を含む Amazon Keyspaces テーブルでは、`STATIC` キーワードを使用して静的列を作成できます。静的列に保存されている値は論理パーティション内のすべての行で共有されます。この列の値を更新すると、Amazon Keyspaces によりパーティション内のすべての行に変更が自動で適用されます。
このセクションでは、静的列に書き込むときのエンコードされたデータサイズを計算する方法について説明します。このプロセスは、行の非静的列にデータを書き込むプロセスとは別に処理されます。静的データのサイズクォータに加えて、静的列の読み取りオペレーションと書き込みオペレーションは、テーブルの計測とスループットキャパシティにも個別に影響します。静的列と範囲読み取り結果のページ分割を使用する場合の Apache Cassandra の機能上の違いについては、「[Pagination (ページ分割)](functional-differences.md#functional-differences.paging)」を参照してください。
**Topics**
+ [Amazon Keyspaces で各論理パーティションの静的列サイズを計算する](static-columns-estimate.md)
+ [Amazon Keyspaces で静的データに対する読み取り/書き込みオペレーションのキャパシティスループット要件を推定する](static-columns-metering.md)
# Amazon Keyspaces で各論理パーティションの静的列サイズを計算する
このセクションでは、Amazon Keyspaces でエンコードされた静的列サイズを推定する方法について説明します。エンコードされたサイズは、請求額とクォータの使用量を計算するときに使用されます。テーブルのプロビジョンドスループット性能要件を計算するときも、エンコードされたサイズを使用する必要があります。Amazon Keyspaces 内のエンコードされた静的列サイズを計算するには、次のガイドラインを使用します。
+ パーティションには、最大 2048 バイトのデータを保存できます。パーティションキーの各キー列には、最大 3 バイトのメタデータが必要です。これらのメタデータバイトは、パーティションあたり 1 MB の静的データサイズクォータにカウントされます。静的データのサイズを計算するときには、各パーティションキー列で上限である 3 バイトのメタデータが使用されていることを想定しておくべきです。
+ データ型に基づいて、静的列データ値の生のサイズを使用します。 のデータ型の詳細については、「[データ型](cql.elements.md#cql.data-types)」を参照してください。
+ メタデータのために静的データのサイズに 104 バイトを足します。
+ クラスタリング列と通常の非プライマリキー列は、静的データのサイズにはカウントされません。行内の非静的データのサイズを見積もる方法については、「[Amazon Keyspaces で行のサイズを推定する](calculating-row-size.md)」を参照してください。
エンコードされた静的列の合計サイズは、次の式に基づいています。
```
partition key columns + static columns + metadata = total encoded size of static data
```
すべての列が整数型であるテーブルの例を考えてみましょう。テーブルには、パーティションキー列が 2 つ、クラスタリング列が 2 つ、通常の列が 1 つ、静的列が 1 つあります。
```
CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, static_col1 int static, primary key((pk_col1, pk_col2),ck_col1, ck_col2));
```
この例では、次のステートメントの静的データのサイズを計算します。
```
INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, static_col1) values(1,2,6);
```
この書き込みオペレーションに必要な合計バイト数を見積もるために、次のステップを使用します。
1. 列に保存されているデータ型のバイトとメタデータバイトを追加して、パーティションキー列のサイズを計算します。この計算をすべてのパーティションキー列に対して繰り返します。
1. パーティションキー (pk\$1col1) の最初の列のサイズを計算します。
```
4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes
```
1. パーティションキー (pk\$1col2) の 2 番目の列のサイズを計算します。
```
4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes
```
1. 両方の列を足して、パーティションキー列の合計サイズを見積もります。
```
7 bytes + 7 bytes = 14 bytes for the partition key columns
```
1. 静的列のサイズを足します。この例では、整数を保存している列 (4 バイトが必要) が 1 つしかありません。
1. 最後に、静的列データのエンコードされたサイズの合計を算出するには、プライマリキー列と静的列のバイト数を合計し、メタデータのために追加で 104 バイトを足します。
```
14 bytes for the partition key columns + 4 bytes for the static column + 104 bytes for metadata = 122 bytes.
```
静的データと非静的データを同じステートメントで更新することもできます。書き込みオペレーションの合計サイズを見積もるには、まず非静的データ更新のサイズを計算する必要があります。次に、次の [Amazon Keyspaces で行のサイズを推定する](calculating-row-size.md) での例に示すように、行の更新のサイズを計算し、結果を足します。
この場合、合計で 2 MB を書き込むことができます。1 MB が生の最大行サイズクォータで、もう 1 MB は論理パーティションごとの最大静的データサイズのクォータです。
同じステートメント内の静的データと非静的データの更新の合計サイズを計算するには、次の式を使用します。
```
(partition key columns + static columns + metadata = total encoded size of static data) + (partition key columns + clustering columns + regular columns + row metadata = total encoded size of row)
= total encoded size of data written
```
すべての列が整数型であるテーブルの例を考えてみましょう。テーブルには、パーティションキー列が 2 つ、クラスタリング列が 2 つ、通常の列が 1 つ、静的列が 1 つあります。
```
CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, static_col1 int static, primary key((pk_col1, pk_col2),ck_col1, ck_col2));
```
この例では、次のステートメントに示すように、テーブルに行を書き込むときにデータのサイズを計算します。
```
INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, ck_col1, ck_col2, reg_col1, static_col1) values(2,3,4,5,6,7);
```
この書き込みオペレーションに必要な合計バイト数を見積もるために、次のステップを使用します。
1. 前述のように、静的データのエンコードされたサイズの合計を計算します。この例では、この合計は 122 バイトです。
1. [Amazon Keyspaces で行のサイズを推定する](calculating-row-size.md) の手順に従い、非静的データの更新に基づいて、行のエンコードされたサイズの合計を足します。この例では、行の更新の合計サイズは 134 バイトです。
```
122 bytes for static data + 134 bytes for nonstatic data = 256 bytes.
```
# Amazon Keyspaces で静的データに対する読み取り/書き込みオペレーションのキャパシティスループット要件を推定する
静的データは、個々の行ではなく、Cassandra の論理パーティションに関連付けられます。Amazon Keyspaces の論理パーティションは、複数のストレージパーティションにまたがることができるので、そのサイズは事実上無制限です。その結果、Amazon Keyspaces により、静的データと非静的データに対する書き込みオペレーションが別々に計測されます。さらに、静的データと非静的データの両方を含む書き込みには、データの整合性を確保するために、基盤となる追加のオペレーションが必要です。
静的データと非静的データを混合した書き込みオペレーションを実行すると、2 つの個別の書き込みオペレーション (非静的データ用と静的データ用) が発生します。これは、オンデマンドおよび読み取り/書き込みのプロビジョンドキャパシティモードの両方に適用されます。
次の例では、静的列がある Amazon Keyspaces のテーブルのプロビジョンドスループット性能要件を計算するときに、必要な読み取りキャパシティユニット (RCU) と書き込みキャパシティユニット (WCU) を見積もる方法について説明します。次の式を使用して、静的データと非静的データの両方を含む書き込みを処理するためにテーブルで必要となるキャパシティを見積もることができます。
```
2 x WCUs required for nonstatic data + 2 x WCUs required for static data
```
例えば、アプリケーションにより 1 秒あたり 27 KB のデータが書き込まれ、各書き込みに 25.5 KB の非静的データと 1.5 KB の静的データが含まれている場合、テーブルには 56 WCU (2 x 26 WCU \$1 2 x 2 WCU) が必要です。
Amazon Keyspaces で、複数の行の読み取りと同じ静的データと非静的データの読み取りが計測されます。その結果、同じオペレーション内で静的データと非静的データを読み取る場合の料金は、読み取りを実行するために処理されるデータの総サイズに基づきます。
Amazon CloudWatch でサーバーレスリソースをモニタリングする方法については、「[Amazon CloudWatch による Amazon Keyspaces のモニタリング](monitoring-cloudwatch.md)」を参照してください。
# Amazon Keyspaces でマルチリージョンテーブルのキャパシティを推定およびプロビジョニングする
マルチリージョンテーブルのスループットキャパシティは、次の 2 とおりの方法で設定できます。
+ オンデマンドキャパシティモード。書き込みリクエストユニット (WRU) で測定します。
+ 自動スケーリングが有効なプロビジョンドキャパシティモード。書き込みキャパシティユニット (WCU) で測定します。
自動スケーリングまたはオンデマンドキャパシティモードでプロビジョンドキャパシティモードを使用すると、マルチリージョンテーブルにすべての に対してレプリケートされた書き込みを実行するのに十分なキャパシティを確保できます AWS リージョン。
**注記**
いずれかのリージョンでテーブルのキャパシティモードを変更すると、すべてのレプリカのキャパシティモードが変更されます。
デフォルトでは、Amazon Keyspaces はマルチリージョンテーブルでオンデマンドモードを使用します。オンデマンドモードでは、アプリケーションが実行する読み込みおよび書き込みの予想スループットを指定する必要がありません。Amazon Keyspaces は、ワークロードがこれまでに到達実績のあるトラフィックレベルまで増減した場合は、瞬時に対応します。ワークロードのトラフィックレベルが新しいピークに達した場合も、ワークロードに対応できるよう迅速に適応します。
テーブルでプロビジョンドキャパシティモードを選択した場合は、アプリケーションに必要な 1 秒あたりの読み取りキャパシティユニット (RCU) と書き込みキャパシティユニット (WCU) の数を設定する必要があります。
マルチリージョンテーブルのスループットキャパシティのニーズを計画するには、まず各リージョンで必要な 1 秒あたりの WCU の数を見積もります。次に、テーブルのレプリケート先のすべてのリージョンでの書き込みを合計し、その合計を各リージョンのキャパシティとしてプロビジョニングします。これは、1 つのリージョンで実行されるすべての書き込みを各レプリカリージョンでも繰り返す必要があるためです。
すべてのリージョンでの書き込みを処理するにはテーブルのキャパシティが不足している場合、キャパシティの例外が発生します。さらに、リージョン間レプリケーションの待機時間が長くなります。
例えば、米国東部 (バージニア北部) で 1 秒あたり 5 回の書き込み、米国東部 (オハイオ) で 1 秒あたり 10 回の書き込み、欧州 (アイルランド) で 1 秒あたり 5 回の書き込みが予想されるマルチリージョンテーブルがある場合、米国東部 (バージニア北部）、米国東部 (オハイオ）、欧州 (アイルランド) の各リージョンでテーブルの消費量は 20 WCU になると予想されます。つまり、この例では、テーブルの各レプリカに 20 WCU をプロビジョニングする必要があります。Amazon CloudWatch を使用して、テーブルのキャパシティ消費量をモニタリングできます。詳細については、「[Amazon CloudWatch による Amazon Keyspaces のモニタリング](monitoring-cloudwatch.md)」を参照してください。
各書き込みは 1 WCU として請求されるため、この例では合計 60 WCUsが請求されます。料金の詳細については、「[Amazon Keyspaces (for Apache Cassandra) pricing (Amazon Keyspaces (Apache Cassandra 向け) の料金)](https://aws.amazon.com/keyspaces/pricing)」を参照してください。
Amazon Keyspaces 自動スケーリングを有効にしたプロビジョンドキャパシティの詳細については、「[Amazon Keyspaces 自動スケーリングでスループットキャパシティを自動的に管理する](autoscaling.md)」を参照してください。
**注記**
テーブルがプロビジョンドキャパシティーモードで自動スケーリングを使用している場合、プロビジョニングされた書き込みキャパシティは、各リージョンの自動スケーリング設定の範囲内で変動させることができます。
# Amazon CloudWatch を使用して Amazon Keyspaces の読み取りと書き込みのキャパシティ消費量を推定する
読み取りと書き込みのキャパシティ消費量を推定し、モニタリングするには、CloudWatch ダッシュボードを使用できます。Amazon Keyspaces で使用可能なメトリクスの詳細については、「[Amazon Keyspaces のメトリクスとディメンション](metrics-dimensions.md)」を参照してください。
特定のステートメントで消費される読み取りと書き込みのキャパシティユニットを CloudWatch でモニタリングするには、以下の手順に従ってください。
1. サンプルデータを使用して新しいテーブルを作成する
1. テーブルの Amazon Keyspaces CloudWatch ダッシュボードを設定します。まずは、[Github](https://github.com/aws-samples/amazon-keyspaces-cloudwatch-cloudformation-templates) で利用可能なダッシュボードテンプレートを使用できます。
1. `ALLOW FILTERING` オプションなどを使用して CQL ステートメントを実行し、テーブルのフルスキャンで消費される読み取りキャパシティユニットをダッシュボードで確認します。
# Amazon Keyspaces で読み取り/書き込みのキャパシティモードを設定する
Amazon Keyspaces には、テーブルで読み込みおよび書き込みを処理するための読み取り/書き込みキャパシティモードが 2 つあります。
+ オンデマンド (デフォルト)
+ プロビジョン済み
読み取り/書き込みキャパシティモードを選択すると、読み取りと書き込みのスループットの料金体系、およびテーブルスループットキャパシティの管理状態を制御できます。
**Topics**
+ [オンデマンドキャパシティモードを設定する](ReadWriteCapacityMode.OnDemand.md)
+ [プロビジョンドキャパシティモードを設定する](ReadWriteCapacityMode.Provisioned.md)
+ [Amazon Keyspaces でテーブルのキャパシティモードを表示する](ReadWriteCapacityMode.ProvisionedThroughput.ManagingCapacity.md)
+ [Amazon Keyspaces でテーブルのキャパシティモードを変更する](ReadWriteCapacityMode.SwitchReadWriteCapacityMode.md)
+ [Amazon Keyspaces でテーブルの事前ウォーミングを設定する](warm-throughput.md)
# オンデマンドキャパシティモードを設定する
Amazon Keyspaces (Apache Cassandra 向け) の*オンデマンド*キャパシティモードは、キャパシティ計画なしで 1 秒あたりに数千ものリクエストを処理できる柔軟な請求オプションです。このオプションには、読み取りおよび書き込みリクエストのリクエストごとの支払い料金が用意されているため、使用した分だけ課金されます。
オンデマンドモードを選択すると、Amazon Keyspaces により、テーブルのスループットキャパシティを以前に到達したトラフィックレベルまで即座に拡張でき、アプリケーショントラフィックが減少した時点で元に戻すことができます。ワークロードのトラフィックレベルが新たなピークに達すると、サービスは瞬時に適応してテーブルのスループットキャパシティを増やします。新規テーブルと既存のテーブルの両方で、オンデマンドキャパシティモードを有効にできます。
以下の条件のいずれかに該当する場合、オンデマンドモードは適切なオプションです。
+ 不明なワークロードを含む新しいテーブルを作成します。
+ アプリケーションのトラフィックが予測不可能です。
+ わかりやすい従量課金制の支払いを希望します。
オンデマンドモードを開始するには、コンソールまたは数行の Cassandra クエリ言語 (CQL) コードを使用して、新規のテーブルを作成するか、既存のテーブルを更新して、オンデマンドキャパシティモードを使用することができます。詳細については、「[テーブル](cql.ddl.table.md)」を参照してください。
**Topics**
+ [読み取りリクエスト単位と書き込みリクエスト単位](#ReadWriteCapacityMode.requests)
+ [ピークトラフィックとスケーリングプロパティ](#ReadWriteCapacityMode.PeakTraffic)
+ [オンデマンドキャパシティモードの初期スループット](#ReadWriteCapacityMode.InitialThroughput)
## 読み取りリクエスト単位と書き込みリクエスト単位
オンデマンドキャパシティモードのテーブルでは、アプリケーションによりあらかじめ使用されることが予測される読み取りスループットと書き込みスループットを指定する必要はありません。Amazon Keyspaces では、読み込みリクエスト単位 (RRU) と書き込みリクエスト単位 (WRU) に関して、テーブルに対して実行する読み取りと書き込みの料金が発生します。
+ 1 *RRU* は、最大 4 KB の行に対して、`LOCAL_QUORUM` 読み取りリクエスト 1 件、または ` LOCAL_ONE` リクエスト 2 件を表します。4 KB より大きい行を読み取る必要がある場合、読み取りオペレーションには追加の RRU が使用されます。必要な RRU の総数は、行サイズと、`LOCAL_QUORUM` または `LOCAL_ONE` の読み取り整合性の使用の有無によって異なります。例えば、8 KB の行の読み取りには、`LOCAL_QUORUM` 読み取り整合性を使用する 場合は 2 RRU、`LOCAL_ONE` 読み取り整合性を選択した場合は 1 RRU が必要です。
+ 1 *WRU* は、最大で 1 KB の行 1 つに対する 1 回の書き込みを表します。すべての書き込みでは `LOCAL_QUORUM` 整合性が使用されており、軽量トランザクション (LWT) の使用には追加料金はかかりません。1 KB より大きい行を書き込む必要がある場合、書き込みオペレーションでは追加の WRU が使用されます。必要な WRU の総数は、行サイズに応じて異なります。例えば、行サイズが 2 KB の場合、1 件の書き込みリクエストを実行するには 2 WRU が必要です。
サポートされている整合性レベルの詳細については、「[Apache Cassandra でサポートされている読み取り/書き込み整合性レベルと関連コスト](consistency.md)」を参照してください。
## ピークトラフィックとスケーリングプロパティ
オンデマンドキャパシティモードが使用されている Amazon Keyspaces テーブルは、アプリケーションのトラフィックボリュームに自動的に適応します。オンデマンドキャパシティーモードは、テーブルにおける前のピークトラフィックの最大 2 倍まで瞬時に対応します。例えば、アプリケーションのトラフィックパターンは、1 秒あたりの `LOCAL_QUORUM` 読み取り数 5,000～10,000 の範囲で変動する可能性があります。1 秒あたりの読み取り数 10,000 は過去のトラフィックピークです。
このパターンでは、オンデマンドキャパシティモードは、1 秒あたりの最大読み取り数 20,000 の持続トラフィックに即座に対応します。アプリケーションによって 1 秒あたりの読み取り数 20,000 のトラフィックを維持する場合、そのピークは新たに過去のピークになり、その後のトラフィックでは 1 秒あたりの最大読み取り数が 40,000 に到達できます。
1 つのテーブルで過去のピークの 2 倍以上が必要な場合、Amazon Keyspaces では、トラフィックボリュームの増加に合わせて、割り当るキャパシティが自動的に増加されます。これにより、そのテーブルに、追加のリクエストを処理できるだけの十分なスループットキャパシティがあることを確認できます。ただし、30 分以内に過去のピークの 2 倍を超えると、スループットキャパシティ不足エラーが発生する可能性があります。
例えば、読み取りの整合性が強力で、アプリケーションのトラフィックパターンが 1 秒あたりの読み取り数 5,000～10,000 の範囲で変動し、1 秒あたりの読み取り数 20,000 が過去に到達したトラフィックピークである場合を考えてみます。この場合、このサービスでは、1 秒あたりの最大読み取り数 40,000 に到達する 30 分以上前の段階で、トラフィックを増やすことが推奨されます。
テーブルの読み取りと書き込みのキャパシティ消費量の推定方法については、「[Amazon Keyspaces で読み取り/書き込みスループットのキャパシティ消費量を推定する](capacity-examples.md)」を参照してください。
アカウントのデフォルトクォータの詳細およびクォータを引き上げる方法については、「[Amazon Keyspaces (Apache Cassandra 向け) のクォータ](quotas.md)」を参照してください。
## オンデマンドキャパシティモードの初期スループット
オンデマンドキャパシティモードが有効になっている新規のテーブルを作成した場合、または、初めて既存のテーブルを最近初めてオンデマンドキャパシティモードに切り替えた場合に、テーブルには、過去にオンデマンドキャパシティモードでトラフィックが扱われたことがなくても、以下に示す過去のピーク設定があります。
+ **オンデマンドキャパシティモードで新たに作成されたテーブル:** 過去のピークは、2,000 WRU および 6,000 RRU です。過去のピークを即座に 2 倍まで引き上げることができます。これにより、新たに作成されたオンデマンドテーブルにおいて、最大で 4,000 WRU および 12,000 RRU です。
+ **オンデマンドキャパシティモードに切り替えられた既存のテーブル:** 過去のピークは、テーブルにプロビジョニングされた過去の WCU と RCU の半分、またはオンデマンドキャパシティモードで新しく作成されたテーブルの設定の、どちらか高い方になります。
# プロビジョンドキャパシティモードを設定する
*プロビジョンドスループット性能*モードを選択した場合は、アプリケーションに必要な 1 秒あたりの読み込みと書き込みの回数を指定します。これにより、Amazon Keyspaces の使用状況を管理して、定義されたリクエストレート以下を維持し、予測可能性を維持できます。プロビジョンドスループットのオートスケーリングの詳細については、「[Amazon Keyspaces 自動スケーリングでスループットキャパシティを自動的に管理する](autoscaling.md)」を参照してください。
以下の条件のいずれかに該当する場合、プロビジョンドスループット性能モードは適切なオプションです。
+ アプリケーションのトラフィックが予測可能です。
+ トラフィックが一定している、または徐々に増加するアプリケーションを実行します。
+ 容量要件を予測できます。
## 読み取りキャパシティユニットと書き込みキャパシティユニット
プロビジョンドスループット性能モードのテーブルでは、読み取りキャパシティユニット (RCU) と書き込みキャパシティユニット (WCU) の観点でスループットキャパシティを指定できます。
+ 1 *RCU* は、最大 4 KB の 1 行に対して、1 秒あたり 1 回の `LOCAL_QUORUM` 読み取り、または 1 秒あたり 2 回の `LOCAL_ONE` 読み取りを表しています。4 KB より大きい行を読み取る必要がある場合、読み取りオペレーションには追加の RCU が使用されます。
必要な RCU の総数は、行サイズ、および、`LOCAL_QUORUM` と `LOCAL_ONE` の読み取りのどちらを使用するかによって異なります。例えば、行サイズが 8 KB の場合、1 秒あたり 1 回の `LOCAL_QUORUM` 読み取りを維持するには 2 RCU が必要になり、`LOCAL_ONE` 読み取りを選択した場合は 1 RCU が必要になります。
+ 1 *WCU* は、最大 1 KB の 1 行 に対する 1 回の書き込みを表します。すべての書き込みでは `LOCAL_QUORUM` 整合性が使用されており、軽量トランザクション (LWT) の使用には追加料金はかかりません。1 KB より大きい行を書き込む必要がある場合、書き込みオペレーションでは追加の WCU が使用されます。
必要な WCU の総数は、行サイズに応じて異なります。例えば、行サイズが 2 KB の場合、1 秒あたり 1 件の書き込みリクエスト処理を維持するには 2 WCU が必要です。テーブルの読み取りと書き込みのキャパシティ消費量を推定する方法の詳細については、「[Amazon Keyspaces で読み取り/書き込みスループットのキャパシティ消費量を推定する](capacity-examples.md)」を参照してください。
アプリケーションでこれより大きな行 (上限は Amazon Keyspaces の最大行サイズ 1 MB) の読み取りまたは書き込みが行われると、消費されるキャパシティユニットがさらに増えます。行サイズを見積もる方法については、「[Amazon Keyspaces で行のサイズを推定する](calculating-row-size.md)」を参照してください。例えば、6 RCU と 6 WCU のプロビジョニングされたテーブルを作成するとします。これらの設定により、アプリケーションで次のことが可能になります。
+ 1 秒あたり最大 24 KB の `LOCAL_QUORUM` 読み取りの実行 (4 KB × 6 RCU)。
+ 1 秒あたり最大 48 KB の `LOCAL_ONE` 読み取りの実行 (読み取りスループットは 2 倍)
+ 1 秒あたり最大 6 KB の書き込みの実行 (1 KB × 6 WCU)。
*プロビジョンドスループット*とは、アプリケーションによりテーブルから消費されるスループットキャパシティの上限です。アプリケーションがプロビジョンドスループット性能を超えると、キャパシティ不足エラーが発生する可能性があります。
例えば、十分なスループットキャパシティがない読み取りリクエストは、`Read_Timeout` 例外が発生して失敗し、`ReadThrottleEvents` メトリクスに投稿されます。十分なスループットキャパシティがない書き込みリクエストは、`Write_Timeout` 例外が発生して失敗し、`WriteThrottleEvents` メトリクスに投稿されます。
Amazon CloudWatch を使用して、プロビジョンドスループットメトリクス、実際のスループットメトリクス、キャパシティ不足イベントを監視することができます。これらのメトリクスの詳細については、[Amazon Keyspaces のメトリクスとディメンション](metrics-dimensions.md) を参照してください。
**注記**
キャパシティ不足によるエラーが繰り返し発生すると、クライアント側のドライバー固有例外が発生する可能性があります。例えば、DataStax Java ドライバーは `NoHostAvailableException` により失敗します。
テーブルのスループットキャパシティ設定を変更する場合は、 AWS マネジメントコンソール や、CQL を使用する `ALTER TABLE` ステートメントを使用できます。詳細については「[ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter)」を参照してください。
アカウントのデフォルトクォータの詳細およびクォータを引き上げる方法については、「[Amazon Keyspaces (Apache Cassandra 向け) のクォータ](quotas.md)」を参照してください。
# Amazon Keyspaces でテーブルのキャパシティモードを表示する
Amazon Keyspaces システムキースペースでシステムテーブルのクエリを実行して、テーブルに関するキャパシティモード情報を確認することができます。テーブルにオンデマンドスループット性モードまたはプロビジョンドスループット性能モードが使用されているかどうかも確認できます。テーブルにプロビジョンドスループット性能モードが設定されている場合、テーブルにプロビジョニングされたスループットキャパシティを確認できます。
を使用して、テーブルのキャパシティモード AWS CLI を表示することもできます。
テーブルのプロビジョンドスループットを変更するには、「[Amazon Keyspaces でテーブルのキャパシティモードを変更する](ReadWriteCapacityMode.SwitchReadWriteCapacityMode.md)」を参照してください。
------
#### [ Cassandra Query Language (CQL) ]
**例**
```
SELECT * from system_schema_mcs.tables where keyspace_name = 'mykeyspace' and table_name = 'mytable';
```
オンデマンドキャパシティモードで設定されたテーブルからは、次の結果が返されます。
```
{
"capacity_mode":{
"last_update_to_pay_per_request_timestamp":"1579551547603",
"throughput_mode":"PAY_PER_REQUEST"
}
}
```
プロビジョンドスループット性能モードで構成されたテーブルからは、次の結果が返されます。
```
{
"capacity_mode":{
"last_update_to_pay_per_request_timestamp":"1579048006000",
"read_capacity_units":"5000",
"throughput_mode":"PROVISIONED",
"write_capacity_units":"6000"
}
}
```
`last_update_to_pay_per_request_timestamp` 値はミリ秒単位で測定されます。
------
#### [ CLI ]
を使用してテーブルのスループットキャパシティモードを表示する AWS CLI
```
aws keyspaces get-table --keyspace-name myKeyspace --table-name myTable
```
このコマンドの出力は、テーブルがプロビジョンドキャパシティモードの場合は、次のようになります。
```
"capacitySpecification": {
"throughputMode": "PROVISIONED",
"readCapacityUnits": 4000,
"writeCapacityUnits": 2000
}
```
オンデマンドモードのテーブルの場合、出力は次のようになります。
```
"capacitySpecification": {
"throughputMode": "PAY_PER_REQUEST",
"lastUpdateToPayPerRequestTimestamp": "2024-10-03T10:48:19.092000+00:00"
}
```
------
# Amazon Keyspaces でテーブルのキャパシティモードを変更する
テーブルをプロビジョンドキャパシティモードからオンデマンドキャパシティモードに切り替えると、Amazon Keyspaces によりテーブルおよびパーティションの構造にいくつかの変更が加えられます。この処理には数分かかることもあります。切り替え期間中、テーブルでは、以前にプロビジョニングされた WCU および RCU の両方と整合性のあるスループットが得られます。
オンデマンドキャパシティモードからプロビジョンドキャパシティモードに戻すと、テーブルでは、テーブルがオンデマンドキャパシティモードに設定されたときに到達した前のピークと整合性のあるスループットが得られます。
キャパシティモードを切り替える際は、次の待機期間が適用されます。
+ オンデマンドモードで新しく作成したテーブルは、いつでもプロビジョンドキャパシティモードに切り替えることができます。ただし、オンデマンドモードに戻すことができるのは、テーブルの作成タイムスタンプから 24 時間後のみです。
+ オンデマンドモードの既存のテーブルは、いつでもプロビジョンドキャパシティモードに切り替えることができます。ただし、キャパシティモードをプロビジョンドからオンデマンドに切り替えることができるのは、24 時間に 1 回のみです。
------
#### [ Cassandra Query Language (CQL) ]
**CQL を使用してテーブルのスループットキャパシティモードを変更する**
1. テーブルのキャパシティモードを `PROVIOSIONED` に変更するには、ワークロードの予想されるピーク値に基づいて読み取りキャパシティユニットと書き込みキャパシティユニットを設定する必要があります。次のステートメントは、その一例です。このステートメントを実行して、テーブルの読み取りキャパシティユニットまたは書き込みキャパシティユニットを調整することもできます。
```
ALTER TABLE catalog.book_awards WITH CUSTOM_PROPERTIES={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 6000, 'write_capacity_units': 3000}};
```
プロビジョンドキャパシティモードと自動スケーリングを設定するには、「[既存のテーブルに対して自動スケーリングを設定する](autoscaling.configureTable.md)」を参照してください。
1. テーブルのキャパシティモードをオンデマンドモードに変更するには、スループットモードを `PAY_PER_REQUEST` に設定します。以下のステートメントは、この例です。
```
ALTER TABLE catalog.book_awards WITH CUSTOM_PROPERTIES={'capacity_mode':{'throughput_mode': 'PAY_PER_REQUEST'}};
```
1. 次のステートメントを使用して、テーブルのキャパシティモードを確認できます。
```
SELECT * from system_schema_mcs.tables where keyspace_name = 'catalog' and table_name = 'book_awards';
```
オンデマンドキャパシティモードで設定されたテーブルからは、次の結果が返されます。
```
{
"capacity_mode":{
"last_update_to_pay_per_request_timestamp":"1727952499092",
"throughput_mode":"PAY_PER_REQUEST"
}
}
```
`last_update_to_pay_per_request_timestamp` 値はミリ秒単位で測定されます。
------
#### [ CLI ]
**を使用してテーブルのスループットキャパシティモードを変更する AWS CLI**
1. テーブルのキャパシティモードを `PROVIOSIONED` に変更するには、ワークロードの予想されるピーク値に基づいて読み取りキャパシティユニットと書き込みキャパシティユニットを設定する必要があります。次のコマンドは、その一例です。このコマンドを実行して、テーブルの読み取りキャパシティユニットまたは書き込みキャパシティユニットを調整することもできます。
```
aws keyspaces update-table --keyspace-name catalog --table-name book_awards
\--capacity-specification throughputMode=PROVISIONED,readCapacityUnits=6000,writeCapacityUnits=3000
```
プロビジョンドキャパシティモードと自動スケーリングを設定するには、「[既存のテーブルに対して自動スケーリングを設定する](autoscaling.configureTable.md)」を参照してください。
1. テーブルのキャパシティモードをオンデマンドモードに変更するには、スループットモードを `PAY_PER_REQUEST` に設定します。以下のステートメントは、この例です。
```
aws keyspaces update-table --keyspace-name catalog --table-name book_awards
\--capacity-specification throughputMode=PAY_PER_REQUEST
```
1. 次のコマンドを使用して、テーブルに設定されているキャパシティモードを確認できます。
```
aws keyspaces get-table --keyspace-name catalog --table-name book_awards
```
オンデマンドモードのテーブルの場合、出力は次のようになります。
```
"capacitySpecification": {
"throughputMode": "PAY_PER_REQUEST",
"lastUpdateToPayPerRequestTimestamp": "2024-10-03T10:48:19.092000+00:00"
}
```
------
# Amazon Keyspaces でテーブルの事前ウォーミングを設定する
Amazon Keyspaces は、オンデマンドまたはプロビジョニングされたスループットに基づいてストレージパーティションを自動的にスケーリングしますが、新しいテーブルや突然のスループットピークの場合、必要なストレージパーティションの割り当てに時間がかかることがあります。新規または既存のテーブルに予想されるピークスループットをサポートするのに十分な容量を確保するために、特定の*ウォームスループット*値を手動で設定してテーブルを*事前ウォーミング*できます。
*ウォームスループット*とは、Amazon Keyspaces テーブルが瞬時にサポートできる読み取りおよび書き込みオペレーションの数を指します。これらの値は、すべての新規および既存のテーブルでデフォルトで使用できます。オンデマンドモードを使用している場合、またはプロビジョニングされたスループットを更新する場合、Amazon Keyspaces はアプリケーションがこれらの値まで即座にリクエストを発行できるようにします。
Amazon Keyspaces は、使用量が増えるとウォームスループット値を自動的に調整します。たとえば、別のデータベースからデータを移行する場合など、今後のピークイベントのスループット容量を調整するには、短時間でテラバイトのデータをロードする必要がある場合があります。テーブルのウォームスループット値を手動で増やすことができます。これは、リクエストレートが 10 倍、100 倍、またはそれ以上増加する可能性がある計画されたピークイベントに役立ちます。まず、現在のウォームスループットが予想されるトラフィックを処理するのに十分かどうかを評価します。次に、計画されたピークワークロードのテーブルを事前ウォーミングする必要がある場合は、スループット設定や[キャパシティモード](ReadWriteCapacityMode.md)を変更せずにウォームスループット値を手動で増やすことができます。
読み取りオペレーション、書き込みオペレーション、またはその両方のためにテーブルを事前ウォーミングできます。この値は、新規および既存の単一リージョンテーブルとマルチリージョンテーブルに対して増やすことができ、設定したウォームスループット設定はマルチリージョンテーブルのすべてのレプリカに自動的に適用されます。事前ウォーミングできる Amazon Keyspaces テーブルの数に制限はありません。事前ウォーミングを完了する時間は、設定した値とテーブルのサイズによって異なります。同時事前ウォーミングリクエストを送信でき、これらのリクエストはテーブルオペレーションを妨げません。そのリージョンのアカウントのテーブルクォータ制限まで、テーブルを事前ウォーミングできます。[Service Quotas コンソール](https://console.aws.amazon.com/servicequotas)を使用して現在のクォータを確認し、必要に応じて引き上げます。
Amazon Keyspaces がオンデマンド使用量またはプロビジョニングされた容量に基づいて調整するウォームスループット値は、追加料金なしですべてのテーブルでデフォルトで使用できます。ただし、デフォルトのウォームスループット値をピークトラフィックイベントの事前ウォームテーブルに手動で増やすと、追加料金が適用されます。詳細については、[「Amazon Keyspaces の料金](https://aws.amazon.com/keyspaces/pricing/)」を参照してください。
Amazon Keyspaces テーブルを事前ウォーミングするときに考慮すべきシナリオとベストプラクティスをいくつか紹介します。
## ウォームスループットと不均等なアクセスパターン
テーブルのウォームスループットは 1 秒あたり 30,000 読み取りユニットと 1 秒あたり 10,000 書き込みユニットですが、これらの値に達する前に読み取りまたは書き込みで容量超過イベントが発生する可能性があります。これは、ホットパーティションが原因である可能性があります。Amazon Keyspaces は実質的に無制限のスループットをサポートするようにスケーリングを続けることができますが、個々のパーティションは 1 秒あたり 1,000 書き込みユニットと 1 秒あたり 3,000 読み取りユニットに制限されています。アプリケーションがテーブルのパーティションのごく一部にトラフィックを送りすぎると、テーブルのウォームスループット値に達する前でも容量超過イベントが発生する可能性があります。シームレスなスケーラビリティを確保し、ホットパーティションを回避するために、[Amazon Keyspaces のベストプラクティス](bp-partition-key-design.md)に従うことをお勧めします。
## プロビジョニングされたテーブルのウォームスループット
1 秒あたり 30,000 読み込みユニットと 1 秒あたり 10,000 書き込みユニットのウォームスループットを持つが、現在 4,000 RCUsと 8,000 WCUs。プロビジョニングされたスループット設定を更新することで、テーブルのプロビジョニングされたスループットを 30,000 RCUsまたは 10,000 WCUs まで即座にスケールできます。プロビジョニングされたスループットをこれらの値を超えて増やすと、新しいピークスループットが確立されるため、ウォームスループットは新しい高い値に自動的に調整されます。たとえば、プロビジョニングされたスループットを 50,000 RCU に設定すると、ウォームスループットは 1 秒あたり 50,000 読み取りユニットに増加します。
```
"ProvisionedThroughput":
{
"ReadCapacityUnits": 4000,
"WriteCapacityUnits": 8000
}
"WarmThroughput":
{
"ReadUnitsPerSecond": 30000,
"WriteUnitsPerSecond": 10000
}
```
## オンデマンドテーブルのウォームスループット
新しいオンデマンドテーブルは、1 秒あたり 12,000 読み取りユニット、1 秒あたり 4,000 書き込みユニットのウォームスループットから始まります。テーブルは、これらのレベルまで持続するトラフィックに即座に対応できます。リクエストが 1 秒あたり 12,000 読み取りユニットまたは 1 秒あたり 4,000 書き込みユニットを超えると、ウォームスループットはより高い値に自動的に調整されます。
```
"WarmThroughput":
{
"ReadUnitsPerSecond": 12000,
"WriteUnitsPerSecond": 4000
}
```
## Amazon Keyspaces テーブルを事前ウォーミングするためのベストプラクティス
Amazon Keyspaces テーブルに事前ウォーミングを実装する場合は、次のベストプラクティスに従ってください。
必要な容量を正確に見積もる
事前ウォーミングには 1 回限りのコストが発生するため、オーバープロビジョニングを避けるため、予想されるワークロードに基づいて必要なスループットを慎重に計算してください。
テーブルのスキーマを考慮する
行が大きいテーブルでは、同じスループットに対してより多くのパーティションが必要になる場合があります。事前ウォーミング要件を推定するときに、平均行サイズを考慮します。
テーブルのパフォーマンスをモニタリングする
事前ウォーミング後、CloudWatch メトリクスを使用して、テーブルが想定どおりに負荷を処理していることを確認します。詳細については、「[Amazon CloudWatch を使用して事前ウォーミングされたテーブルのパフォーマンスをモニタリングする](monitor-prewarming-cloudwatch.md)」を参照してください。
クォータの管理
アプリケーションでデフォルトのクォータ (40,000 RCUs/WCUs または 2,000 パーティション) よりも高いスループットが必要な場合は、トラフィックの多いイベントよりもかなり前にリクエストクォータが増加します。クォータの引き上げをリクエストするには、[ Service Quotas コンソール](https://console.aws.amazon.com/servicequotas)を使用してください。
コストの最適化
トラフィックの多い一時的なイベントの場合、短期間のイベントでは費用対効果が高くなる可能性があるため、大容量のプロビジョニングモードに切り替える代わりに事前ウォーミングを使用することを検討してください。料金の詳細については、[「Amazon Keyspaces の料金](https://aws.amazon.com/keyspaces/pricing/)」を参照してください。
**注記**
テストフェーズ中にアプリケーションのパフォーマンスメトリクスをモニタリングして、事前ウォーミング設定がワークロード要件を適切にサポートしていることを確認します。
**Topics**
+ [ウォームスループットと不均等なアクセスパターン](#warm-throughput-scenarios-uneven)
+ [プロビジョニングされたテーブルのウォームスループット](#warm-throughput-scenarios-provisioned)
+ [オンデマンドテーブルのウォームスループット](#warm-throughput-scenarios-ondemand)
+ [Amazon Keyspaces テーブルを事前ウォーミングするためのベストプラクティス](#prewarming-best-practices)
+ [ウォームスループットがより高い Amazon Keyspaces テーブルを新規作成する](create-table-warm-throughput.md)
+ [既存の Amazon Keyspaces テーブルのウォームスループットを増やす](update-warm-throughput.md)
+ [Amazon Keyspaces テーブルのウォームスループットを表示する](view-warm-throughput.md)
+ [Amazon CloudWatch を使用して事前ウォーミングされたテーブルのパフォーマンスをモニタリングする](monitor-prewarming-cloudwatch.md)
# ウォームスループットがより高い Amazon Keyspaces テーブルを新規作成する
コンソール、CQL、または を使用して、Amazon Keyspaces テーブルを作成するときにウォームスループット値を調整できます AWS CLI。
------
#### [ Console ]
**ウォームスループット設定で新しいテーブルを作成する方法**
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) で Amazon Keyspaces コンソールを開きます。
1. ナビゲーションペインで [**Tables]** (テーブル) を選択して、[**Create table (テーブルの作成)**] を選択します。
1. [**Table details (テーブルの詳細)**] セクションの [**Create table (テーブルの作成)**] ページで、キースペースを選択し、新しいテーブルに名前を付けます。
1. **[列]** セクションで、テーブルのスキーマを作成します。
1. **[プライマリキー]** セクションで、テーブルのプライマリキーを定義し、オプションでクラスタリング列を選択します。
1. **[テーブルの設定]** セクションで、**[設定のカスタマイズ]** を選択します。
1. [**Read/write capacity settings (読み取り/書き込みキャパシティの設定)**] に進みます。
1. **キャパシティモードでは**、**オンデマンド**または**プロビジョンド**のいずれかを選択できます。
1. **テーブルの事前ウォーミング**セクションでは、必要に応じて **1 秒あたりの読み取り単位**と 1 **秒あたりの書き込み単位**の値を増やして、計画されたピークイベントを処理するテーブルを準備することができます。
Amazon Keyspaces がオンデマンド使用量またはプロビジョニングされた容量に基づいて調整するウォームスループット値は、追加料金なしですべてのテーブルでデフォルトで使用できます。デフォルトのウォームスループット値を手動で増やして、ピークトラフィックイベントのテーブルを事前ウォーミングする場合、追加料金が適用されます。
1. 必要に応じて、他のオプションのテーブル機能を設定します。次に、**[Create table]** (テーブルを作成) を選択します。
------
#### [ Cassandra Query Language (CQL) ]
+ 次のいずれかの方法を使用して、ウォームスループットのテーブルを作成します。
+ プロビジョニングモードの場合は、テーブルを作成し、次の CQL 構文を使用して読み取りと書き込みの予想されるピーク容量を指定します。
```
CREATE TABLE catalog.book_awards (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank))
WITH CUSTOM_PROPERTIES = {
'capacity_mode': {
'throughput_mode': 'PROVISIONED',
'read_capacity_units': 20000,
'write_capacity_units': 10000
},
'warm_throughput': {
'read_units_per_second': 40000,
'write_units_per_second': 20000
}
};
```
+ オンデマンドモードでは、テーブルを作成し、次の CQL 構文を使用して読み取りと書き込みの予想されるピーク容量を指定します。
```
CREATE TABLE catalog.book_awards (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank))
WITH CUSTOM_PROPERTIES = {
'capacity_mode': {
'throughput_mode': 'PAY_PER_REQUEST'
},
'warm_throughput': {
'read_units_per_second': 40000,
'write_units_per_second': 20000
}
};
```
テーブルの容量設定を確認するには、「」を参照してください[Amazon Keyspaces テーブルのウォームスループットを表示する](view-warm-throughput.md)。
------
#### [ CLI ]
1. を使用して、次のいずれかの方法を使用してウォームスループットのテーブルを作成する AWS CLI
+ プロビジョンドモードで新しいテーブルを作成し、その新規テーブルの読み取りと書き込みの予想ピークキャパシティの値を指定します。以下のステートメントは、この例です。
```
aws keyspaces create-table \
--keyspace-name 'catalog' \
--table-name 'book_awards' \
--schema-definition 'allColumns=[{name=year,type=int},{name=award,type=text},{name=rank,type=int},{name=category,type=text},{name=book_title,type=text},{name=author,type=text},{name=publisher,type=text}],partitionKeys=[{name=year},{name=award}],clusteringKeys=[{name=category,orderBy=ASC},{name=rank,orderBy=ASC}]' \
--capacity-specification throughputMode=PROVISIONED,readCapacityUnits=20000,writeCapacityUnits=10000 \
--warm-throughput-specification readUnitsPerSecond=40000,writeUnitsPerSecond=20000
```
+ オンデマンドモードで新しいテーブルを作成し、新しいテーブルの読み取りと書き込みに予想されるピーク容量値を指定します。以下のステートメントは、この例です。
```
aws keyspaces create-table \
--keyspace-name 'catalog' \
--table-name 'book_awards' \
--schema-definition 'allColumns=[{name=year,type=int},{name=award,type=text},{name=rank,type=int},{name=category,type=text},{name=book_title,type=text},{name=author,type=text},{name=publisher,type=text}],partitionKeys=[{name=year},{name=award}],clusteringKeys=[{name=category,orderBy=ASC},{name=rank,orderBy=ASC}]' \
--warmThroughputSpecification readUnitsPerSecond=40000,writeUnitsPerSecond=20000
```
1. コマンドの出力は、次の例に示すように、テーブルの ARN を返します。
```
{
"resourceArn": "arn:aws::cassandra:us-east-1:111122223333:/keyspace/catalog/table/book_awards>"
}
```
テーブルの容量設定を確認するには、「」を参照してください[Amazon Keyspaces テーブルのウォームスループットを表示する](view-warm-throughput.md)。
------
#### [ Java ]
**SDK for Java を使用して新しいテーブルを作成します。**
+ プロビジョンドモードで新しいテーブルを作成し、その新規テーブルの読み取りと書き込みの予想ピークキャパシティの値を指定します。次のコード例は、この例です。
```
import software.amazon.awssdk.services.keyspaces.KeyspacesClient;
import software.amazon.awssdk.services.keyspaces.model.*;
public class PreWarmingExample {
public static void main(String[] args) {
KeyspacesClient keyspacesClient = KeyspacesClient.builder().build();
// Define schema
List columns = Arrays.asList(
ColumnDefinition.builder().name("year").type("int").build(),
ColumnDefinition.builder().name("award").type("text").build(),
ColumnDefinition.builder().name("rank").type("int").build(),
ColumnDefinition.builder().name("category").type("text").build(),
ColumnDefinition.builder().name("book_title").type("text").build(),
ColumnDefinition.builder().name("author").type("text").build(),
ColumnDefinition.builder().name("publisher").type("text").build()
);
List partitionKeys = Arrays.asList(
PartitionKey.builder().name("year").build(),
PartitionKey.builder().name("award").build()
);
List clusteringKeys = Arrays.asList(
ClusteringKey.builder().name("category").orderBy("ASC").build(),
ClusteringKey.builder().name("rank").orderBy("ASC").build()
);
SchemaDefinition schema = SchemaDefinition.builder()
.allColumns(columns)
.partitionKeys(partitionKeys)
.clusteringKeys(clusteringKeys)
.build();
// Define capacity specification
CapacitySpecification capacitySpec = CapacitySpecification.builder()
.throughputMode(ThroughputMode.PROVISIONED)
.readCapacityUnits(20000)
.writeCapacityUnits(10000)
.build();
// Define warm throughput specification
WarmThroughputSpecification warmThroughput = WarmThroughputSpecification.builder()
.readUnitsPerSecond(40000L)
.writeUnitsPerSecond(20000L)
.build();
// Create table with PreWarming
CreateTableRequest request = CreateTableRequest.builder()
.keyspaceName("catalog")
.tableName("book_awards")
.schemaDefinition(schema)
.capacitySpecification(capacitySpec)
.warmThroughputSpecification(warmThroughput)
.build();
CreateTableResponse response = keyspacesClient.createTable(request);
System.out.println("Table created with ARN: " + response.resourceArn());
}
}
```
------
# 既存の Amazon Keyspaces テーブルのウォームスループットを増やす
コンソール、CQL、または を使用して、Amazon Keyspaces テーブルの現在のウォームスループット値を増やすことができます AWS CLI。
------
#### [ Console ]
**コンソールを使用してテーブルの事前ウォーム設定を増やす方法**
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) で Amazon Keyspaces コンソールを開きます。
1. ナビゲーションペインで、**テーブル**を選択し、更新するテーブルを選択します。
1. テーブルの**キャパシティ**タブで、**テーブルの事前ウォーミング**に進みます。
1. **テーブルの事前ウォーミング**セクションで、**編集** を選択します。
1. **テーブルの事前ウォーミングの編集**ページで、1 **秒あたりの読み取り単位と 1** **秒あたりの書き込み単位**の値を更新できます。
1. **[Save changes]** (変更の保存) をクリックします。テーブルは、指定された事前ウォーミング設定で更新されます。
------
#### [ Cassandra Query Language (CQL) ]
**CQL を使用してテーブルのウォームスループット設定を増やす**
+ `ALTER TABLE`ステートメントを使用して、テーブルのウォームスループットを向上させます。以下のステートメントは、この例です。
```
ALTER TABLE catalog.book_awards
WITH CUSTOM_PROPERTIES = {
'warm_throughput': {
'read_units_per_second': 60000,
'write_units_per_second': 30000
}
};
```
テーブルの更新された容量設定を確認するには、「」を参照してください[Amazon Keyspaces テーブルのウォームスループットを表示する](view-warm-throughput.md)。
------
#### [ CLI ]
**を使用してテーブルの事前ウォーミング設定を増やす AWS CLI**
+ テーブルのウォームスループットを増やすには、 `update-table` コマンドを使用できます。以下のステートメントは、この例です。
```
aws keyspaces update-table \
--keyspace-name 'catalog' \
--table-name 'book_awards' \
--warmThroughputSpecification readUnitsPerSecond=60000,writeUnitsPerSecond=30000
```
テーブルの更新された容量設定を確認するには、「」を参照してください[Amazon Keyspaces テーブルのウォームスループットを表示する](view-warm-throughput.md)。
------
#### [ Java ]
**SDK for Java を使用してテーブルの事前ウォーミング設定を更新します。**
+ テーブルのウォームスループット設定を更新します。次のコード例は、この例です。
```
import software.amazon.awssdk.services.keyspaces.KeyspacesClient;
import software.amazon.awssdk.services.keyspaces.model.*;
public class UpdatePreWarmingExample {
public static void main(String[] args) {
KeyspacesClient keyspacesClient = KeyspacesClient.builder().build();
// Define new warm throughput specification
WarmThroughputSpecification warmThroughput = WarmThroughputSpecification.builder()
.readUnitsPerSecond(60000L)
.writeUnitsPerSecond(30000L)
.build();
// Update table with new PreWarming settings
UpdateTableRequest request = UpdateTableRequest.builder()
.keyspaceName("catalog")
.tableName("book_awards")
.warmThroughputSpecification(warmThroughput)
.build();
UpdateTableResponse response = keyspacesClient.updateTable(request);
System.out.println("Table update requested: " + response.resourceArn());
}
}
```
------
# Amazon Keyspaces テーブルのウォームスループットを表示する
コンソール、CQL、または を使用して、Amazon Keyspaces テーブルの現在のウォームスループット値を表示できます AWS CLI。
------
#### [ Console ]
**コンソールを使用してテーブルの事前ウォーミング設定を表示する方法。**
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) で Amazon Keyspaces コンソールを開きます。
1. ナビゲーションペインで、**テーブル**を選択し、確認するテーブルを選択します。
1. テーブルの**キャパシティ**タブで、**テーブルの事前ウォーミング**に進みます。
------
#### [ Cassandra Query Language (CQL) ]
**CQL を使用してテーブルのウォームスループット設定を表示する**
+ テーブルのウォームスループット設定を表示するには、次の CQL ステートメントを使用できます。
```
SELECT custom_properties
FROM system_schema_mcs.tables
WHERE keyspace_name='catalog' and table_name='book_awards';
// Output:
...
custom_properties
----------------------------------------------------------------------------------
{
'warm_throughput':
{
'read_units_per_second': '40000',
'write_units_per_second': '20000',
'status': 'AVAILABLE'
}
}
...
```
------
#### [ CLI ]
**を使用してテーブルのウォームスループット設定を表示する AWS CLI**
+ 次の例に示すように、 `get-table` コマンドを使用してテーブルのウォームスループット設定を表示できます。
```
aws keyspaces get-table \
--keyspace-name 'catalog' \
--table-name 'book_awards'
```
以下は、プロビジョニングモードの単一リージョンテーブルの `get-table` コマンドの出力例を示しています。
```
{
"keyspaceName": "catalog",
"tableName": "book_awards",
... Existing Fields ...,
"capacitySpecificationSummary": {
"throughputMode": "PROVISIONED",
"readCapacityUnits": 20000,
"writeCapacityUnits": 10000
},
"warmThroughputSpecificationSummary": {
"readUnitsPerSecond": 40000,
"writeUnitsPerSecond": 20000,
"status": "AVAILABLE"
}
}
```
オンデマンドモードの単一リージョンテーブルの出力例を次に示します。
```
{
"keyspaceName": "catalog",
"tableName": "book_awards_ondemand",
... Existing Fields ...,
"capacitySpecification": {
"throughputMode": "PAY_PER_REQUEST"
},
"warmThroughputSpecificationSummary": {
"readUnitsPerSecond": 40000,
"writeUnitsPerSecond": 20000,
"status": "AVAILABLE"
}
}
```
------
#### [ Java ]
**SDK for Java を使用して、テーブルの事前ウォーミング設定を読み取ります。**
+ を使用してテーブルのウォームスループット値を読み取ります`get-table`。次のコード例は、この例です。
```
import software.amazon.awssdk.services.keyspaces.KeyspacesClient;
import software.amazon.awssdk.services.keyspaces.model.*;
public class GetTableWithPreWarmingExample {
public static void main(String[] args) {
KeyspacesClient keyspacesClient = KeyspacesClient.builder().build();
// Get table details including PreWarming specification
GetTableRequest request = GetTableRequest.builder()
.keyspaceName("catalog")
.tableName("book_awards")
.build();
GetTableResponse response = keyspacesClient.getTable(request);
// Access PreWarming details
if (response.warmThroughputSpecification() != null) {
WarmThroughputSpecificationSummary warmThroughputSummary = response.warmThroughputSpecification();
System.out.println("PreWarming Status: " + warmThroughputSummary.status());
System.out.println("Read Units: " + warmThroughputSummary.readUnitsPerSecond());
System.out.println("Write Units: " + warmThroughputSummary.writeUnitsPerSecond());
// Check if PreWarming is active
if (warmThroughputSummary.status().equals("AVAILABLE")) {
System.out.println("Table is fully pre-warmed and ready for high throughput");
} else if (warmThroughputSummary.status().equals("UPDATING")) {
System.out.println("Table PreWarming is currently being updated");
}
} else {
System.out.println("Table does not have PreWarming enabled");
}
}
}
```
------
# Amazon CloudWatch を使用して事前ウォーミングされたテーブルのパフォーマンスをモニタリングする
Amazon Keyspaces の事前ウォーミングでは新しい CloudWatch メトリクスは導入されませんが、既存の Amazon Keyspaces メトリクスを使用して事前ウォーミングされたテーブルのパフォーマンスをモニタリングできます。
SuccessfulRequestLatency
このメトリクスをモニタリングして、事前ウォーミングされたテーブルが予想されるレイテンシーでリクエストを処理していることを確認します。
WriteThrottleEvents と ReadThrottleEvents
これらのメトリクスは、適切に事前ウォーミングされたテーブルでは低いままにする必要があります。事前ウォーミングにもかかわらず容量不足エラーが発生した場合は、ウォームスループット値を調整する必要がある場合があります。
ConsumedReadCapacityUnits と ConsumedWriteCapacityUnits
これらのメトリクスは容量の実際の消費量を示しています。これは、事前ウォーミング設定が適切かどうかを検証するのに役立ちます。
ProvisionedReadCapacityUnits と ProvisionedWriteCapacityUnits
プロビジョニングされたテーブルの場合、これらのメトリクスには現在割り当てられている容量が表示されます。
これらのメトリクスは、CloudWatch コンソールで表示することも、CloudWatch API を使用してクエリすることもできます。詳細については、「[Amazon CloudWatch による Amazon Keyspaces のモニタリング](monitoring-cloudwatch.md)」を参照してください。
# Amazon Keyspaces 自動スケーリングでスループットキャパシティを自動的に管理する
多くのデータベースワークロードは本質的に循環的なものであり、そうでない場合は前もって予測することは困難です。例えば、日中の時間帯に大部分のユーザーがアクティブなソーシャルネットワーキングアプリがあるとします。データベースは日中のアクティビティを処理できる必要がありますが、夜間のスループットに同じレベルは必要ありません。
別の例としては、急速に導入された新しいモバイルゲームアプリが挙げられます。ゲームの人気があまりに高まると、利用可能なデータベースリソースを超過し、パフォーマンスが低下して顧客が不満を感じるようになります。この種のワークロードでは多くの場合、手動介入によってデータベースリソースを使用レベルに応じて上下させる必要があります。
Amazon Keyspaces (Apache Cassandra 向け) は、実際のアプリケーショントラフィックに応じてスループットキャパシティを自動的に調整するので、可変ワークロードに対するスループットキャパシティの効率的なプロビジョニングに役立ちます。Amazon Keyspaces では、Applicatino Auto Scaling サービスを使用して、ユーザーに代わってテーブルの読み取りキャパシティと書き込みキャパシティの増減を行います。アプリケーションオートスケーリングの詳細については、[「Application Auto Scaling User Guide」](https://docs.aws.amazon.com/autoscaling/application/userguide/)(アプリケーションオートスケーリングユーザーガイド) を参照してください。
**注記**
Amazon Keyspaces のオートスケーリングの簡単な使用方法については「[Amazon Keyspaces の自動スケーリングポリシーを設定および更新する](autoscaling.configure.md)」を参照してください。
## Amazon Keyspaces オートスケーリングの仕組み
次の図は、Amazon Keyspaces オートスケーリングによるテーブルのスループットキャパシティ管理の管理方法について、高レベルの概要を示しています。
![\[ユーザーが Amazon Keyspaces のテーブルに変更を加えたときに関係するさまざまなサービスを示した図。該当するサービスは Amazon CloudWatch、Amazon SNS、Application Auto Scaling です。Application Auto Scaling が ALTER TABLE ステートメントを発行して、ユーザーの読み取りまたは書き込みの使用量に基づいてキャパシティを変更します。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/keyspaces_auto-scaling.png)
テーブルのオートスケーリングを有効にするには、*スケーリングポリシー*を作成します。スケーリングポリシーは、テーブルの読み込みキャパシティと書き込みキャパシティ (またはそのいずれか) およびプロビジョンドキャパシティユニット設定をスケーリングするかどうかを指定するものです。
スケーリングポリシーにより*ターゲット使用率*も定義されます。ターゲット使用率は、プロビジョンドキャパシティユニットに対する消費キャパシティユニットの割合をパーセンテージで示したものです。オートスケーリングでは、*ターゲット追跡*アルゴリズムを使用して、実際のワークロードに応じてテーブルのプロビジョンドスループットを上下に調整します。これにより実際のキャパシティ使用率が、ターゲット使用率またはその付近で維持されます。
読み取りおよび書き込みキャパシティに対して、オートスケーリングのターゲット使用率の値を 20%～90% の範囲で設定できます。ターゲット使用率のデフォルト値は 70% です。トラフィックが急速に変化し、キャパシティのスケールアップをすばやく開始したい場合は、ターゲット使用率の値を低く設定できます。アプリケーショントラフィックの変化が遅く、スループットのコストを削減したい場合は、ターゲット使用率の値を高く設定することもできます。
自動スケーリングポリシーの詳細については、「[Application Auto Scaling ユーザーガイド**](https://docs.aws.amazon.com/autoscaling/application/userguide/)」の「[Target tracking scaling policies for Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)」を参照してください。
スケーリングポリシーを作成すると、Amazon Keyspaces が自動的に Amazon CloudWatch アラームのペアを 2 つ作成します。各ペアは、プロビジョンドスループット設定と消費スループット設定の上下の境界を示します。CloudWatch アラームは、テーブルの実際の使用率が一定期間ターゲット使用率を逸脱したときにトリガーされます。Amazon CloudWatch の詳細については、[「Amazon CloudWatch ユーザーガイド」](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)を参照してください。
いずれかの CloudWatch アラームがトリガーされると、Amazon Simple Notification Service (Amazon SNS) により通知が送信されます (有効にしている場合)。次に、CloudWatch アラームにより アプリケーションオートスケーリングが呼び出されてスケーリングポリシーが評価されます。これにより、Amazon Keyspaces に Alter Table リクエストが発行されて、テーブルのプロビジョンドキャパシティが必要に応じて調整されます。Amazon SNS 通知の詳細については、[「Setting up Amazon SNS notifications」](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)(Amazon SNS 通知の設定) を参照してください。
Amazon Keyspaces は Alter Table リクエストを処理してテーブルのプロビジョンドスループット性能を動的に増減し、ターゲット使用率に近づけます。
**注記**
Amazon Keyspaces の自動スケーリングは、プロビジョニング済みスループットの設定を、実際のワークロードが上回った (または下回った) 状態が数分間続いた場合にのみ変更します。 ターゲットトラッキングアルゴリズムはターゲット使用率を選択した値の付近に長期に渡って維持しようとします。アクティビティの急激かつ短時間の上昇は、テーブルに組み込まれたバーストキャパシティで対応されます。
## マルチリージョンテーブルに対する自動スケーリングの仕組み
プロビジョンドキャパシティモードのすべての AWS リージョン マルチリージョンテーブルで、すべてのテーブルレプリカに十分な読み取りおよび書き込みキャパシティを常に確保するには、Amazon Keyspaces 自動スケーリングを設定することをお勧めします。
プロビジョンドモードのマルチリージョンテーブルで自動スケーリングを使用する場合、テーブルレプリカ単体の自動スケーリングを無効にすることはできません。ただし、テーブルの読み取りの自動スケーリング設定はリージョンごとに調整できます。例えば、テーブルのレプリケート先のリージョンごとに、読み取りキャパシティと読み取り自動スケーリングの設定を変えることができます。
指定したリージョンのテーブルレプリカに対して設定した読み取り自動スケーリング設定は、テーブル全般の自動スケーリング設定よりも優先されます。一方で、書き込みキャパシティは、すべてのリージョンで書き込みをレプリケートするのに十分なキャパシティを確保するため、すべてのテーブルレプリカ間で同期させておく必要があります。
Amazon Keyspaces の自動スケーリングでは、各 AWS リージョン のテーブルにプロビジョニングされたキャパシティを、そのリージョンの使用実績に応じて個別に更新します。その結果、自動スケーリングが有効になっている場合は、マルチリージョンテーブルのリージョンごとに、プロビジョニング済みキャパシティが異なる可能性があります。
マルチリージョンテーブルとそのレプリカの自動スケーリング設定は、Amazon Keyspaces コンソール、API AWS CLI、または CQL を使用して設定できます。マルチリージョンテーブルの自動スケーリング設定を作成および更新する方法については、「[Amazon Keyspaces でマルチリージョンテーブルのプロビジョンドキャパシティと自動スケーリングの設定を更新する](tables-mrr-autoscaling.md)」を参照してください。
**注記**
マルチリージョンテーブルで自動スケーリングを使用する場合は、常に Amazon Keyspaces API オペレーションを使用して自動スケーリングを設定する必要があります。Application Auto Scaling API オペレーションを直接使用して自動スケーリング設定を構成する場合、マルチリージョンテーブル AWS リージョン の を指定することはできません。そのため、サポート対象外の設定になってしまうおそれがあります。
## 使用に関する注意事項
Amazon Keyspaces オートスケーリングの使用を開始する前に、以下を確認する必要があります。
+ Amazon Keyspaces 自動スケーリングは、中東 (UAE) リージョンでは利用できません。
+ Amazon Keyspaces オートスケーリングでは、スケーリングポリシーに従って、読み込みキャパシティや書き込みキャパシティを必要に応じて増加させることができます。[Amazon Keyspaces (Apache Cassandra 向け) のクォータ](quotas.md) で説明されているように、すべての Amazon Keyspaces クォータは有効です。
+ Amazon Keyspaces オートスケーリングにより、プロビジョンドスループット設定を手動で変更できなくなることはありません。これらの手動調整は、スケーリングポリシーにアタッチされている既存の CloudWatch アラームに影響しません。
+ コンソールを使用してプロビジョンドスループット性能でテーブルを作成する場合、Amazon Keyspaces オートスケーリングはデフォルトで有効になります。オートスケーリングの設定はいつでも変更できます。詳細については、「[テーブルの Amazon Keyspaces 自動スケーリングを無効にする](autoscaling.turnoff.md)」を参照してください。
+ CloudFormation を使用してスケーリングポリシーを作成する場合は、スタックがスタックテンプレートと同期 CloudFormation するように、 からスケーリングポリシーを管理する必要があります。Amazon Keyspaces からスケーリングポリシーを変更すると、 CloudFormation スタックがリセットされると、スタックテンプレートの元の値で上書きされます。
+ CloudTrail を使用して Amazon Keyspaces のオートスケーリングを監視する場合、設定検証プロセスの一部として、アプリケーションオートスケーリングによって行われたコールのアラートが表示されることがあります。検証チェックのための `application-autoscaling.amazonaws.com` が含まれている `invokedBy` フィールドを使用すれば、これらのアラートを除外できます。
# Amazon Keyspaces の自動スケーリングポリシーを設定および更新する
コンソール、CQL、または AWS Command Line Interface (AWS CLI) を使用して、新規および既存のテーブルの Amazon Keyspaces 自動スケーリングを設定できます。自動スケーリングの設定変更や無効化を行うこともできます。
スケールインおよびスケールアウトのクールダウン時間の設定など、より高度な機能については、CQL または AWS CLI を使用して Amazon Keyspaces スケーリングポリシーを管理することをお勧めします。
**Topics**
+ [Amazon Keyspaces の自動スケーリング用のアクセス許可を設定する](autoscaling.permissions.md)
+ [自動スケーリングを有効にして新規テーブルを作成する](autoscaling.createTable.md)
+ [既存のテーブルに対して自動スケーリングを設定する](autoscaling.configureTable.md)
+ [テーブルの Amazon Keyspaces 自動スケーリングの設定を表示する](autoscaling.viewPolicy.md)
+ [テーブルの Amazon Keyspaces 自動スケーリングを無効にする](autoscaling.turnoff.md)
+ [Amazon CloudWatch で Amazon Keyspaces テーブルの自動スケーリングアクティビティを表示する](autoscaling.activity.md)
# Amazon Keyspaces の自動スケーリング用のアクセス許可を設定する
まず、自動スケーリング設定を作成し、管理するための適切なアクセス許可がプリンシパルに与えられていることを確認してください。 AWS Identity and Access Management (IAM) では、Amazon Keyspaces スケーリングポリシーを管理するために AWS マネージドポリシー`AmazonKeyspacesFullAccess`が必要です。
**重要**
テーブルの自動スケーリングを無効にするには、`application-autoscaling:*` アクセス許可が必要です。テーブルを削除するには、その前にテーブルの自動スケーリングを無効にしておく必要があります。
Amazon Keyspaces コンソールへのアクセスと Amazon Keyspaces の自動スケーリングで使用する IAM ユーザーまたはロールを設定するには、次のポリシーを追加します。
**`AmazonKeyspacesFullAccess` ポリシーをアタッチするには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。
1. IAM コンソールダッシュボードで **[ユーザー]** を選択して、リストから IAM ユーザーまたはロールを選択します。
1. [**Summary (概要)**] ページで、[**Add permissions (許可の追加)**] を選択します。
1. **[Attach existing policies directly (既存のポリシーを直接アタッチする)**] を選択します。
1. ポリシーリストから [**AmazonKeyspacesFullAccess**] を選択し、次に [**Next: Review (次へ: 確認)**] を選択します。
1. [**Add permissions (許可の追加)**] を選択します。
# 自動スケーリングを有効にして新規テーブルを作成する
新しい Amazon Keyspaces テーブルの作成時に、テーブルの書き込みキャパシティまたは読み取りキャパシティの自動スケーリングを自動的に有効にすることができます。その場合は、Amazon Keyspaces が自動的に Application Auto Scaling と通信してテーブルをスケーラブルターゲットとして登録し、プロビジョニング済みの書き込みキャパシティまたは読み取りキャパシティを調整します。
マルチリージョンテーブルを作成し、テーブルのレプリカごとに異なる自動スケーリング設定を行う方法については、「[Amazon Keyspaces で自動スケーリングが有効なプロビジョンドモードのマルチリージョンテーブルを作成する](tables-mrr-create-provisioned.md)」を参照してください。
**注記**
Amazon Keyspaces の自動スケーリングでは、ユーザーに代わって自動スケーリングアクションを実行するサービスリンクロール (`AWSServiceRoleForApplicationAutoScaling_CassandraTable`) の存在が必要になります。このロールは自動的に作成されます。詳細については、「[Amazon Keyspaces のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
------
#### [ Console ]
**自動スケーリングが有効な新規テーブルをコンソールで作成する**
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) で Amazon Keyspaces コンソールを開きます。
1. ナビゲーションペインで [**Tables]** (テーブル) を選択して、[**Create table (テーブルの作成)**] を選択します。
1. [**Table details (テーブルの詳細)**] セクションの [**Create table (テーブルの作成)**] ページで、キースペースを選択し、新しいテーブルに名前を付けます。
1. **[列]** セクションで、テーブルのスキーマを作成します。
1. **[プライマリキー]** セクションで、テーブルのプライマリキーを定義し、オプションでクラスタリング列を選択します。
1. [**Table settings (テーブルの設定)**] セクションで、[**Customize settings (設定のカスタマイズ)**] を選択します。
1. [**Read/write capacity settings (読み取り/書き込みキャパシティの設定)**] に進みます。
1. [**Capacity mode (キャパシティモード)**] で、[**Provisioned (プロビジョン)**] を選択します。
1. [**Read capacity]** (読み取りキャパシティ) セクションで、[**Scale automatically (自動スケーリング)**] が選択されているか確認します。
このステップでは、テーブルの読み取りキャパシティユニットの最小値と最大値、およびターゲット使用率を選択します。
+ **最小キャパシティユニット** — テーブルをいつでもすぐにサポートできる状態にするために、最小レベルのスループット値を入力します。この値は、1 から、アカウントの秒単位の最大スループットクォータ (デフォルトは 40,000) までの範囲でなければなりません。
+ **最大キャパシティユニット** — テーブルに対してプロビジョニングするスループットの最大量を入力します。この値は、1 から、アカウントの秒単位の最大スループットクォータ (デフォルトは 40,000) までの範囲でなければなりません。
+ **ターゲット使用率**— ターゲット使用率を 20%～90% の範囲で入力します。定義したターゲット使用率をトラフィックが上回ると、キャパシティが自動的に増加されます。定義したターゲットをトラフィックが下回ると、再び容量が自動的に減少されます。
**注記**
アカウントのデフォルトクォータの詳細およびクォータを引き上げる方法については、「[Amazon Keyspaces (Apache Cassandra 向け) のクォータ](quotas.md)」を参照してください。
1. **[書き込みキャパシティ]** セクションで、前の手順で定義した読み取りキャパシティと同じ設定を選択するか、またはキャパシティの値を手動で設定します。
1. [**Create table (テーブルの作成)**] を選択します。指定した自動スケーリングパラメータを使用してテーブルが作成されます。
------
#### [ Cassandra Query Language (CQL) ]
**Amazon Keyspaces の自動スケーリングが有効な新規テーブルを CQL を使用して作成する**
テーブルの自動スケーリング設定をプログラムによって行うには、`AUTOSCALING_SETTINGS` ステートメントに Amazon Keyspaces 自動スケーリングのパラメータを指定します。これらのパラメータでは、テーブルのプロビジョニング済みスループットを調整するように Amazon Keyspaces に指示する条件を定義し、追加で実行するアクションがあれば、それらも任意で定義します。この例では、*mytable* の自動スケーリング設定を定義します。
ポリシーには、次の要素が含まれます。
+ `AUTOSCALING_SETTINGS` – スループットキャパシティの自動調整を Amazon Keyspaces に許可するかどうかを指定します。以下の値が必須です。
+ `provisioned_write_capacity_autoscaling_update`:
+ `minimum_units`
+ `maximum_units`
+ `provisioned_read_capacity_autoscaling_update`:
+ `minimum_units`
+ `maximum_units`
+ `scaling_policy` – Amazon Keyspaces はターゲット追跡ポリシーに対応しています。ターゲット追跡ポリシーを定義するには、次のパラメータを設定します。
+ `target_value` — Amazon Keyspaces の自動スケーリングでは、プロビジョニング済みのキャパシティに占める実際のキャパシティ消費の割合が、この値と同じか近い値で維持されます。`target_value` をパーセンテージとして定義します。
+ `disableScaleIn`: (オプション) テーブルに対して `scale-in` が無効か有効かを指定する `boolean`。このパラメータは、デフォルトでは無効になっています。`scale-in` を有効にするには、`boolean` 値を `FALSE` に設定します。その場合は、テーブルのキャパシティが自動的にスケールダウンされます。
+ `scale_out_cooldown` — スケールアウトアクティビティでテーブルのプロビジョンドスループットを増加させます。スケールアウトアクティビティのクールダウン期間を追加するには、`scale_out_cooldown` の値を秒単位で指定します。値を指定しない場合、デフォルト値は 0 です。ターゲット追跡とクールダウン期間の詳細については、「Application Auto Scaling ユーザーガイド**」の「[ターゲット追跡スケーリングポリシー](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)」を参照してください。
+ `scale_in_cooldown` — スケールインアクティビティでテーブルのプロビジョンドスループットを減少させます。スケールインアクティビティのクールダウン期間を追加するには、`scale_in_cooldown` の値を秒単位で指定します。値を指定しない場合、デフォルト値は 0 です。ターゲット追跡とクールダウン期間の詳細については、「Application Auto Scaling ユーザーガイド**」の「[ターゲット追跡スケーリングポリシー](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)」を参照してください。
**注記**
`target_value` がどのように機能するかをさらに理解するために、書き込み容量単位が 200 で、プロビジョンされたスループット設定を持つテーブルがあるとします。このテーブルのスケーリングポリシーを作成することにしました。`target_value` は 70% です。
ここで、実際の書き込みスループットが 150 容量単位になるように、テーブルへの書き込みトラフィックを駆動し始めたとします。消費とプロビジョンの比率は現在 (150/200)、つまり 75% です。この割合は目標値を上回っているため、自動スケーリングはプロビジョニング済みの書き込みキャパシティを 215 に増やします。これで、割合が (150/215)、つまり 69.77% になります。これは、`target_value` に可能な限り近く、なおかつ上回らない値です。
*mytable* では、読み取りキャパシティと書き込みキャパシティの両方の `TargetValue` を 50% に設定します。Amazon Keyspaces の自動スケーリングは、テーブルのプロビジョニング済みスループットを 5～10 キャパシティユニットの範囲内で調整し、プロビジョニング済みキャパシティに占める実際のキャパシティ消費の割合が 50%、または 50% に近くなるようにします。読み取りキャパシティについては、`ScaleOutCooldown` と `ScaleInCooldown` の値を 60 秒に設定します。
次のステートメントを使用して、自動スケーリングを有効にした新しい Amazon Keyspaces テーブルを作成できます。
```
CREATE TABLE mykeyspace.mytable(pk int, ck int, PRIMARY KEY (pk, ck))
WITH CUSTOM_PROPERTIES = {
'capacity_mode': {
'throughput_mode': 'PROVISIONED',
'read_capacity_units': 1,
'write_capacity_units': 1
}
} AND AUTOSCALING_SETTINGS = {
'provisioned_write_capacity_autoscaling_update': {
'maximum_units': 10,
'minimum_units': 5,
'scaling_policy': {
'target_tracking_scaling_policy_configuration': {
'target_value': 50
}
}
},
'provisioned_read_capacity_autoscaling_update': {
'maximum_units': 10,
'minimum_units': 5,
'scaling_policy': {
'target_tracking_scaling_policy_configuration': {
'target_value': 50,
'scale_in_cooldown': 60,
'scale_out_cooldown': 60
}
}
}
};
```
------
#### [ CLI ]
**を使用して Amazon Keyspaces 自動スケーリングで新しいテーブルを作成する AWS CLI**
テーブルの自動スケーリング設定をプログラムによって行うには、`autoScalingSpecification` アクションに Amazon Keyspaces 自動スケーリングのパラメータを指定します。これらのパラメータでは、テーブルのプロビジョニング済みスループットを調整するように Amazon Keyspaces に指示する条件を定義し、追加で実行するアクションがあれば、それらも任意で定義します。この例では、*mytable* の自動スケーリング設定を定義します。
ポリシーには、次の要素が含まれます。
+ `autoScalingSpecification` – キャパシティスループットの自動調整を Amazon Keyspaces に許可するかどうかを指定します。読み取りキャパシティと書き込みキャパシティに対して別々に自動スケーリングを有効にすることができます。`autoScalingSpecification` の次のパラメータを指定する必要があります。
+ `writeCapacityAutoScaling` – 最大および最小の書き込みキャパシティユニット。
+ `readCapacityAutoScaling` – 最大および最小の読み取りキャパシティユニット。
+ `scalingPolicy` – Amazon Keyspaces はターゲット追跡ポリシーに対応しています。ターゲット追跡ポリシーを定義するには、次のパラメータを設定します。
+ `targetValue` — Amazon Keyspaces の自動スケーリングでは、プロビジョニング済みのキャパシティに占める実際のキャパシティ消費の割合が、この値と同じか近い値で維持されます。`targetValue` をパーセンテージとして定義します。
+ `disableScaleIn`: (オプション) テーブルに対して `scale-in` が無効か有効かを指定する `boolean`。このパラメータは、デフォルトでは無効になっています。`scale-in` を有効にするには、`boolean` 値を `FALSE` に設定します。その場合は、テーブルのキャパシティが自動的にスケールダウンされます。
+ `scaleOutCooldown` — スケールアウトアクティビティでテーブルのプロビジョンドスループットを増加させます。スケールアウトアクティビティのクールダウン期間を追加するには、`ScaleOutCooldown` の値を秒単位で指定します。デフォルト値は 0 です。ターゲット追跡とクールダウン期間の詳細については、「Application Auto Scaling ユーザーガイド**」の「[ターゲット追跡スケーリングポリシー](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)」を参照してください。
+ `scaleInCooldown` — スケールインアクティビティでテーブルのプロビジョンドスループットを減少させます。スケールインアクティビティのクールダウン期間を追加するには、`ScaleInCooldown` の値を秒単位で指定します。デフォルト値は 0 です。ターゲット追跡とクールダウン期間の詳細については、「Application Auto Scaling ユーザーガイド**」の「[ターゲット追跡スケーリングポリシー](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)」を参照してください。
**注記**
`TargetValue` がどのように機能するかをさらに理解するために、書き込み容量単位が 200 で、プロビジョンされたスループット設定を持つテーブルがあるとします。このテーブルのスケーリングポリシーを作成することにしました。`TargetValue` は 70% です。
ここで、実際の書き込みスループットが 150 容量単位になるように、テーブルへの書き込みトラフィックを駆動し始めたとします。消費とプロビジョンの比率は現在 (150/200)、つまり 75% です。この割合は目標値を上回っているため、自動スケーリングはプロビジョニング済みの書き込みキャパシティを 215 に増やします。これで、割合が (150/215)、つまり 69.77% になります。これは、`TargetValue` に可能な限り近く、なおかつ上回らない値です。
*mytable* では、読み取りキャパシティと書き込みキャパシティの両方の `TargetValue` を 50% に設定します。Amazon Keyspaces の自動スケーリングは、テーブルのプロビジョニング済みスループットを 5～10 キャパシティユニットの範囲内で調整し、プロビジョニング済みキャパシティに占める実際のキャパシティ消費の割合が 50%、または 50% に近くなるようにします。読み取りキャパシティについては、`ScaleOutCooldown` と `ScaleInCooldown` の値を 60 秒に設定します。
テーブルの作成時に複雑な自動スケーリング設定を行う場合は、JSON ファイルから自動スケーリング設定を読み込むと便利です。次の例を使用するには、サンプル JSON ファイルを収録した [auto-scaling.zip](samples/auto-scaling.zip) をダウンロードし、`auto-scaling.json` を抽出します。ファイルのパスを書き留めておいてください。この例では、JSON ファイルは現在のディレクトリにあります。さまざまなファイルパスオプションについては、「[ファイルからパラメーターを読み込む方法](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-file.html#cli-usage-parameters-file-how)」を参照してください。
```
aws keyspaces create-table --keyspace-name mykeyspace --table-name mytable
\ --schema-definition 'allColumns=[{name=pk,type=int},{name=ck,type=int}],partitionKeys=[{name=pk},{name=ck}]'
\ --capacity-specification throughputMode=PROVISIONED,readCapacityUnits=1,writeCapacityUnits=1
\ --auto-scaling-specification file://auto-scaling.json
```
------
# 既存のテーブルに対して自動スケーリングを設定する
既存の Amazon Keyspaces テーブルを更新して、そのテーブルの書き込みキャパシティまたは読み取りキャパシティに対して自動スケーリングを有効にすることができます。現時点でオンデマンドキャパシティモードのテーブルを更新する場合は、まずテーブルのキャパシティモードをプロビジョドキャパシティモードに変更する必要があります。
マルチリージョンテーブルの自動スケーリング設定を更新する方法については、「[Amazon Keyspaces でマルチリージョンテーブルのプロビジョンドキャパシティと自動スケーリングの設定を更新する](tables-mrr-autoscaling.md)」を参照してください。
Amazon Keyspaces の自動スケーリングでは、ユーザーに代わって自動スケーリングアクションを実行するサービスリンクロール (`AWSServiceRoleForApplicationAutoScaling_CassandraTable`) の存在が必要になります。このロールは自動的に作成されます。詳細については、「[Amazon Keyspaces のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
------
#### [ Console ]
**既存のテーブルに対して Amazon Keyspaces の自動スケーリングを設定する**
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) で Amazon Keyspaces コンソールを開きます。
1. 使用するテーブルを選択してから、**[キャパシティ]** タブを選択します。
1. **[キャパシティ設定]** セクションで、**[編集]** を選択します。
1. **[キャパシティモード]** で、テーブルが **[プロビジョンド]** キャパシティモードを使用していることを確認します。
1. [**Scale automatically (自動スケーリング)**] を選択し、[自動スケーリングを有効にして新規テーブルを作成する](autoscaling.createTable.md) のステップ 6 を参照して読み取り/書き込みキャパシティを編集します。
1. 自動スケーリング設定が定義されたら、[**Save (保存)**] を選択します。
------
#### [ Cassandra Query Language (CQL) ]
**CQL を使用して既存のテーブルに Amazon Keyspaces 自動スケーリングを設定する**
既存の Amazon Keyspaces テーブルに対して `ALTER TABLE` ステートメントを使用して、そのテーブルの書き込みキャパシティまたは読み取りキャパシティの自動スケーリングを設定できます。現時点でオンデマンドキャパシティモードのテーブルを更新する場合は、`capacity_mode` を provisioned (プロビジョンド) に設定する必要があります。テーブルが既にプロビジョンドキャパシティモードになっている場合、このフィールドは省略できます。
次の例のステートメントは、オンデマンドキャパシティモードのテーブル *mytable* を更新します。このステートメントは、テーブルのキャパシティモードを、自動スケーリングが有効なプロビジョンドモードに変更します。
書き込みキャパシティは、5～10 のキャパシティユニット範囲内で、50% の目標値が設定されています。読み取りキャパシティも、5～10 のキャパシティユニット範囲内で、50% の目標値が設定されています。読み取りキャパシティについては、`scale_out_cooldown` と `scale_in_cooldown` の値を 60 秒に設定します。
```
ALTER TABLE mykeyspace.mytable
WITH CUSTOM_PROPERTIES = {
'capacity_mode': {
'throughput_mode': 'PROVISIONED',
'read_capacity_units': 1,
'write_capacity_units': 1
}
} AND AUTOSCALING_SETTINGS = {
'provisioned_write_capacity_autoscaling_update': {
'maximum_units': 10,
'minimum_units': 5,
'scaling_policy': {
'target_tracking_scaling_policy_configuration': {
'target_value': 50
}
}
},
'provisioned_read_capacity_autoscaling_update': {
'maximum_units': 10,
'minimum_units': 5,
'scaling_policy': {
'target_tracking_scaling_policy_configuration': {
'target_value': 50,
'scale_in_cooldown': 60,
'scale_out_cooldown': 60
}
}
}
};
```
------
#### [ CLI ]
**を使用して Amazon Keyspaces 自動スケーリングで既存のテーブルを設定する AWS CLI**
既存の Amazon Keyspaces テーブルに対して `UpdateTable` オペレーションを使用して、そのテーブルの書き込みキャパシティまたは読み取りキャパシティに対して自動スケーリングを有効にすることができます。
次のコマンドを使用して、既存のテーブルに対して Amazon Keyspaces の自動スケーリングを有効にすることができます。テーブルの自動スケーリング設定は JSON ファイルから読み込まれます。次の例を使用するには、サンプル JSON ファイルを収録した [auto-scaling.zip](samples/auto-scaling.zip) をダウンロードし、`auto-scaling.json` を抽出します。ファイルのパスを書き留めておいてください。この例では、JSON ファイルは現在のディレクトリにあります。さまざまなファイルパスオプションについては、「[ファイルからパラメーターを読み込む方法](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-file.html#cli-usage-parameters-file-how)」を参照してください。
次の例で使用されている自動スケーリング設定の詳細については、「[自動スケーリングを有効にして新規テーブルを作成する](autoscaling.createTable.md)」を参照してください。
```
aws keyspaces update-table --keyspace-name mykeyspace --table-name mytable
\ --capacity-specification throughputMode=PROVISIONED,readCapacityUnits=1,writeCapacityUnits=1
\ --auto-scaling-specification file://auto-scaling.json
```
------
# テーブルの Amazon Keyspaces 自動スケーリングの設定を表示する
コンソール、CQL、または を使用して、テーブルの Amazon Keyspaces 自動スケーリング設定 AWS CLI を表示および更新できます。
------
#### [ Console ]
****
**コンソールを使用して自動スケーリング設定を表示する**
1. 表示対象のテーブルを選択し、**[キャパシティ]** タブに移動します。
1. **[キャパシティ設定]** セクションで、**[編集]** を選択します。**[読み込みキャパシティ]** セクションまたは **[書き込みキャパシティ]** セクションで設定を変更できます。これらの設定の詳細については、「[自動スケーリングを有効にして新規テーブルを作成する](autoscaling.createTable.md)」をご参照ください。
------
#### [ Cassandra Query Language (CQL) ]
**CQL を使用してテーブルの Amazon Keyspaces 自動スケーリングポリシーを表示する**
テーブルの自動スケーリング設定の詳細を表示するには、次のコマンドを使用します。
```
SELECT * FROM system_schema_mcs.autoscaling WHERE keyspace_name = 'mykeyspace' AND table_name = 'mytable';
```
このコマンドの出力は次のようになります。
```
keyspace_name | table_name | provisioned_read_capacity_autoscaling_update | provisioned_write_capacity_autoscaling_update
---------------+------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
mykeyspace | mytable | {'minimum_units': 5, 'maximum_units': 10, 'scaling_policy': {'target_tracking_scaling_policy_configuration': {'scale_out_cooldown': 60, 'disable_scale_in': false, 'target_value': 50, 'scale_in_cooldown': 60}}} | {'minimum_units': 5, 'maximum_units': 10, 'scaling_policy': {'target_tracking_scaling_policy_configuration': {'scale_out_cooldown': 0, 'disable_scale_in': false, 'target_value': 50, 'scale_in_cooldown': 0}}}
```
------
#### [ CLI ]
**を使用してテーブルの Amazon Keyspaces 自動スケーリングポリシーを表示する AWS CLI**
テーブルの自動スケーリング設定を表示するには、`get-table-auto-scaling-settings` オペレーションを使用します。次の CLI コマンドは一例です。
```
aws keyspaces get-table-auto-scaling-settings --keyspace-name mykeyspace --table-name mytable
```
このコマンドの出力は次のようになります。
```
{
"keyspaceName": "mykeyspace",
"tableName": "mytable",
"resourceArn": "arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/mytable",
"autoScalingSpecification": {
"writeCapacityAutoScaling": {
"autoScalingDisabled": false,
"minimumUnits": 5,
"maximumUnits": 10,
"scalingPolicy": {
"targetTrackingScalingPolicyConfiguration": {
"disableScaleIn": false,
"scaleInCooldown": 0,
"scaleOutCooldown": 0,
"targetValue": 50.0
}
}
},
"readCapacityAutoScaling": {
"autoScalingDisabled": false,
"minimumUnits": 5,
"maximumUnits": 10,
"scalingPolicy": {
"targetTrackingScalingPolicyConfiguration": {
"disableScaleIn": false,
"scaleInCooldown": 60,
"scaleOutCooldown": 60,
"targetValue": 50.0
}
}
}
}
}
```
------
# テーブルの Amazon Keyspaces 自動スケーリングを無効にする
テーブルの Amazon Keyspaces 自動スケーリングはいつでも無効にすることができます。テーブルの読み取りキャパシティまたは書き込みキャパシティのスケーリングが不要になった場合は、それ以降は Amazon Keyspaces でテーブルの読み取り/書き込みキャパシティの設定が変更されないように、自動スケーリングを無効にすることを検討してください。コンソール、CQL、または AWS CLIを使用して、テーブルを更新することができます。
自動スケーリングを無効にすると、自動的に作成された CloudWatch アラームも削除されます。
Amazon Keyspaces テーブルにアクセスのために Application Auto Scaling により使用されるサービスリンクロールを削除するには、[Amazon Keyspaces のサービスリンクロールの削除](using-service-linked-roles-app-auto-scaling.md#delete-service-linked-role-app-auto-scaling) のステップを実行します。
**注記**
Application Auto Scaling で使用されているサービスリンクロールを削除するには、すべての AWS リージョンにおいてアカウント内のすべてのテーブルで自動スケーリングを無効にする必要があります。
------
#### [ Console ]
**コンソールを使用してテーブルの Amazon Keyspaces 自動スケーリングを無効にする**
**Amazon Keyspaces コンソールの使用**
1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) で Amazon Keyspaces コンソールを開きます。
1. 更新対象のテーブルを選択し、**[キャパシティ]** タブに移動します。
1. **[キャパシティ設定]** セクションで、**[編集]** を選択します。
1. Amazon Keyspaces の自動スケーリングを無効にするには、**[自動スケーリング]** チェックボックスの選択を解除します。自動スケーリングを無効にすると、Application Auto Scaling のスケーラブルターゲットとしてのテーブルの登録が解除されます。
------
#### [ Cassandra Query Language (CQL) ]
**CQL を使用してテーブルの Amazon Keyspaces 自動スケーリングを無効にする**
次のステートメントは、テーブル *mytable* の書き込みキャパシティの自動スケーリングを無効にします。
```
ALTER TABLE mykeyspace.mytable
WITH AUTOSCALING_SETTINGS = {
'provisioned_write_capacity_autoscaling_update': {
'autoscaling_disabled': true
}
};
```
------
#### [ CLI ]
**を使用してテーブルの Amazon Keyspaces 自動スケーリングをオフにする AWS CLI**
次のコマンドは、テーブルの読み取りキャパシティの自動スケーリングを無効にします。また、自動的に作成された CloudWatch アラームも削除されます。
```
aws keyspaces update-table --keyspace-name mykeyspace --table-name mytable
\ --auto-scaling-specification readCapacityAutoScaling={autoScalingDisabled=true}
```
------
# Amazon CloudWatch で Amazon Keyspaces テーブルの自動スケーリングアクティビティを表示する
使用状況とパフォーマンスに関するメトリクスを生成する Amazon CloudWatch を使用すれば、Amazon Keyspaces 自動スケーリングによるリソースの使用状況をモニタリングできます。『[Application Auto Scaling ユーザーガイド](https://docs.aws.amazon.com/autoscaling/application/userguide/monitoring-cloudwatch.html)』のステップに従って CloudWatch ダッシュボードを作成します。
# Amazon Keyspaces でバーストキャパシティを効果的に使用する
Amazon Keyspaces では、バーストキャパシティを指定することで、パーティションごとのスループットプロビジョニングに柔軟性を与えるこができます。パーティションのスループットが十分に利用されていない場合、Amazon Keyspaces では、スループットの利用率が*バースト*した場合に備えて、未使用のキャパシティーの一部を確保して使用量のスパイクに対応します。
現在 Amazon Keyspaces では、未使用の読み取りキャパシティーと書き込みキャパシティーは、最大 5 分 (300 秒) 確保されます。読み込みアクティビティや書き込みアクティビティが時々バーストする状況では、これらの余分な容量ユニットをすばやく消費して対応できます。これは、テーブルに定義した 1 秒あたりのプロビジョン済みスループットキャパシティよりも高速です。
また、Amazon Keyspaces では、バックグラウンドメンテナンスやその他のタスクのために予告なしにバーストキャパシティーが消費される場合があります。
これらのバーストキャパシティの詳細は将来変更される可能性があります。