Category: Amazon DynamoDB

 このブログは、Amazon DynamoDB を Cassandra 開発者にご紹介する投稿です。DynamoDB の開始がスムーズに行えるよう、Cassandra を使った基本操作を説明しています。また、AWS CLI を使えば、DynamoDB で同じ操作が実行できます。 Amazon DynamoDB は完全マネージド型のマルチリージョンマルチマスター NoSQL データベースで、あらゆる規模でも安定した 10 ミリ秒未満のレイテンシーを実現します。ビルトインのセキュリティ、バックアップと復元、およびメモリ内キャッシュを含んでいます。さらに、分散型データベースの運用とスケーリングの管理負担を軽減できます。 こうした機能を搭載しているため、DynamoDB は Apache Cassandra のような他の NoSQL データベースからの移行が必要となります。DynamoDB クライアントと SDK を使用して、IoTや ゲームなどのさまざまなアプリケーションを構築できます。詳細については、「API の使用」をご参照ください。 次のテーブルは、重要な Cassandra と DynamoDB コンポーネント、およびこれらの概念を DynamoDB に関連付ける方法をまとめたものです。DynamoDB は完全マネージド型サービスのため、テーブルが取り扱う最上位のコンポーネントとなります。 Cassandra DynamoDB 説明 ノード NA データが保存される場所。 データセンター NA レプリケーション戦略に使用。 AWS のアベイラビリティーゾーンに類似。 クラスター NA 単一のノード、単一のデータセンター、またはデータセンターのコレクションを持つことが可能。 キースペース NA リレーショナルデータベースのスキーマに類似。 […]

 キューイングは、分散処理システムで計算コンポーネントを分離するために一般的に使用されるソリューションです。これは、サーバーレスおよびマイクロサービスアーキテクチャで使用する非同期通信システムの形式です。メッセージは処理のためにキューで待機し、1 人のコンシューマーが受信するとキューから出ます。このタイプのメッセージングパターンは、ポイントツーポイント通信と呼ばれます。 この記事では、他の大規模なキューイングシステムで行うように、Amazon DynamoDB テーブルのいずれかを、エンキュー (メッセージをキューに配置) とデキュー (メッセージを読み取り、キューから削除) が行えるキューに変換する方法について説明します。 DynamoDB は、任意の規模で 1 桁のミリ秒のパフォーマンスを実現するキーと値のドキュメントデータベースです。これは、モバイル、ウェブ、ゲーム、広告技術、IoT、および大規模で低レイテンシーのデータアクセスを必要とするその他のアプリケーションに使用できる、サーバーレスで完全マネージド型のサービスです。 永続性、単一メッセージ処理、および分散コンピューティングを提供する多くのキュー実装があります。一般的なキューイングソリューションには、Amazon SQS、Amazon MQ、Apache ActiveMQ、RabbitMQ、Kafka などがあります。これらのサービスは、実装方法、スケーリング、パフォーマンスなど、いくつかの異なる特性を持つさまざまなキュー機能を処理します。 ただし、キューシステムのほとんどは、アイテムがキューに到着した後、アイテムの順序を簡単に変更することはできません。DynamoDB で議論された実装は、処理前にキュー内の順序を変更したり、アイテムをキャンセルしたりできます。 この記事では、DynamoDB のキューイングシステムの重要な側面についても説明します。たとえば、アイテムの優先度の変更、メッセージごとに 1 人のコンシューマーのみの許可、処理成功時のメッセージの削除、メッセージ処理の順序の保証方法、例外の処理方法などです。 通常のキューと優先度付きキュー キューは、アイテム (メッセージ) のコレクションを順番に保持する線形データ構造を定義する抽象データ型です。1 人のコンシューマーは、個々のメッセージを 1 回だけ処理します。最も一般的なキューイング方法の 1 つは、先入れ先出し (FIFO) 構造です。この構造では、新しいアイテムがキューの最後に結合し、キュープロセスは前 (ヘッド) から順番に処理されます。 この記事では、キュー内のメッセージをメッセージの特性でソートする機能を追加することにより、典型的なメッセージキューの実装を強化する方法を示します。これは、優先度付きキューとして知られています。 優先度付きキューでは、各アイテムにキュー内の優先度を定義する追加の属性があります。優先度が変わると、キュー内のアイテムの順序が変わります。優先度付きキューは、ヒープと呼ばれる構造を頻繁に使用するか、自己バランスツリーを使用します。 DynamoDB は、アイテム (レコード) を動的に並べ替えるためにグローバルセカンダリインデックス (GSI) を使用します。キュー項目が表示されている (まだ処理されていない) 限り、キュー内の項目の順序を変更できます。 ソリューションのアーキテクチャ この記事では、DynamoDB のテーブルを使用するマイクロサービスがあるシナリオを使用します。この記事では、キューイングの主なアイデアを説明するために、仮想アプリケーションオブジェクトであるシップメントも紹介します。倉庫内のすべてのアイテムを見つけて、発送の準備ができていることを確認するまで、シップメントを発送できません。シップメントの準備ができたら、それをマークし、ダウンストリーム処理のために FIFO キューに入れることができます。キューでは、アイテムのタイムスタンプが優先度属性として使用されます。 次の図は、このワークフローを示しています。 この記事のアーキテクチャは比較的単純です。JSON […]

一般的な設計のベストプラクティスとして、アプリケーションをテーブル内のすべての論理パーティションキーとインデックス全体での均一な読み込みと書き込みアクティビティのために設計することによって、Amazon DynamoDB のスループットキャパシティーを最大限に活用することができます。このような設計により、テーブルのキャパシティーを過剰に消費する可能性があるホットパーティションの発生を防ぐことができます。 書き込みアクセスをパーティション全体に均等に分散させる 1 つの方法は、パーティションキースペースを拡大させることです。この戦略は、パーティションキーに追加のサフィックスを付加して、基盤となるパーティション全体での配分を向上させるもので、書き込みシャーディングと呼ばれます。 しかし、このアプローチは、いくつかの興味深い設計面での疑問を生じます。いつシャーディングを検討すればよいのか? パーティションキーごとに何個のシャードを作成するべきなのか? シャードをいつ作成するのか? シャード数をスケールするにはどうすればよいのか? シャーディングは読み込みおよび書き込みパターンにどのように影響するのか? この記事では、複合プライマリキー (パーティションキーとソートキー) が存在する DynamoDB テーブルのための動的な書き込みシャーディングのメカニズムを説明します。このメカニズムは、書き込みスループットの需要の増加に基づいてパーティションキーに新しいシャードを臨機応変に追加することによって、DynamoDB テーブルの書き込みキャパシティーを最適化できるようにしてくれます。 パーティション、キー、および書き込みシャーディング DynamoDB は水平分散されたワークロードで能力を発揮します。DynamoDB はテーブルを作成するときに、プロビジョンドスループット要件に対応するために十分なパーティションをテーブルに割り当てます。作成時、DynamoDB はテーブルのキャパシティーを基盤となるパーティション全体に均等に分散します。DynamoDB は、テーブルが作成された後で追加のパーティションをテーブルに割り当てることもあります。詳細については、「パーティションキーを効率的に設計し、使用するためのベストプラクティス」と「パーティションとデータ分散」を参照してください。 DynamoDB は、パーティションに項目を分散するために一貫した内部ハッシュ関数を使用し、DynamoDB が項目を保存するパーティションは項目のパーティションキーによって決定されます。同一のパーティションキーを共有する項目のグループ (コレクションと呼ばれます) は、コレクションがパーティションのストレージ容量を超える場合を除き、同じパーティションにマップされます。 さらに、単一のパーティションが複数のコレクションに関連付けられた項目を保持する場合があります。同じパーティションにマップされた 1 つ、または複数のコレクションに対する過剰な書き込みアクティビティは、ホットパーティションの原因になります。ホットパーティションとは、集中的な読み込みおよび書き込みアクティビティが、パーティションのプロビジョンドキャパシティー、またはパーティションの最大キャパシティーを超え、キャパシティーエラーを生じる場合のことです。 これらのキャパシティーエラーは、プロビジョンドキャパシティーモデルにおける ProvisionedThroughputExceededException、およびオンデマンドキャパシティーモデルにおける InternalServerError によって識別されます。同じコレクションの項目が同じ基盤となるパーティションにマップされるため、これらのキャパシティーエラーは大規模なコレクションで発生する可能性が高くなります。詳細については、「エラー処理」および「読み込み/書き込みキャパシティーモード」を参照してください。 書き込みシャーディングとは、コレクションを効率的に DynamoDB テーブルのパーティション全体に分散させるメカニズムです。これは、パーティションキーに対する書き込み操作を複数のパーティションに分散させることによって、パーティションキーあたりの書き込みスループットを向上させます。このため、個々のパーティションキーの書き込みスループットが基盤となるパーティションのキャパシティーを超過してもよくなり、DynamoDB のパーティションレベルでのキャパシティーエラーが最小限に抑えられます。 さらに、書き込み操作を DynamoDB のパーティション全体に分散させることによって、パーティションのキャパシティーがより均等に使用されます。これはテーブルのキャパシティーのより効率的な使用につながり、コストが削減されます。 書き込みシャーディングは、パーティションキーにシンプルな値のサフィックスを付加することによって、クライアント側から実装することができます。サフィックスの付加による書き込みシャーディングは、パーティションキーに対する 1 バイトの変更でさえも内部ハッシュ関数での異なる出力の生成につながり、項目を異なるパーティションに置くために効率的です。詳細については、「書き込みシャーディングを使用してワークロードを均等に分散させる」を参照してください。 DynamoDB は、一時的な需要のバーストを緩和するバーストキャパシティー、および不均等なアクセスパターンに合わせてパーティション間のキャパシティーを再利用するアダプティブキャパシティーの機能をネイティブに提供します。書き込みシャーディングは、DynamoDB のパーティション全体にトラフィックを均等に分散させるための補完的なメカニズムです。 事前に設定された数のシャードを使った書き込みシャーディングの例 シャーディングすると良いテーブルの例は、ファイルシステムの監査ログです。ここでのパーティションキーはファイルパス、ソートキーはアクセスタイムスタンプになります。このファイルの人気が極度に上がり、頻繁に共有されるようになった場合、単一の DynamoDB パーティションが過剰な数の書き込みリクエストを受けます。 以下の表は、3 つの異なるシャーディングスキームに出現する同一の項目を示しています。 最初のメソッドでは、データが […]

近年、NoSQL データベースをリレーショナルデータベース管理システム (RDBMS) の制約から解放するソリューションと見なす組織が増えているため、NoSQL データベースの使用が大幅に増加しています。NoSQL データベースの柔軟性、俊敏性、およびパフォーマンスは、移行をトリガーする主な利点ですが、組織の重要な要件の一部によって RDBMS は同じままでした。 RDMBS は、最も広く知られ議論されている機能であるトランザクションサポートのために、重要なデータを操作する場合 NoSQL データベースよりも好まれます。 Amazon DynamoDB Transactions 使用する理由 多くのアプリケーションでは、1 つ以上の項目に対して「アトミック」またはオールオアナッシングのデータベース操作を必要とするビジネスロジックが常に必要です。これにより、間違った操作が 1 つ発生した場合、すべてのデータベース操作をロールバックできます。通常、このニーズに対処しようとすると、接続されたすべての操作を追跡し、操作を元に戻すという点で、アプリケーションの実装が難しくなります。 Transactions は、re:Invent 2018 で DynamoDB の新機能として発表されました。データベース内のトランザクションのネイティブサポートを提供し、単一の AWS アカウントとリージョンにある複数の項目に ACID (原子性、一貫性、分離性、耐久性) を提供します。 従来、DynamoDB は単一の項目に対してのみ、これらのプロパティをサポートしていました。データの可用性と耐久性を確保するために設計されましたからです。Transactions は、複数の項目で 1 つ以上のテーブルに原子性 (オールオアナッシング) と分離性 (Transactions 同士は影響なし) を追加しました。 さらに、Transactions の ClientRequestToken キーを使用すると、API 呼び出しがべき等になる可能性があるため、複数の同一の呼び出しが同じ操作を再生せず、呼び出しが 1 つの場合と同じ効果が得られます。 Transactions を使用すると、データベース内でロールバック操作について心配したり、苦労したりする必要がなくなります。Transactions は、複数の項目とテーブルにわたってアクションを調整することにより、データの整合性を維持するのに役立ちます。 仕組みの説明 DynamoDB Transactions は現在、TransactWriteItems […]

大抵のリレーショナルデータベースシステム、そして一部の非リレーショナルデータベースシステムには、ユニークキーまたはユニーク制約として知られるコンストラクトがあります。この機能は、列またはフィールド内のすべての値が行全体で一意であることを確実にします。 たとえば、User テーブルがあるとします。それには、各ユーザーを一意に識別するプライマリキーとして UUID があるかもしれませんが、同じくユーザーにとって一意である必要があるユーザー名フィールドと E メールフィールド (DynamoDB 用語では「属性」) もあるかもしれません。このユースケースは、DynamoDB トランザクションに関する AWS Summit 2018 DAT374 セッションで言及されています。 Amazon DynamoDB では、プライマリキーがパーティションキー (テーブルにソートキーが選択されていない場合)、またはパーティションとソートキーの組み合わせのいずれかになります。プライマリキーは、テーブル内で一意であることが保証されています。しかし、DynamoDB には、プライマリキーではない属性の一意性を確実にするための組み込みメカニズムがありません。 この記事では、アプリケーション側からこのような類の一意性を実装するために使用されるパターンについて説明し、単一テーブルのスキーマ設計でこのパターンを使用するときに項目を作成、更新、および削除する方法の例をご紹介します。 ソリューションの概要 前述の例を使用して、User テーブルがあり、そのテーブルに以下のような属性があると考えてください。 pk (UUID として保存されたプライマリキー) userName email fullName phoneNumber UUID、userName、および email の各属性は一意である必要がありますが、fullName と phoneNumber にその必要はありません。複数の人物が同じ自宅電話番号を共有することができます。以下はサンプル行です。 pk userName email fullName phoneNumber b201c1f2-238e-461f-88e6-0e606fbc3c51 btables bobby.tables@gmail.com Bobby Tables +1-202-555-0124 8ec436a8-97e6-4e72-aec2-b47668e96a94 jsmith johnsmith@yahoo.com John Smith +1-404-555-9325 […]

リレーショナルデータベースから NoSQL への移行を考えていますか? 以下の記事では、Amazon EC2 インスタンスから Amazon DynamoDB への SQL Server データの読み取り、変換、書き込みについて詳しく説明します。AWS Glue を使用して、DynamoDB で複数のテーブルのソースデータモデルを 2 つのターゲットテーブルに変換します。 AWS Glue の代わりに、AWS DMS や AWS Marketplace ツールなど、データモデル変換のためのその他のオプションがあります。この 1 回限りの移行では、複数のテーブルを 1 つに変換するために AWS Glue および Scala コードを選択しました。 概要 このデモでは、商用リレーショナルデータベースをリファクタリングする方法を示します。選択したデータベースは、スポーツイベントのチケットを生成および販売します。データベースを DynamoDB にリファクタリングするためのベストプラクティスと、DynamoDB テーブルを設定し、AWS Glue を使用してデータを転送する方法を説明します。また、VPC エンドポイントと AWS Glue のセキュアな IAM ロールを設定する方法、ソースデータベースをクロールし、Apache Spark ETL ジョブを実行する方法も示します。 すぐに開始するには、DynamoDB リポジトリへのリファクタリングのコードにアクセスしてください。 問題と提案される解決策 環境内で AWS […]

この記事では、Amazon DynamoDB のテーブル構造がスキャンパフォーマンスにどのように影響するかについて説明し、テーブルのスキャン時間を最適化する方法をご紹介します。 Amazon DynamoDB は、柔軟なスキーマを使用できる NoSQL データベースです。これは、項目それぞれにどのような属性が存在するかという点で、同じテーブル内の項目が互いに異なることを意味します。 DynamoDB のスキーマとアクセスパターンの大部分は GetItem 操作と Query 操作を中心に方向づけと最適化が行われ、これによってテーブルまたはインデックスから単一項目にアクセスするときに一貫した 1 桁台のミリ秒での応答時間が提供されますが、ユースケースとアクセスパターンには、テーブルとインデックスのスキャンが必要なものもあります。 概要 柔軟なスキーマを持つデータベースでは、データベーススキャンから返されたすべての項目について、ネットワーク応答にデータだけでなく、メタデータも含まれています。このメタデータには、各属性の属性名とデータタイプが含まれる場合があります。 各項目により多くの属性を追加すると、クライアントオーバーヘッドもいくらか追加されます。これは、ネットワーク応答の各列が、適切なクライアントデータ構造にマーシャルされる必要があるからです。その例は Python ディクショナリー、Node.js マップ、Java オブジェクトなどです。 属性メタデータは容量を消費するため、DynamoDB 応答の 1 MB 上限に収まる項目数が少なくなります。その結果として、データのスキャンに必要な往復回数が増えることになります。 テスト方法 パーティションキーとソートキー (どちらも文字列) で構成されるプライマリキーというシンプルな構造のテーブルを 1 つ作成しました。144 個のランダムな文字の文字列が含まれる field1 という名前の 3 番目の文字列属性もあります。 また、3 文字および 6 文字の属性値の両方を持つ、7 文字の属性名 (field01… field24) の異なる組み合わせを使ったテーブルも作成しました。これらのテーブルには、最初のテーブルと同じプライマリキー構造があります。 柔軟なスキーマを持つ NoSQL データベースは、項目ごとに属性名を保存する必要があります。項目の属性が増える、または属性名が長くなると、項目は属性名を保存するためにより多くの容量を消費します。 最後に、24 個の属性 (それぞれが同じ 7 文字の属性名と […]

広告技術 (アドテック) 企業は、Amazon DynamoDB を使用して、ユーザープロファイル、ユーザーイベント、クリック数、訪問済みリンクなどのさまざまな種類のマーケティングデータを保存します。用途としては、リアルタイム入札 (RTB)、広告ターゲティング、アトリビューションなどがあります。このブログ記事では、DynamoDBを使用するアドテック企業の最も一般的なユースケースと設計パターンを特定します。 こうしたユースケースでは、高いリクエスト率 (1 秒あたり数百万件のリクエスト)、低くて予測可能なレイテンシー、および信頼性が必要です。大規模な読み取りボリュームがある場合、またはミリ秒未満の読み取りレイテンシーが必要な場合、企業は DynamoDB Accelerator (DAX) によるキャッシングを利用します。ますます多くのアドテック企業が、複数の地域で RTB や広告ターゲティングプラットフォームをデプロイしており、これには AWS リージョン間でのデータレプリケーションが必要になります。 完全マネージド型サービスである DynamoDB を使用すると、アドテック企業はデータベースの運用にリソースを投資することなく、こうした要件をすべて満たすことができます。また、こうした企業は、DynamoDB への移行によってデータベースの支出が削減されるため、DynamoDB の費用対効果も高いことに気付きます。たとえば、GumGum が自社のデジタル広告プラットフォームを DynamoDB に移行したとき、古いデータベースに比べてコストが 65〜70％ 削減されたと推定しています。 この記事で使用される用語 この記事では、以下のデータモデリングと設計パターンの用語を使用します。 1:1 モデリング: パーティションキーをプライマリキーとして使用する 1 対 1 関係のモデリング。 1:M モデリング: パーティションキーとソートキーをプライマリキーとして使用する 1 対多関係のモデリング。 DAX によるキャッシング: DynamoDB の前で読み取りキャッシュとして DAX を使用すると、読み取りのレイテンシーを短縮できるだけでなく、頻繁にアクセスされるアイテムに対する高い読み取り負荷を費用効果の高い方法で処理することができます。 アドテックのユースケースと設計パターン ユースケース データモデリングまたは設計パターン RTB および広告ターゲティングでのユーザープロファイルの保存 1:1 モデリング、1:M モデリング […]

7 年前の今日、AWS の CTO であった Werner Vogels が Amazon DynamoDB のリリースを発表しました。そこで、2018 年と 2017 年の「最新情報」の記事を振り返って、DynamoDB の最近の成長を示すのもおもしろいだろうと考えました。こうした記事は、トランザクション、オンデマンドキャパシティモード、ポイントインタイムリカバリ、グローバルテーブル、バックアップとリストア、Auto Scaling など、さまざまな機能リリースをすべて説明しています。

このブログ記事では、お使いのアプリケーションに対するデータベースサービスの候補として DynamoDB を評価する方法を説明してから、DynamoDB への移行を計画する方法を、ベストプラクティスを含めて説明します。