Category: Amazon DynamoDB

 Amazon DynamoDB などの NoSQL データベースを使用する場合、リレーショナルデータベースで慣れているものとは異なる最適化を選択する傾向があります。リレーショナルデータベースの経験から、最初は別の方法で実行するように指示されていたため、簡単ではありませんでした。 これを支援するために、AWS は Windows および macOS で利用可能なクライアント側アプリケーションである Amazon DynamoDB 向け NoSQL Workbench をリリースしました。これを使用して、スケーラブルで高性能なデータモデルを構築し、クエリの開発とテストを簡素化できます。NoSQL Workbench を使用すると、次のことができます。 1 つ以上のテーブルを使用してデータモデルを定義します。 データモデルを視覚化して、さまざまなシナリオでどのように機能するかを理解します。 複数のプログラミング言語用のデータプレーン操作を構築します。 このブログ記事では、一般的に利用可能になった NoSQL Workbench を使用して、複数の顧客の URL ブックマークの管理という一般的なユースケースのデータモデルを設計しています。比較的ユースケースが単純な場合でも、多くの興味深い考慮事項があります。 データモデラー このアプリケーションでは、ブックマークと顧客アカウントに関する情報を保存する必要があります。まず、保存したい属性のリストを、保存する予定の簡単な説明とともに書き留めます。 顧客 customerId – ユニバーサル一意識別子 (UUID) email fullName ­– 例: “Shirley Rodriguez” userPreferences – アプリのユーザー設定を記述する JSON オブジェクト creationDate updateDate ブックマーク URL – “https://…” customerId […]

Amazon DynamoDB では、1 か月あたり数リクエストから 1 秒あたり数百万のリクエストまで、簡単にスケーリングできる完全マネージド型のキーバリューデータベースサービスをお客様に提供しています。DynamoDB は、あらゆる規模で一貫した 1 桁のミリ秒の応答時間を実現することにより、世界最大規模のアプリケーションを複数サポートしています。実質的に無制限のスループットとストレージでアプリケーションを構築できます。DynamoDB グローバルテーブルは、データを複数の AWS リージョンにレプリケートして、グローバルに分散されたアプリケーションのデータにローカルで高速にアクセスできるようにします。マイクロ秒のレイテンシーでさらに高速なアクセスが必要なユースケースでは、DynamoDB Accelerator (DAX) が完全マネージド型のインメモリキャッシュを提供しています。 2019 年 11 月に、Amazon DynamoDB の Amazon CloudWatch Contributer Insights をプレビューとして発表しました。本日、すべての AWS リージョンで一般的にご利用いただけるようになったことをお知らせします。 Amazon DynamoDB の Amazon CloudWatch Contributer Insights 2019 年 11 月に開始された Amazon CloudWatch Contributor Insights は、ログデータを分析し、時系列視覚化データを作成して、システムパフォーマンスに影響を与える上位のコントリビューターを確認できるようにしています。これを行うには、Contributor Insights ルールを作成して、CloudWatch Logs (AWS のサービスからのログを含む) と、自社のサービスまたはオンプレミスサーバーから送信されたカスタムログを評価します。たとえば、不良ホストを見つけたり、最も重いネットワークユーザーを特定したり、エラーを最も多く生成している URL を見つけたりできます。 DynamoDB の上にアプリケーションを構築する開発者にとっては、トラフィックの傾向や頻繁にアクセスするキーなどのデータベースアクセスパターンを理解して、DynamoDB のコストとパフォーマンスを最適化するのに役立ちます。DynamoDB […]

この記事は、Amazon DynamoDB へのデータの取り込みに今日どのようなソリューションが存在するかを再検討するとともに、Amazon S3 バケットから DynamoDB テーブルへの CSV ファイルの一括取り込みのための能率化されたソリューションについて説明して、AWS アカウントへの簡単なデプロイメントのために、このソリューションの AWS CloudFormation テンプレートを提供します。 Amazon DynamoDB は、規模を問わず 1 桁台のミリ秒でのパフォーマンスを実現する key-value /ドキュメントデータベースです。今日、AWS の何十万人ものお客様が、モバイル、ウェブ、ゲーミング、アドテクノロジー、IoT、および低レイテンシーのデータアクセスを必要とするその他アプリケーションのために DynamoDB の使用を選択しておられます。一般的なユースケースは、DynamoDB へのデータの一括取り込みの実装です。大抵の場合、このデータは CSV 形式であり、すでに Amazon S3 内に保存されている場合があります。この一括取り込みは移行取り組みを迅速化するための鍵であり、取り込みのパイプラインジョブを設定する必要性を軽減し、全体的なコストを削減して、Amazon S3 からのデータの取り込みをシンプル化します。 この記事では、DynamoDB に加えて、ソリューションを作成するために AWS の以下のサービスを 200～300 レベルで使用します。 Amazon S3 AWS Lambda AWS CloudFormation 前提条件 この記事のソリューションを完成させるには、以下が必要です。 AWS アカウント。 DynamoDB、Amazon S3、Lambda、および AWS CloudFormation にアクセスできる IAM ユーザー。 DynamoDB […]

これは、YourCast Inc. のソフトウェアエンジニアであるウツミケイスケ氏によるゲスト投稿です。同社の言葉を借りると、「YourCast Inc. は、テレビ放送と同期されたウェブサイトを利用して、ユーザーにインタラクティブなエンターテイメントサービスを提供しています」との事です。 YourCast Inc. は、日本のテレビ視聴者向けにウェブサイトとアプリベースのインタラクティブコンテンツを提供しています。当社のアプリケーションの多くは、Amazon DynamoDB をデータベースとして使用して、登録ユーザー情報を保存し、テレビ放送中のライブ投票イベントでユーザーの投票活動の履歴を記録します。当社のアプリケーションは、毎朝の番組や季節ごとのポップミュージック番組でよく用いられています。このブログ記事では、DynamoDB のオンデマンド読み取り/書き込みキャパシティーモードを使用して、TV ライブ投票イベントで使用されるシステムのコストとパフォーマンスを最適化する方法を確認します。 視聴者の投票期間はテレビ番組の放映時間に制限されているため、ほとんどのライブ投票プロジェクトでは、ユーザーアクセスは数時間しか見られません。この数時間で、アクセスリクエストが急増するのはほんの数分間です。ピーク時以外のワークロードは、ピーク時と比較してほとんどありません。両者を比べると、1:100 または 1:10,000 の割合です。 次のグラフは、視聴者をウェブサイトに投票させるテレビ番組中のウェブサービスへのアクセスリクエストの記録を示しています。投票がなかったときは、視聴者からの投票活動へのアクセスがないため、リクエストはありませんでした。具体的には、19:30 から 20:15 の間、ユーザーからの投票アクティビティがなかったため、リクエストはありませんでした。それから 20:15 に、視聴者が投票を開始し、システムがユーザーのデータを記録し始めたため、数分間スパイクが見られました。プログラムが 22:30 に終了するまで、投票時間中に短いスパイクが繰り返されるこのパターンが不規則に広がっています。Amazon CloudWatch Logs がレコードを収集したため、数値は 1 分あたりの平均値です。ピーク時に記録された実際の数は、非ピーク時の 2～3 倍でした。 Amazon DynamoDB オンデマンドを使用する理由 このケースでは、Amazon DynamoDB オンデマンドが最も有用であることがわかりました。DynamoDB の Auto Scaling を使用することもできましたが、TV プログラムでの計画外のプロモーションが原因でリクエストが突然または予期せず急増した場合、DynamoDB の Auto Scaling では十分に早く追いつけないでしょう。DynamoDB オンデマンドを使用すると、お金を節約し、手動による介入を減らすことができ、遅滞がありません。 一部のライブプログラムには、プログラム中、イベントの厳密なスケジュールがありません。したがって、トラフィックが急増する時間帯を事前に予測することは困難です。ピーク時のトラフィックに備えて DynamoDB のキャパシティーを事前にプロビジョニングした場合、実際にピークがいつ発生したかに関係なく、そのリソースに対して料金を支払う必要があります。DynamoDB オンデマンドが利用できるようになる前は、潜在的なスパイクに対応するためにテレビ番組の開始 1 時間前にキャパシティーを手動でスケールアップし、番組終了後にスケールダウンしていました。突然の急上昇に備えるこのプロセスにはコストがかかりました。 DynamoDB オンデマンドにより、リクエストごとに支払うことができるようになり、トラフィック量が少ない期間が長く続く中で短いリクエストを急に受信する当社のサービスに最適でした。次のグラフは、あるテレビ番組の […]

Amazon DynamoDB バックアップと復元は、DynamoDB テーブルの継続的かつオンデマンドのバックアップを作成し、そのバックアップからデータを復元するためのシンプルで完全に自動化された機能を提供します。ポイントインタイムリカバリ (PITR) を使用すると、DynamoDB テーブルデータの連続バックアップを作成できます。DynamoDB は、1 秒ごとの粒度でデータをバックアップし、過去 35 日間の任意の時点に復元できます。PITR を構築して、誤った書き込みや削除からユーザーを保護します。オンデマンドバックアップ を使用して、DynamoDB テーブルの完全バックアップを作成することもできます。オンデマンドバックアップは、長期の保存とアーカイブに適しており、規制要件に準拠するのに役立ちます。 DynamoDB バックアップからデータを復元するときに異なるテーブル設定が行えるようにするため、新しい復元機能を複数導入しました。このブログ記事では、新機能とその使用方法について説明します。 新しい DynamoDB の復元機能の説明 DynamoDB バックアップからデータを復元するときに、次のタスクを実行できるようになりました。 ソースバックアップが存在する場所とは異なる AWS リージョンの新しいテーブルにバックアップを復元する。リージョン間の復元を実行できると、マルチリージョンのコンプライアンスおよび規制要件を満たし、災害復旧およびビジネス継続性計画を開発するのに役立ちます。 一部またはすべてのローカルおよびグローバルセカンダリインデックスを、復元されたテーブルで作成されないように除外する。セカンダリインデックスを復元対象から除外することにした場合、復元はより高速で費用効率が高くなります。 テーブルの請求方法を変更する (オンデマンドキャパシティーモードまたはプロビジョニング済みキャパシティーモード)。 必要に応じて、プロビジョニング済みのキャパシティーの設定を変更する。 復元されたテーブル (AWS が所有する CMK、AWS が管理する CMK、または顧客が管理する CMK) の暗号化キーを更新する。 AWS マネジメントコンソール、シンプルな API 呼び出し、または AWS コマンドラインインターフェイス (CLI) で数回クリックするだけで、復元された DynamoDB テーブルの設定を変更できます。実稼働アプリケーションのパフォーマンスや可用性に影響を与えることなく、数メガバイトから数百テラバイトのデータからテーブルを復元できます。 これらの新しい復元機能を使用する方法を見てみましょう。 PITR を有効にして開始 復元をテストするには、まずバックアップが必要です。幸いなことに、DynamoDB はテーブルを即座にバックアップしてくれます。テーブルで PITR を有効にすることから始めます。ここでは、私は米国東部 (オハイオ) リージョンを使用しています。けれども、この機能はどの […]

皆さん、こんにちは！ モダンアプリケーション開発スペシャリスト ソリューションアーキテクトの福井です。 私が執筆したモダンアプリケーション開発のホワイトペーパー（日本語版）がAWSホワイトペーパーサイトで公開されましたので、その内容を紹介させて頂きます。このホワイトペーパーは、以前こちらのブログで紹介させて頂いたModern Application Development on AWS（英語版）の日本語版になります。   ホワイトペーパーの内容 公開されたホワイトペーパードキュメントは、「AWS モダンアプリケーション開発 – AWS におけるクラウドネイティブ モダンアプリケーション開発と設計パターン」（日本語版）というタイトルの51ページのドキュメントで、 はじめに モダンアプリケーション開発 モダンアプリケーションの設計パターン AWSでのCI/CD まとめ の各章から構成されています。各章の簡単なご紹介は下記の通りです。

Amazon DynamoDB のベストプラクティスを守ることを新年の抱負としてみてはいかがでしょうか。これらのベストプラクティスに従うことで、DynamoDB を使用する際のパフォーマンスを最大限に発揮し、最小限に抑えることができます。以下のリンクをクリックして、DynamoDB ドキュメントで各ベストプラクティスの詳細をご覧ください。 パーティションキーを効率的に設計して使用する DynamoDB テーブルにある各アイテムを固有に識別するプライマリーキーは、シンプルなキー (パーティションキーのみ) または複合キー (ソートキーと組み合わされたパーティションキー) にすることができます。アプリケーションは、テーブルとそのセカンダリインデックスの論理パーティションキー全体で統一されたアクティビティのために設計してください。バーストキャパシティー、アダプティブキャパシティー、および書き込みシャーディングといった追加のメリットが得られます。 ソートキーを使用してデータを編成する 適切に設計されたソートキーは、関連する情報を一か所に集め、それを効率的にクエリすることができます。複合ソートキーは、データで階層 (1 対多) リレーションシップを定義することを可能にし、任意の階層レベルでクエリすることができます。バージョン管理の目的でソートキーを使用することもできます。 セカンダリインデックスを効率的に使用する 多くの場合、セカンダリインデックスはアプリケーションが必要とするクエリパターンをサポートするために必須です。その一方、非効率的なセカンダリインデックスの使用は不必要にコストを増加させ、パフォーマンスを低下させます。スパースインデックスの使用方法、マテリアライズされた集計クエリのグローバルセカンダリインデックスの使用方法、および結果整合性のあるレプリカの作成方法を学習します。 大型のアイテムと属性を保存する方法を理解する DynamoDB では現在、テーブルに保存する各アイテムのサイズが制限されています。アプリケーションが、サイズ制限を超過したデータをアイテムに保存する必要がある場合、大きな属性を １ つ以上圧縮したり、アイテムを複数のアイテムに分割したり (ソートキーによる効率的なインデックス化) することができます。また、アイテムをオブジェクトとして Amazon S3 に保存して、Amazon S3 オブジェクト識別子を DynamoDB アイテムに保存したりすることもできます。 期間ごとに 1 アプリケーションあたり 1 つのテーブルを使って時系列データに対応する DynamoDB における一般的な設計原則では、使用するテーブルの数を最小限にとどめることが推奨されています。ほとんどのアプリケーションには、単一のテーブルしか必要ありません。しかし、時系列データについては、期間ごとに 1 アプリケーションあたり 1 つのテーブルを使うことができます。 多対多リレーションシップを管理する 隣接リストは、DynamoDB における多対多リレーションシップのモデル化に有用な設計パターンの一部です。より一般的には、DynamoDB でグラフデータ (ノードとエッジ) を表現する方法を提供します。 ハイブリッドデータベースシステムを実装する 状況によっては、1 つ以上のリレーショナルデータベース管理システムから DynamoDB への移行が適切ではない場合があります。この場合は、ハイブリッドシステムの作成が望ましいかもしれません。 […]

 Amazon DynamoDB にとって、2019 年も多忙な年でした。AWS では、信頼性、暗号化、速度、スケーリング、および柔軟性の観点から、当サービスでの皆さんのエクスペリエンスをこれまで以上に向上させることに焦点を当てた新しい更新機能をリリースしてきました。 以下は、2019 年のリリースをカテゴリ単位でアルファベット順に分類してから、リリースされた日付け順 (最新リリースが各カテゴリの最上部) に並べたものです。1 年間に及ぶサービスの変更を把握しておくのは困難だと思います。この便利な 1 ページの記事で、2019 年に DynamoDB で起こった事柄を確認、または思い出してください。ご質問等がございましたら、@DynamoDB までお問い合わせください。(注意: この記事は年末前に掲載されるので、2019 年の終わりまでに行われるローンチが他にもあれば、それらで記事を更新していく予定です。) アダプティブキャパシティー 11 月 15 日: 頻繁にアクセスされる項目を自動的に隔離することにより、Amazon DynamoDB アダプティブキャパシティーが不均衡なワークロードをより良く処理できるようになりました DynamoDB アダプティブキャパシティーは、頻繁にアクセスされる項目を自動的に隔離することによって不均衡なワークロードをより良く処理します。お使いのアプリケーションが、1 つ、または複数の項目に対して過度に高いトラフィックを実行する場合、DynamoDB はパーティション間のバランスを取り直し、頻繁にアクセスされる項目が同じパーティションに格納されないようにします。この最新の拡張機能は、ワークロードに対して中断のないパフォーマンスを維持するために役立ちます。 5 月 23 日: Amazon DynamoDB アダプティブキャパシティーが即時利用可能に DynamoDB は、変化し続けるアプリケーションのトラフィックパターンに対応して、アダプティブキャパシティーをリアルタイムで適用します。これにより、不均衡なワークロードにさえも中断のないパフォーマンスを無期限に維持できます。即時に利用できるアダプティブキャパシティーは、すべての DynamoDB テーブルおよびにグローバルセカンダリインデックスに対してデフォルトで有効になっており、追加の料金はかかりません。 バックアップと復元 11 月 13 日: Amazon DynamoDB のバックアップからのテーブルの復元時におけるテーブル設定の実行が可能に DynamoDB のバックアップからテーブルを復元するときに、テーブルの設定を行うことができます。具体的には、復元されたテーブルと共に作成されないように、ローカルおよびグローバルセカンダリインデックスの一部またはすべてを除外できます。請求モード、およびプロビジョニングされたキャパシティーの設定を変更することも可能です。 4 月 4 […]

以下の 20 のページは、2019 年に最も閲覧された Amazon DynamoDB のドキュメントページです。このリストには、各ページの内容を説明するために、簡単な記述とそれぞれのリンクが含まれています。このリストを使用して、AWS の他のお客様が何を読んでいるかをご覧ください。前から知りたいと思っていたトピックに対する興味が湧くかもしれません。 クエリの操作 DynamoDB のクエリオペレーションは、プライマリキー値に基づいて項目を検索します。複合プライマリキー (パーティションキーおよびソートキー) がある任意のテーブルまたはセカンダリインデックスを照会することができます。 Amazon DynamoDB とは この DynamoDB についての簡単な紹介は、DynamoDB 開発者ガイドのウェルカムページとしても役立ちます。 DynamoDB ローカル (ダウンロード可能バージョン) のセットアップ ダウンロード可能なバージョンの DynamoDB によって、DynamoDB ウェブサービスにアクセスすることなくアプリケーションを記述してテストすることができます。本番用にアプリケーションをデプロイする準備が整うと、コードを若干変更するだけで DynamoDB ウェブサービスを使用できるようになります。 DynamoDB のベストプラクティス DynamoDB を使用する際に、パフォーマンスを最大化し、スループットコストを最小化するための推奨事項をすばやく見つけることができます。 DynamoDB での制限 特に指定のない限り、これらの現在の DynamoDB の制限 (または、場合によっては欠如) は、リージョンごとに適用されます。 クエリ KeyConditionExpression パラメータを使用して、パーティションキーに特定の値を指定します。クエリオペレーションは、そのパーティションキーの値を持つテーブルまたはインデックスからすべての項目を返します。 読み取り/書き込みキャパシティーモード DynamoDB には、テーブルの読み取りと書き込みを処理するために、オンデマンドとプロビジョンドの 2 つの読み取り/書き込みキャパシティーモードがあります。 DynamoDB コアコンポーネント DynamoDB で用いる主要なコンポーネントは、テーブル、項目、属性です。テーブルは項目の集合であり、それぞれの項目は属性の集合です。 DynamoDB の使用開始 […]

Amazon DynamoDB は、任意の規模で 1 桁のミリ秒のパフォーマンスを実現するために構築されたキーと値およびドキュメントデータベースです。これは、マルチリージョンでマルチマスターのフルマネージドデータベースで、組み込みのセキュリティ、バックアップとリストア、およびインターネット規模のアプリケーション用のメモリ内キャッシュを備えています。 この記事では、開始するために知っておく必要がある基本的な事項を確認します。テーブルを作成し、DynamoDB テーブルを設計するときの主な考慮事項について学習します。次に、いくつかのサンプル項目を挿入し、最後にそれらをクエリします。サンプル項目は実際の例で、AWS のオープンデータのレジストリからの Amazon Customer Reviews Dataset です。このガイドでは、データセットのビジネス要件および技術要件が DynamoDB 設計にどのように通知されるかについて説明します。この記事は読者に前提知識がないことを想定しています。 まず、ユースケースを分析しましょう。この記事のこのデータセットは、1 日数百万人のユーザーにサービスを提供している e コマースウェブサイトの本番レビューを表しています。特定の製品のレビューにすばやくアクセスし、投稿したすべてのレビューをユーザーが見られるようにしたい場合があるでしょう。 これらの条件は両方とも、大規模なデータセットへの高速アクセスを必要とします。DynamoDB は、それに対する完璧なソリューションです。 テーブルの作成 最初のステップは、テーブルを作成することです。 以下のスクリーンショットのプレビューに示すように、AWS マネジメントコンソール のサービスの検索で、DynamoDB を入力して選択します。 以下の画像に示すように、[テーブルの作成] を選択します。 テーブル名 には、product_reviews などの名前を入力します。ここで、重要な決定を行います。DynamoDB は、キーを使用して、複数のインスタンスにデータを整理および配布します。キータイプには、次の 2 つの基本的なタイプがあります。 – パーティションキー – これは、DynamoDB が内部ハッシュ関数に使用して、保存するアイテムの物理的な保存場所を決定する値です。 – ソートキー – これは、一致するパーティションキーを持つアイテムをソートするために使用します。複数の値を連結して、複合ソートキーを作成できます。 ホットキーを回避するために、データが可能な限り均等に分散されるパーティションキーを選択します。パーティションキーの設計とホットキーの回避の詳細については、ドキュメントの「ワークロードを均等に分散するためのパーティションキーの設計」を参照してください。DynamoDB でさらに読み取りを行い、hash と ranges キーを参照する場合、これらはパーティションキーおよびソートキーの以前の用語です。 DynamoDB テーブルには、テーブル内の各アイテムを一意に識別するプライマリキーが必要です。プライマリキー には以下の 2 つのタイプがあります。 – […]