助け合いフォーラム
AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30554
問題を開く
DynamoDBのテーブルに行われた追加・削除および更新のログを保存しておきたい。どの機能を有効にするのがよいか。
正解
DynamoDB Streams
解説
Amazon DynamoDBのDynamoDB Streams(ストリーム)とは、テーブルに対して行われた直近の24時間の変更(追加や更新、削除)をログに保存する機能です。ストリームを参照することによって、いつ誰がどのようにテーブルを更新したかがわかります。
以上より正解は
・DynamoDB Streams
です。
ログには、アプリケーションがリアルタイムにアクセスできるため、変更内容に応じて処理を組み込むことができます。例えば、ログを監視し問題のある処理があった場合はアラートを上げさせたり、プロフィール画像を更新(追加)したらフレンドに通知させるというような運用が可能です。
その他の選択肢については以下の通りです。
・DynamoDB Accelerator(DAX)
DynamoDBのインメモリキャッシュクラスタのことですので誤りです。
・オンデマンドモード
DynamoDBの利用料金に関連するモードですので誤りです。オンデマンドモードは、テーブルに対する読み込み・書き込みのリクエスト単位で利用料金がかかります。
・WCU(Write Capacity Unit)
DynamoDBの利用料金に関連するモードの一つ「プロビジョニングモード」における読み書きの単位ですので誤りです。最大1KBのデータを1秒間に1回書き込みする単位をWCUといいます。
以上より正解は
・DynamoDB Streams
です。
ログには、アプリケーションがリアルタイムにアクセスできるため、変更内容に応じて処理を組み込むことができます。例えば、ログを監視し問題のある処理があった場合はアラートを上げさせたり、プロフィール画像を更新(追加)したらフレンドに通知させるというような運用が可能です。
その他の選択肢については以下の通りです。
・DynamoDB Accelerator(DAX)
DynamoDBのインメモリキャッシュクラスタのことですので誤りです。
・オンデマンドモード
DynamoDBの利用料金に関連するモードですので誤りです。オンデマンドモードは、テーブルに対する読み込み・書き込みのリクエスト単位で利用料金がかかります。
・WCU(Write Capacity Unit)
DynamoDBの利用料金に関連するモードの一つ「プロビジョニングモード」における読み書きの単位ですので誤りです。最大1KBのデータを1秒間に1回書き込みする単位をWCUといいます。
参考
【Amazon DynamoDB】
Amazon DynamoDBは、AWSが提供するデータベースサービスの一つです。
「NoSQL」は多くの場合、SQLを使用する「リレーショナルデータベース(RDB)」に属さないデータベース、といった意味で使われます。
本項では、DynamoDBが扱うデータ構造、DynamoDBの特徴である高可用性、キャパシティ、データ参照時の一貫性、自動スケール、更新ログの保存機能であるStreams、Time To Live(TTL)機能について解説します。
●データ構造
・Key-Value型
DynamoDBでは、Key-Value型という「保存するデータ(Value)」とそれを特定するための「キー(Key)」がペアになっている形式のデータを扱います。
例えば「ユーザーが保有しているアイテム」を管理するには以下のように表せます。
新たにアイテムが追加された場合や追加されたアイテムを初めて保有する際にも、既存のデータ構造に変更を加えることなく新しい項目を追加することができます。
Key-Value型で構成された項目の塊をテーブルと呼びます。ある表AとBのデータを結合して結果を得たり分析するような利用方法よりも、上例のように単一のデータを格納・取得するというシンプルな利用に向いています。シンプルな構造であるためパフォーマンスは非常に高く、ピーク時には秒間2000万件のリクエストに対応します。更にストレージの容量制限もありませんので拡張性にも優れています。
・ドキュメント型
DynamoDBでは、ドキュメント型という、階層的なデータ構造をもった形式のデータを扱います。
構造的にはKey-Value型を背景に持ちますが、ドキュメント型ではデータをJSON形式で表現することができます。JSONは、階層的なデータ構造を簡単に表現することができるデータフォーマット(形式)です。DynamoDBにJSON形式のデータを格納することで、階層的なデータの効率的な管理が実現できます。
さらに、DynamoDBは「スキーマレス」と言われることが多いデータベースで、属性の追加や変更が非常に柔軟に行えます。スキーマとはデータベースの構造のことです。新たなデータ項目を追加する場合、通常はスキーマの変更と既存の格納済みデータへのスキーマ変更に対応する修正を行う必要がありますが、DynamoDBのようなデータベースではプライマリキー(データを一意に識別するために使われる項目)以外の属性については、スキーマの変更作業自体が不要になります。
また、DynamoDBでは、テーブル内のデータに高速にアクセスできるように様々なインデックス(書籍の索引のようにデータを一意に特定する仕組み)を作成することができます。インデックスを効果的に作成することでスループットを向上させることができ、コストダウンの効果も期待できます(スループットとコストの関係については、下部「●キャパシティ」も参照してください)。
●高可用性
・3つのAZにデータを分散して保存
DynamoDBでは、単一障害点(SPOF: Single Point Of Failure:ある箇所が故障すると、システム全体が機能不全になる箇所)を持たず、高い可用性を誇ります。
また、データは3つのAZに自動的に保存されますので、耐障害性にも優れています。
各AZのデータはパーティションという単位で分散して保存されます。パーティション分割によって一か所にデータを集中させないようにすることで、プロビジョニング(予約)されたスループットを保てるようにしています。なお、パーティション分割はAWSによって自動的に行われるので、ユーザーが通常意識することはありません。
・バックアップ
DynamoDBには2つのバックアップ方法があります。
「オンデマンドバックアップ」は、ユーザーが任意のタイミングで作成するバックアップのことです。マネジメントコンソールまたはAPIを利用して、テーブルの完全なバックアップを作成します。
自動的にバックアップを行いたい場合は「ポイントインタイムリカバリ(PITR)」を有効にします。オンデマンドバックアップとは違い、差分バックアップが定期的に自動で取得されます。リカバリ時は、35日前まで遡ることができます。
●キャパシティ
DynamoDBでは、テーブルに対する書き込み・読み込みの量と利用料金が関係しています。
・オンデマンドモード ... 書き込み・読み込みのリクエスト単位で利用料金がかかる
・プロビジョニングモード ... 1秒間に行う書き込み・読み込みの量で利用料金が異なる
プロビジョニングモードの書き込み・読み込みは、「キャパシティユニット」という単位で管理されています。これは1秒間にどれだけ読み込み・書き込みを行うかを予約する設定で、容量が大きいほど料金がかかります。
キャパシティユニットは、テーブル作成時にはWCU、RCUともに 5 に設定されています。キャパシティユニットの変更はいつでも行うことができます。
また、データアクセスの負荷に応じてキャパシティユニットを自動的にスケール(増減)することもできます。常に高いパフォーマンスを維持しておく必要がないため、コストを抑えたい場合に有用です。
大規模に利用する場合は「リザーブドキャパシティ」を用いることもできます。
リザーブドキャパシティはWCU、RCUともに100ユニット単位で1年または3年の期間で予約購入するサービスです。通常のプロビジョニングモードよりも割安に利用できます。
・キャパシティユニットとパーティション
パーティション(「●高可用性」を参照)の数やサイズは、キャパシティユニットの値をもとにAWSが算出します。パーティション分割はプロビジョニングされたスループットを保つための仕組みですから、キャパシティユニットの値を大きくする(=1秒間の処理件数を増やす)と、パーティションの数も多くなります。
●データ参照時の一貫性
アプリケーションが書き込みを行った場合、3つのAZのテーブルのうち2つのテーブルに書き込みができた時点で完了とみなされます。残りの1つには後からレプリケートされます。このレプリケートされるまでの間は、書き込みが行われた後の結果と書き込みが行われる前の結果が混在することになります。このとき、レプリケートが完了していないテーブルに対して読み込みが発生すると、古いデータを読み出してしまう可能性があります。
DynamoDBでは以下の2つの読み込みモードをサポートしています。
○結果整合性のある読み込み(デフォルト)
一時的には読み込んだデータが最新ではないタイミングが発生する可能性はあるが、最終的には読み出すデータは最新のものとなる(書き込みから少し時間をおくことで回避できる)。
○強力な整合性のある読み込み
必ず最新のデータを取り出すことができる。ただし読み込み時のコストが2倍になる、レイテンシが高くなる可能性がある、などの条件がつく。
●自動スケール
データ容量が増えた場合でも、DynamoDBは自動的にスケールアウト(拡張)されます。データベース用ノードの追加やディスクを増やすといった作業がないため、ダウンタイム(サービスを停止する時間)がなくサービスを提供し続けることができます。
●更新ログ保存機能(DynamoDB Streams)
DynamoDB Streams(ストリーム)とは、テーブルに対して行われた直近の24時間の変更(追加や更新、削除)をログに保存する機能です。ストリームを参照することによって、いつ誰がどのようにテーブルを更新したかがわかります。
ログには、アプリケーションがリアルタイムにアクセスできるため、変更内容に応じて処理を組み込むことができます。例えば、ログを監視し問題のある処理があった場合はアラートを上げさせたり、プロフィール画像を更新(追加)したらフレンドに通知させるというような運用が可能です。
なお、DynamoDB Streamsは非同期で動作するため、ストリームを有効にしても元のテーブルのパフォーマンスには影響を与えません。
●Time To Live(TTL)機能
Time To Live(TTL)機能は、特定の時点で自動的にデータ項目を削除する機能です。項目にTTL属性(UNIX時間形式のタイムスタンプ)を設定することで、その時刻が来たときにDynamoDBが自動的に項目を削除します。このプロセスは完全に自動化されており、追加の管理やコストが発生しません。これにより、データのライフサイクル管理が簡素化され、不要なデータによるストレージコストの増加を防ぎます。
【DynamoDB Accelerator(DAX)】
DynamoDB Accelerator(DAX)は、DynamoDBのインメモリのキャッシュクラスタです。
DAXを利用することにより、ミリ秒(千分の一秒)だったレスポンスをマイクロ秒(百万分の一秒)レベルのパフォーマンスにまで向上させることができます。
またキャッシュであるDAXからデータを取得することができればDynamoDBへアクセスする回数も削減されるため、RCUを抑えることもできます。
【グローバルテーブル】
DynamoDBのグローバルテーブルは、DynamoDBテーブルを複数のリージョンにまたがって運用できるサービスです。複数のリージョンにDynamoDBテーブルが自動的にレプリケートされ、ユーザーは地理的に近いリージョンのDynamoDBテーブルへ高速な読み込みと書き込みが可能になります。データのレプリケーションは通常1秒以内に完了し、リージョン間のデータ冗長化によって高可用性が確保されます。
下記のように、グローバルテーブルのレプリケート先のリージョンはユーザーが指定します。
【S3へのエクスポート】
DynamoDBでは、既存のテーブルデータを任意のS3バケットに直接エクスポートする機能が提供されています。ユーザはこの機能のために独自のアプリケーションを用意したり、追加のコードを記述したりする必要はありません。また、この機能を使用したデータのエクスポートでは、対象のテーブルに設定されたRCUを消費せず、テーブルの可用性やパフォーマンスにも影響を及ぼさないという点が大きなメリットです。
なお、この機能は、内部的にDynamoDBの継続的バックアップの機能(ポイントインタイムリカバリの前提となる機能)を使用しているため、対象のテーブルのポイントインタイムリカバリを有効にしておく必要があります。
Amazon DynamoDBは、AWSが提供するデータベースサービスの一つです。
「NoSQL」は多くの場合、SQLを使用する「リレーショナルデータベース(RDB)」に属さないデータベース、といった意味で使われます。
本項では、DynamoDBが扱うデータ構造、DynamoDBの特徴である高可用性、キャパシティ、データ参照時の一貫性、自動スケール、更新ログの保存機能であるStreams、Time To Live(TTL)機能について解説します。
●データ構造
・Key-Value型
DynamoDBでは、Key-Value型という「保存するデータ(Value)」とそれを特定するための「キー(Key)」がペアになっている形式のデータを扱います。
例えば「ユーザーが保有しているアイテム」を管理するには以下のように表せます。
新たにアイテムが追加された場合や追加されたアイテムを初めて保有する際にも、既存のデータ構造に変更を加えることなく新しい項目を追加することができます。
Key-Value型で構成された項目の塊をテーブルと呼びます。ある表AとBのデータを結合して結果を得たり分析するような利用方法よりも、上例のように単一のデータを格納・取得するというシンプルな利用に向いています。シンプルな構造であるためパフォーマンスは非常に高く、ピーク時には秒間2000万件のリクエストに対応します。更にストレージの容量制限もありませんので拡張性にも優れています。
・ドキュメント型
DynamoDBでは、ドキュメント型という、階層的なデータ構造をもった形式のデータを扱います。
構造的にはKey-Value型を背景に持ちますが、ドキュメント型ではデータをJSON形式で表現することができます。JSONは、階層的なデータ構造を簡単に表現することができるデータフォーマット(形式)です。DynamoDBにJSON形式のデータを格納することで、階層的なデータの効率的な管理が実現できます。
さらに、DynamoDBは「スキーマレス」と言われることが多いデータベースで、属性の追加や変更が非常に柔軟に行えます。スキーマとはデータベースの構造のことです。新たなデータ項目を追加する場合、通常はスキーマの変更と既存の格納済みデータへのスキーマ変更に対応する修正を行う必要がありますが、DynamoDBのようなデータベースではプライマリキー(データを一意に識別するために使われる項目)以外の属性については、スキーマの変更作業自体が不要になります。
また、DynamoDBでは、テーブル内のデータに高速にアクセスできるように様々なインデックス(書籍の索引のようにデータを一意に特定する仕組み)を作成することができます。インデックスを効果的に作成することでスループットを向上させることができ、コストダウンの効果も期待できます(スループットとコストの関係については、下部「●キャパシティ」も参照してください)。
●高可用性
・3つのAZにデータを分散して保存
DynamoDBでは、単一障害点(SPOF: Single Point Of Failure:ある箇所が故障すると、システム全体が機能不全になる箇所)を持たず、高い可用性を誇ります。
また、データは3つのAZに自動的に保存されますので、耐障害性にも優れています。
各AZのデータはパーティションという単位で分散して保存されます。パーティション分割によって一か所にデータを集中させないようにすることで、プロビジョニング(予約)されたスループットを保てるようにしています。なお、パーティション分割はAWSによって自動的に行われるので、ユーザーが通常意識することはありません。
・バックアップ
DynamoDBには2つのバックアップ方法があります。
「オンデマンドバックアップ」は、ユーザーが任意のタイミングで作成するバックアップのことです。マネジメントコンソールまたはAPIを利用して、テーブルの完全なバックアップを作成します。
自動的にバックアップを行いたい場合は「ポイントインタイムリカバリ(PITR)」を有効にします。オンデマンドバックアップとは違い、差分バックアップが定期的に自動で取得されます。リカバリ時は、35日前まで遡ることができます。
●キャパシティ
DynamoDBでは、テーブルに対する書き込み・読み込みの量と利用料金が関係しています。
・オンデマンドモード ... 書き込み・読み込みのリクエスト単位で利用料金がかかる
・プロビジョニングモード ... 1秒間に行う書き込み・読み込みの量で利用料金が異なる
プロビジョニングモードの書き込み・読み込みは、「キャパシティユニット」という単位で管理されています。これは1秒間にどれだけ読み込み・書き込みを行うかを予約する設定で、容量が大きいほど料金がかかります。
キャパシティユニットは、テーブル作成時にはWCU、RCUともに 5 に設定されています。キャパシティユニットの変更はいつでも行うことができます。
また、データアクセスの負荷に応じてキャパシティユニットを自動的にスケール(増減)することもできます。常に高いパフォーマンスを維持しておく必要がないため、コストを抑えたい場合に有用です。
大規模に利用する場合は「リザーブドキャパシティ」を用いることもできます。
リザーブドキャパシティはWCU、RCUともに100ユニット単位で1年または3年の期間で予約購入するサービスです。通常のプロビジョニングモードよりも割安に利用できます。
・キャパシティユニットとパーティション
パーティション(「●高可用性」を参照)の数やサイズは、キャパシティユニットの値をもとにAWSが算出します。パーティション分割はプロビジョニングされたスループットを保つための仕組みですから、キャパシティユニットの値を大きくする(=1秒間の処理件数を増やす)と、パーティションの数も多くなります。
●データ参照時の一貫性
アプリケーションが書き込みを行った場合、3つのAZのテーブルのうち2つのテーブルに書き込みができた時点で完了とみなされます。残りの1つには後からレプリケートされます。このレプリケートされるまでの間は、書き込みが行われた後の結果と書き込みが行われる前の結果が混在することになります。このとき、レプリケートが完了していないテーブルに対して読み込みが発生すると、古いデータを読み出してしまう可能性があります。
DynamoDBでは以下の2つの読み込みモードをサポートしています。
○結果整合性のある読み込み(デフォルト)
一時的には読み込んだデータが最新ではないタイミングが発生する可能性はあるが、最終的には読み出すデータは最新のものとなる(書き込みから少し時間をおくことで回避できる)。
○強力な整合性のある読み込み
必ず最新のデータを取り出すことができる。ただし読み込み時のコストが2倍になる、レイテンシが高くなる可能性がある、などの条件がつく。
●自動スケール
データ容量が増えた場合でも、DynamoDBは自動的にスケールアウト(拡張)されます。データベース用ノードの追加やディスクを増やすといった作業がないため、ダウンタイム(サービスを停止する時間)がなくサービスを提供し続けることができます。
●更新ログ保存機能(DynamoDB Streams)
DynamoDB Streams(ストリーム)とは、テーブルに対して行われた直近の24時間の変更(追加や更新、削除)をログに保存する機能です。ストリームを参照することによって、いつ誰がどのようにテーブルを更新したかがわかります。
ログには、アプリケーションがリアルタイムにアクセスできるため、変更内容に応じて処理を組み込むことができます。例えば、ログを監視し問題のある処理があった場合はアラートを上げさせたり、プロフィール画像を更新(追加)したらフレンドに通知させるというような運用が可能です。
なお、DynamoDB Streamsは非同期で動作するため、ストリームを有効にしても元のテーブルのパフォーマンスには影響を与えません。
●Time To Live(TTL)機能
Time To Live(TTL)機能は、特定の時点で自動的にデータ項目を削除する機能です。項目にTTL属性(UNIX時間形式のタイムスタンプ)を設定することで、その時刻が来たときにDynamoDBが自動的に項目を削除します。このプロセスは完全に自動化されており、追加の管理やコストが発生しません。これにより、データのライフサイクル管理が簡素化され、不要なデータによるストレージコストの増加を防ぎます。
【DynamoDB Accelerator(DAX)】
DynamoDB Accelerator(DAX)は、DynamoDBのインメモリのキャッシュクラスタです。
DAXを利用することにより、ミリ秒(千分の一秒)だったレスポンスをマイクロ秒(百万分の一秒)レベルのパフォーマンスにまで向上させることができます。
またキャッシュであるDAXからデータを取得することができればDynamoDBへアクセスする回数も削減されるため、RCUを抑えることもできます。
【グローバルテーブル】
DynamoDBのグローバルテーブルは、DynamoDBテーブルを複数のリージョンにまたがって運用できるサービスです。複数のリージョンにDynamoDBテーブルが自動的にレプリケートされ、ユーザーは地理的に近いリージョンのDynamoDBテーブルへ高速な読み込みと書き込みが可能になります。データのレプリケーションは通常1秒以内に完了し、リージョン間のデータ冗長化によって高可用性が確保されます。
下記のように、グローバルテーブルのレプリケート先のリージョンはユーザーが指定します。
【S3へのエクスポート】
DynamoDBでは、既存のテーブルデータを任意のS3バケットに直接エクスポートする機能が提供されています。ユーザはこの機能のために独自のアプリケーションを用意したり、追加のコードを記述したりする必要はありません。また、この機能を使用したデータのエクスポートでは、対象のテーブルに設定されたRCUを消費せず、テーブルの可用性やパフォーマンスにも影響を及ぼさないという点が大きなメリットです。
なお、この機能は、内部的にDynamoDBの継続的バックアップの機能(ポイントインタイムリカバリの前提となる機能)を使用しているため、対象のテーブルのポイントインタイムリカバリを有効にしておく必要があります。
解説文の誤字
投稿日 2023/07/04
・オンデマンドモード
DynamoDBの利用料金に関連するモードですので誤りです。オンデマンドモードは、テーブルに対する読み込み・書き込みのリクエスト単位で料理料金がかかります。
解説にある、上記の「料理料金」の箇所は「利用料金」の誤字かと思いますので、指摘させていただきました。
スタッフからの返信
この投稿に対して返信しませんか?
s staff_satomi
2023/07/05 10:28
Pnt713_019様 ご指摘の点を修正いたしました。 ご報告いただきまして、誠にありがとうございます。