よくある質問

Q: Amazon DynamoDB とは何ですか?

Amazon DynamoDB は、完全マネージド型の NoSQL データベースサービスであり、高速で予測可能なパフォーマンスとシームレスな拡張性が特長です。Amazon DynamoDB を使用すると、分散データベースの運用と AWS にスケーリングするための管理負荷を軽減できます。ハードウェアのプロビジョニング、設定と構成、スループット容量のプランニング、レプリケーション、ソフトウェアのパッチ適用、クラスターのスケーリングなどについて心配する必要はありません。

Q: Amazon DynamoDB は私に代わって何を管理してくれますか?

Amazon DynamoDB により、データベースの拡張、データベースソフトウェアの管理、およびハードウェアの実行に必要なプロビジョニングに伴う主な障害の 1 つが取り除かれます。顧客は非リレーショナルデータベースをほんの数分で展開できます。DynamoDB では、テーブルサイズの増大に合わせてワークロードのデマンドに応じたスループット容量のスケーリング、データのパーティション化や再パーティション化が自動的に行われます。さらに、Amazon DynamoDB では、同じ AWS リージョン内の 3 つの施設間でデータが同期的にレプリケートされるため、可用性とデータ耐久性が高まります。

Q: 読み込み整合性とは何ですか? なぜ気にかける必要があるのですか?

Amazon DynamoDB では、地理的に分散した 3 つの場所に各テーブルのレプリカが保存されるので、可用性とデータ耐久性が高まります。読み込みの整合性とは、書き込みの成功またはデータ項目の更新が、その同一項目に対するその後の読み込み処理において反映される、方法とタイミングを表します。Amazon DynamoDB ではロジックを公開しており、お客様のアプリケーション内の各読み込みリクエストに、希望する整合性特性を指定できるようにしています。

Q: Amazon DynamoDB の整合性モデルとは何ですか?

Amazon DynamoDB からデータを読み込むとき、ユーザーはその読み込みに対して結果的に整合性のある読み込みを設定するか強い整合性を設定するかを指定できます。

結果的に整合性のある読み込み (デフォルト) – 結果整合性のあるオプションを選択すると、読み込みスループットが最大限に向上します。ただし、結果的に整合性のある読み込みには、最新の書き込み結果が反映されない可能性があります。データの全コピーの整合は通常 1 秒以内に行われます。短時間後に読み込みを繰り返すことによって、更新されたデータが返されます。

強い整合性の読み込み – Amazon DynamoDB には結果整合性のある読み込みに加えて、お客様のアプリケーションまたはアプリケーションの要素が必要とする場合に、強い整合性のある読み込みをリクエストするための、柔軟性と制御が用意されています。強い整合性のある読み込みの結果には、読み込みの前に適切な応答を受け取ったすべての書き込みが反映されています。

Q: DynamoDB では、インプレースアトミック更新がサポートされていますか?

Amazon DynamoDB では、高速なインプレース更新がサポートされています。1 回の API 呼び出しを使用して、1 行の数値属性をインクリメントまたはデクリメントできます。同様に、セット、リスト、マップの追加や削除もアトミックに実行できます。アトミック更新の詳細については、Amazon のドキュメントを参照してください。

Q: Amazon DynamoDB が SSD (Solid State Drive) を使用しているのはなぜですか?

Amazon DynamoDB は SSD（Solid State Drive）でのみ実行されます。SSD は、あらゆる規模のデータの格納およびアクセスに対して、予測可能で低遅延な応答時間を実現するのに役立ちます。また、I/O パフォーマンスが高いので、大容量のリクエスト負荷に対して効率的にサービスを提供でき、リクエストのコストを低く抑えられます。

Q: DynamoDB の保存コストは高いようです。今のユースケースでコスト効果の高いサービスを実現することはできますか?

すべての製品についてそうですが、Amazon DynamoDB の採用をお考えのお客様には、1 つの角度からみた価格だけではなく、ソリューション全体のコストを考慮していただくようお願いしています。データベース負荷に対するサービスを提供する総コストは、リクエストトラフィック要件と保存されているデータ量に基づきます。データベース負荷の多くは、GB あたり高い I/O（高い読み込み/秒および書き込み/秒）を格納する必要があります。Amazon DynamoDB は SSD ドライブに基づいているため、スピニングメディアに比べると GB あたりの格納コストが高くなっていますが、リクエストのコストは大幅に削減できます。標準のデータベース負荷から判断すると、SSD ベースの DynamoDB サービスの総使用コストは、通常、標準のスピニングメディアベースのリレーショナルデータベースまたは非リレーショナルデータベースの使用コストよりも低く抑えられるはずです。ただし、ほとんどアクセスしないデータを大量に格納する必要がある事例では、この DynamoDB は適さない可能性があります。このような場合は、S3 をご利用になることをお勧めします。

保存コストには、AWS リージョン内の複数の施設に各データ項目のコピーを複数格納するコストが含まれることにも注意が必要です。

Q: DynamoDB は大規模アプリケーションのみを対象としていますか?

いいえ。DynamoDB では、シームレスなスケーリングをサポートしているため、アプリケーションの要件の増加に合わせて自動的にスケールできます。DynamoDB は、規模を問わず、高速で予測可能なパフォーマンスが必要な場合に適しています。

Q: どのように Amazon DynamoDB の利用を開始できますか?

[今すぐ申し込む] をクリックして、Amazon DynamoDB を今日から使い始めましょう。そのページから、AWS Management Console または Amazon DynamoDB API のいずれかを使用して Amazon DynamoDB の操作を開始できます。AWS Management Console を使用する場合は、数回クリックするだけで、Amazon DynamoDB でテーブルを作成して使用できるようになります。

Q: DynamoDB ではどのようなクエリ機能がサポートされていますか?

Amazon DynamoDB では、ユーザー定義プライマリキーを使用した GET/PUT オペレーションがサポートされています。プライマリキーはテーブル内の項目の唯一の必須属性で、各項目を一意に識別します。このプライマリキーは、テーブルを作成するときに指定します。それに加え、DynamoDB は、グローバルセカンダリインデックスとローカルセカンダリインデックスを使用してプライマリキー以外の属性をクエリすることができる、柔軟なクエリ機能を提供しています。

プライマリキーは、単一属性パーティションキーまたは複合パーティションソートキーのいずれかになります。例えば、“UserID” は単一属性パーティションのプライマリキーです。これにより、指定されたユーザー ID に関連付けられた項目のデータをすばやく読み込んだり書き込んだりできます。

複合パーティションソートキーは、パーティションキー要素およびソートキー要素としてインデックス化されます。このマルチパートキーにより、1 番目の要素値と 2 番目の要素値の間の階層が維持されます。例えば、複合パーティションソートキーは、“UserID” (パーティション) と “Timestamp” (ソート) の組み合わせにすることができます。パーティションキー要素を一定に保つことで、ソートキー要素を検索して項目を取得することができます。これにより、クエリ API を使用して、例えば、単一の UserID のすべての項目をタイムスタンプの範囲にわたって取得できます。

グローバルセカンダリインデックスとそのクエリ機能の詳細については、よくある質問の「セカンダリインデックス」セクションをご覧ください。

 

Q: Amazon DynamoDB ではデータ項目に対する更新およびクエリをどのように実行しますか?

AWS Management Console または CreateTable API を使用してテーブルを作成したら、PutItem API または BatchWriteItem API を使用して項目を挿入できます。テーブルに追加した項目は、GetItem や BatchGetItems を使用して、または Query API を使用して (テーブルで複合プライマリキーが有効化されており使用されている場合) 取得できます。

Q: Amazon DynamoDB では条件付き演算がサポートされていますか?

はい。対象の項目で実行する挿入、更新、または削除オペレーションに対して条件を指定できます。条件付きオペレーションを実行するには、次から構成される ConditionExpression を定義できます。

• ブール関数の ATTRIBUTE_EXIST、CONTAINS、BEGINS_WITH
• 比較演算子の =、<>、<、>、<=、>=、BETWEEN、IN
• 論理演算子の NOT、AND、OR 

ネストされた句を含む複数の条件句を組み合わせた、自由形式の条件式を構成できます。条件付き演算を使用すると、DynamoDB でオプティミスティック同時実行制御システムを実装できます。条件付きオペレーションの詳細については、 Amazon のドキュメントを参照してください。

Q: キー条件で式はサポートされていますか?

はい。式をクエリ API 呼び出しの一部として指定し、KeyConditionExpression パラメータを使用してテーブルのプライマリキーの値に基づいて結果をフィルタリングすることができます。

Q: パーティションおよびパーティションソートキーで式はサポートされていますか?

はい。パーティションおよびパーティションソートキーの両方で式を使用できます。パーティションおよびパーティションソートキーで機能する式に関する詳細については、ドキュメントページを参照してください。

Q: Amazon DynamoDB ではインクリメント演算またはデクリメント演算がサポートされていますか?

はい。Amazon DynamoDB では、スカラー値でアトミックなインクリメント演算とデクリメント演算を行うことができます。

Q: Amazon DynamoDB、もしくは Amazon RDS または Amazon EC2 でのリレーショナルデータベースエンジンは、どのような場合に使用しますか?

今日のウェブベースのアプリケーションでは、大量のデータが生成および使用されます。例えば、開始当初はわずか数千人のユーザーしかいなかったオンラインゲームがあるとします。データベースの負荷も1秒あたりの書き込み数が10、読み込み数が 50 で取るに足りませんでした。しかし、ゲームが多くの人に受け入れられると、ユーザー数はあっという間に数百万に膨れ上がり、1秒あたりの書き込みおよび読み込み数は何万（場合によっては何十万）に増えることがあります。また、1 日に作成されるデータ量は数テラバイトを超えるかもしれません。Amazon DynamoDB のアプリケーションを開発すると、小さな規模から始めて、要件に応じてダウンタイムなしでテーブルのリクエスト容量を調整できます。プロビジョニングしたリクエスト容量に対してコスト効果の高い料金をお支払いいただくと、Amazon DynamoDB が、お客様のニーズ応じてデータとトラフィックをパーティション化して十分なサーバー容量に分散します。データベースの管理は Amazon DynamoDB が行うので、お客様はデータを格納しリクエストするだけです。また、自動レプリケーションとフェイルオーバーにより、フォールトトレランス、高い可用性、そしてデータ堅牢性を備えています。Amazon DynamoDB によって、データベースが完全に管理され、アプリケーションの要件に応じて拡大できるという安心感を得られます。

Amazon DynamoDB はデータベースの拡張性、管理、パフォーマンス、および信頼性に関する主な問題に対処しますが、リレーショナルデータベースのすべての機能が用意されているわけではありません。複雑なリレーショナルクエリ（結合など）やトランザクションはサポートされていません。この機能が必要な場合、または既存のリレーショナルエンジンと対応させたい場合は、Amazon RDS または Amazon EC2 でリレーショナルエンジンを実行することができます。リレーショナルデータベースエンジンには堅牢な機能が用意されていますが、1 つのリレーショナルデータベースインスタンスを越えて負荷を拡張する作業は複雑で、かなりの時間がかかります。また専門知識も必要です。したがって、新しいアプリケーションで拡張が必要な場合、リレーショナル機能が不要であれば、Amazon DynamoDB を使用することをお勧めします。

Q: Amazon DynamoDB と Amazon SimpleDB の違いは何ですか?

どちらを使用するべきですか?どちらのサービスも非リレーショナルデータベースで、データベース管理作業が不要です。Amazon DynamoDB は、シームレスな拡張性と迅速で予測可能なパフォーマンスを提供することに焦点を当てています。遅延の少ない応答時間を実現するために SSD（Solid State Disk）で実行され、1 つのテーブルのリクエスト容量と保存容量に制限はありません。これは、拡張の要件に合わせて、ご利用のデータと負荷が十分な数のサーバーに分散されるよう Amazon DynamoDB によって自動的にパーティション化されるからです。一方、Amazon SimpleDB テーブルには保存容量に厳格な制限があり 10GB までしか保存できません。また、リクエスト容量も制限されています（通常は 25 書き込み/秒）。追加拡張の必要が出てきた場合、追加の SimpleDB テーブルでのデータのパーティションまたは再パーティションの管理はお客様が行います。SimpleDB は拡張制限がありますが、クエリに柔軟性が必要で、負荷が少ない場合は適しているかもしれません。Amazon SimpleDB では、すべての項目属性が自動的にインデックス化されるので、クエリの柔軟性はサポートされますが、代わりにパフォーマンスと拡張性が低下します。

Amazon における非リレーショナルデータベーステクノロジー革新の詳細については、Amazon CTO である Werner Vogels 氏の DynamoDB ブログの投稿を参照してください。

Q: Amazon DynamoDB と Amazon S3 はどのように使い分けますか?

Amazon DynamoDB には、プライマリキーによってインデックス化された構造化データが格納され、1 バイト～ 400 KB の項目に対して低レイテンシーでの読み込みおよび書き込みアクセスが可能です。Amazon S3 には非構造化 Blob が格納されます。これは最大 5TB の大きなオブジェクトを格納するのに適しています。AWS サービスのコストを最適化するには、大きなオブジェクトまたはアクセス頻度の少ないデータは Amazon S3 に格納します。一方、比較的小さなデータ要素またはファイルポインタ（Amazon S3 オブジェクトへのポインタなど）は Amazon DynamoDB に格納することをお勧めします。

Q: DynamoDB は、どのオペレーティングシステムで実行するアプリケーションでも使用できますか?

はい。DynamoDB は、API を介してアクセスする完全マネージド型のクラウドサービスです。DynamoDB は、どのオペレーティングシステム（例: Linux、Windows、iOS、Android、Solaris、AIX、HP-UX など）で実行するアプリケーションでも使用できます。DynamoDB の使用を開始するには、AWS SDK の使用をお勧めします。AWS SDK の一覧は、開発者用リソースのページにあります。SDK のインストールや使用に問題がある場合は、該当する AWS フォーラムに投稿してお知らせください。

Q: データモデルとは何ですか?

Amazon DynamoDB のデータモデルは次のとおりです。

テーブル: データ項目のコレクションです。リレーショナルデータベースのテーブルが行のコレクションであるのと同様です。各テーブルのデータ項目の数に制限はありません。Amazon DynamoDB はスキーマレスです。テーブルのデータ項目の属性および属性数は同じである必要はありません。各テーブルにはプライマリキーが必要です。プライマリキーは、単一属性キー、または 2 つの属性が組み合わされた「複合」属性キーです。プライマリキーはテーブル内の各項目を一意に識別するので、プライマリキーに指定する属性はすべての項目で存在していなければなりません。

項目: プライマリキーまたは複合キー、および任意の数の属性で構成されます。個別の項目に関連付けられる属性の数に明示的な制限はありませんが、1 つの項目の合計サイズ (すべての属性名と属性値を含む) は 400 KB を超えることはできません。

属性: データ項目に関連付けられる各属性は属性名（「Color」など）と 1 つの値（「Red」など）または値セット（「Red、Yellow、Green」など）で構成されます。各属性のサイズに明示的な制限はありませんが、1 つの項目の合計サイズ（すべての属性名と値を含む）が 400 KB を超えることはできません。

Q: 項目のサイズに制限はありますか?

1 つの項目の合計サイズ（すべての属性名と属性値を含む）は 400 KB を超えることはできません。

Q: 項目に設定できる属性の数に制限はありますか?

項目に設定できる属性の数に制限はありません。ただし、1 つの項目の合計サイズ（すべての属性名と属性値を含む）は 400 KB を超えることはできません。

Q: API とは何ですか?

• CreateTable – テーブルを作成し、データアクセスに使用するプライマリインデックスを指定します。
• UpdateTable – 指定されたテーブルのプロビジョニングされたスループット値を更新します。
• DeleteTable – テーブルを削除します。
• DescribeTables – テーブルサイズ、ステータス、およびインデックス情報を返します。
• ListTables – 現在のアカウントおよびエンドポイントに関連付けられたすべてのテーブルのリストを返します。
• PutItem – 新しい項目を作成するか、古い項目を (すべての属性を含め) 新しい項目で置き換えます。指定したテーブルに同じプライマリキーを持つ項目が存在する場合、既存の項目は新しい項目に完全に置き換えられます。条件付き演算子を使用して、所定の条件に一致する属性値を持つ項目のみを置き換えたり、その項目が存在しない場合にのみ新しい項目を挿入したりすることもできます。
• BatchWriteItem – 1 回のトランザクションとしてではなく、1 回のリクエストにより複数のテーブル間で複数の項目を挿入、置換、削除します。Put または Delete で最大 25 項目のバッチをサポートし、合計リクエストサイズは最大 16 MB です。
• UpdateItem – 既存の項目の属性を編集します。条件付き演算子を使用して、項目の属性値が所定の条件に一致する場合にのみ更新を実行することもできます。
• DeleteItem – プライマリキーを使用してテーブルから 1 つの項目を削除します。条件付き演算子を使用して、項目の属性値が所定の条件に一致する場合にのみ項目を削除することもできます。
• GetItem – GetItem 演算は、プライマリキーに一致する項目の属性セットを返します。GetItem 演算は、デフォルトでは、結果的に整合性のある読み込みを提供します。ご利用のアプリケーションで結果的に整合性のある読み込みを使用できない場合は、ConsistentRead を使用します。
• BatchGetItems – BatchGetItems 演算は、複数の項目の属性を複数のテーブルから、それぞれのプライマリキーを使用して返します。16 件の応答のサイズ制限は 1 MB で、最大 100 個の項目を返します。強い整合性と結果整合性の両方をサポートします。
• Query – テーブルのプライマリキーを使用して、または、セカンダリインデックスからインデックスキーを使用して、1 つ以上の項目を取得します。比較演算子や式を使用すると、テーブルのクエリの範囲を絞りこむことができます。また、非キー属性に対してフィルタを使用することで、クエリ結果をフィルタリングすることもできます。強い整合性と結果整合性の両方をサポートします。応答 1 件あたりのサイズ上限は 1 MB です。
  
• スキャン – テーブルまたはセカンダリインデックスの全体をフルスキャンして、すべての項目および属性を取得します。リターンセットを制限するには、1 つまたは複数の属性と照合するフィルタを指定します。
  

Q: スキャンオペレーションの整合性モデルとは?

スキャンオペレーションでは、結果整合性および整合性のある読み込みがサポートされています。デフォルトでは、スキャンオペレーションは結果整合性です。ただし、整合性モデルはスキャン API 呼び出しのオプションの ConsistentRead パラメータを使用して変更できます。ConsistentRead パラメータを true に設定すると、スキャンオペレーションを整合性のある読み込み操作にすることができます。詳細については、スキャンオペレーションのドキュメントを参照してください。

Q: スキャンオペレーションはどのように作動しますか?

スキャンオペレーションはイテレータと考えることができます。指定したスキャン API リクエストに対してスキャンされた項目の合計サイズが 1 MB の制限を超えると、指定されたリクエストは終了し、取得された結果は（以降のオペレーションでスキャンを続行できるように）LastEvaluatedKey と共に返されます。

Q: スキャンオペレーションに制限はありますか?

テーブルまたはセカンダリインデックスへのスキャンオペレーションあたり、1 MB のデータ制限があります。1 MB の制限を超えると、スキャンオペレーションは終了し、その時点までに一致した値と、以降のオペレーションに適用される LastEvaluatedKey が返され、中止した場所がわかります。

Q: スキャンオペレーションではいくつの読み込み容量ユニットが使用されますか?

必要な読み込みユニットは、スキャンオペレーションで取得されたバイト数を直近の 4 KB 単位に切り上げて 4 KB で除算したものです。整合性のある読み込みでテーブルをスキャンすると、結果的に整合性のある読み込みでスキャンしたときの 2 倍の読み込み容量が消費されます。

Q: DynamoDB ではどのようなデータ型がサポートされていますか?

DynamoDB は、数値、文字列、バイナリ、ブールの 4 種類のスカラーデータ型をサポートします。また DynamoDB は、数値セット、文字列セット、バイナリセット、異種データ型リスト、異種データ型マップの各コレクションデータ型をサポートします。DynamoDB は NULL 値もサポートします。

Q: DynamoDB はどのような型のデータ構造をサポートしますか?

DynamoDB はキー値および文書データ構造をサポートします。

Q: キー値ストアとは何ですか?

キー値ストアはデータベースサービスの 1 つで、格納される実内容を含むキーと値を使用して、特定対象となるオブジェクトのコレクションの保存、クエリ、更新をサポートします。

Q: 文書ストアとは何ですか?

文書ストアは、JSON、XML、HTML などの文書形式の項目の保存、クエリ、更新をサポートします。

Q: DynamoDB には JSON データ型は含まれますか?

いいえ。ただし、文書 SDK を使用して JSON データを直接 DynamoDB に渡すことができます。DynamoDB のデータ型は、JSON によってサポートされるデータ型の上位集合です。文書 SDK は JSON 文書をネイティブの DynamoDB データ型に自動的にマッピングします。

Q: AWS マネジメントコンソールを使用して JSON 文書を表示、編集できますか?

はい。AWS マネジメントコンソールのシンプルな UI を使って、DynamoDB テーブルに保存されている JSON 文書などのデータを解析、編集できます。テーブルのデータを表示、編集するには、AWS マネジメントコンソールにログインし、DynamoDB を選び、表示するテーブルを選択して、[Explore Table] ボタンをクリックします。

Q: DynamoDB での JSON データのクエリに何か違いはありますか?

いいえ。最上位の JSON 要素で、グローバルセカンダリインデックスまたはローカルセカンダリインデックスを作成できます。たとえば、ある個人についての姓、名、郵便番号、友人全員のリストの情報を含む JSON 文書を保存したとします。姓、名および郵便番号は最上位の JSON 要素です。インデックスを作成することで、姓、名または郵便番号に基づいてクエリを実行できます。友人のリストは最上位の要素ではないので、友人リストにインデックスを作成することはできません。グローバルセカンダリインデックスとそのクエリ機能の詳細については、よくある質問の「セカンダリインデックス」セクションをご覧ください。

Q: ネストされた JSON データが DynamoDB に含まれる場合、そのデータの特定要素のみを検索できますか?

はい。GetItem、BatchGetItem、Query、または Scan API を使用するとき、ProjectionExpression を定義してテーブルからどの属性を検索するかを指定できます。これらの属性には、JSON 文書のスカラー、セット、または要素が含まれます。

Q: ネストされた JSON データが DynamoDB に含まれる場合、そのデータの特定要素のみを更新できますか?

はい。DynamoDB の項目を更新するとき、更新対象となる JSON 文書の下位要素を指定できます。

Q: 文書 SDK とは何ですか?

文書 SDK は、JS データ型と DynamoDB データ型間の相互運用性を高める JavaScript のデータ型ラッパーです。この SDK により、リクエストが自動的にラップされます。同様にレスポンスについても、データ型がアンラップされます。詳細および SDK のダウンロードについては、こちらの GitHub リポジトリを参照してください。

 

Q: Amazon DynamoDB に保存できるデータ量に制限はありますか?

いいえ。Amazon DynamoDB テーブルで保存できるデータ量の制限はありません。データセットのサイズが増えると、Amazon DynamoDB では、保存要件に対応するために十分な数のマシンリソースにデータが自動的に分散されます。

Q: 1 つのテーブルから取得できるスループットの量に制限はありますか?

いいえ。API や AWS マネジメントコンソールを使用して、Auto Scaling に設定した容量の上限を引き上げることや、テーブルに手動でプロビジョニングしたスループットを増やすことができます。DynamoDB は大規模な動作が可能であり、実現できる最大スループットに理論的な制限はありません。DynamoDB ではテーブルが複数のパーティションに自動的に分割されます。各パーティションは、独立した並列計算ユニットです。DynamoDB でスループットを増やすには、パーティションを追加します。

スループットレートが 10,000 書き込み/秒または 10,000 読み込み/秒を超える場合は、こちらのオンラインフォームを使用して事前に Amazon までご連絡ください。

Q: Auto Scaling によりスケーリングがトリガーされるときや、プロビジョンドスループットの変更により DynamoDB がスケールアップまたはスケールダウンするとき、Amazon DynamoDB を引き続き利用できますか?

はい。Amazon DynamoDB は、Auto Scaling による管理でも手動による管理の場合でも、利用できる状態のままで、プロビジョンドスループットをスケールアップまたはスケールダウンできるように設計されています。

Q: Amazon DynamoDB でクライアント側のパーティションを管理する必要がありますか?

いいえ。Amazon DynamoDB では、スループット拡張の目的でデータベーステーブルをパーティション化する必要はありません。

Q: Amazon DynamoDB の高い可用性はどのように実現されていますか?

このサービスは、高い可用性を備えた実績のある Amazon のデータセンターで実行されます。このサービスでは、データが同じ AWS リージョン内の 3 つの施設間でレプリケートされるので、サーバー障害の発生やアベイラビリティーゾーンの停止に対する耐障害性が高まります。

Q: Amazon DynamoDB の高い稼働率と耐久性はどのように実現されていますか?

高い稼働率と耐久性を実現するために、Amazon DynamoDB では、同じ AWS リージョン内の 3 つの施設間でデータが同期的にレプリケートされます。

Q: DynamoDB Auto Scaling とは何ですか?

DynamoDB Auto Scaling は、フルマネージド型で、DynamoDB テーブルやグローバルセカンダリインデックスのプロビジョニングされた読み込み容量や書き込み容量を、アプリケーションからのリクエストの増減に合わせて自動的にスケールアップおよびスケールダウンします。

Q: Auto Scaling を使用する必要があるのはなぜですか?

Auto Scaling を使用すると、新しいテーブルを作成する際に十分な容量をプロビジョニングするといった予測は不要になります。さらに、消費されたスループットを継続的にモニタリングし、プロビジョニングされた容量を手動で調整するといった運用上の負担も軽減できます。Auto Scaling により、アプリケーションの可用性は確保され、未使用のプロビジョニングされた容量にかかるコストを削減できます。

Q: Auto Scaling にはどのようなアプリケーションのリクエストパターンおよびワークロードが適していますか?

Auto Scaling は、均一かつ予測可能で、数分から数時間持続する高いスループットまたは低いスループット使用量があるリクエストパターンに最適です。

Q: DynamoDB テーブルまたはグローバルセカンダリインデックスに対して Auto Scaling を有効にするにはどうすればよいですか?

DynamoDB コンソールで新しいテーブルを作成する際、[デフォルト設定の使用] をチェックしたままにすると、Auto Scaling を有効にでき、テーブルのグローバルセカンダリインデックスにも同じ設定を適用することができます。[デフォルト設定の使用] のチェックを外す場合は、プロビジョニングされた容量を手動で設定するか、目標使用率、最小容量と最大容量のカスタム値を指定して Auto Scaling を有効にできます。既存のテーブルの場合は、Auto Scaling を有効にするか、[容量] タブに移動して既存の Auto Scaling 設定を変更できます。インデックスの場合は、[インデックス] タブで Auto Scaling を有効にできます。さらに、CLI や AWS SDK を使用して Auto Scaling をプログラムで管理することもできます。詳細については、DynamoDB 開発者ガイドをご覧ください。

Q: Auto Scaling ではどのような設定ができますか?

Auto Scaling では、目標使用率、プロビジョンドスループットの合計に対し実際に消費されるスループットの割合、ある時点において Auto Scaling でスケールダウン可能な最小容量とスケールアップ可能な最大容量の、3 つの項目を設定できます。デフォルト値の場合、目標使用率は 70% (許容範囲は 20%～80% (1% 単位))、最小容量は 1 ユニット、最大容量はリージョン内のアカウントのテーブル上限です。リージョンレベルのデフォルトのテーブル上限の詳細については、DynamoDB での制限をご覧ください。

Q: 既存の Auto Scaling ポリシーの設定を変更できますか?

はい。既存の Auto Scaling ポリシーの設定はいつでも変更できます。マネジメントコンソールの [容量] タブに移動して変更するか、AutoScaling API を使用して CLI または SDK からプログラムでも変更できます。

Q: Auto Scaling はどのように動作しますか?

DynamoDB テーブルに新しい Auto Scaling ポリシーを作成すると、指定した目標使用率のしきい値が設定された Amazon CloudWatch アラームが作成されます。この値は、CloudWatch に発行される消費された容量とプロビジョニングされた容量のメトリクスに基づき計算されています。テーブルの実際の使用率が特定の時間において逸脱すると、CloudWatch アラームにより Auto Scaling がアクティベートされます。Auto Scaling によってポリシーが評価された後、DynamoDB に対し UpdateTable API リクエストが行われます。これにより、テーブルのプロビジョンドスループット性能は動的に増加または減少し、実際の使用率は目標値に近い値になります。

Q: 1 つの Auto Scaling ポリシーを複数のリージョンにある複数のテーブルに対して有効にすることはできますか?

いいえ。Auto Scaling ポリシーを設定できるのは、単一リージョン内の 1 つのテーブルまたは 1 つのグローバルセカンダリインデックスに対してのみです。

Q: Auto Scaling ポリシーを即座に最大容量にスケールアップまたは最小容量にスケールダウンするよう強制することはできますか?

いいえ。即座に最大容量にスケールアップまたは最小容量にスケールダウンすることはサポートされていません。その代わり、Auto Scaling を一時的に無効にし、必要な期間において必要な容量を手動で設定し、再度 Auto Scaling を有効にすることができます。

Q: Auto Scaling によってトリガーされたスケーリングアクションはどこでモニタリングできますか?

Auto Scaling によってトリガーされたスケーリングアクションのステータスは、マネジメントコンソールの [容量] タブや、[メトリックス] タブにある CloudWatch のグラフでモニタリングできます。

Q: テーブルに有効な Auto Scaling ポリシーがあるかどうかは、どのように確認できますか?

DynamoDB コンソールの左のメニューで [テーブル] をクリックし、アカウント内のすべての DynamoDB テーブルのリストビューを表示します。テーブルに有効な Auto Scaling ポリシーがある場合、Auto Scaling が読み込み、書き込み、または両方で有効かどうかに応じて、[Auto Scaling] 列に READ_CAPACITY、WRITE_CAPACITY、READ_AND_WRITE のいずれかが表示されます。さらに、テーブルの [概要] タブの [テーブルの詳細] セクションにあるプロビジョニングされた容量のラベルでも、Auto Scaling が読み込み、書き込み、または両方で有効かどうかを確認できます。

Q: 有効なポリシーがあるテーブルまたはグローバルセカンダリインデックスを削除した場合、Auto Scaling ポリシーはどうなりますか?

コンソールからテーブルまたはグローバルセカンダリインデックスを削除すると、その Auto Scaling ポリシーやサポートしている Cloud Watch アラームも削除されます。

Q: Auto Scaling を使用する場合、追加料金は発生しますか?

いいえ。DynamoDB および CloudWatch アラームに対して既にお支払いいただいている料金以外に、Auto Scaling を使用するための追加料金はかかりません。DynamoDB の料金の詳細については、DynamoDB 料金表のページをご覧ください。

Q: Auto Scaling により管理されるスループット容量はリザーブドキャパシティーとどのように連携しますか?

Auto Scaling をリザーブドキャパシティーと連携する方法は、プロビジョンドスループット性能と手動で連携する際の現在の方法と同じです。リザーブドキャパシティーは、リザーブドキャパシティーを購入したリージョン内でプロビジョニングされた総容量に適用されます。Auto Scaling によりプロビジョニングされた容量において、最初にリザーブドキャパシティーが消費され、割引料金で課金されます。これを超過する容量に対しては、標準料金で課金されます。購入したリザーブドキャパシティーに対して合計消費量を制限するには、Auto Scaling が有効になっているすべてのテーブルに容量の上限を分散させることで、購入したリザーブドキャパシティーの合計量よりも累積的に少なくすることができます。

Q: グローバルセカンダリインデックスとは何ですか?

グローバルセカンダリインデックスとは、パーティション、またはパーティション/ソートキーを含んでいるインデックスで、テーブルのプライマリキーとは異なります。

テーブル内のデータに効率的にアクセスするため、Amazon DynamoDB はプライマリキー属性用にインデックスを作成して維持します。このため、アプリケーションはプライマリキーの値を指定することで、迅速にデータを取得することができます。しかし多くのアプリケーションでは、プライマリキー以外の属性を使って、データに効率的にアクセスできるようにするセカンダリ（または代替）キーを 1 つ以上設定することで、メリットが得られることがあります。これに対応するために、1 つのテーブルで 1 つ以上のセカンダリインデックスを作成して、それらのインデックスに対してクエリリクエストを実行することができます。

Amazon DynamoDB は、次の 2 種類のセカンダリインデックスをサポートしています。

• ローカルセカンダリインデックス – テーブルとパーティションキーは同じですが、ソートキーが異なるインデックスです。ローカルセカンダリインデックスは、ローカルセカンダリインデックスのすべてのパーティションの範囲が、同じパーティションキーを持つテーブルパーティションに限定されるという意味で "ローカル" です。
• グローバルセカンダリインデックス – テーブルとはパーティションキーまたはパーティション/ソートキーが異なるインデックスです。グローバルセカンダリインデックスは、インデックスに関するクエリが、すべてのパーティションにまたがり、表内のすべての項目を対象とする可能性があるため、「グローバル」と見なされます。 

セカンダリインデックスは、スパース型オブジェクトとして、Amazon DynamoDB が自動的に保持します。項目は、インデックスの定義元のテーブル内に存在する場合のみ、表示されます。このため、インデックスに対するクエリは非常に効率的に実行されます。これは、インデックス内の項目数が、大抵の場合、テーブル内の項目数と比べて非常に少ないためです。

グローバルセカンダリインデックスは、一意でない属性をサポートしているため、テーブル内の非キー属性に対するクエリを有効にすることで、クエリの柔軟性が向上します。

プライマリキーが UserId (パーティション) と GameTitle (ソート) で構成されている DynamoDB テーブルに、プレーヤーの情報を保存するゲームアプリケーションを検討してみましょう。項目には、TopScore、Timestamp、ZipCode などの属性名が付けられています。テーブルの作成時、プライマリキーに関する暗黙的なインデックス（プライマリインデックス）を提供します。このプライマリキーにより、DynamoDB は効率的なクエリをサポートし、特定ユーザーのすべてのゲームに関するハイスコアを返すことができます。

ただし、アプリケーションが特定のゲームに関するユーザーのハイスコアを必要とする場合にプライマリインデックスを使用すると、テーブル全体のスキャンが必要になり、効率が悪くなります。その代わり、パーティションキー要素として GameTitle を、ソートキー要素として TopScore を指定してグローバルセカンダリインデックスを使用することにより、アプリケーションは、ゲームのハイスコアを短時間で取得できます。

GSI はソートキー要素を必要としません。例えば、パーティション要素である GameTitle のみのキーを持つ GSI を設定できます。次の例では、GSI には射影された属性がないため、クエリ対象の GameTitle と一致する属性を持つすべての（プライマリキーによって識別された）項目だけが返されます。

Q: グローバルセカンダリインデックスはいつ使うのですか?

グローバルセカンダリインデックスは、多数の異なる値が存在する属性間の関係を追跡する場合に特に便利です。例えば、テーブルのプライマリパーティションキーとして CustomerID を、グローバルセカンダリインデックスのパーティションキーとして ZipCode を持つ DynamoDB テーブルを作成できます。郵便番号は多数存在し、お客様の数も多数存在するためです。プライマリキーを使用して、任意のお客様に対するレコードをすばやく取得することができます。グローバルセカンダリインデックスを使用すると、特定の郵便番号の地域内に住んでいるすべてのお客様に対して、効率的なクエリを実行することができます。

グローバルセカンダリインデックスの能力を最大限に活用できるように、均一なワークロードに関するベストプラクティスのドキュメントを参照してください。

Q: DynamoDB テーブル用にグローバルセカンダリインデックスを作成するにはどうすればいいですか?

テーブルに関連付ける GSI はいつでも指定できます。テーブルとそのインデックスの作成に関する詳細な手順は、こちらを参照してください。1 テーブルにつき、最大 5 つのグローバルセカンダリインデックスを作成できます。

Q: DynamoDB のローカルバージョンはグローバルセカンダリインデックスをサポートしますか?

はい。DynamoDB のローカルバージョンは DynamoDB をベースとするアプリケーションの開発とテストに役立ちます。DynamoDB のローカルバージョンは、こちらからダウンロードできます。

Q: 射影された属性とは何ですか?

セカンダリインデックスのデータは、テーブルからインデックスへ射影（つまりコピー）された属性から構成されています。セカンダリインデックスを作成する場合、インデックスの代替キーと、インデックスに射影されたその他の属性を定義します。Amazon DynamoDB は、これらの属性とプライマリキー属性をテーブルからインデックスにコピーします。次に、テーブルに対してクエリを実行する場合と同様に、インデックスに対してクエリを実行します。

Q: グローバルセカンダリインデックスキーを、一意でない属性に対して定義できますか?

はい。テーブルに関するプライマリキーとは異なり、GSI インデックスはインデックス対象の属性が一意である必要はありません。例えば GameTitle に関する GSI では、すべてのゲームでユーザーのスコアを追跡するすべての項目に対して、インデックスを作成できます。この例では、GSI に対してクエリを実行すると、ゲーム「TicTacToe」をプレイしたことがあるすべてのユーザーが返されます。

Q: グローバルセカンダリインデックスは、ローカルセカンダリインデックスとどのような点が異なりますか?

グローバルとローカルのセカンダリインデックスはどちらも、クエリの柔軟性を向上させます。LSI が特定のパーティションキーの値に関連付けられるのに対して、GSI はすべてのパーティションキーの値が対象となります。パーティションキーの値が同じ項目は、DynamoDB の同じパーティションを共有しているため、"ローカル" セカンダリインデックスは (同じパーティションに) 一緒に保存される項目のみを対象とします。つまり LSI の目的は、パーティションキーの値が同じで、ソートキーの値が異なる項目に対してクエリを実行することです。例えば、お客様の注文を追跡する DynamoDB テーブルを検討してみましょう。この場合、CustomerId がパーティションキーです。

OrderTime に関する LSI では、効率的なクエリを実行して、特定のお客様が最後に注文した項目を取得することができます。

これとは対照的に、GSI は共通するパーティションキーの値を持つ項目のみに限定されません。その代わり、GSI はプライマリキーと同様、テーブルのすべての項目が対象となります。上記のテーブルの場合、ProductId に関する GSI を使って、特定の製品に関するすべての注文を効率的に検索できます。この場合、GSI のソートキーが指定されないこと、および同じ ProductId を持つ注文が複数存在する場合でも、GSI では個別の項目として保存されるという点に注意してください。

テーブル内のデータとインデックスが同じパーティションに一緒に配置されるようにするため、LSI はすべての要素 (テーブルとインデックス) の合計サイズを、パーティションキー値ごとに 10 GB に制限します。GSI はデータの Co-Location を実行しないため、このような制限はありません。

テーブルへの書き込みを行うと、DynamoDB は影響を受けるすべての LSI を自動的に更新します。これとは対照的に、テーブルに関して定義されているすべての GSI に対する更新は、結果的に整合されます。

LSI では、Query API を使って、射影リストに含まれていない属性を取得することができます。これは、GSI ではサポート対象外の動作になります。

Q: グローバルセカンダリインデックスはどのように動作しますか?

GSI の動作はさまざまな点で、DynamoDB テーブルの動作に似ています。GSI ソートキー要素に関する条件付きフィルターを指定し、パーティションキー要素を使用して、GSI に対するクエリを実行することができます。ただし、一意でなければならない DynamoDB テーブルのプライマリキーと異なる点は、GSI キーは複数の項目で同じ値を取ることができることです。GSI キーが同じ項目が複数存在する場合、これらの項目は個別の GSI 項目として追跡され、GSI クエリを実行すると、そのすべての個別の項目として取得されます。項目の追加、削除、または更新時、DynamoDB は内部的に、GSI の内容が適切に更新されたことを確認します。

DynamoDB は、GSI の射影された属性を、GSI キーおよび一致する項目のプライマリキーと一緒に、GSI データ構造内に保存します。GSI は、ソーステーブル内に存在する、射影された項目に対してストレージを使用します。このため、クエリはテーブルではなく、GSI に対して実行されることになり、クエリの柔軟性とワークロード分散が向上します。したがって、GSI インデックスへのクエリを実行した場合、テーブル内の項目に含まれていて、GSI キー、テーブルのプライマリキー、または射影された属性に含まれていない属性は返されません。GSI へのクエリ実行後、テーブルから追加データを必要とするアプリケーションは、GSI からプライマリキーを取得し、GetItem または BatchGetItem のいずれかの API で使用して、テーブルから目的の属性を取得することができます。GSI は最終的に整合されるため、このパターンを使用するアプリケーションは、GSI への呼び出しと GetItem/BatchItem への呼び出し間でテーブルから削除された項目を格納する必要があります。

DynamoDB は、テーブルに対して対応する変更が実行されると、GSI に対する項目の追加、更新、および削除を自動的に処理します。（GSI キー属性を持つ）項目をテーブルに追加すると、DynamoDB は GSI を非同期的に更新し、新しい項目を追加します。同様に、テーブルから項目を削除すると、DynamoDB は影響を受ける GSI から項目を削除します。

Q: パーティションベースのテーブルとパーティション/ソートスキーマのテーブルに対して、グローバルセカンダリインデックスを作成できますか?

はい、DynamoDB テーブルのプライマリキーの種類にかかわらず、グローバルセカンダリインデックスを作成できます。テーブルにはパーティションキーのみを格納することも、パーティションキーとソートキーの両方を格納することもできます。

Q: グローバルセカンダリインデックスの整合性モデルとは何ですか?

GSI は、結果整合性をサポートしています。テーブルに項目を挿入または更新すると、GSI の同期更新は実行されません。通常の動作条件では、グローバルセカンダリインデックスへの書き込みにかかる時間は 1 秒の数分の 1 です。可能性は低いものの、さらに長い遅延が発生する場合があります。このため、アプリケーションのロジックは、潜在的に期限切れとなる可能性がある GSI クエリ結果を処理できなければなりません。これは、結果整合性のある読み込みをサポートする他の DynamoDB API が示す動作と同じである点に注意してください。

属性 UserId、GameTitle、および TopScore で構成される各項目のハイスコアを追跡するテーブルを検討してみましょう。パーティションキーは UserId で、プライマリソートキーは GameTitle です。アプリケーションがGameTitle「TicTacToe」と UserId「GAMER123」の新しいトップスコアを示す項目を追加し、その後 GSI に関するクエリを実行した場合、新しいスコアがクエリの結果に表示されなくなる可能性があります。ただし GSI の伝搬が終了すると、新しい項目が GSI に関するクエリで表示されるようになります。

Q: テーブルと各グローバルセカンダリインデックスに対して、個別にスループットをプロビジョニングすることはできますか?

はい。GSI はベースとなるテーブルのスループットを個別に管理します。コンソールで新しいテーブルや既存のテーブルに Auto Scaling を有効にするときに、GSI と同じ設定を適用するよう選択することもできます。また、テーブルとグローバルセカンダリインデックスに対して異なるスループットを手動でプロビジョニングすることもできます。

アプリケーションによっては、GSI に関する要求ワークロードは、テーブルや他の GSI に関する要求ワークロードと大幅に異なることがあります。これを示すいくつかのシナリオを以下に示します。

• 少数のテーブルの項目を含んでいる GSI の場合、テーブルと比べて、必要な書き込みスループットは大幅に小さくなります。
• 項目のルックアップを頻繁に実行しない GSI の場合、テーブルと比べて、必要な読み込みスループットは大幅に小さくなります。
• 読み込みが頻繁に実行されるバックグラウンドタスクが使用する GSI の場合、1 日数時間、高い読み込みスループットが必要となることがあります。

必要性が増大するにつれて、テーブルのプロビジョニングされたスループットにかかわらず、GSI のプロビジョニングされたスループットを変更できます。

すべての属性が射影された、全項目の 50% に GSI キーが存在する GSI を持つ DynamoDB テーブルを検討してみましょう。この場合、GSI の書き込みプロビジョニング容量ユニットを、テーブルの書き込みプロビジョニング容量ユニットの 50% に設定する必要があります。同様の方法を使って、GSI の読み込みスループットを見積もることができます。詳細については、DynamoDB GSI のドキュメントを参照してください。

Q: グローバルセカンダリインデックスを追加すると、テーブルのプロビジョニングされたスループットとストレージはどのような影響を受けますか?

DynamoDB テーブルと同じように、GSI は GSI への読み込みまたは書き込みが実行されると、プロビジョニングされたスループットを消費します。GSI 項目を追加または更新する書き込みは、更新サイズに基づいて、書き込み容量ユニットを消費します。GSI 書き込みが消費する容量は、テーブルの項目の更新に必要な容量に追加されます。

DynamoDB テーブルに対して項目の追加、削除、または更新を実行した際に、GSI への変更が発生しなかった場合、GSI は書き込み容量ユニットを消費しません。これは、GSI キー属性を持たない項目を DynamoDB に追加するか、GSI キーまたは射影された属性を変更せずに項目を更新した場合に発生します。

GSI へのクエリは、クエリの調査対象の項目サイズに基づいて、読み込み容量ユニットを消費します。

GSI のストレージコストは、対象の GSI に保存される総バイト数をベースにしています。これには、GSI キー、射影された属性とその値、およびインデックス作成用の 100 バイトのオーバーヘッドが含まれます。

Q: DynamoDB を使用した場合、GSI のプロビジョニングされたスループットが原因で、アプリケーションからテーブルへの書き込み速度が抑制されることはありますか?

DynamoDB テーブルへの一部またはすべての書き込みでは、関連する GSI への書き込みも行われるため、GSI のプロビジョニングされたスループットを使い果たしてしまう可能性があります。このようなシナリオでは、テーブルへの以降の書き込みは抑制されます。テーブルに使用可能な書き込み容量ユニットがある場合でも、このような事態が発生する可能性があります。

Q: インデックスレベルで、プロビジョニングされたスループットを変更できる頻度はどれ位ですか?

GSI が存在するテーブルには、スループット変更操作に関して、通常のテーブルと同じ日次制限があります。

Q: DynamoDB グローバルセカンダリインデックスの料金はどのように課金されますか?

テーブルとテーブルの GSI に対する集約プロビジョニングされたスループットが 1 時間単位で課金されます。必須ではありませんが、手動でプロビジョニングする場合は、テーブルとテーブルの GSI に対する集約プロビジョニングされたスループットが 1 時間単位で課金されます。さらに、GSI が占有するデータストレージに対する料金と、標準のデータ転送 (外部) 料金が課金されます。GSI のプロビジョンドスループット性能を変更するには、DynamoDB コンソール、UpdateTable API、PutScalingPolicy API のいずれかを使用して Auto Scaling ポリシーの設定を更新します。

Q: クエリに対して、どのグローバルセカンダリインデックスを使用するか指定することはできますか?

はい。一般的なクエリパラメータに加え、GSI Query コマンドは、操作対象の GSI 名を明示的に含みます。クエリは 1 つの GSI しか使用できないことに注意してください。

Q: グローバルセカンダリインデックスでは、どの API 呼び出しがサポートされていますか?

GSI がサポートする API 呼び出しは、Query と Scan です。Query 操作はインデックスキー属性値だけを検索し、比較演算子のサブセットをサポートします。GSI は非同期で更新されるため、クエリでConsistentRead パラメータを使用することはできません。クエリとスキャンで GSI を使用する詳細については、こちらを参照してください。

Q: グローバルセカンダリインデックスへのスキャン結果は、どのような順序になりますか?

パーティションのみのキースキーマを持つグローバルセカンダリインデックスの場合、順序付けは行われません。パーティションソートキースキーマを持つグローバルセカンダリインデックスの場合、同じパーティションキーの結果は、ソートキー属性に基づいて順序付けされます。

Q: テーブル作成後、グローバルセカンダリインデックスを変更できますか?

はい。グローバルセカンダリインデックスは、テーブルの作成後でもいつでも変更できます。

Q: 既存のテーブルにグローバルセカンダリインデックスを追加するにはどうすればよいですか?

コンソールまたは API 呼び出しを使って、グローバルセカンダリインデックスを追加できます。DynamoDB コンソールで、まずグローバルセカンダリインデックスの追加先のテーブルを選択し、[Create Index] ボタンをクリックして新しいインデックスを追加します。インデックス作成ウィザードの手順に従い、完了したら [Create] を選択します。UpdateTable API 呼び出しと GlobalSecondaryIndexes パラメータを組み合わせて使って、グローバルセカンダリインデックスを追加/削除することもできます。詳細については、ドキュメントページを参照してください。

Q: グローバルセカンダリインデックスを削除するにはどうすればよいですか?

コンソールまたは API 呼び出しを使って、グローバルセカンダリインデックスを削除できます。DynamoDB コンソールで、グローバルセカンダリインデックスを削除するテーブルを選択します。次に、[Table Items] で [Indexes] タブを選択し、横にある [Delete] ボタンを使ってインデックスを削除します。UpdateTable API 呼び出しを使ってグローバルセカンダリインデックスを削除することもできます。詳細については、ドキュメントページを参照してください。

Q: 1 回の API 呼び出しで、同じテーブルの 1 つ以上のインデックスを追加/削除できますか?

1 回の API 呼び出しでは追加/削除できるのは、1 つのインデックスだけです。

Q: 同じインデックスを追加するための複数のリクエストを送信するとどうなりますか?

最初の追加リクエストだけが受け付けられ、最初の追加リクエストが完了するまで、その後の追加リクエストは失敗します。

Q: 同じテーブル上の数個のインデックスを同時に追加/削除できますか?

いいえ。1 つのテーブルで一度に行えるのは 1 つのインデックスの追加/削除操作だけです。

Q: グローバルセカンダリインデックスを追加するために、追加のスループットをプロビジョニングする必要がありますか?

Auto Scaling を使用する場合は、テーブルと同じ設定をグローバルセカンダリインデックスにも適用することをお勧めします。必須ではありませんが、手動でプロビジョニングする場合は、インデックス用のスループットとは別に追加の書き込みスループットをプロビジョニングすることを強くお勧めします。追加の書き込みスループットをプロビジョニングしないと場合、新しいインデックスの追加には、インデックスの書き込みスループットが使用されます。これにより、インデックス作成中のインデックスの書き込みパフォーマンスに影響を及ぼし、新しいインデックスの作成にさらに時間がかかります。

Q: インデックスの作成後、グローバルセカンダリインデックスの追加スループットを減らす必要がありますか?

はい。インデックスの作成が完了したら、インデックス追加のためにプロビジョニングした追加の書き込みスループットを元に戻す必要があります。

Q: グローバルセカンダリインデックス追加のためにプロビジョニングした書き込みスループットを変更できますか?

はい。インデックス作成のためにプロビジョニングしたスループットは、作成中にいつでも調整できます。

Q: グローバルセカンダリインデックスの追加/削除中、テーブルを使用できますか?

はい。グローバルセカンダリインデックスの更新中もテーブルを使用できます。

Q: グローバルセカンダリインデックスの追加/削除中、既存のインデックスを使用できますか?

はい。グローバルセカンダリインデックスの更新中も既存のインデックスを使用できます。

Q: グローバルセカンダリインデックスの作成中、新しいインデックスを使用できますか?

いいえ。新しいインデックスは、インデックスの作成が完了すると使用可能になります。

Q: グローバルセカンダリインデックスの追加にかかる時間はどれくらいですか?

追加にかかる時間は、テーブルサイズと、グローバルセカンダリインデックスの作成にプロビジョニングされた追加の書き込みスループットの量によって異なります。インデックスの追加/削除にかかる時間は、数分から数時間まで大きく異なります。例えば、500 の書き込みキャパシティーユニットがプロビジョニングされた 1 GB のテーブルがあり、インデックスと新しいインデックス作成のために追加の書き込みキャパシティーを 1000 プロビジョニングしたとします。新しいインデックスにテーブルのすべての属性が含まれ、テーブルがすべての書き込みキャパシティーユニットを使用している場合、インデックスの作成にかかる時間は約 30 分です。

Q: グローバルセカンダリインデックスの削除にかかる時間はどれくらいですか?

インデックスの削除は通常、数分で完了します。例えば、1 GB のデータを持つインデックスの削除は通常 1 分未満で完了します。

Q: グローバルセカンダリインデックスの追加/削除操作の進行状況を追跡するにはどうすればよいですか?

テーブルに関連付けられているすべてのインデックスの状況を確認するには、DynamoDB コンソールまたは DescribeTable API を使用します。インデックスの追加操作の場合、インデックスの作成中、インデックスの状況は [CREATING] となります。インデックスの作成が完了すると、インデックスの状況は [CREATING] から [ACTIVE] に変わります。インデックスの削除操作の場合、リクエストが完了すると、削除されたインデックスは表示されなくなります。

Q: グローバルセカンダリインデックス追加のためのインデックス作成が完了したら通知を受け取ることはできますか?

インデックスの追加が完了したことを確認する通知を自分のメールアドレス宛てに送信するようリクエストすることができます。コンソールを使ってインデックスを追加する場合は、インデックス作成前の最後のステップで通知をリクエストできます。インデックス作成が完了すると、DynamoDB は指定されたメールアドレスに SNS 通知を送信します。

Q: すでに 5 つのローバルセカンダリインデックスがある場合に、もう 1 つ追加しようとするとどうなりますか?

GSI は現在 5 つまでに制限されています。[Add] 操作が失敗し、エラーが表示されます。

Q: 削除したインデックスの名前を、グローバルセカンダリインデックスで再使用できますか?

はい。グローバルセカンダリインデックスの削除後、新しいインデックスを追加する際にそのインデックス名を再使用できます。

Q: インデックスの作成中にインデックスの追加をキャンセルできますか?

いいえ。インデックスの作成プロセスが開始したら、作成プロセスをキャンセルすることはできません。

Q: DynamoDB のすべての項目で、GSI キー属性は必要ですか?

いいえ。GSI はスパース型インデックスです。プライマリキーの所有要件とは異なり、DynamoDB テーブル内の項目は GSI キーを含む必要がありません。GSI キーにパーティション要素とソート要素の両方が存在し、テーブルの項目でこの 2 つのいずれかが省略されている場合、対応する GSI によってその項目のインデックスが作成されることはありません。このような場合、一般的でない属性を持つ項目を効率的に特定するには、GSI が非常に有効です。

Q: グローバルセカンダリインデックスから DynamoDB テーブルの属性をすべて取得することはできますか?

GSI に関するクエリでは、作成時に GSI に含めるように指定された属性だけが返されます。GSI に含まれる属性は、GSI のキー属性やテーブルのプライマリキー属性、射影するようにユーザーが指定した属性など、デフォルトで射影される属性です。このため GSI クエリでは、テーブルに含まれていて、GSI に含まれていない項目の属性は返されません。すべての属性を射影された属性として指定する GSI を使って、任意のテーブル属性を取得できます。クエリで GSI を使用する詳細については、こちらを参照してください。

Q: テーブルに関連付けられている GSI を一覧表示するにはどうすればいいですか?

DescribeTable API は、テーブルのグローバルセカンダリインデックスに関する詳細情報を返します。

Q: どのデータ型をインデックス化できますか?

ローカルセカンダリインデックスキーのソートキー要素に、すべてのスカラーデータ型 (数値、文字列、バイナリ、ブール) を使用できます。セット型、リスト型、マップ型にインデックスは作成できません。

Q: 複合属性のインデックスは可能ですか?

いいえ。ただし、属性を文字列に連結して、キーとして使用することはできます。

Q: GSI の射影された属性に含まれるのはどのデータ型ですか?

任意のデータ型を GSI に射影するように属性を指定できます。

Q: GSI のスケーラビリティに関する考慮事項は何ですか?

DynamoDB テーブルのプライマリキーに関するパフォーマンスの考慮事項が、GSI キーにも適用されます。GSI では、すべてのキーで比較的ランダムなアクセスパターンが使用されていると見なされます。セカンダリインデックス用にプロビジョンされるスループットを最大限活用するには、独自の大きな値を持つ GSI パーティションキー属性と、できるだけランダムとなるように均一に要求される GSI ソートキー属性を選択する必要がありあす。

Q: グローバルセカンダリインデックスに対して、CloudWatch を介して使用できる新しいメトリクスは何ですか?

GSI を設定したテーブルは、テーブルと GSI の集計メトリクス、およびテーブルと各 GSI の分割メトリクスを提供します。

個々の GSI のレポートでは、テーブルがサポートする CloudWatch メトリクスのサブセットがサポートされます。具体的には次のとおりです。

• 読み込み容量（プロビジョンされた読み込み容量、消費された読み込み容量）
• 書き込み容量（プロビジョニングされた書き込み容量、消費された書き込み容量）
• 調整された読み込みイベント
• 調整された書き込みイベント

DynamoDB テーブルとインデックスがサポートするメトリクスの詳細については、こちらを参照してください。

Q: グローバルセカンダリインデックスをスキャンするにはどうすればよいですか?

グローバルセカンダリインデックスをスキャンするには、コンソールまたはスキャン API を使用します。

グローバルセカンダリインデックスをスキャンするには、スキャン対象テーブルの名前に加えて、インデックスを明示的に参照します。インデックスパーティション属性の名前と値を指定する必要があります。インデックスキーソート属性に対してオプションで条件を指定できます。

Q: グローバルセカンダリインデックスのスキャンでは、射影されていない属性を結果セットに入れて返すように指定できますか?

グローバルセカンダリインデックスのスキャンでは、射影されていない属性は取得できません。

Q: インデックスは並列スキャンできますか?

はい、インデックスは並列スキャンできます。構文はメインテーブルの構文と同じです。

Q: ローカルセカンダリインデックスとは何ですか?

ローカルセカンダリインデックスを使用すると、一般的なクエリを簡単にコスト効率のよい方法で実行できます。ローカルセカンダリインデックスを使用しない場合は、多数の項目を取得し、結果をフィルタリングする必要があります。つまり、アプリケーションには、より幅広い属性をベースにした、より柔軟なクエリを使用できます。

パーティション内の特定の項目 (同一のパーティションキーを共有する項目) を検索する場合は、ローカルセカンダリインデックスを呼び出す前に、DynamoDB は単一のパーティションキーを共有するすべてのオブジェクトを取得し、結果をフィルタリングします。例えば、顧客 ID 注文のタイムスタンプのパーティションソートスキーマを使用して、DynamoDB テーブルに顧客注文データを保存する e コマースアプリケーションがあるとします。LSI がない場合、“顧客 X によって行われた、出荷日が過去 30 日間のすべての注文を出荷日別に並べ替えて表示する” という質問の答えを見つけるには、Query API を使用してパーティションキー “X” を持つすべてのオブジェクトを取得し、結果を出荷日で並べ替え、古いレコードを除外することが必要でした。

ローカルセカンダリインデックスにより、この処理が簡略化されます。「出荷日」属性でインデックスを作成し、このクエリを効率よく実行して、必要な項目だけを取得します。これにより、特定の基準を満たす項目だけが取得されるため、クエリのレイテンシーとコストが大幅に減少します。さらに、結果をフィルタリングするためのカスタマーロジックを作成する必要がないため、アプリケーションのプログラミングモデルが簡略化されます。この新しいセカンダリインデックスを ‘ローカル’ セカンダリインデックスと呼びます。理由は、このインデックスがパーティションキーとともに使用され、パーティションキーバケット内をローカルに検索できるためです。そのため、以前はパーティションキーとソートキーを使用して検索することしかできなかったのに対し、現在ではソートキーの代わりにセカンダリインデックスを使用して検索することもできます。これにより、効率的に実行できるクエリに使用可能な属性の数が増加します。

データ属性の冗長コピーが、定義したローカルセカンダリインデックスにコピーされます。これらの属性には、テーブルのパーティションおよびソートキーと、ユーザーが定義する代替のソートキーが含まれています。他のデータ属性をローカルセカンダリインデックスに冗長的に格納することもでき、テーブル自体にアクセスせずに、それらの他の属性にアクセスできます。

ローカルセカンダリインデックスはすべてのアプリケーションに適しているわけではありません。ローカルセカンダリインデックスでは、単一のパーティションキー値に保存できるデータ量に一定の制約があります。詳しくは、項目コレクションに関する以下の「よくある質問」の項目を参照してください。

Q: 射影とは何ですか?

ローカルセカンダリインデックスにコピーされる一連の属性を射影と呼びます。射影により、最も効率よく取得できる属性が決定します。ローカルセカンダリインデックスにクエリを行う場合、Amazon DynamoDB から任意の射影された属性にアクセスできますが、その際のパフォーマンス特性は、それらの属性が独自のテーブルにある場合と同じです。射影されていない属性を取得する必要がある場合、Amazon DynamoDB は自動的にそれらの属性をテーブルから取得します。

ローカルセカンダリインデックスを定義する場合は、インデックスに射影される属性を指定する必要があります。少なくとも、各インデックスエントリは、(1) テーブルのパーティションキー値、(2) インデックスソートキーとして機能する属性、(3) テーブルソートキー値で構成されている必要があります。

この最小限の構成に限定されず、他の非キー属性のユーザー指定リストを選択してインデックスに射影することもできます。すべての属性をインデックスに投影することもできます。その場合、インデックスはテーブル自体と同じデータを複製しますが、データはユーザーが指定する別のソートキーによって編成されます。

Q: LSI を作成するにはどうすればよいですか?

LSI は、テーブル作成時に作成する必要があります。現時点では、後から追加することはできません。LSI を作成するには、次の 2 つのパラメータを指定します。

Indexed Sort key – インデックス化されてクエリの対象となる属性です。

Projected Attributes – テーブルにある属性のうち、ローカルセカンダリインデックスに直接コピーされる属性のリストです。ローカルセカンダリインデックスにコピーされた属性は、テーブルの全項目を含むプライマリインデックスからデータを取得することなく迅速に取得できます。射影された属性を使用しない場合、ローカルセカンダリインデックスにはプライマリインデックスキーとセカンダリインデックスキーのみが含まれます。

Q: LSI の整合性モデルとは何ですか?

プライマリインデックスが更新されると、ローカルセカンダリインデックスが自動的に更新されます。プライマリインデックスからの読み込みと同様に、LSI は厳密な整合性のある読み込みオプションまたは最終的な整合性のある読み込みオプションの両方をサポートしています。

Q: ローカルセカンダリインデックスにはテーブル内のすべての項目への参照が含まれているのですか?

いいえ、必ずしもそうではありません。ローカルセカンダリインデックスは、その LSI 用に指定された、インデックス化されたソートキーを含む項目のみを参照します。DynamoDB の柔軟なスキーマは、必ずしもすべての項目がすべての属性を含むとは限らないことを意味します。

つまり、ローカルセカンダリインデックスは、プライマリインデックスに比べて、含まれる属性が少ない場合があります。ローカルセカンダリインデックスは、スパース型であるため、共通でない属性に対するクエリをサポートするために効率的です。

例えば、前に説明した Orders の例では、お客様は項目の中に、注文を取り消した場合（CanceledDateTime や CanceledReason など）にのみ含まれる追加の属性を持っている場合があります。取り消された項目に関連したクエリでは、どちらの属性についても、ローカルセカンダリインデックスが効率的です。インデックスで参照される唯一の項目は、これらの属性が設定されていた項目であるためです。

Q: ローカルセカンダリインデックスへのクエリを行うには、どうすればよいですか?

ローカルセカンダリインデックスへのクエリは、Query API を介してのみ実行できます。

ローカルセカンダリインデックスへのクエリを行うには、クエリ対象テーブルの名前に加えて、インデックスを明示的に参照します。インデックスパーティション属性の名前と値を指定する必要があります。インデックスキーソート属性に対してオプションで条件を指定できます。

クエリで、プライマリに格納された射影されていない属性を取得できます。そのためには、追加の読み取り容量ユニットのコストはかかりますが、テーブル取得オペレーションを実行します。

厳密な整合性のある読み込みと最終的な整合性のある読み込みの両方が、ローカルセカンダリインデックスを使用したクエリでサポートされています。

Q: ローカルセカンダリインデックスを作成するには、どうすればよいですか?

ローカルセカンダリインデックスは、テーブル作成時に定義する必要があります。また、テーブルのプライマリインデックスで複合パーティションソートキーを使用する必要があります。

Q: 既存のテーブルにローカルセカンダリインデックスを追加できますか?

いいえ、現時点では既存のテーブルにローカルセカンダリインデックスを追加することはできません。Amazon では、この機能を追加するように作業を進めており、将来この機能をリリースする予定です。ローカルセカンダリインデックスを使用してテーブルを作成する場合、現在使用されていないソートキー要素を定義して、将来使用するためのローカルセカンダリインデックスを作成することもできます。ローカルセカンダリインデックスはスパース型なので、使用時までコストは発生しません。

Q: 1 つのテーブルに何個のローカルセカンダリインデックスを作成できますか?

各テーブルに最大 5 個のローカルセカンダリインデックスを作成できます。

Q: 射影された非キー属性は、1 つのテーブルにつき何個作成できますか?

各テーブルに最大 20 個の射影された非キー属性を作成できます。この数は、テーブル内のすべてのローカルセカンダリインデックスの合計です。また、各インデックスで、プライマリインデックスからすべての非キー属性が射影されるように指定することもできます。

Q: インデックスを作成後に変更できますか?

いいえ、インデックスを作成後に変更することはできません。Amazon では、この機能を追加するように作業中です。

Q: ローカルセカンダリインデックスは削除できますか?

いいえ、現時点では、ローカルセカンダリインデックスを作成後にテーブルから削除することはできません。テーブル全体を削除した場合は、ローカルセカンダリインデックスも削除されます。Amazon では、この機能を追加するように作業を進めており、将来この機能をリリースする予定です。

Q: ローカルセカンダリインデックスではプロビジョニングされた容量はどのように使用されますか?

ローカルセカンダリインデックス用の容量を明示的にプロビジョニングする必要はありません。プロビジョニングされた容量は、ローカルセカンダリインデックスが関連付けられているテーブルの一部として使用されます。

LSI からの読み込みおよび LSI を含むテーブルへの書き込みでは、データ 1 KB ごとに 1 ユニットという標準式に基づいて容量が使用されますが、次の違いがあります。

書き込みに含まれるデータが 1 つ以上のローカルセカンダリインデックスに関連している場合、書き込みは適切なローカルセカンダリインデックスにミラーリングされます。その場合、書き込み容量はテーブル自体のために使用され、追加の書き込み容量が関連する各 LSI のために使用されます。

更新によって既存の項目が上書きされる場合、2 つのオペレーション（削除と挿入）が実行され、データ 1 KB ごとに書き込み容量の追加ユニットが使用されます。

LSI に射影されていない属性が読み込みクエリで要求された場合、DynamoDB はそれらの属性をプライマリインデックスから取得します。この暗黙的な GetItem 要求では、取得する項目データ 4 KB あたり 1 ユニットの読み込み容量が使用されます。

Q: ローカルセカンダリインデックスはどれくらいのストレージを使用しますか?

ローカルセカンダリインデックスでは、すべての射影された非キー属性について、各 LSI のプライマリキーおよびインデックスキーの属性名と値のためにストレージが使用されます。それに加えて、LSI に射影された項目ごとに 100 バイトが使用されます。

Q: どのデータ型をインデックス化できますか?

ローカルセカンダリインデックスキーのソートキー要素として、すべてのスカラーデータ型 (数値、文字列、バイナリ) を使用できます。セット型は使用できません。

Q: どのデータ型をローカルセカンダリインデックスに射影できますか?

すべてのデータ型 (セット型を含む) をローカルセカンダリインデックスに射影できます。

Q: 項目コレクションとは何ですか? また、LSI とどのように関係していますか?

Amazon DynamoDB では、項目コレクションとは、テーブルおよびテーブルのすべてのローカルセカンダリインデックス全体で同じパーティションキーを持つ任意の項目グループです。従来のパーティション化 (またはシャーディング) されたリレーショナルデータベースシステムでは、シャードまたはパーティションと呼ばれており、1 つのパーティションキーに含まれるすべてのデータベース項目または行を指していました。

項目コレクションは、ローカルセカンダリインデックスを含むすべてのテーブルに対して自動的に作成され、維持されます。DynamoDB では、各項目コレクションが単一のディスクパーティションに格納されます。

Q: 項目コレクションのサイズに制限はありますか?

Amazon DynamoDB のすべての項目コレクションには、10 ギガバイトの最大サイズ制限が適用されます。任意の個別パーティションキー値の場合、テーブルの項目サイズの合計と、そのテーブルのすべてのローカルセカンダリインデックス全体の項目サイズの合計を足したサイズが、10 GB を超えてはなりません。

項目コレクションに対する 10 GB 制限は、ローカルセカンダリインデックスを含まないテーブルには適用されません。1 つ以上のローカルセカンダリインデックスを含むテーブルのみに影響します。

個々の項目コレクションはサイズが制限されていますが、ローカルセカンダリインデックスを含むテーブル全体のストレージサイズは制限されません。Amazon DynamoDB のインデックス化されたテーブルの合計サイズは、実質的に無制限です。ただし、任意の 1 つのパーティションキーの合計ストレージサイズ (テーブルとインデックス) が 10 GB のしきい値を超えない場合に限ります。

Q: 項目コレクションのサイズを追跡するには、どうすればよいですか?

DynamoDB の書き込み API（PutItem、UpdateItem、DeleteItem、および BatchWriteItem）に含まれているオプションを使用すると、関連する項目コレクションのサイズ予測を API 応答に含めることができます。この予測には、特定の項目コレクション内のデータの下限および上限サイズ予測（ギガバイト単位）が含まれます。

項目コレクションのサイズを監視するようにアプリケーションを設定することをおすすめします。アプリケーションは項目コレクションのサイズに関して API 応答を検査し、項目コレクションがユーザー定義の制限（例えば 8 GB）を超えた場合はエラーメッセージをログに記録する必要があります。これが早期警告システムとなり、項目コレクションが大きくなりすぎていることが通知され、対処するための十分な時間が与えられます。

Q: 項目コレクションの 10 GB の制限を超えた場合は、どうすればよいですか?

特定の項目コレクションが 10 GB の制限を超過した場合は、新しい項目を書き込めなくなります。また、その特定のパーティションキーについて既存の項目のサイズを大きくすることもできません。項目コレクションのサイズを縮小させる読み込みおよび書き込みオペレーションは、引き続き実行できます。テーブル内の他の項目コレクションは影響されません。

この問題に対処するには、項目を削除したり、10 GB を超過したコレクションの項目サイズを減らしたりします。または、この問題を回避するために、新しいパーティションキー値で新しい項目を作成できます。頻繁にはアクセスされない履歴データがテーブルに含まれている場合は、Amazon S3、Amazon Glacier または他のデータストアにアーカイブすることを検討してください。

Q: ローカルセカンダリインデックスをスキャンするにはどうすればよいですか?

ローカルセカンダリインデックスをスキャンするには、スキャン対象テーブルの名前に加えて、インデックスを明示的に参照します。インデックスパーティション属性の名前と値を指定する必要があります。インデックスキーソート属性に対してオプションで条件を指定できます。

スキャンで、プライマリインデックスに格納された射影されていない属性を取得できます。そのためには、テーブル取得オペレーションを実行します。ただし、追加の読み込み容量ユニットのコストがかかります。

Q: ローカルセカンダリインデックスのスキャンでは、射影されていない属性を結果セットに入れて返すように指定できますか?

ローカルセカンダリインデックスのスキャンでは、射影されていない属性は取得できません。

Q: ローカルセカンダリインデックスへのスキャン結果は、どのような順序になりますか?

ローカルセカンダリインデックスの場合、コレクション内での順序は、インデックスが作成された属性に基づいて決まります。

Q: DynamoDB の FGAC（Fine-Grained Access Control）とは何ですか?

FGAC（Fine Grained Access Control）とは、DynamoDB テーブルの所有者がテーブル内のデータに対して詳細なコントロールを行うための機能です。具体的には、テーブル所有者は誰（呼び出し元）がテーブルのどの項目や属性にアクセスでき、どのようなアクション（読み込み/書き込み）を実行できるかを指定できます。FGAC は、AWS Identity and Access Management（IAM）と組み合わせて使用されます。セキュリティ認証情報および対応するアクセス権限の管理は、IAM で行います。

Q: DynamoDB FGAC の一般的なユースケースを教えてください。

FGAC が効果を発揮するのは、DynamoDB テーブルを使用して情報をトラッキングするアプリケーションにおいて、エンドユーザー（またはエンドユーザーの代理となるアプリケーションクライアント）がテーブルの読み取りや変更を、中間層サービスなしで直接行う必要がある場合です。たとえば、「Acme」という名前のモバイルアプリで FGAC を使用し、Acme ユーザーそれぞれのトップスコアを DynamoDB テーブル内でトラッキングします。FGAC を利用すると、アプリケーションクライアントが変更するのはアプリを実行しているユーザーのトップスコアだけとなるように制限できます。

Q: JSON 文書では Fine Grain Access Control を使用できますか?

はい。Fine Grain Access Control（FGAC）を使用して、文書の最上位の属性に基づいてデータへのアクセスを制限できます。FGAC を使用して、ネストされた属性に基づいてアクセスを制限することはできません。たとえば、ある個人についての ID、姓、名、友人全員のリストの情報を含む JSON 文書を保存したとします。FGAC を使用して、ID、姓、名に基づいてアクセスを制限できますが、友人リストに基づいて制限することはできません。

Q: FGAC を使用しない場合は、どのようにすれば項目レベルでアクセスをコントロールできるのですか?

このレベルのコントロールを FGAC なしで達成する方法はいくつかありますが、いずれも手間がかかる可能性があります。たとえば、次のようなものです。

1. プロキシ: アプリケーションクライアントはリクエストを仲介プロキシに送信し、このプロキシが認証と認可を実行します。このような方法では、システムアーキテクチャが複雑になり、総所有コスト（TCO）が上昇する可能性があります。
2. クライアント別テーブル: アプリケーションクライアントそれぞれに専用のテーブルを割り当てます。アプリケーションクライアントはそれぞれ別のテーブルにアクセスするので、互いに干渉することはありません。この方法では、作成するテーブルの数が膨大になる可能性があり、したがってデータベース管理がきわめて煩雑になります。
3. クライアント別埋め込みトークン: 秘密のトークンをアプリケーションクライアントに埋め込みます。この方法の欠点は、トークンの変更や、保存されているデータへの影響の扱いが難しいことです。この方法では、クライアントからアクセスできる項目のキーに秘密のトークンを格納します。

Q: DynamoDB FGAC のしくみを教えてください。

FGAC を使用する場合は、アプリケーションはセキュリティトークンをリクエストします。このトークンは、特定の DynamoDB テーブル内の特定の項目のみへのアクセスをアプリケーションに認可するものです。このトークンを使用して、エンドユーザーアプリケーションエージェントは DynamoDB に対して直接リクエストを発行します。このリクエストが受信されると、リクエストの認証情報が DynamoDB によって検証されます。リクエストの認証には IAM が使用され、そのユーザーにどの操作を許可するかが決定します。ユーザーのリクエストが許可されない場合は、データへのアクセスが FGAC によって阻止されます。

Q: DynamoDB FGAC の料金はどれくらいですか?

FGAC は追加料金なしで使用できます。通常どおり、お支払いいただくのは DynamoDB テーブルに関連してプロビジョニングされたスループットとストレージの料金のみです。

Q: 使用を開始する方法を教えてください。

DynamoDB 開発者ガイドの「Fine-Grained Access Control」のセクションをご覧ください。ここでは、アクセスポリシーを作成し、アプリ用の IAM ロールを作成して（例: AcmeFacebookUsers というロールを Facebook アプリ ID 34567 用に作成）、ロールにアクセスポリシーを割り当てる方法を説明しています。どの認証プロバイダが受け入れられるか（例: Login with Amazon、Facebook、または Google）はロールの信頼ポリシーによって決まり、どの AWS リソースにアクセスできるか（例: DynamoDB テーブル）はアクセスポリシーで規定されます。これで、アプリがロールを使用して DynamoDB に対する一時的認証情報を取得できるようになります。取得するには、AWS Security Token Service（STS）の AssumeRoleWithIdentityRequest API を呼び出します。

Q: ユーザーにローカルセカンダリインデックスへのクエリを許可するが、射影されない属性を取り出すテーブルフェッチを禁止するには、どうすればよいでしょうか。

ローカルセカンダリインデックスに対するクエリ操作の中には、他の操作と比較して高コストになるものがあります。それは、インデックスとして射影されていない属性を要求している場合です。このような高コストの可能性がある「フェッチ」操作を制限するには、射影された属性のみにアクセスできるように権限を設定します。このようにするには、「dynamodb:Attributes」コンテキストキーを使用します。

Q: 特定の属性に対するユーザーアクセスを禁止するには、どうすればよいでしょうか?

特定の属性へのアクセスを禁止するには、最小権限の原則に従い、特定の属性へのアクセスのみを許可することをお勧めします。

別の方法としては、アクセスを許可しない属性を Deny ポリシーで指定するというものがあります。ただし、この方法は次のような理由からお勧めできません。

1. Deny ポリシーによる方法では、隠された属性名をユーザーが発見することも可能です。リクエストを繰り返し発行して、考えられる属性名を 1 つずつ指定していくと、最終的にそのユーザーはアクセスを拒否されます。
2. Deny ポリシーは脆弱です。将来 DynamoDB に新しい API 機能が導入されたときに、開発者がそれまでブロックしていたアクセスパターンが許可されるようになることも考えられるからです。

Q: ユーザーによってテーブルに無効なデータが追加されるのを防ぐには、どうすればよいでしょうか?

FGAC によるコントロールには、どの項目の変更や読み取りが可能で、どの属性の変更や読み取りが可能かを特定する機能があります。ユーザーは、ブロックされた属性を除いて新しい項目を追加でき、変更可能と指定されている属性の値を自由に変更できます。

Q: 複数の属性へのアクセスを許可する場合に、その属性をすべて列記しないで済む方法はありますか?

IAM ポリシー言語では、StringLike や StringNotLike など、多数の比較演算がサポートされています。 詳細については、IAM ポリシーリファレンスを参照してください。

Q: 適切なポリシーを作成するには、どうすればよいでしょうか?

DynamoDB コンソールにある DynamoDB Policy Generator の使用をお勧めします。また、作成したポリシーと Amazon DynamoDB 開発者ガイドに記載されているポリシーとを比較して、推奨パターンに従っているかどうかを確認することもお勧めします。ポリシーを AWS フォーラムに投稿すると、DynamoDB のコミュニティから意見をもらうことができます。

Q: ユーザーがログインに使用した認証プロバイダごとのユーザー ID ではなく、1 つの標準ユーザー ID に基づいてアクセスを許可することはできますか?

実現するには、「トークン自動交付機能」のようなものが必要です。ユーザーが IAM ロールに対するフェデレーテッドアクセス権を、Facebook 認証情報と STS を使用して直接取得した場合は、その一時的認証情報に含まれているのはそのユーザーの Facebook ログインに関する情報のみであり、そのユーザーの Amazon ログインや Google ログインの情報はありません。開発者が、これらのログインから独自の永続的な識別子へのマッピングを内部的に保存する必要がある場合は、ユーザーがログインするときの接続先となるサービスを実行してください。このサービスで STS を呼び出して、ユーザーに認証情報 (そのユーザーの正規ユーザー ID となるパーティションキー値をスコープとする) を付与します。

Q: FGAC を使用しても隠せない情報には、どのようなものがありますか?

現時点で、テーブル内の項目に関する情報のうち、呼び出し元からのアクセスをブロックできないものは次のとおりです。

• 項目コレクションのメトリクス。呼び出し元は、項目コレクションの項目数やバイト単位のサイズの推計値を問い合わせることができます。
• 使用されたスループット。呼び出し元は、プロビジョニングされたスループットのうち操作で使用された分の詳細な内訳や集計値を問い合わせることができます。
• 検証ケース。場合によっては、開発者がアクセスを許可する意図がなくても、あるテーブルが存在することと、そのプライマリキースキーマを呼び出し元が知ってしまうこともあります。このことを防ぐには、最小権限の原則に従い、意図的にアクセスを許可するテーブルとアクションのみについてアクセスを許可することをお勧めします。
• アクセスを許可する特定の属性のホワイトリストを作成するのではなく、特定の属性へのアクセスを拒否するようになっていると、隠されている属性の名前を呼び出し元が特定することは理論的には可能です。これが可能になるのは、「～を除くすべてを許可」ロジックが使用されている場合です。代わりに、特定の属性名をホワイトリスト化するほうが安全です。

Q: Amazon DynamoDB を使用すると、どのように課金されますか?

各 DynamoDB テーブルには、プロビジョニングされた読み込みスループットと書き込みスループットがあり、テーブルに関連付けられています。無料利用枠を超える場合は、そのスループット容量に対して 1 時間ごとに課金されます。

テーブルにリクエストを送信するかどうかにかかわらず、スループット容量に対して 1 時間ごとに課金されることに注意してください。テーブルのプロビジョンドスループット性能を変更するには、AWS マネジメントコンソール、UpdateTable API、Auto Scaling の PutScalingPolicy API のいずれかを使用します。

さらに、DynamoDB では、インデックス化データストレージに対する料金と標準のインターネットデータ転送料金が課金されます。

DynamoDB の料金計算の詳細については、DynamoDB 料金表のページをご覧ください。

Q: 価格設定例を教えてください。

米国東部 (バージニア北部) リージョンの料金表を使用してスループットコストを計算する方法の例を次に示します。他のリージョンの料金については、料金表のページをご覧ください。

テーブルを 1 つ作成し、10 ユニットの書き込み容量と 200 ユニットの読み込み容量のプロビジョニングされたスループットをリクエストした場合は、以下のように課金されます:

0.01 USD + (4 x 0.01 USD) = 1 時間あたり 0.05 USD

スループットを変更し、予約されたスループット要件を 10,000 ユニットの書き込み容量と 50,000 ユニットの読み込み容量に増やすと、以下のように変更されます:

(1,000 x 0.01 USD) + (1,000 x 0.01 USD) = 1 時間あたり 20 USD

DynamoDB の料金計算の詳細については、DynamoDB 料金表のページをご覧ください。

Q: 料金は税込み価格ですか?

税金の詳細については、Amazon Web Services Tax Help を参照してください。

Q: プロビジョニングされたスループットとは何ですか?

Amazon DynamoDB Auto Scaling では、スループット容量は必要な目標使用率、最小容量と最大容量の制限に基づき、リクエストボリュームの変化に応じて自動的に調整されます。または、テーブルで必要なリクエストスループットを手動で指定することもできます。指定されたスループットレートを達成するために、リソースのプロビジョニングが見えないところで処理されます。当社では、スループットレートに影響するインスタンス、ハードウェア、メモリなどの要因についてお客様に尋ねるのではなく、目標とするスループットレベルをプロビジョニングしていただくようお願いしています。これが、サービスのプロビジョニングされたスループットモデルです。

新しいテーブルまたはグローバルセカンダリインデックスの作成時に、デフォルトの目標使用率、最小容量と最大容量の制限が設定された Auto Scaling がデフォルトで有効になります。または、必要な読み込みおよび書き込み容量を手動で指定することもできます。この場合は、Amazon DynamoDB によって自動的にパーティション化され、スループット要件を満たすよう適切なリソース量が確保されます。

Q: プライマリキーの選択は達成できる拡張性にどのように影響しますか?

Amazon DynamoDB は、データを保存するときに、テーブルを複数のパーティションに分けて、プライマリキーのパーティションキー要素に基づいてデータを分散します。容量リソースを割り当てる際、Amazon DynamoDB はすべてのプライマリキーで比較的ランダムなアクセスパターンが使用されると仮定します。データモデルを設定するときは、リクエストによるトラフィックがプライマリキー全体に均等に分散するようにします。1 つのテーブルに頻繁にアクセスされるパーティションキー要素がごく少数含まれる場合 (場合によっては、非常に頻繁に使用されるパーティションキー要素が 1 つのみの場合)、少数のパーティション (場合によっては 1 つのパーティションのみ) にトラフィックが集中します。1 つまたは一部のパーティションに偏ってしまうなど、負荷のバランスが極端に悪いと、プロビジョニングされたスループットレベルが達成されません。Amazon DynamoDB のスループットを最大限に活用するには、テーブルを作成するときに、パーティションキー要素に個別の値が多数含まれ、できるだけランダムに、かつ均一に値がリクエストされるようにします。たとえば、アプリケーションの利用顧客が多く、様々な顧客レコードへのリクエストがほぼ均一な場合は、CustomerID をプライマリキーとして使用するとよいでしょう。大きな偏りが生じるプライマリキーの例としては、製品カテゴリによって人気にばらつきがある場合の「製品カテゴリ名」が挙げられます。

Q: 読み込み/書き込み容量のユニットとは何ですか?

使用しているアプリケーションに必要な読み込み/書き込み容量のユニットはどのように見積もりますか? 1 ユニットの書き込み容量で、最大 1 KB のサイズの項目について 1 秒に 1 書き込みを実行できます。同様に、1 ユニットの読み込み容量で、最大 4 KB の項目に対して強い整合性のある読み込みを 1 秒あたり 1 回（結果的に整合性のある読み込みについては 1 秒あたり 2 回）行うことができます。項目のサイズが大きくなるほど、多くの容量が必要になります。必要な読み込みおよび書き込み容量のユニット数を計算するには、必要な 1 秒あたりの読み込みまたは書き込み回数を見積もり、項目のサイズ（KB に切り上げ）を掛け合わせます。

書き込みに必要な容量のユニット数 = 1 秒あたりの項目書き込み回数 x 項目のサイズ (1 KB ブロック)

読み込みに必要な容量のユニット数* = 1 秒あたりの読み込み回数 x 項目のサイズ (4 KB ブロック)

* 結果整合性のある読み込みを使用する場合は、1 秒あたりの読み込み回数によってスループットが 2 倍になります。

項目のサイズが 1 KB を下回る場合は、読み込み容量のユニットごとに 1 秒あたり強力な整合性のある 1 読み込み、書き込み容量のユニットごとに 1 秒あたり 1 書き込みの容量が割り当てられます。例えば、項目のサイズが 512 バイトで、1 秒あたり 100 個の項目をテーブルから読み込む必要がある場合は、100 ユニットの読み込み容量をプロビジョニングする必要があります。

項目のサイズが 4 KB を上回る場合は、必要な読み込み容量と書き込み容量のユニット数を計算する必要があります。例えば、項目のサイズが 4.5 KB で、1 秒あたり 100 個の強力な整合性のある読み込みを行う必要がある場合は、「100（秒あたりの読み込み）x 2（4.5 KB の保存に必要な 4 KB ブロックの数）= 200（読み込み容量のユニット数）」をプロビジョニングする必要があります。

必要な読み込み容量のユニット数は、API 呼び出し数ではなく、1 秒あたりに読み込まれる項目数によって決まります。例えば、1 秒あたり 500 個の項目をテーブルから読み込む必要があり、項目のサイズが 4 KB 以下の場合は、500 ユニットの読み込み容量が必要です。個別の GetItem 呼び出しを 500 回行う場合でも、10 個の項目を返す BatchGetItems 呼び出しを 50 回を行う場合でも同じです。

Q: プロビジョニングされたスループットのレベルは必ず達成することができますか？

Amazon DynamoDB では、すべてのプライマリキーで比較的ランダムなアクセスパターンが使用されていると見なされます。データモデルを設定するときは、リクエストによるトラフィックがプライマリキー全体に均等に分散するようにします。アクセスパターンが極端にばらついている場合、または偏りがある場合は、プロビジョニングされたスループットレベルを達成できない可能性があります。

Amazon DynamoDB は、データを保存するときに、テーブルを複数のパーティションに分けて、プライマリキーのパーティションキー要素に基づいてデータを分散します。また、テーブルに関連付けられているプロビジョニングされたスループットもパーティションに分けられます。各パーティションのスループットは、パーティションに指定された割り当て量に基づいて個別に管理されます。プロビジョニングされたスループットがパーティションをまたいで共有されることはありません。つまり、負荷がパーティションキー値に均等に分散されている場合、Amazon DynamoDB のテーブルはプロビジョニングされたスループットレベルに最適に対応できます。リクエストを複数のパーティションキー値に分散させると、リクエストが複数のパーティションに分散されます。これは、完全にプロビジョニングされたスループットレベルを達成するのに役立ちます。

プライマリキーの負荷パターンが不均等で、プロビジョニングされたスループットレベルを達成できない場合、プロビジョニングされたスループットレベルを上げ、各パーティションに割り当てるスループットを増やすと、スループットのニーズに対応できることがあります。しかし、プライマリキーで比較的ランダムなアクセスパターンを実現するには、リクエストパターンまたはデータモデルの変更を検討することをお勧めします。

Q: JSON 文書の 1 つの要素に限り検索する場合、項目全体の読み込み料金がかかりますか?

はい。DynamoDB からデータを読み込むと、項目全体の読み込みに必要なスループットを消費します。

Q: 1 つの DynamoDB テーブルにプロビジョニングできる最大スループットはどのくらいですか?

DynamoDB にスケールの制限はありません。ただし、各テーブルのスループットレートが 10,000 書き込み容量ユニットまたは 10,000 読み込み容量ユニットを超える場合は、こちらのオンラインフォームを使用して事前に Amazon までご連絡ください。また、1 つの登録アカウントから 20,000 を超える書き込み容量ユニットまたは読み込み容量ユニットをプロビジョンする場合も、上記のフォームを使用して事前にご連絡ください。

Q: 1 つの DynamoDB テーブルにプロビジョンできる最小スループットはどのくらいですか?

Auto Scaling の場合でも、手動でスループットをプロビジョニングする場合でも、リクエスト可能なプロビジョンできる最小スループットは、1 書き込み容量ユニットと 1 読み込み容量ユニットです。

これは無料利用枠（書き込み容量 25 ユニットと読み込み容量 25 ユニットまで）の範囲内です。無料利用枠は、テーブルレベルではなくアカウントレベルに適用されます。つまり、お客様の全テーブルのプロビジョニングされた容量の合計が、書き込み容量 25 ユニットと読み込み容量 25 ユニットを超えていなければ、このプロビジョニングされた容量は無料利用枠の範囲内になります。

Q: プロビジョニングされたスループットを 1 回のリクエストで変更できる量に制限はありますか?

テーブルのプロビジョニングされるスループット容量は、UpdateTable API を使用して必要量を増加できます。たとえば、テーブルのプロビジョニングされる書き込み容量を、1 回の API 呼び出しで 1 書き込み容量ユニットから 10,000 書き込み容量ユニットに増加できます。ただし、お客様のアカウントにはテーブルレベルとアカウントレベルでの容量制限が課せられます。詳しくはドキュメントページを参照してください。プロビジョニングされる容量の制限を引き上げる必要がある場合は、サポートセンターを表示し、[Open a new case] をクリックして、サービス制限引き上げリクエストを申請します。

Q: プロビジョニングされたスループットにはどのように課金されますか?

Amazon DynamoDB テーブルでは、お客様が指定したスループットレートを達成するのに必要なリソースが事前にプロビジョニングされています。テーブルのリソースがこの量で十分である限り、1 時間ごとに課金されます。課金例が記載された詳しい価格リストについては、DynamoDB 料金表ページを参照してください。

Q: 既存の DynamoDB テーブルのプロビジョニングされたスループットはどのように変更しますか?

Amazon DynamoDB テーブルのプロビジョニングされたスループットは 2 通りの方法で更新できます。管理コンソールで変更を行う方法、または UpdateTable API 呼び出しを使用する方法です。どちらの場合でも、Amazon DynamoDB は、プロビジョニングされたスループットレベルを拡大または縮小している時も使用できます。

Q: プロビジョニングされたスループットはどのくらいの頻度で変更できますか?

プロビジョニングされたスループットは必要な頻度で増やすことができます。1 日に最大 4 回減らすことができます。日付は GMT (グリニッジ標準時) に基づいて定義されます。また、過去 4 時間で減少しなかった場合は、さらに縮小することができ、実質的に 1 日に減らせる最大回数は 9 回になります (1 日のうち、最初の 4 時間で 4 回の減少、それ以降は 4 時間ごとに 1 回の減少)。

お客様が最後に行ったプロビジョニングされたスループットに対する変更リクエストが Amazon DynamoDB テーブルで処理中の場合、スループットは変更できないことにご注意ください。テーブルのステータスは、管理コンソールまたは DescribeTables API を使用して確認します。ステータスが「CREATING」、「DELETING」、または「UPDATING」の場合、テーブルのスループットは調整できません。テーブルが「ACTIVE」ステータスになってから、再度お試しください。

Q: 整合性レベルはスループットレートに影響しますか？

はい。特定のリソース割り当てでは、DynamoDB テーブルで達成できる読み込みレートは、強い整合性のある読み込みと結果的に整合性のある読み込みで異なります。「1,000 読み込み容量ユニット」をリクエストすると、最大 4KB の項目について、強い整合性のある読み込みを 1 秒あたり 1,000 回達成できるようにリソースが割り当てられます。最大 4 KB の項目について結果整合性のある読み込みを 1,000 回達成するには、その容量の半分、つまり 500 読み込み容量ユニットが必要です。テーブルの適切なスループットレートを選択するための詳細なガイダンスについては、プロビジョニングされたスループットに関するガイドを参照してください。

Q: 項目のサイズはスループットレートに影響しますか?

はい。特定のリソース割り当てでは、DynamoDB テーブルで達成できる読み込み速度は項目のサイズよって異なります。目標とするプロビジョニングされた読み込みスループットを指定するとき、DynamoDB では、項目のサイズが 4 KB 未満になるという前提でリソースがプロビジョニングされます。項目が最大で 4 KB 増加するたびに、同じスループットレートを達成するのに必要なリソースが直線的に増加します。例えば、100 ユニットの読み込み容量で DynamoDB テーブルをプロビジョニングした場合、このテーブルは、1 秒あたり 100 回の 4 KB の読み込み、1 秒あたり 50 回の 8 KB の読み込み、または 1 秒あたり 25 回の 16 KB の読み込みを処理できることを意味します。

同様に、DynamoDB テーブルが達成できる書き込み速度は項目のサイズによって異なります。目標とするプロビジョニングされた書き込みスループットを指定するとき、DynamoDB では、項目のサイズが 1 KB 未満になるという前提でリソースがプロビジョニングされます。最大 1 KB の増加があるたびに、同じスループットレートを達成するのに必要なリソースが正比例的に増えます。例えば、100 単位の書き込み容量で DynamoDB テーブルをプロビジョニングした場合、このテーブルは、100 回の 1 KB の書き込み/秒、50 回の 2 KB の書き込み/秒、または 25 回の 4 KB の書き込み/秒を処理できることを意味します。

テーブルの適切なスループットレートを選択するための詳細なガイダンスについては、プロビジョニングされたスループットに関するガイドを参照してください。

Q: プロビジョニングされた容量を超える読み込みまたは書き込みがアプリケーションで行われるとどうなりますか?

1 秒あたりに、テーブルでプロビジョニングされたスループット容量を超える読み込みまたは書き込みがアプリケーションで行われると、プロビジョニングされた容量を超えた分のリクエストは調整され、エラーコード 400 が返されます。たとえば、1,000 ユニットの書き込み容量を要求した場合、1KB の項目に対して 1,500 書き込み/秒を行おうとしても、1,000 書き込み/秒しか処理できず、処理できなかった分のリクエストに対してエラーコード 400 が返されます。必要なリクエストレートを達成できるだけのプロビジョニングされたスループットを常に確保するためには、CloudWatch を使用してリクエストレートを監視する必要があります。

Q: プロビジョニングされたスループットを超えたことを確認するにはどうすればよいですか？

使用したスループット容量は CloudWatch 基準として公開されています。プロビジョニングされた容量に近づいたら通知されるように、この基準に基づいてアラームを設定することができます。

Q: テーブルのプロビジョニングされたスループットレベルを変更するにはどのくらい時間がかかりますか？

通常、スループットを減らす場合は数秒から数分、増やす場合は数分から数時間かかります。

追加スループットが必要になった時点でスループットを増加したり増加のスケジュールを立てたりすることはお勧めできません。スループット容量のプロビジョニングは、必要なときに確実に容量を確保できるようかなり前から行っておくことをお勧めします。

Q: リザーブドキャパシティーとは何ですか?

リザーブドキャパシティは課金の機能で、以下の料金をお支払いただくことで、プロビジョニングされたスループット容量に割引を受けることができます。

• 一括前払いのお支払い
• 契約期間中の最小月額使用料を規定します。

リザーブドキャパシティは単一の AWS リージョン内で適用され、1 年または 3 年の期間で購入できます。Auto Scaling により管理されている場合でも、テーブルの作成や更新時に手動でプロビジョニングした場合でも、すべての DynamoDB テーブルには関連するプロビジョンドスループット性能があります。この容量は、DynamoDB テーブルが実現できる読み書きのスループットを決定するものです。リザーブドキャパシティは請求の仕組みで、DynamoDB テーブルのパフォーマンスや容量に直接の影響は与えません。例えば、書き込み容量 100 ユニットのリザーブドキャパシティを購入すると、割引価格を支払う代わりに、契約期間（1 年または 3 年）の容量に対して支払いをする契約となります。

Q: リザーブドキャパシティはどのように購入するのですか?

AWS マネジメントコンソールにログインして、DynamoDB コンソールのページに移動し、[Reserved Capacity] をクリックします。[Reserved Capacity Usage] ページが表示されます。[Purchase Reserved Capacity] をクリックします。そこで表示されるフォームに必要事項を記入して、リザーブドキャパシティの購入手続きを行います。リザーブドキャパシティが使用される予定の AWS リージョンが選択されていることを確認してください。リザーブドキャパシティを購入すると、[Reserved Capacity Usage] ページに、購入内容が示されます。

Q: リザーブドキャパシティーの購入をキャンセルできますか?

いいえ。リザーブドキャパシティはキャンセルできず、前払い料金は返金不可能です。使用されたかどうかにかかわらず、リザーブドキャパシティの期間が終了するまで毎時間の料金をお支払いただきます。

Q: 購入できるリザーブドキャパシティーの最小数量はどのくらいですか?

リザーブドキャパシティとして提供される最小容量は、100 ユニット（読み取りまたは書き込み）です。

Q: リザーブドキャパシティーの購入に使用できる API はありますか?

まだありません。将来的に、API および追加のリザーブドキャパシティのオプションを用意する予定です。

Q: リザーブドキャパシティーを別のリージョンに移動させることはできますか?

いいえ。リザーブドキャパシティは 1 つのリージョンに関連付けられています。

Q: リザーブドキャパシティーよりも多くのスループットをプロビジョンできますか?

はい。リザーブドキャパシティを購入すると、最小使用量を契約し、その使用量に対して割引料金を支払うことになります。最小量よりも多くの容量をプロビジョニングする場合、追加の容量に対しては標準料金をお支払いただきます。

Q: リザーブドキャパシティーはどのように使用するのですか?

リザーブドキャパシティは自動的に請求に適用されます。例えば、書き込み容量 100 ユニットのリザーブドキャパシティを購入し、300 ユニットの容量をプロビジョニングした場合、書き込み容量 100 ユニットのコストについては自動的にリザーブドキャパシティが充てられ、残りの書き込み容量 200 ユニットについては標準料金でお支払いただきます。

Q: リザーブドキャパシティーよりも少ないスループットの容量をプロビジョンした場合はどうなりますか?

リザーブドキャパシティの購入は、割引価格の代わりに、契約期間中、プロビジョニングするスループット容量の最小量に対してお支払いいただく契約です。使用する容量がリザーブドキャパシティより少ない場合も、プロビジョニングするスループット容量の最小量に対して毎月課金されます。

Q: リザーブドキャパシティーを複数の DynamoDB テーブルに使用できますか?

はい。リザーブドキャパシティは、リザーブドキャパシティを購入したリージョン内でプロビジョニングされた総容量に適用されます。例えば、書き込み容量 5,000 ユニットのリザーブドキャパシティを購入すると、1 つのテーブルに書き込み容量 5,000 ユニットを適用するか、または 100 のテーブルに書き込み容量 50 ユニットを適用する、あるいは 1,000 のテーブルに書き込み容量 5 ユニットを適用することなどが可能になります。

Q: リザーブドキャパシティーは、一括請求 (コンソリデーティッドビリング) アカウントの DynamoDB の使用に適用されますか?

はい。一括請求 (コンソリデーティッドビリング) に関連付けられた複数のアカウントを所有している場合、支払いアカウントレベルまたは連結アカウントレベルで購入されたリザーブドキャパシティーのユニットは、支払いアカウントに関連付けられたすべてのアカウントの間で共有されます。リザーブドキャパシティーは、まずそれを購入したアカウントに適用され、その後未使用のキャパシティーが他の連結アカウントに適用されます。

 

Q: DynamoDB クロスリージョンレプリケーションとは何ですか?

DynamoDB クロスリージョンレプリケーションを使用すると、DynamoDB テーブル（マスターテーブル）の同一コピー（レプリカ）を複数の AWS リージョンに保持できます。テーブルのクロスリージョンレプリケーションを有効にすると、そのテーブルの同一コピーが別の AWS リージョンに作成されます。そのテーブルに対する書き込みは、すべてのレプリカに自動的に反映されます。

 

Q: クロスリージョンレプリケーションはどのような場合に使用しますか?

クロスリージョンレプリケーションは、次のような場合に使用できます。

• 効率的な災害対策: 複数のデータセンターにテーブルをレプリケートすることで、あるデータセンターで障害が発生した場合に、別のリージョンの DynamoDB テーブルを使用するように切り替えることができます。
• 読み込みの高速化: お客様が複数のリージョンに分散している場合に、最寄りの AWS データセンターの DynamoDB テーブルを読み込むことでデータ配信を高速化できます。
• トラフィック管理の簡単化: レプリカを使用すると読み取りワークロードを複数のテーブルに分散できるので、マスターテーブルの読み込み容量の消費を抑えられます。
• リージョン間移行の簡単化: 別のリージョンにリードレプリカを作成し、そのレプリカをマスターに格上げすることで、そのリージョンにアプリケーションを簡単に移行できます。
• ライブデータの移行: リージョン間で DynamoDB テーブルを移行するには、移行元リージョンのテーブルのレプリカを移行先リージョンに作成します。移行元と移行先のテーブルが同期されたら、移行先リージョンに書き込むようにアプリケーションを切り替えます。
  

Q: クロスリージョンレプリケーションでサポートされているのはどのモードですか?

クロスリージョンレプリケーションでは現在、単一マスターモードがサポートされています。このモードでは、1 つのマスターが、マスターテーブルと 1 つ以上のレプリカテーブルを持ちます。

Q: テーブルに単一マスタークロスリージョンレプリケーションを設定するにはどうすればよいですか?

DynamoDB クロスリージョンレプリケーションライブラリを使用してクロスリージョンレプリカを作成できます。

Q: ブートストラップが完了したことはどのようにしてわかりますか?

レプリケーション管理アプリケーションで、レプリケーションの状態が「ブートストラップ」から「アクティブ」に変わります。

Q: 1 つのマスターテーブルに対して複数のレプリカを作成できますか?

はい。1 つのマスターテーブルから作成できるレプリカテーブルの数に制限はありません。レプリカテーブルごとに DynamoDB ストリームリーダーが作成され、マスターテーブルからデータをコピーして各レプリカを同期状態に維持します。

Q: 1 つのテーブルにクロスリージョンレプリケーションを設定するために必要な料金を教えてください。

DynamoDB クロスリージョンレプリケーションは DynamoDB クロスリージョンレプリケーションライブラリを使用して有効化されます。クロスリージョンレプリケーションライブラリに対する特別の課金はありませんが、プロセスで使用される以下のリソースについて、通常の料金をお支払いいただきます。以下が課金対象となります。

• プロビジョニングされたスループット（書き込みと読み込み）およびレプリカテーブルのストレージ。
• リージョン間データ転送。
• テーブル間の同期を維持するための DynamoDB ストリームからのデータの読み込み。
• レプリケーションプロセスをホストするためにプロビジョニングされた EC2 インスタンス。インスタンスの費用は、選択したインスタンスタイプとインスタンスをホストしているリージョンによって異なります。

Q: クロスリージョンレプリケーションをホストする Amazon EC2 インスタンスは、どのリージョンで動作しますか?

クロスリージョンレプリケーションアプリケーションは、クロスリージョンレプリケーションアプリケーションが最初に起動されたのと同じリージョンにある Amazon EC2 インスタンスによってホストされます。このリージョンのインスタンス価格が請求されます。

Q: マスターテーブルとレプリカテーブルのサイズとスループットの変動に応じて、Amazon EC2 インスタンスは Auto Scale によって自動スケールされますか?

現時点では、EC2 インスタンスは自動スケールされません。DynamoDB クロスリージョンレプリケーションを設定するときは、お客様にインスタンスサイズを選択していただく必要があります。

Q: レプリケーションを管理する Amazon EC2 インスタンスでエラーが発生するとどうなりますか?

Amazon EC2 インスタンスは Auto Scaling Group の配下で動作しているため、アプリケーションは別のインスタンスに自動的にフェイルオーバーされます。アプリケーションは下層で Kinesis クライアントライブラリ (KCL) を使用しており、これによりコピーのチェックポイントが作成されます。インスタンスでエラーが発生した場合、アプリケーションは、チェックポイントを検索してそこから再開すればよいことを認識しています。

Q: リードレプリカの作成中も DynamoDB テーブルを使い続けることができますか?

はい。レプリカの作成はオンライン操作です。リードレプリカの作成中も読み取りおよび書き込み可能な状態に維持されます。ブートストラップでは、スキャンオペレーションを使用してソーステーブルからコピーを実行します。スキャンオペレーションをサポートするために十分な読み込み容量ユニットでテーブルをプロビジョニングすることをお勧めします。

 

Q: レプリカの作成にはどのぐらい時間がかかりますか?

マスターテーブルからレプリカテーブルへの初回コピーに要する時間はマスターテーブルのサイズ、マスターテーブルとレプリカテーブルのプロビジョニングされた容量によって異なります。項目レベルの変更がマスターテーブルからレプリカテーブルに反映されるまでに要する時間は、マスターテーブルとレプリカテーブルのプロビジョニング容量とレプリケーションアプリケーションを実行している Amazon EC2 インスタンスのサイズによって異なります。

Q: マスターテーブルのプロビジョニング済み容量を変更すると、レプリカテーブルのプロビジョニング済み容量も更新されますか?

レプリケーションが作成された後、マスターテーブルのプロビジョニング済み容量を変更しても、レプリカテーブルのスループット容量は更新されません。

 

Q: レプリカテーブルのインデックスはマスターテーブルと同じですか?

レプリケーションアプリケーションからレプリカテーブルを作成するよう選択した場合、マスターテーブルのセカンダリインデックスがレプリカテーブルに自動的に作成されることはありません。レプリケーションアプリケーションは、マスターテーブルのセカンダリインデックスに対する変更をレプリカテーブルに反映しません。通常の DynamoDB テーブルで行うのと同じ要領で、AWS マネジメントコンソール経由で各レプリカテーブルのインデックスを追加/更新/削除する必要があります。

 

Q: レプリカのプロビジョニングされたスループット容量はマスターテーブルと同じですか?

レプリカテーブルを作成する際には、最低でもマスターテーブルと同じ書き込み容量をプロビジョニングして、すべての受信書き込みを処理できるだけの容量を確保することをお勧めします。レプリカテーブルのプロビジョニングされる読み込み容量は、アプリケーションに合った任意のレベルに設定できます。

 

Q: レプリケートされたテーブルの整合性モデルとは何ですか?

各レプリカは非同期に更新されます。DynamoDB では、マスターテーブルに受け入れられた時点で書き込みオペレーションを成功と認識します。その後、その書き込み内容が各レプリカに反映されます。つまり、すべてのレプリカテーブルに書き込みが反映されるまでには若干の遅延が発生することになります。

Q: クロスリージョンレプリケーションの CloudWatch メトリクスはありますか?

CloudWatch メトリクスはすべてのレプリケーション設定で使用可能です。メトリクスを確認するには、レプリケーショングループを選択し、[モニタリング] タブに移動します。スループットのメトリクスと処理されたレコード数が確認でき、マスターテーブルとレプリカテーブルのスループットの差異を監視できます。

Q: マスターテーブルと同じリージョンにレプリカを配置できますか?

はい。レプリカテーブルとマスターテーブルの名前が異なっていれば、両テーブルを同じリージョンに配置できます。

Q: レプリケーショングループを作成した後、レプリカを追加または削除できますか?

はい。レプリケーショングループに対してはいつでもレプリカの追加または削除を実行できます。

Q: レプリカグループを作成後に削除できますか?

はい。レプリケーショングループの削除により、グループのためのEC2 インスタンスを削除します。ただし、DynamoDB メタデータテーブルを削除する必要があります。

Q: DynamoDB トリガーとは何ですか?

DynamoDB トリガーとは、DynamoDB テーブルの項目レベルの更新に基づいてカスタムアクションを実行できるようにする機能です。コード内でカスタムアクションを指定できます。

Q: DynamoDB トリガーでできることは何ですか?

DynamoDB トリガーを使用すると便利なアプリケーションシナリオはいくつかあります。例えば、通知の送信、集計テーブルの更新、DynamoDB テーブルの別のデータソースへの接続などのユースケースがあります。

Q: DynamoDB トリガーのしくみを教えてください。

DynamoDB トリガーのカスタムロジックは、AWS Lambda 関数にコードとして格納されます。特定のテーブルのトリガーを作成するには、AWS Lambda 関数を（DynamoDB ストリームを使用して）DynamoDB テーブルのストリームに関連付けます。テーブルが更新されると、更新内容が DynamoDB ストリームに発行されます。そして、AWS Lambda が自分に関連付けられたストリームからこの更新内容を読み込み、関数内のコードを実行します。

Q: DynamoDB トリガーの使用料を教えてください。

DynamoDB トリガーを使用する場合は、AWS Lambda 関数をリクエストした回数および AWS Lambda 関数の実行所要時間分のみのお支払いとなります。AWS Lambda の料金の詳細については、こちらをご覧ください。お客様の AWS Lambda 関数が、テーブルに関連付けられたストリームに対して（DynamoDB ストリームを介して）行う読み込みについては課金されません。

Q: テーブルのトリガー数に制限はありますか?

テーブルのトリガー数に制限はありません。

Q: DynamoDB トリガーでサポートされている言語を教えてください。

DynamoDB トリガーでは現在、トリガー関数の言語として JavaScript、Java、および Python をサポートしています。

Q: DynamoDB トリガーを作成、編集、削除するための API はサポートされていますか?

いいえ。現時点では、DynamoDB トリガーを作成、編集、削除するためのネイティブ API は用意されていません。AWS Lambda コンソールを使用して AWS Lambda 関数を作成し、DynamoDB ストリームのストリームに関連付ける必要があります。詳細については、AWS Lambda FAQ ページを参照してください。

Q: DynamoDB トリガーを作成するには、どうすればよいですか?

トリガーを作成するには、AWS Lambda 関数を作成し、その関数のイベントソースを DynamoDB ストリームのストリームに関連付けます。詳細については、AWS Lambda FAQ ページを参照してください。

Q: DynamoDB トリガーを削除するにはどうすればよいですか?

トリガーを削除するには、関連付けられた AWS Lambda 関数を削除します。AWS Lambda 関数は、AWS Lambda コンソールから、または AWS Lambda API 呼び出しを使用して削除できます。詳細については、AWS Lambda FAQ ページおよびドキュメントページを参照してください。

Q: 既存の AWS Lambda 関数を使用して DynamoDB トリガーを作成するにはどうすればよいですか?

AWS Lambda 関数のイベントソースは、DynamoDB ストリームのストリームを指すように変更できます。この変更は DynamoDB コンソールから実行できます。ストリームが有効になっているテーブルで、そのストリームを選択し、[Associate Lambda Function] ボタンを選択して、Lambda 関数の一覧から DynamoDB トリガーに使用する関数を選択します。

Q: どのリージョンで DynamoDB トリガーを利用できますか?

DynamoDB トリガーは、AWS Lambda と DynamoDB が利用できるすべての AWS リージョンで利用できます。

Q: DynamoDB ストリームとは何ですか?

DynamoDB ストリームは、過去 24 時間以内にテーブルのデータに対して行われた項目レベルの変更を時系列ストリームとして提供したものです。簡単な API 呼び出しでストリームにアクセスできます。ストリームを使用すると、変更された直近の DynamoDB で他のデータストアを最新の状態に維持したり、テーブルに対する変更内容に基づいてアクションを実行したりできます。

Q: DynamoDB ストリームを使用する利点は何ですか?

DynamoDB Streams API を使用すると、開発者は、更新を使用して変更する前後の項目レベルのデータを受け取ることができます。それを使用して、DynamoDB を基礎として構築されたアプリケーションにお好みの拡張機能を作成できます。例えば、DynamoDB を使用してグローバルなマルチプレーヤーゲームを開発する場合、DynamoDB Streams API を使用してマルチマスタートポロジを構築し、各マスターに対して DynamoDB Streams を使用して、リモートマスターで更新を再生することで、各マスターの同期を維持できます。別の例として、ユーザーが新しい自分の写真をアップロードするとすぐにサークル内のすべての友人のモバイルデバイスに自動的に通知するモバイルアプリケーションを DynamoDB Streams API を使用して作成できます。また、DynamoDB ストリームを使用して、DynamoDB テーブルに対するすべての変更を Amazon Redshift などのデータウェアハウスツールに同期させて、リアルタイム分析を行うことも可能です。DynamoDB は Amazon DynamoDB Logstash Plugin によって Elasticsearch と統合されるため、開発者が DynamoDB コンテンツにフリーテキスト検索を追加することも可能です。

DynamoDB ストリームの詳細については、当社のドキュメントをご覧ください。

Q: DynamoDB テーブルに対する変更を DynamoDB Streams で利用できる期間はどれくらいですか?

DynamoDB Streams はテーブルに対するすべての変更のレコードを 24 時間保持します。その後、レコードは消去されます。

Q: DynamoDB Streams はどうすれば有効にできますか?

DynamoDB ストリームはテーブルごとに有効にする必要があります。既存の DynamoDB テーブルで DynamoDB ストリームを有効にするには、AWS マネジメントコンソールからテーブルを選択し、[Overview] タブを選択し、[Manage Stream] ボタンをクリックし、表示のタイプを選択し、それから [Enable] をクリックします。

詳細については、当社のドキュメントを参照してください。

Q: DynamoDB ストリームが有効になったかどうかを確認するにはどうすればよいですか?

DynamoDB ストリームを有効にすると、AWS マネジメントコンソールにそのストリームが表示されます。テーブルを選択し、[Overview] タブを選択します。ストリームの詳細で、ストリームの有効化が [Yes] に設定されているか確認してください。

Q: DynamoDB ストリームにアクセスするにはどうすればよいですか?

DynamoDB ストリームを介して利用可能なストリームにアクセスするには、DynamoDB SDK または Kinesis クライアントライブラリ (KCL) を使用した簡単な API 呼び出しを使用します。KCL を使用すると、ストリームのデータを使用および処理したり、複数のリーダーへの負荷分散、インスタンス障害への対応、処理されたレコードのチェックポイントなどのタスクを管理したりできます。

DynamoDB ストリームへのアクセスに関する詳細については、当社のドキュメントを参照してください。

Q: DynamoDB Streams では DynamoDB のテーブルに対して行われたすべての変更が順番に表示されますか?

特定の項目に対して行われた変更は、正しい順序で表示されます。異なる項目に対して行われた変更は、受信した順序とは異なる順序で DynamoDB ストリームに表示されることがあります。

例えば、ゲームのハイスコアを追跡している DynamoDB テーブルがあり、テーブルの各項目が個別のプレーヤーを表している場合について考えます。次の 3 つの更新をこの順序で行うものとします。

• 更新 1: プレーヤー 1 のハイスコアを 100 ポイントに変更します
• 更新 2: プレーヤー 2 のハイスコアを 50 ポイントに変更します
• 更新 3: プレーヤー 1 のハイスコアを 125 ポイントに変更します
  

更新 1 と更新 3 は同じ項目（プレーヤー 1）に対する変更なので、DynamoDB ストリームでは、更新 1 より後に更新 3 が表示されます。これにより、各プレーヤーの最新のハイスコアを取得できます。3 つの更新すべてが正しい順序で（つまり、更新 2 が更新 1 より後、かつ更新 3 より前に）表示されるとは限りませんが、プレーヤーごとのレコードに対する更新は正しい順序になります。

Q: DynamoDB Stream のストリームの容量を管理する必要がありますか?

いいえ。ストリームの容量は、DynamoDB ストリームによって自動的に管理されます。テーブルに対するトラフィックが大幅に増加した場合、DynamoDB はストリームの容量を自動的に調節して、すべての更新を引き続き受け入れられるようにします。

Q: DynamoDB ストリームからの読み取り速度はどれくらいですか?

DynamoDB テーブルのプロビジョニングされている書き込み容量の最大 2 倍の速度で、DynamoDB ストリームから更新を読み取ることができます。例えば、1 秒間に 1,000 項目を更新するのに十分な容量をテーブルにプロビジョニングしている場合、1 秒間に最大 2,000 件の更新をストリームから読み取ることができます。

Q: DynamoDB テーブルを削除した場合、DynamoDB ストリームのストリームも削除されますか?

いいえ、すぐには削除されません。テーブルに対して最後に行われた更新を読み取ることができるように、ストリームは DynamoDB ストリーム内に 24 時間保持されます。24 時間経過すると、ストリームは DynamoDB ストリームから自動的に削除されます。

Q: テーブルの DynamoDB ストリームを無効にするとどうなりますか?

DynamoDB ストリームを無効にした場合、ストリームは 24 時間保持されますが、DynamoDB テーブルに対して行われた追加変更で更新されなくなります。

Q: DynamoDB Streams を無効にした後で有効に戻すとどうなりますか?

DynamoDB Streams を無効にすると、ストリームは 24 時間保持されますが、DynamoDB テーブルに対して行われた追加変更で更新されることはありません。DynamoDB ストリームを有効に戻すと、DynamoDB ストリームに新しいストリームが作成され、作成時点以降に DynamoDB テーブルに対して行われた変更が格納されます。

Q: DynamoDB ストリームに重複またはギャップはありますか?

DynamoDB ストリームは、テーブルに対して行われた更新はすべて 1 度だけストリームに出力されるように設計されています。

Q: DynamoDB ストリームにはどのような情報が含まれていますか?

DynamoDB ストリームには、項目の変更前の値と変更後の値に関する情報が含まれます。また、変更タイプ（INSERT、REMOVE、または MODIFY）と変更された項目のプライマリキーも含まれます。

Q: DynamoDB ストリームに含める情報はどのようにして選択すればよいですか?

新しいテーブルの場合は、CreateTable API 呼び出しを使用し、ViewType パラメータを指定して、ストリームに含める情報を選択します。
既存のテーブルの場合は、UpdateTable API 呼び出しを使用し、ViewType パラメータを指定して、ストリームに含める情報を選択します。

ViewType パラメータは、次の値を持つことができます。

ViewType: {
                    { KEYS_ONLY,
                      NEW_IMAGE,
                      OLD_IMAGE,
                      NEW_AND_OLD_IMAGES}
                }

値には次のような意味があります。KEYS_ONLY: 変更のあった項目のキーの名前のみストリームに含められます。

• NEW_IMAGE: キーの名前と更新後の項目（新しい項目）がストリームに含められます。
• OLD_IMAGE: キーの名前と更新前の項目（古い項目）がストリームに含められます。
• NEW_AND_OLD_IMAGES: キーの名前、更新前の項目（古い項目）と更新後の項目（新しい項目）がストリームに含められます。

Q: Kinesis クライアントライブラリを使用して DynamoDB ストリームにアクセスできますか?

Kinesis API を使い慣れている開発者は、DynamoDB ストリームを簡単に使用できるようになります。Amazon Kinesis インターフェイスを実装する DynamoDB Streams Adapter を使用すると、アプリケーションで Amazon Kinesis クライアントライブラリ（KCL）を使用して DynamoDB Streams にアクセスできます。KCL を使用して DynamoDB Streams にアクセスする詳細については、ドキュメントを参照してください。

Q: DynamoDB ストリームに含める情報の種類を変更できますか?

ストリームを作成した後でそこに格納する情報の種類を変更する場合は、そのストリームを無効にし、UpdateTable API を使用して新しいストリームを作成する必要があります。

Q: DynamoDB テーブルを変更したとき、どれくらいの時間でその変更が DynamoDB ストリームに表示されますか?

通常、変更は DynamoDB ストリームに 1 秒未満で反映されます。

Q: 項目を削除した場合、その変更は DynamoDB ストリームに含まれますか?

DynamoDB ストリーム内の各更新には、更新が削除されたのか、新しい項目が挿入されたのか、あるいは既存の項目が変更されたのかを指定するパラメーターが含まれます。更新の種類の詳細については、ドキュメントを参照してください。

Q: テーブルで DynamoDB ストリームを有効にした後、ストリームからの読み取りを開始できるのはいつですか?

DescribeStream API を使用してストリームの現在のステータスを取得できます。ステータスが [ENABLED] に変わったら、テーブルのすべての更新がストリームに含まれます。

ストリームの作成を開始するとすぐにストリームからの読み取りが始まりますが、ステータスが [ENABLED] に変わるまでは、テーブルの一部の更新がストリームに含まれない可能性があります。

Q: Amazon DynamoDB Logstash Plugin for Elasticsearch とは何ですか?

Elasticsearch は人気のあるオープンソースの検索、分析エンジンで、リアルタイム検索とビッグデータ分析を簡単に実現するよう設計されています。Logstash はオープンソースのデータパイプラインで、Elasticsearch と連携させることでログやその他のイベントデータの処理に役立ちます。Amazon DynamoDB Logstash Plugin によって、簡単に DynamoDB のテーブルを Elasticsearch クラスターに統合できます。

Q: Amazon DynamoDB Logstash Plugin の料金はいくらですか?

Amazon DynamoDB Logstash Plugin のダウンロードと使用は無料です。

Q: Amazon DynamoDB Logstash Plugin をダウンロードおよびインストールするにはどうすればよいですか?

Amazon DynamoDB Logstash Plugin は GitHub でダウンロードできます。プラグインのインストールと実行の詳細については、ドキュメントページを参照してください。

Q: DynamoDB Storage Backend for Titan とは何ですか?

DynamoDB Storage Backend for Titan は、お客様が DynamoDB を Titan のグラフデータベースの基盤となるストレージレイヤーとして使用することを可能にするプラグインです。これは、DynamoDB ですばやいグラフ探索を可能にする、インデックスフリーの隣接関係を実装するためのクライアント側のソリューションです。

Q: グラフデータベースとは何ですか?

グラフデータベースとは、頂点と、これらの頂点をつなぐ有向辺を保存したものです。頂点と辺はいずれも、キーと値のペアとして保存されたプロパティを持ちます。

グラフデータベースは隣接関係のリストを使用して辺を保存し、探索を容易にします。グラフデータベースのグラフは特定の辺のタイプによって、またはグラフ全体にかけて探索できます。グラフデータベースはアクション、所有権、親子関係などによって、エンティティ同士の関係性を表すことができます。

Q: グラフデータベースにはどのようなアプリケーションが適していますか?

モデル化するデータの核となるのがエンティティ同士のつながりまたは関係性である場合は、グラフデータベースが適しています。したがって、グラフデータベースはソーシャルネットワーク、ビジネス関係、依存関係、船舶移動などをモデル化およびクエリするのに便利です。

Q: DynamoDB Storage Backend for Titan の使用を開始するにはどうすればよいですか?

使用を開始する最も簡単な方法は、このドキュメントページに記載されている CloudFormation テンプレートを使用して、Gremlin サーバーを実行する EC2 インスタンスと DynamoDB Storage Backend for Titan を合わせて起動することです。また、GitHub レポジトリからプロジェクトを複製し、このドキュメントの指示に従って独自のコンピュータで Marvel および Graph-Of-The-Gods のチュートリアルを使用して開始することもできます。テストを拡大する、または本稼働環境で実行する準備ができたら、バックエンドを変更して DynamoDB サービスを使用できます。詳細は、この AWS ドキュメントをご覧ください。

Q: DynamoDB Storage Backend と他の Titan ストレージバックエンドの違いは何ですか?

DynamoDB はマネージドサービスです。そのため、DynamoDB を Titan のストレージバックエンドとして使用することで、グラフストレージのための独自のクラスターを管理することなくグラフワークロードを実行できます。

Q: DynamoDB Storage Backend for Titan はフルマネージドサービスですか?

いいえ。DynamoDB Storage Backend for Titan は、Titan ワークロードのストレージレイヤーを管理します。ただし、このプラグインではクライアント側のプロビジョンおよび管理は実行されません。Titan のプロビジョンを簡素化するため、AWS では DynamoDB Storage Backend for Titan を Gremlin で設定するための CloudFormation テンプレートを開発しました。こちらから手順をご覧ください。

Q: DynamoDB Storage Backend for Titan の使用料金はいくらですか?

お客様は、通常の DynamoDB スループットおよびストレージの費用を課金されます。Titan グラフのワークロード向けのストレージバックエンドとして DynamoDB を使用する場合、追加料金は発生しません。

Q: DynamoDB のバックエンドは、他のバックエンドに設定された Titan 機能と完全な互換性がありますか?

さまざまな Titan ストレージバックエンドの機能を比較した表がこちらのドキュメントでご覧いただけます。

Q: このプラグインはどのバージョンの Titan をサポートしていますか?

AWS は、バージョン 0.5.4 および 1.0.0 の Titan 向けの DynamoDB ストレージバックエンドプラグインをリリースしています。

Q: 現在、異なるバックエンドで Titan を使用しています。DynamoDB に移行できますか?

もちろんできます。DynamoDB Storage Backend for Titan は Titan KCV ストアインターフェイスを実装しているため、アプリケーションに最低限の変更を加えるだけで異なるストレージバックエンドから DynamoDB に移行できます。Titan のストレージバックエンドの完全な比較は、こちらのドキュメントをご覧ください。

Q: 現在、異なるバックエンドで Titan を使用しています。どうすれば DynamoDB に移行できますか?

バルクロードを使用して一方のストレージバックエンドから DynamoDB Storage Backend for Titan にグラフをコピーできます。

Q: Titan インスタンスをプラグイン経由で DynamoDB に接続するにはどうすればよいですか?

DynamoDB Storage Backend for Titan がインストールされた状態でグラフおよび Gremlin サーバーインスタンスを作成した場合、DynamoDB に接続するために必要なのは、デフォルトの AWS 認証情報プロバイダーチェーンにプリンシパルおよび認証情報のセットを提示することのみです。これは、EC2 インスタンスのプロファイル、環境変数、またはホームフォルダの認証情報ファイルによって実行可能です。最後に、接続する DynamoDB エンドポイントを選択する必要があります。

Q: DynamoDB Storage Backend for Titan を使用した場合、データの堅牢性はどの程度になりますか?

DynamoDB Storage Backend for Titan を使用した場合、Amazon の実証済みの、可用性の高いデータセンターにかけて実行される DynamoDB の強力な保護がデータに対して適用されます。このサービスでは、データが同じ AWS リージョン内の 3 つの施設間でレプリケートされるので、サーバー障害の発生やアベイラビリティーゾーンの停止に対する耐障害性が高まります。

Q: DynamoDB Storage Backend for Titan の安全性はどの程度ですか?

DynamoDB Storage Backend for Titan はグラフデータを複数の DynamoDB テーブルに保存するため、他のすべての DynamoDB ワークロードと同じく高いセキュリティが適用されます。Fine-Grained Access Control、IAM の役割、AWS プリンシパルおよび認証情報のセットが、DynamoDB テーブルおよび DynamoDB テーブルの項目へのアクセスを制御します。

Q: DynamoDB Storage Backend for Titan はどのようにスケールしますか?

DynamoDB Storage Backend for Titan は、DynamoDB の他のワークロードと同様にスケールできます。必要なスループットを随時増加または減少できます。

Q: グラフにはいくつの頂点および辺を含めることができますか?

辺の保管に複数項目モデルを使用している場合、Titan の制限である (2^60) で最大の辺の数が制限され、その半分の数の頂点をグラフに含めることができます。単一項目モデルを使用している場合、特定の 1 つの外頂点キーに保存できる辺の数は、DynamoDB の最大項目サイズ（現在は 400 KB）によって制限されます。

Q: 頂点および辺のプロパティはどのくらい大きくできますか?

複数項目モデルにおける辺のプロパティの合計は、最大の項目サイズである 400 KB を超えることはできません。複数項目モデルでは、各頂点のプロパティは最大で 400 KB までです。単一項目モデルでは、合計項目サイズ（頂点のプロパティ、辺および辺のプロパティを含む）が 400 KB を超えることはできません。

Q: いくつのデータモデルがあり、どのような違いがありますか?

DynamoDB Storage Backend for Titan には、単一項目モデルと複数項目モデルという 2 種類のストレージモデルがあります。単一項目のストレージモデルでは、頂点、頂点のプロパティ、辺が 1 つの項目に保存されます。複数項目のデータモデルでは、頂点、頂点のプロパティ、辺が異なる項目に保存されます。どちらの場合でも、辺のプロパティは対応する辺と同じ項目に保存されます。

Q: どちらのデータモデルを使用すればよいでしょうか?

通常、テーブルに対する辺の保管およびグラフのインデックス化には複数項目のデータモデルを推奨しています。そうでなければ、1 つの外頂点に対して保存できる辺および頂点のプロパティの数が制限される、もしくはグラフインデックス内の特定のプロパティの名前と値のペアに対してインデックス化できるエンティティの数が制限されることになります。通常、単一項目のデータモデルは Titan バージョン 0.5.4 および 1.0.0 の他の 4 KCV ストアに対して使用できます。これらに保存される各項目は通常 400 KB より小さくなるためです。Titan プラグインが DynamoDB に作成するテーブルの完全なリストは、こちらをご覧ください。

Q: Titan グラフデータベースのスキーマを作成する必要がありますか?

Titan は自動のタイプ作成をサポートしているため、新規の辺および頂点のプロパティとラベルは最初の使用時に迅速に登録されます (詳細についてはこちらをご覧ください)。Gremlin 構成 (Edge labels=MULTI、Vertex properties=SINGLE) がデフォルトで使用されています。

Q: Titan グラフデータベースのスキーマを変更できますか?

はい。ただし、既存の頂点および辺のプロパティとラベルのスキーマは変更できません。詳細については、こちらをご覧ください。

Q: DynamoDB Storage Backend for Titan はどのようにスーパーノードに対応しますか?

DynamoDB は頂点ラベルのパーティショニングによってスーパーノードに対応します。作成時に、頂点ラベルを管理システム内でパーティショニング済みと定義した場合、辺保管テーブル内のパーティションソートキースペースの複数のパーティションキーで、1 つの頂点から発生する辺および頂点のプロパティの複数のサブセットにキー付けをすることができます。通常、辺保管場所に 1 つよりも多いパーティションがある場合、これによって仮想の頂点ラベルのパーティションが異なる物理的 DynamoDB パーティションに保管されることになります。辺保管テーブルをバックアップする物理的パーティションの数を推測するには、こちらのドキュメントをご覧ください。

Q: DynamoDB Storage Backend for Titan はバッチグラフ操作をサポートしていますか?

はい。DynamoDB Storage Backend for Titan は Blueprints BatchGraph の実装によって、また Titan のバルクロード設定オプションの使用によってバッチグラフ操作をサポートしています。

Q: DynamoDB Storage Backend for Titan はトランザクションをサポートしていますか?

DynamoDB Storage Backend for Titan はオプティミスティックロックをサポートしています。つまり、DynamoDB Storage Backend for Titan では、キーと列のペアまたはキーの既存の値に対する個々のキーと列のペア（複数項目モデルの場合）または個々のキー（単一項目モデルの場合）の書き込みに条件をつけることができます。

Q: Titan インスタンスを 1 つのリージョンで所有し、他のリージョンで DynamoDB にアクセスできますか?

EC2 Titan インスタンスと異なるリージョンで DynamoDB エンドポイントにアクセスすることは可能ですが、推奨されません。Gremlin サーバーを EC2 で実行する場合、クロスリージョンのリクエストによるレイテンシーの影響を緩和するために、EC2 インスタンスと同じリージョンの DynamoDB エンドポイントに接続することを推奨します。また、ネットワークパフォーマンスを向上するため、EC2 インスタンスを VPC で実行することを推奨します。CloudFormation テンプレートが、この設定全体をお客様に代わって実行します。

Q: このプラグインと、ストリームの更新およびクロスリージョンレプリケーションなどの他の DynamoDB 機能を併用できますか?

クロスリージョンレプリケーションと DynamoDB ストリームの機能を使用して、グラフテーブルの読み取り専用レプリカを異なるリージョンに作成できます。

Q: Amazon DynamoDB は CloudWatch メトリクスをレポートしますか?

はい、Amazon DynamoDB は CloudWatch のいくつかのテーブルレベルのメトリクスをレポートします。Amazon DynamoDB テーブルについて運用上の決定を下し、それらメトリクスに基づいてアラームを設定するなどの具体的なアクションを起こすことができます。レポートされるすべてのメトリクスのリストについては、ドキュメンテーションの「CloudWatch による DynamoDB のモニタリング」セクションを参照してください。

Q: Amazon DynamoDB テーブルの CloudWatch メトリクスはどのようにして見ることができますか?

Amazon DynamoDB コンソールで、CloudWatch メトリクスを見るテーブルを選択し、[Metrics] タブを選択します。

Q: メトリクスはどれほどの頻度でレポートされますか?

Amazon DynamoDB の CloudWatch メトリクスのほとんどは 1 分間隔でレポートされます。一部のメトリクスは 5 分間隔でレポートされます。詳細については、ドキュメンテーションの「CloudWatch による DynamoDB のモニタリング」セクションを参照してください。

Q: タグとは何ですか?

タグとは、AWS リソースに割り当てるラベルです。各タグは 1 つのキーと 1 つの値で構成されており、いずれもお客様が定義します。タグは、コスト配分レポートでリソースのコストを整理するためのメカニズムとして使用されます。タグ付けの詳細については、AWS Billing and Cost Management ユーザーガイドを参照してください。

Q: DynamoDB でタグを付けることができるのはどのリソースですか?

DynamoDB テーブルにタグを付けることができます。タグ付けされたテーブルに関連付けられているローカルセカンダリインデックスとグローバルセカンダリインデックスには、自動的に同じタグが付けられます。ローカルセカンダリインデックスとグローバルセカンダリインデックスのコストは、対応する DynamoDB テーブルに使用されているタグごとに表示されます。

Q: DynamoDB にタグを付けるとよいのはどのような場合ですか?

コスト配分のために、DynamoDB にタグを付けることができます。コスト配分のためにタグを使用すると、DynamoDB のリソースにラベルを付けて、プロジェクトなどお客様のコスト構造を反映する条件に対するコストを簡単に追跡できます。

Q: コスト配分のためにタグを使用するにはどうすればよいですか?

コスト配分タグを使用して、AWS のコストを分類および追跡できます。AWS のコストエクスプローラーや請求明細レポートでは、タグによって AWS のコストを分類できます。通常、お客様は、コストセンターやビジネスユニット、顧客、プロジェクトといったビジネスタグを使用して、AWS のコストを従来のコスト配分ディメンションに関連付けています。ただし、コスト配分レポートで使用できるタグに制限はありません。特定のアプリケーション、環境、コンプライアンスプログラムなど、技術やセキュリティに関するディメンションを使って、簡単にコストの関連付けを行うことができます。

Q: タグ付けされた AWS リソースに配分されたコストを確認するにはどうすればよいですか?

タグ付けされた AWS リソースに配分されたコストは、コストエクスプローラーやコスト配分レポートで確認できます。

コストエクスプローラーは、最大で過去 13 か月分のコストを表示し、今後 3 か月間の使用量を予測できる無料の AWS ツールです。特定のタグに関連するコストを確認するには、[Tag] でフィルタリングしてから、タグのキーと値を選択します (タグの値を指定していない場合は、[No tag] を選択します)。

コスト配分レポートでは、AWS のすべてのコストが請求期間別に表示されます。タグ付きとタグなしのどちらのリソースもこのレポートに出力されるので、リソース別の請求額を明確に分類できます。例えば、リソースにアプリケーション名のタグを付けると、1 つのアプリケーションが実行されているすべてのリソースのコスト総額がわかります。コスト配分に関する詳細については、AWS 請求情報とコスト管理ユーザーガイドをご覧ください。

Q: DynamoDB ストリームの使用量にタグを付けることはできますか?

いいえ。現在のところ、DynamoDB ストリームの使用量にタグを付けることはできません。

Q: 請求書では、テーブルのタグごとにリザーブドキャパシティーの使用量が表示されますか?

はい。テーブルごとの DynamoDB リザーブドキャパシティーの料金は、関連するタグごとに表示されます。リザーブドキャパシティーは、リンクされたすべての AWS アカウントの DynamoDB で先着順に適用されます。つまり、ある 2 つの月を比べたときに、テーブルやインデックス全体で DynamoDB の使用量が同じでも、コスト配分レポートに表示されるタグごとの使用量は異なる可能性があります。リザーブドキャパシティーは、DynamoDB リソースを使用した順に配分されるためです。

Q: 請求書では、テーブルのタグごとにデータ使用料が表示されますか?

いいえ。DynamoDB のデータ使用料にタグは付けられません。データ使用料はテーブルごとではなくアカウントごとに請求されるためです。

Q: タグには値の属性が必要ですか?

いいえ。タグの値を null にすることもできます。

Q: タグでは大文字と小文字が区別されますか?

はい。タグのキーと値では大文字と小文字が区別されます。

Q: 1 つの DynamoDB テーブルに追加できるタグはいくつですか?

1 つの DynamoDB テーブルに追加できるタグは最大で 50 個です。"aws:" というプレフィックスが付いたタグは自動的に作成されるもので、リソースごとのタグ数の上限には関係しません。

Q: タグをさかのぼって DynamoDB テーブルに適用できますか?

いいえ。タグによるデータの整理や追跡は、タグを適用した日から開始されます。1 月 1 日にテーブルを作成したもののタグを指定したのが 2 月 1 日である場合、1 月のテーブルの使用量すべてにタグは付けられていません。

Q: ある月の途中で DynamoDB テーブルからタグを削除した場合、そのタグは請求書に表示されますか?

はい。特定の期間に追跡された費用のレポートを作成する場合、コストレポートにはその期間中にタグ付けされていたリソースのコストが表示されます。

Q: DynamoDB テーブルを削除された場合、関連付けられていたタグはどうなりますか?

DynamoDB テーブルが削除された場合、タグは自動的に削除されます。

Q: 既存のタグとキーが同じタグを追加するとどうなりますか?

各 DynamoDB テーブルには、キーが同じタグを 2 つ以上設定できません。既存のタグとキーが同じタグを追加すると、既存のタグが新しい値に更新されます。

Q: DynamoDB 有効期限 (TTL) とは?

DynamoDB 有効期限 (TTL) は、有効期限の切れた項目をテーブルから削除する特定のタイムスタンプを設定できるメカニズムです。タイムスタンプの期限が切れると、対応する項目は期限切れとしてマークされ、その後テーブルから削除されます。この機能を使用すれば、手動で期限切れデータを追跡して削除する必要がなくなります。ストレージの使用量を減らし、価値のなくなったデータの保存にかかっていたコストを削減するのに役立ちます。

Q: どのようなときに TTL が必要ですか?

TTL が役立つ主なシナリオには 2 種類あります。

• 不要になった古いデータを削除する場合があります。イベントログ、使用履歴、セッションデータなど、長期間、収集すると量が膨大になり、古いデータをシステムに保存しておく価値がないことがあります。このような場合、古くなったレコードをシステムから削除し、保存に費やしていたお金を節約するほうが賢明です。
• データの保持と管理についてのポリシー遵守のため、特定の期間のみデータを DynamoDB に保存しておきたい場合もあります。保持が義務付けられている期間の経過後は、削除したいことがあります。ただし、その他の重要不可欠なオペレーションのスループットを優先するため、TTL はベストエフォートベースで動作することにご注意ください。DynamoDB では、有効期限の切れた項目を 2 日以内に削除することを目標とします。データのサイズによっては、これより長い時間がかかる可能性もあります。

Q: DynamoDB TTL の仕組みを教えてください。

テーブルに対して TTL を有効にするには、まずテーブル内の各項目に有効期限タイムスタンプを保存できる属性があるかどうかを確認します。タイムスタンプはエポック時刻形式であることが必要です。これにより、クライアントとサーバーの間でのタイムゾーンの違いによる問題を避けられます。

DynamoDB では、すべての項目をモニタリングするバックグラウンドスキャナーが実行されています。タイムスタンプの有効期限が切れると、項目がこのプロセスによって期限切れとマークされ、続いて削除のキューに入れられます。

注: TTL では、データの失効条件を指定するためのエポックタイムスタンプが入力された、数値形式の DynamoDB テーブル属性が必要です。TTL 属性の値に誤った値を設定すると、期限前に項目を削除してしまう可能性があるため、属性値の設定には十分注意してください。

Q: TTL はどのようにして指定できますか?

TTL を指定するには、まずテーブルの TTL 設定を有効にしてから、TTL 値として使用する属性を指定します。テーブルに項目を追加する際、有効期限切れとなったときに自動的に削除するよう DynamoDB を設定する場合は、TTL 属性を指定できます。この値は有効期限切れとなる時間であり、エポック時刻形式で指定します。残りの処理は DynamoDB が自動的に行います。TTL はコンソールで、テーブルの概要タブから指定できます。別の方法として、開発者は TTL API を呼び出してテーブルに TTL を設定することもできます。ドキュメントと API ガイドを参照してください。

Q: 既存のテーブルに TTL を設定できますか?

はい。テーブルが既に作成されていて、項目の TTL として使用できる属性も存在している場合、そのテーブルに TTL を有効化し、適切な属性を TTL に指定することで使用できます。TTL として使用できる属性がテーブルに存在しない場合、そのような属性を作成し、項目の TTL の値を更新する必要があります。

Q: テーブル全体に TTL を設定すれば、テーブル全体を削除できますか。

いいえ。TTL に使用する属性はテーブルレベルで定義することが必要ですが、データ削除は項目レベルです。つまり、テーブル内にある、有効期限後の削除が必要な各項目に対して、TTL 属性に定義する値が必要です。テーブル全体を自動的に削除するオプションはありません。

Q: テーブル内の一部の項目のみに TTL を設定できますか?

はい。TTL は、TTL 属性に値が定義されている項目のみに影響を与えます。そのテーブル内のその他の項目には影響がありません。

Q: TTL を指定する形式はどのようなものですか?

TTL 値には、1970 年 1 月 1 日 UTC からの経過秒数であるエポック時刻形式を使用します。項目の TTL 属性に指定された値の形式が正しくない場合、その値は無視され、項目は削除されません。

Q: テーブルからどうすれば TTL の値を確認できますか?

TTL 値は項目のその他の属性と変わりません。その他の属性と同じ方法で読み取れます。TTL 値を確認しやすくするため、DynamoDB コンソールで TTL 属性にマウスカーソルを合わせると、値が現地時間と UTC 時間で表示されます。

Q: テーブル内の項目に割り当てられた TTL 値に基づくインデックスは作成できますか?

はい。TTL は項目のその他の属性と同じように動作します。その他の項目と同じ方法でインデックスを作成できます。

Q: TTL 属性をインデックスに射影できますか?

はい。その他の属性と同じように、TTL 属性もインデックスに射影可能です。

Q: 項目に一度設定された TTL 属性の値を変更できますか?

はい。項目のその他の属性と同じように、TTL 属性の値も編集可能です。

Q: テーブルの TTL 属性は変更できますか?

はい。既に TTL の設定されている TTL に別の TTL 属性を指定する場合、テーブルの TTL をいったん無効にしてから、新しい TTL 属性でテーブルの TTL を再度有効化できます。TTL の無効化はすべてのパーティションに適用されるまでに最大 1 時間かかる場合があり、このアクションが完了するまでは、TTL を再有効化できないことにご注意ください。

Q: AWS マネジメントコンソールから TTL の値の参照や編集を実行できますか?

はい。AWS マネジメントコンソールを使って、TTL の値の参照、設定、更新を簡単に実行できます。

Q: JSON ドキュメント内の属性を TTL 属性に設定できますか?

いいえ。JSON ドキュメント内の属性を TTL 属性として指定することは、現時点でサポートされていません。TTL を設定するには、各項目に TTL 属性を明示的に追加する必要があります。

Q: JSON ドキュメント内の特定の要素に TTL を設定できますか?

いいえ。TTL 値はドキュメント全体に対してのみ設定できます。JSON ドキュメント内の特定の項目が期限切れになった場合の削除はサポートされていません。

Q: 特定の項目の TTL を削除する必要がある場合はどうすればよいですか?

その項目から TTL 属性に指定された値を削除するか、または属性そのものを削除すれば TTL を削除できます。

Q: TTL タイムスタンプ値を過去の時点に設定した場合はどうなりますか?

過去の TTL 値を使用して項目を更新することは可能です。バックグラウンドプロセスによって期限切れの項目がチェックされるときに、その項目が発見され、マークされ、最終的に削除されます。ただし、TTL 属性の値が 5 年以上前のタイムスタンプを示すエポック値であった場合、DynamoDB ではそのタイムスタンプが無視され、その項目は削除されません。これは、TTL 属性に非常に低い値が設定され、誤って項目が削除されてしまうリスクを緩和するための処置です。

Q: 項目に設定された TTL 有効期限から、実際に削除される時間までにはどれほど遅延がありますか?

TTL では、システム内のバックグラウンドスループットを利用して期限切れ項目のスキャンと削除が実行されます。このため、期限切れとなった項目がテーブルから即座に削除されない場合があります。その他のデータオペレーション向けにシステムのバックグラウンドスループットの十分な可用性を確保しておくため、DynamoDB では、ベストエフォートベースで有効期限から 2 日の間に項目を削除することを目指しています。ある項目の有効期限から実際の削除までに必要となる時間の長さは、ワークロードの性質やテーブルのサイズによって異なります。

Q: TTL によって期限切れとなった項目に対するクエリやスキャンを行った場合はどうなりますか?

ある項目の有効期限が切れてから実際にバックグラウンドプロセスにより削除されるまでには時間差があることから、有効期限が切れたもののまだ実際に削除されていない項目を読み取ろうとした場合、返される結果には期限切れの項目も含まれます。期限切れの項目を表示しないようにするには、TTL 値によるフィルターを利用できます。

Q: 期限切れになった場合、ローカルセカンダリインデックス (LSI) のデータはどうなりますか?

この場合の影響は、その他の削除オペレーションと同じです。ローカルセカンダリインデックスは、項目と同じパーティションに保存されます。このため、項目が削除された場合、ローカルセカンダリインデックスから即座に削除されます。

Q: 期限切れになった場合、グローバルセカンダリインデックス (GSI) のデータはどうなりますか?

この場合の影響は、その他の削除オペレーションと同じです。グローバルセカンダリインデックス (GSI) は結果整合性であるため、元の有効期限切れ項目が削除された場合でも、GSI が更新されるまでにはいくらか時間がかかる場合があります。

Q: TTL は DynamoDB Streams とどのように連携しますか?

消去をトリガーする TTL 値によるテーブルのデータの期限切れは、削除オペレーションとして記録されます。このため、Streams でも削除オペレーションが記録されます。他の削除と TTL により発生した削除とを区別できるよう、削除レコードには修飾子が付加されます。レコードの削除された実際の時刻を反映するため、ストリームのエントリは TTL 有効期限切れの時刻ではなく、削除の時点で書き込まれます。ドキュメントと API ガイドを参照してください。

Q: 削除オペレーションと TTL はどのように使い分けられますか?

TTL は期限切れレコードをテーブルから削除するのに最適です。ただし、不要なデータの消去を助けるためのベストエフォート型オペレーションとして設計されているため、実際の削除がいつまでに発生するかを特定できません。このため、テーブル内のデータを特定の期間内に (通常は即時に) 削除する必要がある場合は、削除コマンドの使用を推奨します。

Q: TTL 値の設定や更新のアクセス権は制御できますか?

はい。TTL 属性はテーブルのその他の属性と同じです。テーブルの属性レベルでアクセスをコントロールすることが可能です。TTL 属性は、そのテーブルに指定された通常のアクセスコントロールに従います。

Q: TTL 有効期限切れで削除されたデータを取得する方法はありますか?

いいえ。期限切れの項目について、削除前のバックアップは実行されません。必要であれば、DynamoDB Streams を活用してテーブルに対する変更の追跡と値の回復を実現できます。Streams の削除レコードは削除時刻から 24 時間利用できます。

Q: テーブルの TTL が有効かどうかをどのように判断できますか?

DescribeTable API の呼び出しによって、または DynamoDB コンソールでテーブルの詳細を参照することで、いつでも TTL の状態を確認できます。ドキュメントと API ガイドを参照してください。

Q: TTL によって削除された項目を追跡するにはどうすればよいですか?

DynamoDB Streams が有効にされている場合、TTL による削除はすべて DynamoDB Streams に表示され、自分で明示的に実行した削除と区別できるよう、システムによる削除であることが示されます。必要に応じて、ストリームから項目を読み取り、処理することが可能です。Lambda 関数を記述して項目を個別に取得することもできます。ドキュメントと API ガイドを参照してください。

Q: データに TTL 機能を有効化するために別途料金の支払いが必要ですか?

いいえ。TTL の有効化に追加料金は不要です。

Q: TTL を有効にした場合、プロビジョンドスループットの全体的な使用量にどのような影響がありますか?

TTL のスキャンと削除に必要なオペレーションはシステムによって実行されるため、プロビジョンドスループットや使用量として計算されることはありません。

Q: TTL のモニタリングのためのスキャンオペレーションによる支払いは発生しますか?

いいえ。項目の TTL 有効期限をモニタリングする内部的なスキャンオペレーションによって課金が発生することはありません。また、これらのオペレーションがテーブルのスループット使用量に影響することもありません。

Q: 有効期限が切れた項目でも、実際に削除されるまではストレージコストがかかるのですか?

はい。有効期限が切れた項目は削除キューに追加され、削除待ちになります。ただし、実際に削除されるまでの間は、その他の通常の項目と同じように読み取りや更新が実行でき、ストレージのコストも発生します。

Q: 有効期限の切れた項目をクエリした場合、読み込み容量は消費されますか?

はい。この場合の動作は、テーブルに存在しない項目をクエリした場合と同じです。

Q: Amazon DynamoDB Accelerator (DAX) とは何ですか?

Amazon DynamoDB Accelerator (DAX) は、フルマネージド型で可用性の高い、DynamoDB 用インメモリキャッシュであり、要件の厳しいアプリケーションに対して高速なインメモリパフォーマンスを利用できるようにします。DAX は DynamoDB の読み取り負荷の高いワークロードのパフォーマンスを向上させるため、キャッシュされたデータを繰り返し読み込んでも非常に低いレイテンシーで即時処理され、DynamoDB を再度クエリする必要はありません。DAX はキャッシュミスの際は DynamoDB テーブルから自動的にデータを取得します。書き込みは書き込みスルーとして指定されます (データはまず DynamoDB に書き込まれて、その後 DAX キャッシュで更新されます)。

DynamoDB と同様に、DAX は耐障害性がありスケーラブルです。DAX クラスターにはプライマリノードと 0 個以上のリードレプリカノードがあります。プライマリノードに障害が発生すると、DAX が自動的にフェイルオーバーして新しいプライマリを選択します。スケーリングについては、リードレプリカを追加または削除できます。

開始するには、DAX クラスターを作成し、DAX SDK for Java (DynamoDB API と互換性があります) をダウンロードして、DynamoDB クライアントではなく DAX クライアントを使用するようにアプリケーションを再構築します。最後に、DAX クライアントを DAX クラスターエンドポイントに指定します。アプリケーションに追加のキャッシュロジックを実装する必要はありません。DAX クライアントに実装されている API コールは DynamoDB と同じものです。

Q: 「DynamoDB と互換性がある」とはどういう意味ですか?

現在 DynamoDB とともにすでに使用しているコード、アプリケーション、およびツールのほとんどは、何も変更しないかわずかな変更で DAX でも使用できるという意味です。DAX エンジンは DynamoDB のデータの読み込みおよび変更に DynamoDB API をサポートするように設計されています。CreateTable/DescribeTable/UpdateTable/DeleteTable などのテーブル管理の操作はサポートされていません。

Q: インメモリキャッシュとは何ですか? アプリケーションでどのように利用できますか?

キャッシュは、低レイテンシーで高スループットのアクセスを実現するためにメモリ内にデータの重要な部分を保存することにより、アプリケーションのパフォーマンスを向上させます。DAX の場合、DynamoDB オペレーションの結果がキャッシュされます。アプリケーションがキャッシュに保存されているデータをリクエストすると、DAX は、DynamoDB の通常のテーブルに対してクエリを実行する必要がなく、そのデータをすばやく提供できます。データは、そのデータに有効期限 (TTL) 値を指定することで、期限切れになったり、DAX から削除されたります。または、使用可能なメモリが不足すると、Least Recently Used (LRU) に基づいて項目が削除されます。

Q: DAX の整合性モデルとは何ですか?

DAX からデータを読み込むとき、その読み込みを結果整合性にするか強い整合性にするかを指定できます。

結果的に整合性のある読み込み (デフォルト) – 結果整合性オプションは、読み込みスループットを最大化し、レイテンシーを最小化します。キャッシュヒットでは、DAX クライアントはキャッシュから直接結果を返します。キャッシュミスでは、DAX は DynamoDB をクエリし、キャッシュを更新して、結果セットを返します。結果的に整合性のある読み込みには、最近完了した書き込みの結果が反映されない可能性があることに注意してください。アプリケーションに完全な整合性が必要な場合は、強い整合性のある読み込みを使用することをお勧めします。

強い整合性のある読み込み – DAX では、結果整合性に加えて、強い整合性のある読み込みをアプリケーションまたはアプリケーションの要素が必要とする場合は、それをリクエストする柔軟性とコントロールも提供しています。強い整合性のある読み込みは DAX に対するパススルーであり、結果は DAX にキャッシュされず、読み込みに先立って DynamoDB で成功の応答が返されたすべての書き込みを反映した結果が返されます。

Q: DAX の一般的なユースケースを教えてください。

DAX には、互いを排除しない多数のユースケースがあります。

可能な限り迅速な読み込み応答時間を必要とするアプリケーション。例えば、リアルタイム入札、ソーシャルゲーム、トレーディングアプリケーションなどです。DAX はこれらのユースケースに対して、高速なインメモリ読み込みパフォーマンスを提供します。

少数の項目を他のものよりも頻繁に読み込むアプリケーション。例えば、人気商品の 1 日限りのセールを行う e コマースシステムを考えてみます。セール中は、その商品 (および DynamoDB 内のそのデータ) に対する需要が他の商品全般に比べて急増します。「ホット」キーおよび不均一なデータディストリビューションの影響を緩和するために、1 日限りのセールが終了するまで、読み込みアクティビティを DAX キャッシュにオフロードできます。

読み込み負荷が高いが、コストも重要なアプリケーション。DynamoDB を使用する場合、アプリケーションが要求する読み込み数を 1 秒ごとにプロビジョニングします。読み込みアクティビティが上昇すれば、テーブルにプロビジョニングされた読み込みスループットも増加し (追加コストがかかり) ます。代わりに、アプリケーションからのアクティビティを DAX クラスターにオフロードして、そうしない場合に購入する必要がある読み込み容量ユニットの量を削減できます。

大規模データセットに対して繰り返し読み込みが必要なアプリケーション。このようなアプリケーションは、データベースリソースを他のアプリケーションから引き離してしまう可能性があります。例えば、ある地域の気象データの長期実行分析などは、一時的に DynamoDB テーブルのすべての読み込みキャパシティーを消費し、同じデータにアクセスする必要のある他のアプリケーションに悪影響を与える可能性があります。DAX を使用することで、代わりにキャッシュデータに対して気象分析を実行できます。

仕組み

Q: DAX はユーザーに代わって何を管理しますか?

DAX は、DynamoDB 用のフルマネージド型のキャッシュです。サーバーリソースのプロビジョニングから DAX ソフトウェアのインストールまで、専用キャッシュノードのセットアップに含まれる作業を管理します。DAX キャッシュクラスターがセットアップされ実行されると、障害検出と回復やソフトウェアのパッチなど、一般的な管理タスクがサービスで自動化されます。DAX はクラスターに関連付けられた詳細な CloudWatch モニタリングメトリクスを提供するため、問題をすばやく診断して対応できます。これらのメトリクスを使用して、CloudWatch アラームを受信するためのしきい値を設定できます。DAX がデータのキャッシュ、取得、削除をすべて処理するので、アプリケーションがこれを行う必要はありません。単純にデータの書き込みと取得 DynamoDB API を使用すれば、DAX が見えない部分でキャッシュロジックをすべて処理し、パフォーマンスが向上します。

Q: DAX はどのようなデータをキャッシュするのですか?

すべての読み込み API コールが DAX でキャッシュされます。強い整合性のあるリクエストは DynamoDB から直接読み込まれますが、結果的に整合性のある読み込みでは、項目が DAX にある場合はそれが読み込まれます。書き込み API コールは書き込みスルーです (DynamoDB に正常に書き込まれた場合にキャッシュで更新される同期書き込みです)。

次の API コールは、キャッシュの試験になります。ヒットすると、項目が返されます。ミスの場合、リクエストはパススルーされ、取得に成功すると項目はキャッシュされて返されます。

• GetItem
• BatchGetItem
• Query
• Scan

次の API コールは、書き込みスルー操作です。

• BatchWriteItem
• UpdateItem
• DeleteItem
• PutItem

Q: DAX はデータ削除をどのように処理するのですか?

DAX はキャッシュ削除を 3 つの異なる方法で処理します。まず、項目がキャッシュ内で使用可能な絶対時間を示す有効期限 (TTL) 値を使用します。次に、キャッシュがいっぱいになると、DAX クラスターは Least Recently Used (LRU) アルゴリズムを使用して、削除する項目を決定します。その次に、書き込みスルー機能によって、新しい値が DAX によって書き込まれると、DAX が古い値を削除します。これにより、DAX 項目キャッシュを、単一の API コールを使用して基礎となるデータストアと整合させることができます。

Q: DAX は DynamoDB GSI および LSI で機能しますか?

DynamoDB テーブルと同様に、DAX は、DynamoDB GSI と LSI の両方に対するクエリとスキャンの両方の操作の結果セットをキャッシュします。

Q: DAX はクエリとスキャンの結果セットをどのように処理するのですか?

DAX クラスター内には、1) 項目キャッシュと 2) クエリキャッシュという、2 つの異なるキャッシュがあります。項目キャッシュは、個々のキー値のペアの GetItem、PutItem、および DeleteItem リクエストを管理します。クエリキャッシュは、スキャンおよびクエリリクエストの結果セットを管理します。この点で、スキャン/クエリテキストは「キー」であり、結果セットは「値」です。項目キャッシュとクエリキャッシュは同じクラスターで管理されます (また、キャッシュごとに異なる TTL 値を指定することもできます)。ただし、重複はしません。例えば、テーブルのスキャンでは項目キャッシュが入力されず、代わりにスキャンの結果セットを格納するクエリキャッシュにエントリが記録されます。

Q: 項目キャッシュの更新によって、クエリキャッシュ内の結果セットが更新または無効化されますか?

いいえ。項目キャッシュとクエリキャッシュの結果セット間の不一致を緩和する最適な方法は、クエリキャッシュの TTL を、アプリケーションがそのような不一致を処理するのに適した時間になるように設定することです。

Q: VPC の外部から DAX クラスターに接続できますか?

VPC の外部から DAX クラスターに接続する唯一の方法は、VPN 接続を使用することです。

Q: DAX を使用しているとき、基礎となる DynamoDB テーブルが調整されるとどうなりますか?

DAX が DynamoDB テーブルに対して読み取りまたは書き込みを行っているときに、スロットリング例外を受け取ると、DAX はその例外を DAX クライアントに返します。さらに、DAX サービスはサーバー側の再試行を試みません。

Q: DAX はキャッシュの事前ウォーミングをサポートしていますか?

DAX は遅延ロードを使用してキャッシュにデータを格納します。これは、項目を最初に読み取ったときに、DAX が DynamoDB から項目を取り出してキャッシュに入力することを意味します。DAX はキャッシュの事前ウォーミングを機能としてはサポートしていませんが、DAX キャッシュは、目的のデータを読み取る外部スクリプト/アプリケーションを実行することによって、アプリケーションに対して事前ウォーミングを行うことができます。

Q: DAX は DynamoDB TTL 機能とどのように連携しますか?

DynamoDB と DAX には、どちらにも「TTL」 (有効期限) 機能という概念があります。DynamoDB のコンテキストでは、TTL は、特定の属性と対応するタイムスタンプでデータにタグを付けることによって、お客様がデータをエージアウトできるようにする機能です。例えば、お客様がデータを 1 か月間保存した後にデータを削除したい場合は、エージングワークフロー自体を管理するのではなく、DynamoDB TTL 機能を使用してこのタスクを実行します。

DAX のコンテキストでは、TTL はキャッシュ内の項目が有効である期間を示します。例えば、TTL が 5 分に設定されている場合、項目はキャッシュに入力された後も引き続き有効で、5 分の期間が経過するまでキャッシュから提供されます。この話の中心ではありませんが、同じ項目用のキャッシュへの書き込みによって、または DAX ノードにメモリ負荷がかかっていて、LRU によって最も長時間使用されていない項目が削除される場合は、TTL を事前に無効にすることができます。

DynamoDB と DAX の TTL は通常はまったく異なる時間単位で使用されますが (DAX TTL は分/時間の範囲で、DynamoDB TTL は週/月/年の範囲で使用します)、お客様にはこれらの 2 つの機能が互いにどのように影響するかの説明が必要になる可能性があります。例えば、DynamoDB の TTL 値が DAX の TTL 値よりも小さいシナリオを想像してみましょう。このシナリオでは、項目が DAX にキャッシュされ、その後 DynamoDB TTL 機能によって DynamoDB から削除される可能性があります。その結果、一貫性のないキャッシュになります。2 つの機能の時間単位は通常は桁が異なるため、このようなシナリオが頻繁に発生するとは考えていませんが、2 つの機能が互いにどのように関連しているかを知っておくとよいでしょう。

Q: DAX はクロスリージョンレプリケーションをサポートしていますか?
現時点で DAX がサポートしているのは、DAX クラスターと同じ AWS リージョン内の DynamoDB テーブルのみです。

開始方法

Q: どうすれば DAX の使用を開始できますか?
AWS コンソールまたは AWS SDK を使用して新しい DAX クラスターを作成して、DAX クラスターエンドポイントを取得できます。新しい DAX エンドポイントを使用するには、DAX 対応クライアントをダウンロードしてアプリケーションで使用する必要があります。

Q: DAX クラスターを作成するには、どうすればよいですか?

DAX クラスターは、AWS コンソールまたは DAX CLI を使用して作成できます。DAX クラスターの範囲は、13 GiB キャッシュ (dax.r3.large) から 216 GiB (dax.r3.8xlarge) までです。スループットが増加したら、AWS コンソールで数クリックするか、API コールを 1 つ行うだけで、クラスターにレプリカを追加できます (最大 10 個のレプリカ)。

単一ノード構成では、コスト効率よく迅速に DAX を開始できます。その後、ニーズが増えるに従って、複数ノード構成にスケールアウトできます。複数ノード構成は、書き込みを管理するプライマリノードと、最大 9 個のリードレプリカノードで構成されます。プライマリノードは自動的にプロビジョニングされます。

任意のサブネットグループ/アベイラビリティーゾーン (オプション)、ノード数、ノードタイプ、VPC サブネットグループ、その他のシステム設定を指定するだけです。必要な設定を選択したら、DAX が必要なリソースをプロビジョニングし、DynamoDB 専用のキャッシュクラスターを設定します。

Q: DAX を使用するためにすべてのデータをメモリに合わせる必要がありますか?

いいえ。DAX はノード上の使用可能なメモリを利用します。TTL と LRU、またはそのどちらかを使用すると、メモリ領域が使い尽くされたときに新しいデータ用の領域を作るために項目が消去されます。

Q: DAX でサポートされている言語を教えてください。

DAX には、今すぐダウンロードできる DAX SDK for Java が用意されています。引き続き、クライアント向けのサポートの追加に取り組んでいます。

Q: DAX と DynamoDB を同時に使用できますか?

はい、異なるクライアントを通して DAX のエンドポイントと DynamoDB に同時にアクセスできます。ただし、DAX は DynamoDB に直接書き込まれたデータの変更を検出できません。検出できるのは、DynamoDB で直接更新が行われた後に読み込みオペレーションを通してその変更が明示的に DAX に読み込まれたときだけです。

Q: 同じ DynamoDB テーブルに対して複数の DAX クラスターを利用できますか?

はい、同じ DynamoDB テーブルに対して複数の DAX クラスターをプロビジョニングできます。これらのクラスターは、異なるユースケースに使用できる異なるエンドポイントを提供します。これにより、異なるシナリオごとの最適なキャッシュになります。2 つの DAX クラスターは互いに独立しており、状態や更新を共有しません。そのため、まったく異なるテーブルでこれらを使用することで最良の処理が提供されます。

Q: 自分のワークロードに必要な DAX ノードタイプを見つけるにはどうしたらいいですか?

DAX クラスターのサイズ変更は反復プロセスです。メモリ内のアプリケーションの作業設定に合わせた十分なメモリがある、3 つのノードがあるクラスター (高可用性のため) をプロビジョニングすることをお勧めします。アプリケーションのパフォーマンスとスループット、DAX クラスターの使用率およびキャッシュヒット/キャッシュミスの比率に基づいて、目的の結果を実現するために DAX クラスターをスケールする必要がある場合があります。

Q: どのような EC2 インスタンスで DAX を実行できますか?

有効なノードタイプは次のとおりです。

• dax.r3.large (13 GiB)
• dax.r3.xlarge (26 GiB)
• dax.r3.2xlarge (54 GiB)
• dax.r3.4xlarge (108 GiB)
• dax.r3.8xlarge (216 GiB)

Q: DAX はリザーブドインスタンスや AWS 無料利用枠をサポートしていますか?

現在、DAX はオンデマンドインスタンスのみをサポートしています。

Q: DAX はどのような料金設定ですか?

DAX の料金は、ノードが起動してから終了するまでにかかったノード時間単位で計算されます。1 時間未満のノード時間は、1 時間分として請求されます。料金は、DAX クラスター内のすべての個別のノードに対して適用されます。例えば、3 つのノードで構成される DAX クラスターを使用している場合、時間単位で、異なる各ノード (合計 3 つ) に対して課金されます。

可用性

Q: どうすれば DAX クラスターで高可用性を実現できますか?

DAX 組み込みマルチ AZ のサポートを提供しているため、DAX クラスターのノードに好きなアベイラビリティーゾーンを選択できます。DAX ではノード間の整合性を取るために非同期レプリケーションを使用するため、障害発生時は、別のノードでリクエストを処理できます。計画内および計画外両方の停止に備えて DAX クラスターで高可用性を実現するには、少なくとも 3 つのノードを 3 つの別々のアベイラビリティーゾーンにデプロイすることをお勧めします。各アベイラビリティーゾーンは、その独自の、物理的にはっきりと独立したインフラストラクチャ上で稼働しています。また高い信頼性を保つように設計されています。

Q: DAX ノードに障害が発生するとどうなりますか?

プライマリノードに障害が発生した場合、DAX は自動的に障害を検出し、使用可能なリードレプリカの 1 つを選択して新しいプライマリに昇格させます。さらに、DAX は障害のあるプライマリと同じアベイラビリティーゾーンに新しいノードをプロビジョニングします。この新規ノードは新しく昇格されたリードレプリカを置き換えます。一時的なアベイラビリティーゾーンの障害のためにプライマリに障害が発生すると、AZ が回復してすぐに新しいレプリカが起動されます。単一ノードクラスターに障害が発生した場合、DAX は同じアベイラビリティーゾーンの新しいノードを起動します。

スケーラビリティ

Q: DAX でサポートされているスケーリングのタイプは何ですか?

DAX は現在 2 つのスケーリングオプションをサポートしています。最初のオプションは、クラスターにリードレプリカを追加することで追加のスループットを獲得する読み取りスケーリングです。単一 DAX クラスターは最大 10 個のノードをサポートし、1 秒あたり数百万件のリクエストを提供します。追加レプリカの追加や削除はオンラインオペレーションです。クラスターをスケールする 2 番目の方法は、より大きい r3 インスタンスタイプまたはより小さい r3 インスタンスタイプを選択することでスケールアップまたはスケールダウンすることです。大きいノードではクラスターがアプリケーションのデータセットをより多くメモリに保存できるため、キャッシュミスが軽減され、アプリケーション全体のパフォーマンスが向上します。DAX クラスターを作成する際は、クラスター内のすべてのノードは同じインスタンスタイプである必要がある場合があります。さらに、DAX クラスターのインスタンスタイプを変更する場合 (例: r3.large から r3.2xlarge へのスケールアップ)、目的のインスタンスタイプで新しい DAX クラスターを作成する必要があります。現在、DAX はオンラインアップまたはスケールダウンオペレーションをサポートしていません。

Q: アプリケーションの書き込みスケーリングはどうすればよいですか?

DAX クラスター内では、プライマリノードだけが DynamoDB への書き込みオペレーションを処理します。したがって、DAX クラスターにノードを追加すると、読み取りスループットは向上しますが、書き込みスループットは向上しません。アプリケーションの書き込みスループットを向上させるには、より大きなインスタンスサイズにスケールアップするか、複数の DAX クラスターをプロビジョニングして、アプリケーションレイヤーのキースペースをシャーディングする必要があります。

モニタリング

Q: DAX クラスターのパフォーマンスを監視するにはどうすればいいですか?
DAX クラスターの CPU 使用率、キャッシュヒット/キャッシュミス数、読み込み/書き込みトラフィックのメトリクスは、AWS マネジメントコンソールまたは Amazon CloudWatch API 経由で利用できます。Amazon CloudWatch のカスタムメトリクス機能を使用して、ユーザー定義メトリクスを追加することもできます。CloudWatch メトリクスに加えて、DAX は AWS マネジメントコンソール経由でキャッシュヒット、キャッシュミス、クエリおよびクラスターパフォーマンスの情報も提供します。

メンテナンス

Q: 保守管理時間枠とは何ですか?DAX クラスターはソフトウェアメンテナンス中も利用できますか。

DAX の保守管理時間枠は、ソフトウェアのパッチなどクラスターの変更が実行されるタイミングをコントロールする機会と考えることができます。「メンテナンス」イベントが特定の週に予定されている場合、お客様が識別する保守管理時間枠の間の一定の時点で、開始されて完了します。

要求されたパッチに対しては、安全で信頼性に関連のあるパッチのみが自動的にスケジューリングされます。そのようなパッチ適用は頻繁に起こるものではありません (通常、数か月ごとに 1 度です)。クラスターの作成時点で、希望する週間保守管理時間枠が指定されていない場合は、デフォルト値が割り当てられます。ユーザーに代わってメンテナンスが実行される時間を変更する場合は、AWS マネジメントコンソールでクラスターを修正するか、UpdateCluster API を使用してこれを行うことができます。クラスターごとに、別々の保守管理時間枠を指定できます。

複数ノードのクラスターの場合、クラスター内の更新は順次実行され、一度に 1 つのノードが更新されます。ノードが更新されると、クラスター内のピアの 1 つと同期されるため、ノードには最新の作業データセットが保存されます。単一ノードのクラスターでは、レプリカをプロビジョニングし (無料)、レプリカを最新のデータと同期させてから、フェイルオーバーを実行して新しいレプリカをプライマリノードにします。これにより、1 ノードのクラスターのアップグレード中にデータが失われることはありません。