注記
DynamoDB グローバルテーブルには、グローバルテーブルバージョン 2019.11.21 (現行) と グローバルテーブルバージョン 2017.11.29 (レガシー) の 2 つのバージョンがあります。可能な限り、バージョン 2019.11.21 (現行) を使用してください。2017.11.29 (レガシー) よりも柔軟性と効率が高く、消費する書き込みキャパシティが少ないためです。使用中のバージョンを確認するには、「使用している DynamoDB グローバルテーブルのバージョンを確認する」を参照してください。
このセクションでは、DynamoDB コンソールを使用して、グローバルテーブルをバージョン 2019.11.21 (現行) にアップグレードする方法について説明します。バージョン 2017.11.29 (レガシー) からバージョン 2019.11.21 (現行) へのアップグレードは 1 回限りのアクションであり、元に戻すことはできません。現在、グローバルテーブルはコンソールからのみアップグレードできます。
トピック
レガシーバージョンと現行バージョンの動作の違い
以下のリストは、グローバルテーブルのレガシーバージョンと現行バージョンの動作の違いを示しています。
-
いくつかの DynamoDB オペレーションにおいて、バージョン 2019.11.21 (現行) は、バージョン 2017.11.29 (レガシー) よりも書き込みキャパシティの消費が少ないため、ほとんどのユーザーにとってコスト効率が向上します。DynamoDB オペレーションの違いは次のとおりです。
-
あるリージョンの 1KB アイテムに対して PutItem を呼び出し、他のリージョンにレプリケートする場合、2017.11.29 (レガシー) ではリージョンごとに 2 rWRU が必要ですが、2019.11.21 (現行) では 1 rWRU のみ必要です。
-
1KB アイテムに対して UpdateItem を呼び出す場合、2017.11.29 (レガシー) ではソースリージョンで 2 rWRU、送信先リージョンで 1 rWRU が必要ですが、2019.11.21 (現行) ではソースリージョンおよび送信先リージョンでそれぞれ 1 rWRU のみ必要です。
-
1KB アイテムに対して DeleteItem を呼び出す場合、2017.11.29 (レガシー) ではソースリージョンで 1 rWRU、送信先リージョンで 2 rWRU が必要ですが、2019.11.21 (現行) ではソースリージョンおよび送信先リージョンでそれぞれ 1 rWRU のみ必要です。
次の表は、2 つのリージョンの 1 KB 項目に対する 2017.11.29 (レガシー) テーブルと 2019.11.21 (現行) テーブルの rWRU 消費量を示しています。
Operation 2017.11.29 (レガシー) 2019.11.21 (現行) 削減量 PutItem 4 rWRU 2 rWRU 50% UpdateItem 3 rWRU 2 rWRU 33% DeleteItem 3 rWRU 2 rWRU 33% -
-
バージョン 2017.11.29 (レガシー) は、11 か所の AWS リージョンでのみ利用可能です。一方、バージョン 2019.11.21 (現行) は、すべての AWS リージョンで使用可能です。
-
バージョン 2017.11.29 (レガシー) グローバルテーブルを作成するには、まず空のリージョンテーブルのセットを作成し、次に CreateGlobalTable API を呼び出してグローバルテーブルを作成します。バージョン 2019.11.21 (現行) グローバルテーブルを作成するには、UpdateTable API を呼び出して、既存のリージョンテーブルにレプリカを追加します。
-
バージョン 2017.11.29 (レガシー) では、新しいリージョンにレプリカを追加する前 (作成時を含む) に、テーブル内のすべてのレプリカを空にする必要があります。バージョン 2019.11.21 (現行) では、データが既に含まれているリージョンのテーブルに対してレプリカを追加および削除できます。
-
バージョン 2017.11.29 (レガシー) では、以下の専用コントロールプレーン API のセットを使用してレプリカを管理します。
バージョン 2019.11.21 (現行) は、DescribeTable API および UpdateTable API を使用してレプリカを管理します。
-
バージョン 2017.11.29 (レガシー) は、書き込みごとに 2 つの DynamoDB Streams レコードを発行します。バージョン 2019.11.21 (現行) は、書き込みごとに 1 つの DynamoDB Streams レコードのみを発行します。
-
バージョン 2017.11.29 (レガシー) は、
aws:rep:deleting
、aws:rep:updateregion
、aws:rep:updatetime
の各属性を入力および更新します。バージョン 2019.11.21 (現行) は、これらの属性を入力または更新しません。 -
バージョン 2017.11.29 (レガシー) は、レプリカ間で DynamoDB での Time to Live (TTL) の使用 設定を同期しません。バージョン 2019.11.21 (現行) は、レプリカ間で TTL 設定を同期します。
-
バージョン 2017.11.29 (レガシー) は、TTL 削除を他のレプリカにレプリケートしません。バージョン 2019.11.21 (現行) は、TTL 削除をすべてのレプリカにレプリケートします。
-
バージョン 2017.11.29 (レガシー) は、レプリカ間で自動スケーリング設定を同期しません。バージョン 2019.11.21 (現行) は、レプリカ間で自動スケーリング設定を同期します。
-
バージョン 2017.11.29 (レガシー) は、レプリカ間でグローバルセカンダリインデックス (GSI) 設定を同期しません。バージョン 2019.11.21 (現行) は、レプリカ間で GSI 設定を同期します。
-
バージョン 2017.11.29 (レガシー) は、レプリカ間で保管中の暗号化設定を同期しません。バージョン 2019.11.21 (現行) は、レプリカ間で保管中の暗号化設定を同期します。
-
バージョン 2017.11.29 (レガシー) は
PendingReplicationCount
メトリクスを発行します。バージョン 2019.11.21 (現行) は同メトリクスを発行しません。
アップグレードの前提条件
バージョン 2019.11.21 (現行) のグローバルテーブルへのアップグレードを開始する前に、以下の前提条件を満たす必要があります。
-
レプリカの DynamoDB での Time to Live (TTL) の使用 設定がリージョン間で一貫していること。
-
レプリカのグローバルセカンダリインデックス (GSI) 定義がリージョン間で一貫していること。
-
レプリカの保管時の暗号化設定がリージョン間で一貫していること。
-
すべてのレプリカの WCU で DynamoDB 自動スケーリングが有効になっていること、またはすべてのレプリカでオンデマンドキャパシティモードが有効になっていること。
-
アプリケーションで、テーブルアイテムの
aws:rep:deleting
、aws:rep:updateregion
、aws:rep:updatetime
属性が必須でないこと。
グローバルテーブルのアップグレードに必要なアクセス許可
バージョン 2019.11.21 (現行) にアップグレードするには、レプリカがあるすべてのリージョンで dynamodb:UpdateGlobalTableversion
アクセス許可が必要です。DynamoDB コンソールへのアクセス許可、およびテーブル表示に必要なアクセス許可に加えて、このアクセス許可が必要です。
次の IAM ポリシーは、グローバルテーブルをバージョン 2019.11.21 (現行) にアップグレードするアクセス許可を付与します。
{
"version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "dynamodb:UpdateGlobalTableversion",
"Resource": "*"
}
]
}
次の IAM ポリシーは、2 つのリージョンにレプリカがある Music
グローバルテーブルのみをバージョン 2019.11.21 (現行) にアップグレードするアクセス許可を付与します。
{
"version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "dynamodb:UpdateGlobalTableversion",
"Resource": [
"arn:aws:dynamodb::123456789012:global-table/Music",
"arn:aws:dynamodb:ap-southeast-1:123456789012:table/Music",
"arn:aws:dynamodb:us-east-2:123456789012:table/Music"
]
}
]
}
アップグレード中の注意点
-
すべてのグローバルテーブルレプリカは、アップグレード中も読み取りと書き込みのトラフィックを処理します。
-
テーブルのサイズとレプリカの数にもよりますが、アップグレードプロセスには、数分から数時間かかります。
-
アップグレードプロセス中、TableStatus の値は
ACTIVE
からUPDATING
に変わります。テーブルのステータスを表示するには、DescribeTable API を呼び出すか、DynamoDB コンソールのテーブルビューを使用します。 -
テーブルのアップグレード中、自動スケーリングはグローバルテーブルのプロビジョニング済のキャパシティ設定を調整しません。アップグレード中は、テーブルをオンデマンドキャパシティモードに設定することを強くお勧めします。
-
アップグレード中に自動スケーリングでプロビジョニングされた容量を使用する場合は、アップグレード中に予想されるトラフィックの増加に対応しスロットリングを回避するために、ポリシーの最小読み取りスループットと最小書き込みスループットを増やす必要があります。
-
ReplicationLatency
メトリクスは、アップグレードプロセス中にレイテンシーのスパイクを一時的に報告したり、メトリクスデータのレポートを停止したりする場合があります。詳細については、「ReplicationLatency」を参照してください。 -
アップグレードプロセスが完了すると、テーブルのステータスは
ACTIVE
に変わります。
アップグレード前、アップグレード中、アップグレード後の DynamoDB Streams の動作
Operation | レプリカリージョン | アップグレード前の動作 | アップグレード中の動作 | アップグレード後の動作 |
---|---|---|---|---|
Put または Update |
ソース |
タイムスタンプの生成は UpdateItem を使用して行われます。 | タイムスタンプの生成は PutItem を使用して行われます。 | カスタマー表示タイムスタンプは生成されません。 |
2 つの Streams レコードが生成されます。最初のレコードには、お客様が書き込んだ属性が含まれます。2 つ目のレコードには、aws:rep:* 属性が含まれます。 |
2 つの Streams レコードが生成されます。最初のレコードには、お客様が書き込んだ属性が含まれます。2 つ目のレコードには、aws:rep:* 属性が含まれます。 |
お客様が作成した属性を含む 1 つの Streams レコードが生成されます。 | ||
お客様による書き込みごとに 2 つの rWCU が消費されます。 | お客様による書き込みごとに 2 つの rWCU が消費されます。 | お客様による書き込みごとに 1 つの rWCU が消費されます。 | ||
ReplicationLatency メトリクスおよび PendingReplicationCount メトリクスは、CloudWatch に公開されます。 |
ReplicationLatency メトリクスおよび PendingReplicationCount メトリクスは、CloudWatch に公開されます。 |
ReplicationLatency メトリクスは、CloudWatch に公開されます。 |
||
送信先 |
レプリケーションは PutItem を使用して行われます。 | レプリケーションは PutItem を使用して行われます。 | レプリケーションは PutItem を使用して行われます。 | |
お客様が作成した属性と aws:rep:* 属性の両方を含む 1 つの Streams レコードが生成されます。 |
お客様が作成した属性と aws:rep:* 属性の両方を含む 1 つの Streams レコードが生成されます。 |
お客様が作成した属性のみを含みレプリケーション属性を含まない 1 つの Streams レコードが生成されます。 | ||
アイテムが送信先のリージョンに存在する場合、1 rWCU が消費されます。アイテムが送信先のリージョンに存在しない場合、2 rWCU が消費されます。 | アイテムが送信先のリージョンに存在する場合、1 rWCU が消費されます。アイテムが送信先のリージョンに存在しない場合、2 rWCU が消費されます。 | お客様による書き込みごとに 1 つの rWCU が消費されます。 | ||
ReplicationLatency メトリクスおよび PendingReplicationCount メトリクスは、CloudWatch に公開されます。 |
ReplicationLatency メトリクスおよび PendingReplicationCount メトリクスは、CloudWatch に公開されます。 |
ReplicationLatency メトリクスは、CloudWatch に公開されます。 |
||
[Delete] (削除) |
ソース |
DeleteItem を使用して、より小さいタイムスタンプを持つすべてのアイテムを削除します。 | DeleteItem を使用して、より小さいタイムスタンプを持つすべてのアイテムを削除します。 | DeleteItem を使用して、より小さいタイムスタンプを持つすべてのアイテムを削除します。 |
お客様が作成した属性と aws:rep:* 属性の両方を含む 1 つの Streams レコードが生成されます。 |
お客様が作成した属性と aws:rep:* 属性の両方を含む 1 つの Streams レコードが生成されます。 |
お客様が作成した属性を含む 1 つの Streams レコードが生成されます。 | ||
お客様による削除ごとに 1 rWCU が消費されます。 | お客様による削除ごとに 1 rWCU が消費されます。 | お客様による削除ごとに 1 rWCU が消費されます。 | ||
ReplicationLatency メトリクスおよび PendingReplicationCount メトリクスは、CloudWatch に公開されます。 |
ReplicationLatency メトリクスおよび PendingReplicationCount メトリクスは、CloudWatch に公開されます。 |
ReplicationLatency メトリクスは、CloudWatch に公開されます。 |
||
送信先 |
2 つのフェーズでの削除が行われます。
|
DeleteItem を使用してアイテムを削除します。 | DeleteItem を使用してアイテムを削除します。 | |
2 つの Streams レコードが生成されます。1 つ目のレコードには、aws:rep:deleting フィールドへの変更が含まれます。2 つ目のレコードには、お客様が作成した属性と aws:rep:* 属性が含まれます。 |
お客様が作成した属性を含む 1 つの Stream レコードが生成されます。 | お客様が作成した属性を含む 1 つの Stream レコードが生成されます。 | ||
お客様による削除ごとに 2 つの rWCU が消費されます。 | お客様による削除ごとに 1 rWCU が消費されます。 | お客様による削除ごとに 1 rWCU が消費されます。 | ||
ReplicationLatency メトリクスおよび PendingReplicationCount メトリクスは、CloudWatch に公開されます。 |
ReplicationLatency メトリクスは、CloudWatch に公開されます。 |
ReplicationLatency メトリクスは、CloudWatch に公開されます。 |
バージョン 2019.11.21 (現行) へのアップグレード
AWS Management Console を使用して DynamoDB グローバルテーブルのバージョンをアップグレードするには、次の手順に従います。
グローバルテーブルをバージョン 2019.11.21 (現行) にアップグレードするには
-
DynamoDB コンソール (https://console.aws.amazon.com/dynamodb/home
) を開きます。 -
コンソールの左側のナビゲーションペインで、[テーブル] を選択し、バージョン 2019.11.21 (現行) にアップグレードするグローバルテーブルを選択します。
-
[グローバルテーブル] タブを選択します。
-
[Update version (バージョンの更新)] を選択します。
-
新しい要件を読んで同意してから、[バージョンを更新] を選択します。
-
アップグレードプロセスが完了すると、コンソールに表示されるグローバルテーブルのバージョンが 2019.11.21 に変更されます。