メインコンテンツに移動

Amazon DynamoDB

DynamoDB について

すべて開く

DynamoDB は、あらゆる規模で単一桁ミリ秒のパフォーマンスを実現する、サーバーレスでフルマネージド型の分散型 NoSQL データベースサービスです。DynamoDB では、インフラストラクチャ管理やダウンタイムなしのメンテナンス、あらゆるアプリケーション需要への即時スケーリング、リクエストごとの課金が可能です。コールドスタート、バージョンアップグレード、メンテナンスウィンドウはありません。DynamoDB は完全マネージド型であるため、バックアップ、セキュリティ、コンプライアンス、モニタリングなどの分化されていないデータベース管理タスクに伴う面倒な作業は不要です。グローバルに分散されたアプリケーションの場合、DynamoDB グローバルテーブルはマルチリージョン、マルチアクティブデータベースで、最大 99.999% の可用性を備え、データベースの耐障害性が最高です。マルチリージョンの強力な整合性をサポートしているため、アプリケーションは常に利用可能な状態を維持し、どのリージョンからでも常に同じデータを読み取ることができるため、RPO ゼロのアプリケーションを構築できます。DynamoDB は、政府、グローバル銀行、その他の機密性の高い組織の要件を満たすように構築された幅広いセキュリティコントロールとコンプライアンス標準を備えています。

DynamoDB を使用すると、分散データベースの運用とスケーリングに関する管理上の負担を AWS にオフロードできるため、ハードウェアのプロビジョニング、設定と構成、スループットキャパシティのプランニング、レプリケーション、ソフトウェアのパッチ適用、クラスターのスケーリングなどについて心配する必要がなくなります。分散型の NoSQL データベースはほんの数分でデプロイできます。DynamoDB は、ワークロードのデマンドに合わせてスループットキャパシティを自動的にスケーリングし、テーブルサイズの増大に応じてデータをパーティション化および再パーティション化します。また、DynamoDB は、同じ AWS リージョン内の 3 つのアベイラビリティーゾーン (AZ) 間でデータを同期的にレプリケートし、高い可用性とデータの耐久性を実現します。

DynamoDB 特有の利点として、1 桁ミリ秒のパフォーマンスと最大 99.999% の可用性を実現する、実績のあるフルマネージド型のスケールツーゼロサーバーレスデータベースであることが挙げられます。DynamoDB は、規模を問わず一貫したパフォーマンスを発揮するだけでなく、最も厳しい要件を持つグローバルアプリケーションに必要なセキュリティ、耐久性、信頼性も組み込まれています。その使いやすさにより、DynamoDB は、新しいデータ駆動型および生成 AI アプリケーション、無制限のスケーラビリティによる一貫した高速パフォーマンスを求める確立されたインターネット規模のアプリケーションの両方でよく選ばれています。

ストレージ

すべて開く

DynamoDB テーブルクラスは、DynamoDB テーブルのパフォーマンスとコストを最適化するためのオプションです。使用可能な 2 つのテーブルクラスは、DynamoDB Standard (最大のパフォーマンスを必要とするワークロード向けに設計され、予測できないワークロードのテーブルに最適なデフォルトのテーブルクラス) と DynamoDB Standard-Inrequent Access (ストレージが主なコストであるテーブルに最適化され、アクセス頻度の低いデータを格納するテーブルに最適なテーブルクラス) です。標準テーブルでは、読み取りと書き込みのコストは低いが、ストレージのコストは高くなります。標準 IA テーブルはストレージコストは低くなりますが、読み取りと書き込みのコストは高くなります。これらのテーブルクラスは、ダウンタイムなしで 30 日間に 2 回切り替えることができるため、テーブルの使用パターンに基づいてコストを最適化できます。どのクラスを選択するかは、アプリケーションの特定のニーズとデータのアクセスパターンによって異なります。

DynamoDB でテーブルクラスを選択する際に考慮すべき要素がいくつかあります。考慮すべき最も一般的なものは、データのアクセスパターン、コストに関する考慮事項、およびワークロードの予測可能性です。コーディングやダウンタイムなしでテーブルクラスを切り替えることができるため、時間の経過とともにニーズが変わった場合は選択を調整できます。

DynamoDB 標準 IA (低頻度アクセス) テーブルは、既存の DynamoDB 機能とシームレスに連携します。通常の DynamoDB テーブルと同じ API を使用するため、コードを変更せずに既存のアプリケーションで使用できます。マルチリージョンレプリケーション、ポイントインタイムリカバリ (PITR)、オンデマンドバックアップ、AWS Key Management Service (KMS) を使用した保存時の暗号化、DynamoDB ストリーム、項目を自動的に削除する有効期限、トランザクションの読み取り/書き込みオペレーションをサポートするグローバルテーブルをサポートしています。標準 IA テーブルは DynamoDB Accelerator (DAX) と互換性があります。

Amazon DynamoDB はデータをパーティションに保存します。パーティションはテーブルに割り当てられたストレージで、ソリッドステートドライブ (SSD) を基盤とし、AWS リージョン内の複数のアベイラビリティーゾーンに自動的にレプリケートされます。パーティション管理は完全に DynamoDB によって処理されるため、パーティションを自分で管理する必要はありません。

DynamoDB テーブルに保存できる項目の最大サイズは 400 KB です。事前に定義されたストレージ制限はありません。

はい。DynamoDB は BLOB を格納できますが、一般的にドキュメントや画像の保存には適していません。より適切なアーキテクチャパターンは、Amazon S3 オブジェクトへのポインタを DynamoDB テーブルに保存することです。

デフォルトでは、Amazon DynamoDB テーブルに保存されるデータには有効期限や削除時間は設定されていません。ユーザーが明示的に削除しない限り、あるいは Time to Live (TTL) が有効になっている場合には TTL による削除を行わない限り、データはテーブル内に無期限に残ります。

DynamoDB テーブルに保存できる項目の数には、事前に定義された制限はありません。DynamoDB は、任意の数の項目にわたって数百テラバイト以上のデータにスケールできます。

画像をバイナリデータ (base64 エンコード) として DynamoDB に保存することは技術的には可能ですが、項目サイズの上限が 400 KB であるため、いくつかの制限と欠点があります。DynamoDB に画像を直接保存するよりも、Amazon S3 (Simple Storage Service) に画像を保存し、S3 オブジェクトの URL またはキーを DynamoDB に保存する方がよいでしょう。

DynamoDB にリストを保存するには、DynamoDB のリストデータ型のいずれか (リスト型またはセット型) を使用する必要があります。テーブルに項目を書き込む場合、その属性の値は、文字列や数値などのスカラー (非オブジェクト) データ型の配列またはコレクションにすることができます。DynamoDB は、リストデータを自動的にシリアル化し、リスト構造を維持する方法で格納します。その後、テーブル属性をクエリして全リストを取得できます。リストへの要素の追加、更新、削除は、通常の書き込み操作と同じ方法で動作します。

はい。DynamoDB はマップを属性データ型として保存することをサポートしています。 

セキュリティ

すべて開く

はい。DynamoDB は IAM アクセス権限をサポートしています。IAM アクセス権限は、ID ベースのポリシー、リソースベースのポリシー、またはその他の AWS ポリシーで定義して、DynamoDB リソースへのアクセスを制御できます。IAM ポリシーを IAM ユーザー、グループ、ロール、DynamoDB テーブルとストリームにアタッチし、必要に応じて制御できます。

はい。DynamoDB はテーブルとストリームのリソースベースのポリシーをサポートしています。各テーブルのリソースベースのポリシーには、テーブルのインデックス (グローバルセカンダリインデックスとローカルセカンダリインデックス) のアクセス権限も含まれます。リソースベースのポリシーを使用すると、お客様は AWS アカウントレベルでフルアクセスを許可しなくても、DynamoDB テーブルやその他のリソースに対するきめ細かなアクセス権限を定義できます。これらのポリシーにより、お客様は特定の DynamoDB テーブル、インデックス、ストリームに対して読み取り、書き込み、削除などのアクションを実行できるユーザー、ロール、およびフェデレーションユーザーを制御できます。リソースベースのポリシーは、各 DynamoDB リソース内でアタッチおよび管理されます。

リソースベースのポリシーは、AWS Identity and Access Management (IAM) Access Analyzer および Block Public Access (BPA) との統合をサポートします。IAM Access Analyzer は、お客様が権限を絞り込み、最小特権に従うのに役立ちます。BPA は、お客様が DynamoDB テーブル、インデックス、ストリームへのパブリックアクセスを防止するのに役立ち、DynamoDB では常に有効になっています。
 

DynamoDB は、DynamoDB テーブルとインデックス用に一般提供されている属性ベースのアクセス制御をサポートしています。

はい。VPC エンドポイントを使用して Amazon DynamoDB を使用できます。DynamoDB は、ゲートウェイエンドポイントと AWS PrivateLink の使用という 2 種類の VPC エンドポイントをサポートしています。ゲートウェイエンドポイントを使用すると、VPC のインターネットゲートウェイや NAT デバイスを必要とせずに、VPC から DynamoDB にアクセスできます。ただし、ゲートウェイエンドポイントでは、オンプレミスネットワークからのアクセス、他の AWS リージョンのピア接続 VPC からのアクセス、またはトランジットゲートウェイ経由のアクセスは許可されません。このようなシナリオでは、追加料金で利用できる AWS PrivateLink を使用する必要があります。

きめ細かなアクセス制御 (FGAC) により、DynamoDB テーブル所有者は、AWS Identity and Access Management (IAM) のポリシーと条件を通じてテーブル内のデータをきめ細かく制御できます。FGAC では、所有者がテーブルの項目または属性、および関連するアクションへのアクセス権限を付与できます。きめ細かなアクセス制御は、セキュリティ認証情報と関連する権限を管理する AWS IAM と連携して使用されます。

はい。Amazon DynamoDB のすべてのユーザーデータは、転送中と保管時に完全に暗号化されます

HTTPS プロトコルは、セキュアソケットレイヤー (SSL) 暗号化を使用してネットワークトラフィックを保護するために使用されます。

保管時の DynamoDB 暗号化では、AWS Key Management Service (AWS KMS) に保存されている暗号化キーが使用されます。保管中のデータは、最高レベルのセキュリティが求められる場合のゴールドスタンダードである AES-256 を使用して暗号化されます。

保管中のデータの暗号化には次のキータイプを使用できます。
1.AWS 所有のキー: これらはすべて AWS によって管理され、他にオプションが指定されていない場合はデフォルトで使用されます。これらは無料で使用でき、追加の設定は不要です。
2.AWS マネージドキー: これらは AWS キー管理サービス (KMS) に保存されているカスタマーマスターキー (CMK) で、AWS がお客様に代わって作成、管理、使用するものです。AWS が所有するキーと比較して、制御および監査機能が強化されています。
3.カスタマー管理キー: これらは AWS KMS で作成、所有、管理する CMK です。アクセス制御の作成、更新、無効化、定義など、暗号化キーを最高レベルで制御できます。

これらのキータイプはそれぞれ、利便性、制御、コストのバランスが異なります。AWS 所有のキーは最も簡単に使用でき、一方でカスタマー管理キーはより細かく制御できる反面、管理の手間が増えます。

保存時の暗号化は、機密情報を含むファイルが非アクティブな状態で暗号化されるため、データを保護するのに役立ちます。データが保存時に暗号化されると、権限のない第三者は、データを保存しているデバイスに物理的にアクセスできたとしても、プレーンテキストコンテンツにアクセスできなくなります。これにより、アクセス制御だけでなく、データのセキュリティがさらに強化され、物理デバイスを紛失したり盗まれたりした場合でも、機密情報の機密性が保たれます。

はい。DynamoDB はテーブルの項目レベルの変更に関する監査ログ記録をサポートしています。DynamoDB は、DynamoDB 内のユーザー、ロール、または AWS サービスによって実行されたアクションの記録を項目レベルで提供するサービスである AWS CloudTrail と統合されています。キャプチャされるその他のログデータには、作成、更新、削除、および条件付きチェックの失敗が含まれます。お客様は CloudWatch Logs に保存されているこれらのログレコードにアクセスし、監査、監視、またはその他の目的で項目レベルの変更を分析するアプリケーションを構築できます。監査ログ記録により、DynamoDB テーブルの通常の読み込み/書き込みパフォーマンスに影響を与えることなく、データの変更をきめ細かく把握できます。

はい。Amazon DynamoDB を使用して HIPAA 準拠のアプリケーションを構築し、AWS との履行済み事業提携契約 (BAA) に基づく保護された医療情報を含む医療関連情報を保存できます。

DynamoDB は、HIPAA 適格、FedRAMP、ISO 27001、SOC 1/SSAE 16/ISAE 3402 (旧称 SAS 70)、SOC 2 など、多くのコンプライアンス認証を満たしています。詳細については、[DynamoDB の業界別コンプライアンス検証]を参照してください。AWS コンプライアンスレポートは、AWS Artifact からダウンロードできます。

高可用性と回復性

すべて開く

Amazon DynamoDB グローバルテーブルは、フルマネージド型、サーバーレス、マルチリージョン、およびマルチアクティブのデータベースです。グローバルテーブルにより、99.999% の可用性、アプリケーションの耐障害性の向上、およびビジネス継続性の向上を実現できます。選択した AWS リージョンにわたって DynamoDB テーブルを自動的にレプリケートするので、ローカルで高速な読み取りと書き込みのパフォーマンスを実現できます。グローバルテーブルは単一リージョンの DynamoDB テーブルと同じ API を使用するため、アプリケーションを変更しなくても DynamoDB テーブルを簡単にグローバルに利用できる状態にできます。

グローバルテーブルとは、1 つまたは複数のレプリカテーブル (すべて単一の AWS アカウントが所有) のコレクションのことです。単一の Amazon DynamoDB グローバルテーブルには、AWS リージョンごとに 1 つのレプリカテーブルしか含めることができません。

複数のリージョンにわたるアプリケーションの回復力を向上させるには、グローバルテーブルを使用する必要があります。また、グローバルテーブルを使用すると、万が一リージョン全体が分離したり機能低下したりした場合でも、アプリケーションは高可用性を維持できます。

DynamoDB グローバルテーブルには、バージョン 2019.11.21 (現在) とバージョン 2017.11.29 (レガシー) の 2 つのバージョンがあります。お客様は、すべての新しいグローバルテーブルにバージョン 2019.11.21 (現在) を使用してください。このバージョンはより効率的で、消費する書き込み容量が少ないためです。バージョン 2017.11.29 (レガシー) を使用している場合は、グローバルテーブルをバージョン 2019.11.21 (現在) にアップグレードする必要があります。

AWS マネジメントコンソールで数回クリックするだけで、グローバルテーブルのバージョンをアップグレードできます。バージョン 2017.11.29 (レガシー) からバージョン 2019.11.21 (現在) へのアップグレードは 1 回限りのアクションで、元に戻すことはできません。アップグレードする前に、バージョン間の動作の違いを確認し、必要なテストをすべて実行してください。詳細については、「Upgrading global tables from version 2017.11.29 (Legacy) to version 2019.11.21 (Current)」を参照してください。

DynamoDB グローバルテーブルは、リージョン間でマルチアクティブレプリケーションを使用し、グローバルテーブル内のすべてのリージョンのすべてのレプリカテーブルで読み込みトラフィックと書き込みトラフィックがサポートされますグローバルテーブルにはプライマリリージョンがないため、読み取りトラフィックと書き込みトラフィックを別のリージョンに転送するときにデータベースのフェイルオーバーは必要ありません。万が一 AWS リージョンが孤立したり劣化したりしても、アプリケーションは影響を受けていないリージョンのレプリカテーブルから読み書きするだけで済みます。詳細については、「DynamoDB グローバルテーブル設計のベストプラクティス」を参照してください。

レプリカテーブルとは単一の DynamoDB テーブルのことです。各レプリカテーブルには、同じデータ項目のセット、同じテーブル名、および同じプライマリキースキーマが保存されます。アプリケーションがあるリージョンのあるレプリカテーブルにデータを書き込むと、DynamoDB は自動的に別の AWS リージョンの別のレプリカテーブルに書き込みをレプリケートします。

はい。DynamoDB グローバルテーブルは、アプリケーションの回復力を高め、単一リージョンの整合性を高めるため、事業継続性を強化します。マルチリージョンでの高い整合性により、RPO (目標復旧時点) がゼロで最高レベルの回復力を備えたアプリケーションを構築できます。

このステップバイステップガイドを使用すると、DynamoDB コンソール、AWS CLI、または AWS CloudFormation を使用してグローバルテーブルを作成できます。

DynamoDB グローバルテーブルに異なるリージョンのレプリカを追加するには、DynamoDB Streams が有効になっていること、他のすべてのレプリカと同じ名前であること、他のすべてのレプリカと同じパーティションキーであること、同じ書き込みキャパシティが設定されていることが必要になります。

DynamoDB グローバルテーブルのすべてのレプリカテーブルは同じ名前でなければなりません。

他のデータベースと同様に、DynamoDB はデータをテーブルに保存します。テーブルは項目のコレクションで、各項目は属性のコレクションです。DynamoDB はプライマリキーを使用してテーブル内の各項目を一意に識別し、セカンダリインデックスを使用してクエリの柔軟性を高めています。

はい。DynamoDB グローバルテーブルの各レプリカでポイントインタイムリカバリを有効にできます。

はい。DynamoDB は変更データキャプチャ (CDC) をサポートしています。CDC はストリーミングモデルを使用して実装されており、アプリケーションが DynamoDB テーブルの項目レベルの変更をデータレコードのストリームとしてほぼリアルタイムでキャプチャできるようにします。データレコードの CDC ストリームにより、アプリケーションは DynamoDB テーブルのデータ変更を効率的に処理し、応答できるようになります。DynamoDB では、CDC 用に DynamoDB StreamsKinesis Data Streams for DynamoDB という 2 つのストリーミングモデルを提供しています。アプリケーションに適したソリューションを選択するには、「変更データキャプチャのストリーミングオプション」を参照してください。

DynamoDB ストリームとは、DynamoDB テーブル内の項目への変更に関する情報の順序付けられたフローのことです。DynamoDB ストリームは、重複排除された項目レベルの変更の順序を時系列でテーブルに取り込み、この情報を最大 24 時間ログに保存します。DynamoDB ストリームは容量を自動的にスケールし、容量のプロビジョニングと管理の作業を排除します。 DynamoDB ストリーム設定に基づいて、変更前と変更後のデータ項目を表示できます。これらのストリームイベントを使用するアプリケーションを構築し、イベントストリームの内容に基づいてワークフローを呼び出すことができます。

DynamoDB ストリームは、AWS Lambda とのネイティブ統合を使用してトリガーでデータ変更に対応したり、顧客とのやり取りをほぼリアルタイムで追跡および分析したり、アプリケーションのパフォーマンスをほぼリアルタイムで監視したり、順序付けられたイベントのシーケンスをキャプチャしたり、項目レベルのトランザクションデータをレプリケートしてアプリケーションの回復力を向上させたりする場合に役立ちます。

Kinesis Data Streams は、DynamoDB テーブルの項目レベルの変更をキャプチャし、 Kinesis データストリームにレプリケートします。アプリケーションはこのストリームにアクセスして、項目レベルの変更をほぼリアルタイムで確認できます。Amazon Kinesis データストリームを使用すると、特定のニーズに合わせてストリーミングデータを処理または分析するカスタムアプリケーションを構築できます。DynamoDB ストリームとは異なり、Kinesis Data Streams for DynamoDB にはレコードの順序付けや重複排除の保証はありません。レコードの順序付けと重複排除は、項目レベルのレコードの ApproximateCreationDateTime フィールドを使用してクライアントアプリケーションで実装する必要があります。

Kinesis Data Streams for DynamoDB は、より広範な Kinesis 機能 (Kinesis Client LibraryAmazon Managed Service for Apache FlinkAmazon Data Firehose など) との統合、長期間のデータ保持と再生性 (最大 365 日)、ダウンストリームの消費とストリーミング分析のためのカスタマイズされたシャード管理が必要な場合に役立ちます。

DynamoDB テーブルで DynamoDB ストリームまたは Kinesis データストリームが有効になっている場合、テーブルは、そのテーブルのデータへの変更をキャプチャするデータレコードを送信します。このデータレコードには、項目が最近作成、更新、または削除された特定の時間、その項目のプライマリキー、変更前の項目の画像、および変更後の項目の画像が含まれます。

AWS マネジメントコンソール、AWS SDK、AWS コマンドラインインターフェイス (AWS CLI)、または Kinesis クライアントライブラリ (KCL) を使用して、既存の DynamoDB テーブルのストリームを有効または無効にできます。

特に DynamoDB テーブルの変更を追跡する必要がある場合は、DynamoDB Streams を選択してください。幅広いストリーミングニーズ、より高いスループット要件、またはより長いデータ保持期間が必要な場合は、Kinesis Data Streams を選択してください。

Amazon DynamoDB の Time to Live (TTL) 機能は、関連性がなくなった期限切れの項目をテーブルから自動的に削除します。これにより、ストレージの使用量が削減され、コストが低減されます。TTL では、項目ごとにタイムスタンプを定義して項目が不要になるタイミングを判断できます。DynamoDB は、書き込みスループットを消費することなく、その項目をテーブルから自動的に削除します。項目が作成または更新されるたびに、有効期限を計算して TTL 属性に保存できます。TTL は、特定の時間が経過すると関連性が失われる項目を保存する場合に便利です。

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

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

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

DynamoDB は、グローバルセカンダリインデックス (GSI) の最大 8 つの属性で構成されるプライマリキーをサポートし、パーティションキーとソートキーにはそれぞれ最大 4 つの属性を使用できます。

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

はい。DynamoDB は、API を介してアクセスする完全マネージド型のクラウドサービスです。DynamoDB は、どのオペレーティングシステム (Linux、Windows、iOS、Android、Solaris、AIX、HP-UX など) で実行するアプリケーションでも使用できます。DynamoDB の使用を開始するには、AWS SDK の使用をお勧めします。

DynamoDB と OpenSearch Service のゼロ ETL 統合により、トランザクションデータストアから検索データストアへのデータのレプリケーションをオーケストレートする際の運用面の複雑さが軽減されます。トランザクションデータストアと検索データストアの同期を維持するために使用されるデータパイプラインにより、構築と管理が困難でコストがかかり、追跡が困難な断続的なエラーが発生する可能性があります。 

この統合により、DynamoDB のお客様は、DynamoDB のトランザクションデータが書き込まれてから数秒以内に OpenSearch Service で利用できるようにするフルマネージドソリューションを提供することで、トランザクションデータからほぼリアルタイムの検索結果を取得できるようになります。お客様は、OpenSearch Service で分析したいデータを含む DynamoDB テーブルを選択するだけで、このゼロ ETL 統合により、OpenSearch Ingestistion パイプラインを使用してスキーマとデータを OpenSearch Service にシームレスにレプリケートできます。お客様は、複数の DynamoDB テーブルのデータを単一の OpenSearch Service マネージドドメインまたはサーバーレスコレクションにレプリケートして、複数のアプリケーションにわたって総合的なインサイトを得ることができます。また、中核となる分析資産を統合することで、大幅なコスト削減と運用効率の向上を実現できます。 

お客様は、DynamoDB 用 AWS マネジメントコンソール、OpenSearch Service、AWS CLI、AWS SDK、または AWS CloudFormation を使用して開始できます。統合を有効にするには、まずデータをレプリケートする必要がある DynamoDB テーブルを選択します。次に、お客様は、2 つのシステム間のデータを同期させる CDC メカニズムとして、ほぼリアルタイムのレプリケーション用の DynamoDB ストリームまたは遅延レプリケーション用の DynamoDB 増分エクスポートのいずれかを選択します。 

この ゼロ ETL 統合により、お客様のアカウントに OpenSearch Ingeston パイプラインが設定され、OpenSearch Service が管理するクラスターまたはサーバーレスコレクションへのデータのレプリケートが行われます。OpenSearch Ingestion は DynamoDB テーブルの構造を分析し、同等の OpenSearch Service マネージドドメインまたはサーバーレスコレクションを作成し、DynamoDB テーブルの既存のデータを使用して送信先のブートストラップを行います。オプションで、お客様は OpenSearch Service で作成されるインデックスのスキーマを指定できます。 

このゼロ ETL 統合では、Amazon CloudWatch のリアルタイムのメトリクスとログを使用して、エンドツーエンドの統合の状態をモニタリングできるダッシュボードが提供されます。ユーザー定義のしきい値を超えた場合のアラートを設定できます。この統合により、DynamoDB テーブルと OpenSearch Service インデックスの状態も継続的にモニタリングされ、これらのエンティティのいずれかでリグレッションが発生した場合は直ちにユーザーに通知されます。

OpenSearch Ingestion がこれら両方のシステム間でデータをレプリケートするために必要なアクセス許可を持っていることを確認するために、DynamoDB と OpenSearch Service のゼロ ETL 統合により、DynamoDB テーブルからデータを読み込み、OpenSearch ドメインまたはコレクションに書き込むために必要な権限を持つ IAM ロールが作成されます。その後、OpenSearch Ingestion パイプラインがこのロールを継承し、データをソースから送信先に移動する際に常に適切なセキュリティ体制が維持されるようにします。

このゼロ ETL 統合では、OpenSearch Ingestion パイプラインのネイティブデータ変換機能を使用して、移動中のデータを集約してフィルタリングします。DynamoDB テーブルからデータを移動する場合、お客様はいくつかのフィールドを削除するか、既存のフィールド全体の集計に基づいて新しいフィールドを作成したい場合があります。 

オプションとして、お客様が OpenSearch Ingeston 用のカスタムロジックを記述して、特注のトランスフォーメーション機能を実現することもできます。データ全体をソースからシンクに移動したいだけの他のユーザーには、このゼロ ETL 統合により、すぐに使える OpenSearch Ingestion ブループリントが提供され、ボタンを数回クリックするだけで統合を実行できるようになります。

このゼロ ETL 統合により、お客様はカスタムデータスキーマと、OpenSearch Ingestion が DynamoDB から OpenSearch Service にデータを書き込む際に使用するインデックスマッピングを指定するオプションを利用できるようになります。このエクスペリエンスは DynamoDB 内の UI コンソールに追加されるため、お客様は OpenSearch Service で作成されるインデックスの形式を完全に制御できます。

DynamoDB と OpenSearch Service のゼロ ETL 統合を使用しても、基盤となる既存のコンポーネントのコストを除けば、追加コストは発生しません。このゼロ ETL 統合では、OpenSearch Ingestion を使用して DynamoDB テーブルのデータを読み込み、OpenSearch Service にレプリケートします。DynamoDB と OpenSearch Service のゼロ ETL 統合を使用する場合にかかるコストは、OpenSearch Ingestion がシステム間でデータをレプリケートするために必要な OpenSearch Compute Unit (OCU) のコストです。さらに、お客様は CDC の選択肢として DynamoDB ストリームまたは増分エクスポートのいずれかを選択できます。増分エクスポートでは、S3 バケットへのデータの書き込みに関連するコストがかかります。DynamoDB ストリームの場合、お客様には DynamoDB ストリームの使用に対する標準料金が課金されます。

DynamoDB と OpenSearch Service のゼロ ETL 統合は、現在 OpenSearch Ingestion が利用可能なすべてのリージョンで利用できます。

はい。Amazon DynamoDB の使用量に合わせてデータベース用 Savings Plans を購入できます。1 年間の契約期間中に一定量の使用をコミットすることで、最大 18% のコスト削減が可能です。 対象となる使用量に関する追加情報は、データベース用 Savings Plans の料金ページでご確認いただけます。

はい。DynamoDB は 25 GB のストレージ、25 個のプロビジョニング済み書き込みキャパシティーユニット (WCU)、25 個のプロビジョニング済み読み込みキャパシティーユニット (RCU) という手厚い無料利用枠を提供しています。これは、1 か月あたり 2 億件のリクエストを処理するのに十分な容量となっています。

DynamoDB は完全にサーバーレスの非リレーショナルデータベースです。ストレージなどのさまざまな指標に基づいて課金される他のデータベースと比較すると、DynamoDB はゼロまでスケーリングできます。つまり、お客様がオンデマンドモードを利用する場合、消費されたアクティブなリソースに対してのみ料金が発生します。

端的に言えば、オンデマンドは、使用した分だけ支払いを希望するお客様や、ワークロードを予測できないお客様に適しています。プロビジョンドキャパシティは、トラフィックが一貫しているか予測可能なアプリケーションを使用しており、キャパシティ要件を予測してコストを管理したいお客様に人気があります。

DynamoDB は、消費したリソースに対してのみ料金を支払うオプションをユーザーに提供していますが、オンデマンド料金で使用されていないときにはゼロにスケーリングされるというユニークな仕組みを持つサーバーレスデータベースです。データベースが使用中の場合、書き込み要求単位と読み込み要求単位を使用して料金が計算されます。

DynamoDB には、サービスに追加できる幅広いオプションが用意されています。これには次のようなものがあります。

  • 特定の時点でスナップショットバックアップを作成するオンデマンドバックアップ
  • マルチリージョン、マルチアクティブレプリケーション用のグローバルテーブル
  • Amazon DynamoDB 互換キャッシングサービスである DynamoDB Accelerator (DAX) は、インメモリキャッシュによりレイテンシーを短縮します
  • テーブルへの項目レベルの変更に関する時系列シーケンスを表す DynamoDB ストリーム