Category: Amazon DynamoDB

皆さん、こんにちは！ モダンアプリケーション開発スペシャリスト ソリューションアーキテクトの福井です。 私が執筆したモダンアプリケーション開発のホワイトペーパー（日本語版）が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） アマゾンウェブサービスジャパン株式会社のソリューションアーキテクトとして、主にメディア系のお客様に対する技術支援を担当。技術的な得意/興味領域としては、アナリティクス系テクノロジー、広告系ソリューションなど。

AWS AppSyncはGraphQLのマネージドサービスで、単一または複数のデータソースのデータに安全にアクセスしたり、操作したり、結合するための柔軟なAPIを作成でき、アプリケーション開発をシンプルにすることができます。多くの場合、異なったデータソースは異なったユースケースに合わせて最適化され、データが配信されるスピードも異なっていることでしょう。その基になるGraphQLスキーマで定義されているデータフィールドもかなり多様です。

本記事は「新しいサーバーレスアプリ作成機能で CI/CD も作れます」のその後のステップとして記述しています。まだその記事を見ていない方は、まずはそちらをご覧ください。以下は、その機能で、テンプレートとして Serverlerss API backend を選択し、プロジェクトリポジトリとして CodeCommit を作成された結果を元に説明しています。CI/CD や CodeCommit をよくご存知の方は読み飛ばしていただいて構いません。 実行テスト 作成されたアプリケーションは、何も変更しなくてもすでに実行できる状態にあります。 例えば、ターミナルなどから以下のコマンドを実行してみてください（なお、下記のように日本語を含むデータで実行する場合は、ターミナルの文字コード設定が UTF-8 であることを確認ください）。 curl -d ‘{“id”:”001″,”name”:”テスト”}’ -H “Content-Type:application/json” -X POST https://<<API EndPoint>> DynamoDBのコンソールをみると、新しいデータが登録されることがわかります。もちろん、好みの REST API テストツール（ブラウザプラグインなど）を使っても構いません。 構成の確認 生成されたアプリケーションで、API 定義、Lambda 関数がどのように定義されているかを見るのは、サーバーレスを始めたばかりの開発者には参考になるかと思います。例えば、API Gateway の構成を見てみると、以下のように設定されていることがわかります。 名称で想像できる通り、3つの関数は、全件検索、データの書き込み、特定 ID のデータの取得のための処理であり、それらが対応する API に紐づけられています。この 3つの処理はよく使われる典型的なものですので、そのコードは、多くの処理で参考になるでしょう。 コードの編集 テンプレートベースのサーバーレスアプリ作成機能で設定された Lambda 関数がどういうものか、コンソールから確認してみましょう。作成したサーバーレスアプリケーションへ Lambda コンソールからアクセスし、その中のリソースのセクションを見ると Lambda Function タイプのものが作成されていることがわかります。 ここにあるリンクをクリックすれば、それぞれの Lambda 関数の画面に飛びますが、そのコードは表示されず、「インラインコード編集を有効にできません」と表示される場合があります。生成されたコードはどこにあるのでしょう? もう一度、Lambda […]