Category: Amazon 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 つのタイプがあります。 – […]

Amazon DynamoDB はサーバーレスデータベースです。このサービスは、この分散システムの背後にあるインフラストラクチャの運用と保守に関連する、未分化の困難な作業を扱います。お客様は、API を使用して、テーブルのモニタリングと操作に使用できる操作データをキャプチャします。この記事では、DynamoDB を運用するためにダッシュボードとアラームを構築する際に考慮する一連のメトリクスについて説明します。 DynamoDB によって公開された Amazon CloudWatch メトリクスを使用すると、データモデルのコンテキストで進化するワークロードと DynamoDB の相互作用を理解するのに役立ちます。メトリクスは、適用されるリソースレベルに基づいて、次の 3 つのカテゴリーに分類されます。 DynamoDB で箱から出してすぐに使用できるメトリクス (「箱から出してすぐに」と注記)。 メトリクス計算 によるコンピューティングを必要とするメトリクス (「メトリクス計算が必要」と注記)。 カスタム AWS Lambda 関数を使用して Amazon CloudWatch に自己公開する必要があるメトリクス。 本番環境に移行すると、DynamoDB で運用の卓越性を実現するための推奨事項も取得できます。 この例で必要なカスタムメトリクスを公開するコードをダウンロードするには、「GitHub リポジトリ」を参照してください。カスタム CloudWatch メトリクスを公開するための Lambda 関数は、デフォルト設定をオーバーライドするための多くの環境変数を受け入れます。詳細については、README を確認してください。この記事の公開時点で、環境変数は次のとおりです。 CLOUDWATCH_CUSTOM_NAMESPACE – デフォルトでは、AWS Lambda 関数は「Custom_DynamoDB」名前空間にメトリクスを公開します。変更する場合は、CLOUDWATCH_CUSTOM_NAMESPACE 環境変数を設定します DYNAMODB_ACCOUNT_TABLE_LIMIT – デフォルトでは、AWS Lambda 関数は DynamoDB アカウントテーブルの制限が 256 であると想定します。アカウントテーブルの制限を決定する API 呼び出しはないため、AWS にアカウントのこの制限を増やすように依頼した場合は、DYNAMODB_ACCOUNT_TABLE_LIMIT を […]

AWS Lambda は、Amazon Kinesis Data Streams と Amazon DynamoDB ストリームのイベントソースで利用可能な、新しいスケーリングパラメータを導入しました。Parallelization Factor は、各シャードにおける Lambda 関数呼び出しの同時実行数を増やす設定を可能にします。このパラメータは、デフォルトでは 1 です。これによって、処理されるレコードの順序を保証しながら、シャード数を過大にスケールすることなく、より高速なストリーム処理が可能になります。

みなさんこんにちは！アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの木村公哉です。 11月21日に「ビルシリーズ@六本木一丁目住友不動産六本木グランドタワー 第１回」を開催いたしました。今回は「初めてのサーバレスWebアプリケーションハンズオン」を実施しました。こちら「ビルシリーズとは？」とお思いの方も多いかと思いますので、開催報告と合わせてご説明いたします。 「ビルシリーズ」とは？ このイベントは、日頃AWSをご利用いただいているお客様に、AWSからの情報発信はもちろん、同じビルに拠点を構えるお客様同士の活発な意見交換と交流の場を定期的に作ることを目的としたものです（同じビルなので移動が楽！）。 今回、住友不動産六本木グランドタワーのFringe81様、BASE様、エブリー様、ディップ様で同じようなニーズがあり、このようなビル単位でのイベントを開催する運びとなりました。場所はFringe81様の素敵な大会場をお借りいたしました。Fringe81様ありがとうございました。 来月には住友不動産麻布十番ビルでも開催を予定しており、今後もこのようなビル単位で交流ができるようなイベントを開催していきたいと考えております。 当日の様子 当日は約40人のお客様にお越しいただき、イベントは終始盛り上がりを見せておりました。   まずはAWSJ 植本より、今回のビルシリーズの趣旨などを説明いたしました。   次に、AWSJ 木村より「サーバレスのご紹介 – ユースケースパターンを切り口に」というタイトルで、AWSのサーバレスプラットフォームについてご紹介いたしました。   続けてAWSJ 木村より「初めてのWebアプリケーションハンズオン」を実施いたしました。   ハンズオンの終了後、ご参加いただいた皆様と共に、簡単な懇親会を開催いたしました。   今回、AWSJより、アカウントマネージャー植本、藤田、細木、ソリューションアーキテクト上原、石見、小宮、木村がビルシリーズをサポートいたしました。こちらはソリューションアーキテクトの集合写真です。 貴社担当のアカウントマネージャから「ビルシリーズ」のお誘いがあるかもしれませんが、是非ご検討いただければと思います。それでは、次回のビルシリーズでお会いしましょう！   著者について 木村 公哉（Kimura, Koya） 香川県出身のソリューションアーキテクトです。好きなサービスはAWS AmplifyとAWS Lambda、Amazon Kinesisです。好きな食べ物はうどんです。   上原 誠（Uehara, Makoto） アマゾンウェブサービスジャパン株式会社のソリューションアーキテクトとして、主にメディア系のお客様に対する技術支援を担当。技術的な得意/興味領域としては、アナリティクス系テクノロジー、広告系ソリューションなど。