レガシーバージョン (2017.11.29) から現行バージョン (2019.11.21) へのアップグレード - Amazon DynamoDB

レガシーバージョン (2017.11.29) から現行バージョン (2019.11.21) へのアップグレード

DynamoDB グローバルテーブルには、グローバルテーブルバージョン 2019.11.21 (現行)グローバルテーブルバージョン 2017.11.29 (レガシー) の 2 つのバージョンがあります。可能な限り、2019.11.21 (現行) バージョンを使用してください。2017.11.29 (レガシー) よりも柔軟性と効率が高く、消費する書き込みキャパシティーが少ないためです。使用中のバージョンを確認するには、「使用しているグローバルテーブルのバージョンを確認する」を参照してください。

このセクションでは、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 のみ必要です。

    次の表は、2017.11.29 (レガシー) テーブルと 2019.11.21 (現行) テーブルの rWRU 消費量を示しています。

    2 つのリージョンの 1KB アイテムの 2017.11.29 (レガシー) テーブルおよび 2019.11.21 (現行) テーブルの rWRU 消費量
    操作 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 (レガシー) は、1 回の書き込みで 2 つの DynamoDB Streams レコードを公開します。バージョン 2019.11.21 (現行) は、1 回の書き込みで 1 つの DynamoDB Streams レコードのみを公開します。

  • バージョン 2017.11.29 (レガシー) は、aws:rep:deletingaws:rep:updateregion、および aws:rep:updatetime 属性の入力と更新を行います。バージョン 2019.11.21 (現行) は、これらの属性の入力または更新を行いません。

  • バージョン 2017.11.29 (レガシー) は、レプリカ間で 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 (現行) グローバルテーブルへのアップグレードを開始する前に、次の前提条件を満たす必要があります。

  • レプリカの Time to Live (TTL) 設定がリージョン間で一貫していること。

  • レプリカのグローバルセカンダリインデックス (GSI) 定義がリージョン間で一貫していること。

  • レプリカの保管時の暗号化設定がリージョン間で一貫していること。

  • すべてのレプリカの WCU で DynamoDB 自動スケーリングが有効になっていること、またはすべてのレプリカでオンデマンドキャパシティモードが有効になっていること。

  • アプリケーションで、テーブルアイテムの aws:rep:deletingaws:rep:updateregionaws: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 コンソールテーブルビューを使用します。

  • テーブルのアップグレード中、自動スケーリングはグローバルテーブルのプロビジョニング済のキャパシティ設定を調整しません。アップグレード中は、テーブルをオンデマンドキャパシティモードに設定することを強くお勧めします。

  • アップグレード中に自動スケーリングでプロビジョニングされた容量を使用する場合は、アップグレード中に予想されるトラフィックの増加に対応しスロットリングを回避するために、ポリシーの最小読み取りスループットと最小書き込みスループットを増やす必要があります。

  • アップグレードプロセスが完了すると、テーブルのステータスは ACTIVE に変わります。

アップグレード前、アップグレード中、アップグレード後の DynamoDB Streams の動作

操作 レプリカリージョン アップグレード前の動作 アップグレード中の動作 アップグレード後の動作

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 つのフェーズでの削除が行われます。

  • フェーズ 1 では、UpdateItem によって削除フラグが設定されます。

  • フェーズ 2 では、DeleteItem によってアイテムが削除されます。

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 (現行) にアップグレードするには
  1. DynamoDB コンソール (https://console.aws.amazon.com/dynamodb/home) を開きます。

  2. コンソールの左側のナビゲーションペインで、[テーブル] を選択し、バージョン 2019.11.21 (現行) にアップグレードするグローバルテーブルを選択します。

  3. [グローバルテーブル] タブを選択します。

  4. [Update version (バージョンの更新)] を選択します。

    [Update version (バージョンの更新)] ボタンを示すコンソールのスクリーンショット。
  5. 新しい要件を読んで同意してから、[バージョンを更新] を選択します。

  6. アップグレードプロセスが完了すると、コンソールに表示されるグローバルテーブルのバージョンが 2019.11.21 に変更されます。