Power Unit Inc. | 想像力のない者に翼はない | Amazon DynamoDB
17332
page-template,page-template-full_width,page-template-full_width-php,page,page-id-17332,qode-quick-links-1.0,woocommerce-no-js,ajax_fade,page_not_loaded,,side_area_uncovered_from_content,columns-4,qode-theme-ver-16.7,qode-theme-bridge,wpb-js-composer js-comp-ver-5.5.2,vc_responsive
 

Amazon DynamoDB

Amazon DynamoDB

どのような規模にも対応する高速で柔軟な NoSQL データベースサービス
必要とするスループットとストレージにのみ支払いが発生します

Amazon DynamoDB は、整合性があり、10 ミリ秒未満のレイテンシーを必要とする、すべての規模のアプリケーションに対応した、高速かつフレキシブルな NoSQL データベースサービスです。完全マネージド型のクラウドデータベースで、ドキュメントとキー値のストアモデルの両方をサポートしています。柔軟性のあるデータモデルと信頼性の高いパフォーマンスにより、モバイル、ウェブ、ゲーム、アドテック、IoT など、より多くのアプリケーションで大いに活用できます。

Amazon DynamoDB のメリット

高速、安定したパフォーマンス

Amazon DynamoDB は、あらゆる規模のすべてのアプリケーションで安定した高速パフォーマンスを実現します。通常、サービス側の平均レイテンシーは 1 桁台のミリ秒単位です。データのボリュームが増えてアプリケーションのパフォーマンス向上が必要になった場合、Amazon Dynamo DB では自動パーティション化と SSD テクノロジを使用してスループット要件を満たし、すべてのスケールで低レイテンシーを提供します。

高いスケーラビリティ

テーブルを作成するときに、必要なリクエスト容量を指定します。スループット要件が変わった場合は、AWS Management Console または Amazon DynamoDB API を使用して、テーブルのリクエスト容量を更新します。Amazon Dynamo DB はすべてのスケーリングを水面下で管理し、ユーザーはスケーリングの進行中でもスループットレベルを実現することができます。

完全マネージド型

Amazon DynamoDB は完全マネージド型のクラウド NoSQL データベースサービスです。開発者はデータベーステーブルを作成し、スループットを設定するだけで、残りの処理は自動的に行われます。ハードウェアまたはソフトウェアのプロビジョニング、設定と構成、ソフトウェアの修正、信頼できる分散型データベースクラスターの操作、拡張による複数のインスタンスでのデータのパーティション化などのデータベース管理タスクについて心配する必要はありません。

イベントドリブンプログラミング

Amazon DynamoDB は、AWS Lambda と統合され、データの変化に自動的に反応するアプリケーションの設計を可能にするトリガーを実現しています。

FGAC (きめ細かなアクセス制御)

Amazon DynamoDB と AWS Identity and Access Management (IAM)との統合により、組織内のユーザーのアクセスを細かく管理することもできます。独自のセキュリティ認証情報を各ユーザーに割り当て、各ユーザーのサービスとリソースへのアクセスを制御できます。

柔軟性

Amazon DynamoDB では、ドキュメントとキー値データストラクチャの両方をサポートしているため、アプリケーションに最適なアーキテクチャを柔軟に設計できます。

Amazon DynamoDB のユースケース

Amazon DynamoDB の適用分野としてあげられるのは、いわゆるビッグデータ解析のためのデータ収集です。これには、ユーザーセッションのアナリティクス(検索、広告)、コマース(リテール、EC などの行動分析、商品分析、ワークフローの最適化)、ソーシャルネットワーク(投稿、コメント、チャット、ショートメッセージ、いいねなどのユーザーアクション)、コンテンツドキュメントマネージメント、メディアストリーミングのメタ情報解析、モバイル端末・モバイルアプリのバックエンド、オンラインゲームのバックエンド、IoT (計測系センサー、制御系センサー)、人工知能(機械学習・深層学習)、時系列データ(金融サービス、経済モデル、科学計算、ヘルスケア)などが含まれます。

広告エンジン

Amazon DynamoDB は、あらゆる規模のアプリケーションで、1 桁ミリ秒単位の安定したレイテンシーを実現する、NoSQL データベースサービスです。DynamoDB はリアルタイム入札 (RTB) プラットフォームや広告推奨エンジンの作成に必要なパフォーマンスと可用性を備えています。

インターネット広告サービスはターゲティング広告をサービスする上で、制約された時間で処理しなければいけません。つまり、サイトやアプリでアクセスした顧客の行動履歴に応じて最適な広告を瞬時に判断し効果的な方法で低レイテンシーなレスポンスが必要になります。これは、いくつもの技術的挑戦を意味しています。

AWS では、信頼性、耐障害性、高可用性を兼ね備えた広告サービスのためのプラットフォームをクラウド上に構築するための汎用サービスとインフラストラクチャーを提供しています。以下では、広告サービスのシステムにおける 2 つの中核について紹介します。2 つの中核とは、つまり、広告サービスのインフラスタラクチャー【図の黒色部分】とデータ解析クラスタに最適化されたクリックスルーコレクション【図の白色部分】です。

  1. サイトの訪問者が Web ページをロードすると、広告サービスは(クライアントに)表示するための広告リソースへのポインターを返却します。これらの広告サーバは、Amazon Elastic Computing Cloud (Amazon EC2) インスタンスで動作しています。広告サーバは、Amazon DynamoDB のテーブルに保存されているデータセットに対して問い合わせをして顧客のプロフィールに応じて関連性の高い広告を見つけ出します。
  2. 広告ファイル(イメージやビデオ)は、Amazon CloudFront を経由してダウンロードされます。Amazon CloudFront とは、低レイテンシー、高速なデータ転送スピード、制限のないコンテンツデリバリーネットワークです。表示された広告から生成された(インプレッション)ログ情報は、高可用性を備えた Amazon Simple Storage Service (Amazon S3) に保存されます。
  3. クリックスルー(広告をクリックすることをクリックスルーと呼びます)サーバは、クリックスルーデータを収集ための Amazon EC2 インスタンスのグループ(クラスター)です。サーバの情報には、Web サーバのクリックスルーのログファイルが含まれていて、定期的に Amazon S3 にアップロードされます。
  4. 広告のインプレッションとクリックスルーデータは Amazon S3 から抽出され、並列ジョブフローでデータ処理するためのホスト型 Hadoop フレームワークを利用した Amazon Elastic MapReduce クラスターで処理されます。クラスターの容量は、Spot Instance を利用することで動的に変更可能で、処理時間や、ジョブフローのランニングコストを削減することができます。
  5. データ処理された結果は、高速で、事前に予期可能なパフォーマンス(事前にパフォーマンスに制約を設定できます)とシームレスなスケーラビリティーを提供する完全マネージド型の NoSQL データベースサービスの Amazon DynamoDB にプッシュバックされます。Amazon DynamoDB のテーブルは、どんな容量のデータでも保存・抽出することができ、リクエストのトラフィックのレベルを制御できます。これらは、両方とも、訪問者のプロフィール情報を保存、高速抽出するために指定された要求に相当します。
  6. Amazon DynamoDB の高可用性と高速なパフォーマンスによって、たとえ、非常に膨大なトラフィックや巨大なプロフィールデータセットであったとしても、予測可能なレスポンスタイム内で広告サーバのフロントエンドがリクエストを処理できます。

オンラインゲームのバックエンド

Amazon DynamoDB を使用して、モバイル、コンソール、およびデスクトップ向けに応答速度が必要とされるゲームを作成できます。Cloud Canvas を使用して、プレイヤーのステータス、ハイスコア、または世界の動的コンテンツといった Amazon Lumberyard ゲームデータを保存し、クエリできます。成功するモバイルゲームの開発には、ゲーム以外の要素も関係します。Amazon DynamoDB は、ユーザー認証、ダウンロード可能なコンテンツ、ソーシャル機能について、AWS Mobile SDK および AWS の広範囲にわたるサービスと統合されています。

オンラインゲームのバックエンド・インフラストラクチャーは、保守・運用する上で非常にチャレンジングになります。使用限度のピーク性能、複数のプレーヤー、非常に大量の書き込み処理といった事象が、オペレーションチームが直面するよくある問題の 1 つになります。

しかし、最も難しくチャレンジングなことは、システムの規模における柔軟性を保証することです。人気のあるゲームは、一瞬のうちに何百万ものユーザーを獲得するにもかかわらず、多くのプレーヤーの体験を満足させ続けなければいけません。AWS は、大量のトラフィックパターンをスケールするためのオンラインゲームの構築に利用可能な様々なツールやサービスを提供しています。

以下では、自動的にキャパシティーを調整し、高可用性と高速なデータベースを保証し、プレーヤーの行動分析のためのデータ処理クラスターに焦点を当てたオンラインゲームのためのコスト重視のアーキテクチャーを紹介します。

  1. ブラウザーベース(アプリベースでもバックエンドの基本的な概念は同じです)のゲームはクライアント・サーバアプリケーションに相当します。クライアントは、イメージ、サウンド、フラッシュアプリケーション、Java アプレットといった静的なファイルによって構成されています。これらのファイルは、高可用性と高信頼性を備えたデータストアである Amazon Simple Storage Service (Amazon S3) によってホストされます。
  2. ユーザーベースの拡大は、より地理的(ワールドワイド)に拡大し、Amazon CloudFront のような、レイテンシー、耐障害性、コストについて十分な改善を提供する高パフォーマンスキャッシュが必要になります。Amazon CloudFront の配信のオリジンサーバとして Amazon S3 を利用することによって、ゲームインフラストラクチャーは、高速なネットワークデータ通信とシンプルな配布・キャッシュのワークフローという恩恵を受けることができます。
  3. ゲームを操作した時のインタラクション・リクエストは Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上で動作しているウェブサーバのグループから構成される Elastic Load Balancing (ELB) によって配信されます。Auto Scaling は、ネットワークの負荷、CPU のワークロードなどに基づくルールに従ってクラスターのグループのサイズを自動的に調整します。
  4. プレーヤーのデータは、フルマネージド型の NoSQL データベースサービスの Amazon DynamoDB に保管されます。プレーヤー人口の増大に伴って、Amazon DynamoDB は予測可能なパフォーマンスとシームレスなスケーラビリティーを提供します。
  5. それぞれの Web サーバが生成されたログファイルは、 長期保存のための Amazon S3 にプッシュバックされます。
  6. オンラインゲームのプラットフォームが生成する膨大な量のデータを管理・分析することは非常にチャレンジングなことです。Amazon Elastic MapReduce (Amazon EMR) は膨大な量のデータを簡単に処理することができます。入力データとして、Amazon S3 に保存されている Web サーバのログファイルから抽出したり、Amazon DynamoDB のテーブルに保存されているプレーヤーのデータを利用して、プレーヤーの行動、使用パターン、などを分析することができます。処理した結果は、再び Amazon S3 に保存することもできますし、従来のビジネスインテリジェンス(BI)ツールを用いてさらなる分析のためにリレーショナルデータベースに保存することもできます。
  7. ゲームの必要性に応じて、Amazon Simple Email Service (Amazon SES) でコストに優しく、スケーラブルな方法でプレーヤーに対して電子メールを送信することもできます。

IoT のバックエンド

DynamoDB では、デバイスデータの保存とクエリが簡単に行えるため、新たな優れた AWS IoT ソリューションの構築に専念できます。高速かつ容量の大きな DynamoDB 内の IoT データを Amazon Redshift データウェアハウスに接続し、BI 分析を実施します。

IoT のユースケースの紹介の前に注意すべき点として、以下で紹介するように、定期的にスケジューリングされたデータ処理に対しては AWS Data Pipeline を用いるのが適切ですが、イベントドリブンなデータ処理に対しては、AWS Data Pipeline ではなく Amazon Lambda を利用すべきだということです。

データが一連の定期的な測定値として受信する場合、それは時系列情報として知られています。時系列情報を処理することで、AWS サービスの柔軟性に対して特徴的に位置づけられるシステムのスケーリングの問題が提起されます。

柔軟性は、取り込み処理のグループの Auto Scaling、スケジュール化された Amazon Elastic MapReduce (Amazon EMR) のジョブ、システムとシステム間のデータオーケストラレーションのための AWS Data Pipeline、超巨大なスケールの分析を可能にする Amazon RedShift 等を用いることによって可能になります。センサーメッセージのバッファリングと、間隔のあけた AWS Data Pipeline のスケジューリングのための Amazon SQS を含むキーとなるアーキテクチャーのスロットルポイント(きも)はソリューション全体のコストを予測し制御します。

  1. 電力計、モバイルクライアント、広告ネットワーククライアント、産業用メータ、サテライト、環境計測器などの、遠隔デバイスは、世界中でデータを計測し、サンプル化したデータを処理するために HTTP(S) でメッセージとして送信してきます。
  2. 自動的にスケールする Amazon EC2 ワーカーを利用して Amazon DynamoDB で処理するために Amazon Simple Queue Service (Amazon SQS) のキューにメッセージを送信してください。もしくは、センサーの元がそうすることができるのならば、センサーのサンプルを直接 Amazon DynamoDB に送信します。Amazon DynamoDB のテーブルは、週にもとづく、もしくは、時間ベースのテーブル構造から始めてください。
  3. (自社データセンター内にある)SCADA(Supervisory Control And Data Acquisition の略)があれば、Amazon DynamoDB のサンプルへ、もしくはサンプルから追加的なクラウド処理、もしくは何か他の既存のシステムをサポートするためにうまく制御フローを作成します。
  4. AWS Data Pipeline を利用して、コストのかかるサンプル処理の計算とサンプルと結果の配布の両方を取り持つパイプラインを作成します。
  5. パイプラインは、追加的な分析のために Amazon Redshift に結果を配置します。
  6. パイプラインは、Amazon DynamoDB から週にもとづく過去の週にもとづくサンプルデータを Amazon Simple Storage Service (Amazon S3) に書き出します。
  7. パイプラインは、オプションとして(自社データセンター内にある)カスタムアプリケーションが受理できる形式で書き出します。
  8. オプションとして Amazon Redshift を用いて過去のサンプルを読み込み(データウェアハウスで)計算結果を求めます。
  9. インハウスもしくは、Amazon パートナーのビジネスインテリジェンス(BI)ソリューションを利用して、Amazon Redshift は、超巨大なスケールで追加的な解析をサポートします。

「週にもとづく」という部分は、対象となるデータの性質に合わせて適時置き換えてください。もし、天気予報に関する気象情報であれば週単位ではなく時間単位が適切でしょう。なお、時間単位であれば、データパイプラインは時間単位でスケジューリングされます。

そもそも NoSQL とはなんなのか?

背景

近年、データベースの世界では NoSQL の存在が注目されています。NoSQL は「NO SQL(SQL ではない)」ではありません。「Not only SQL」です。つまり、NoSQLとは、関係データベース管理システム (RDBMS) 以外のデータベース管理システムを指すおおまかな分類語です。

NoSQL が急速に注目浴びるきっかけは、従来では考えられないようなデータの増加です。最初の波は 2000 年頃で、ユースケースでも紹介した Web サイトの広告エンジンです。広告エンジンは、検索エンジン、アクセスアナリティクス(アクセス解析)をビジネスとして成り立たせるビジネスモデルでもありました。その後、インターネットを通じてユーザーから送られてくるデータの量は、ソーシャルネットワーク(投稿、ショートメッセージ、いいねなどのユーザーアクション)、オンラインゲーム、メディアストリーミング、モバイルアプリなどの発達に従い爆発的に増加します。

例えば、Google は、膨大な Web サイトの最新の状態をクロール(監視)し、ユーザーの検索項目に最もマッチした検索結果を低レイテンシーで応答しなければいけません。また、Google はインターネット広告配信を生業とする企業ですから、検索したユーザーのプロフィールや行動履歴を元に最適な広告を瞬時に解析し、検索結果の Web ページに最適な広告を埋め込む必要があります。これらは、常に Web ページに対するユーザーからのアクセスを総合的に分析して、広告主に対してより多くの広告を出稿することを動機付けるためのダッシュボードを提供しなければいけません。

さらに、ここ数年最大の変化(イノベーション)として考えられている IoT (Internet of Things:モノのインターネット) では、年間 1 兆個のセンサーを使用する社会 “Trillion Sensors Universe” が遠くない将来到来すると予測されています。そこでは農業・工業・流通/物流・医療/ヘルスケア・環境・社会インフラ等、ありとあらゆる分野に存在するデバイスに搭載されたセンサーで覆われ、これら全てのセンサーがインターネットに接続されます。そしてそこから膨大な量のデータが生み出され、ビッグデータの適用範囲が拡大し、人工知能(AI)、機械学習(ML)、深層学習(DL)と共に我々の社会や生活を一変させるといわれています。これまでとは桁違いのデータがそこに存在することになるのです。

例えば、自動運転自動車は、1 台の車に 100 ものセンサーを搭載し、コンマ 1 秒単位でセンサーから集められた測定データを瞬時に解析しハンドル、スロットル、ブレーキなどを操作します。一連の時系列データは、同時に 2 次利用目的のために集約化されます。こうした分析後の統計データはインターネットを通じて近接する自動車間で安全運転のために深層学習されたり、さらには道路交通システムといった社会インフラのビッグデータ分析に適用されたりします。

NoSQL vs SQL (RDBMS)

こうしたデータの性質の変化は、それを管理するためのデータベースの特性の変化を求め、おのずと従来の RDBMS とは異なるデータベースつまり NoSQL データベースが注目されるようになったのです。

NoSQL データベースが従来の RDBMS とは、目的・用途が異なり、その特徴の違いから NoSQL の必要性が叫ばれている背景について紹介してきましたが、以下では、もう少し論理的な詳細な違いについて紹介します。

最も大きな違いは、データベースのデータモデルです。従来の RDBMS は行と列(もしくはそのカラム)から構成されるテーブルが基本にあります。一方で、NoSQL データベースは、キーバリュー型(KVS)、ドキュメント型、ワイドカラム型、グラフ型に大別できます。このうちAmazon DynamoDB はキーバリュー型、およびドキュメント(JSON)型をサポートします。データモデルのベースになるスキーマについては RDBMS は SQL で厳密に定義され静的です。一方、NoSQL はスキーマレス(基本的にない)でダイナミックに変更可能(非構造化)です。

データベースの操作言語は、どんな RDBMS であっても厳密に SQL で統一されています。一方で、NoSQL は、Java、JavaScript、その他データベースの種類によって様々です。

Amazon DynamoDB の特徴は、データベースの問い合わせが HTTP(S) ベースのリクエストとレスポンスで実現されています。これは AWS のストレージサービスの Amazon Simple Storage Service (Amazon S3) が HTTP(S) でアクセス可能なように、データベースにもインターネットの標準プロトコル HTTP(S) でアクセス可能になります。

拡張性については、RDBMS はスケールアップ(垂直方向)が基本です。データのサイズも最大でもテラバイト級です。一方で、NoSQL はスケールアウト(平行方向)に拡張できます。簡単に言うと、 RDBMS では、より高性能(がゆえに高価)なサーバが必要になりますが、NoSQL では、安価なサーバを追加していくことで、理論的には無限に拡張していくことができ、データのサイズは最大でペタバイト級になります。

NoSQL と CAP 定理

それぞれのデータベースには、長所と短所があり、従来の RDBMS の最大の長所は、厳密にデータの一貫性が保証されていることです。これは一般に ACID トランザクションによって保証され、複数のクライアントによる読み込み時に必ず同じ値であることが保証されます。扱うデータは、頻繁に読み書きされ、複雑な SQL を用いた問い合わせ処理(クエリー)もサポートしています。

しかし、すでに紹介したように、データベースの容量やパフォーマンスを拡張するにはデータベースサーバそのもののスケールアップするのが基本で、水平方向にスケールアウトしようとすると、シャーディングを用いて手動でチューニングする必要があります。そのため膨大なデータを高速に処理することに向いていません。これを理論的にいうと CAP 定理における、可用性(Availability)と一貫性(Consistency)は保証されますが、ネットワーク対断絶性(Partition-tolerance)が満たされないことを表しています。

NoSQL の最大の長所は、スケールアウトによる水平方向への拡張性です。大量のデータを並列で高速処理することが得意です。データは基本的に一度読み込まれたものは、何度も読み出されることはあっても上書き変更されることはあまり想定されていません。そのため複雑な問い合わせ処理(クエリー)は豊富にはサポートされておらず、キーなどで簡単に読み出すことが主です。

NoSQL の最大の短所は、データの一貫性が保証されていないことです。理論的には RDBMS の ACID に対して CAP 定理の一貫性(Consistency)を犠牲にしています。そのため、読み出しのタイミングによってはクライアントによって値が異なっていることがありえます。NoSQL では、こうした「ゆるい」一貫性を結果整合性と呼んでいます。しかし、NoSQL の主な利用形態(ビッグデータ)では、一度書き込みしたデータを更新することはあまり想定されていないので、厳密な意味でのデータの一貫性よりも、CAP 定理における可用性(Availability)とネットワーク対断絶性(Partition-tolerance)が優先されます。

Amazon DynamoDB の特徴

Amazon DynamoDB は、完全に管理された NoSQL データベースサービスで、高速かつ予測可能なパフォーマンスとシームレスな拡張性を提供します。DynamoDB を使用すると、分散データベースの運用とスケーリングに伴う管理作業をまかせることができるため、ハードウェアのプロビジョニング、設定と構成、レプリケーション、ソフトウェアパッチ適用、クラスタースケーリングなどを自分で行う必要はなくなります。

DynamoDB では、任意の量のデータを保存および取得できるデータベーステーブルを作成し、任意のレベルのリクエストトラフィックを処理できます。ダウンタイムやパフォーマンスの低下を発生させずに、テーブルのスループット容量を拡張または縮小し、AWS マネジメントコンソールを使用して、リソースの利用率とパフォーマンスメトリクスをモニタリングできます。

DynamoDB は十分な数のサーバ間でデータとトラフィックを自動的に分散し、一貫した高速なパフォーマンスを維持したまま、スループットとストレージの要件に対応します。すべてのデータは SSD (Solid State Disk) に保存され、1 つの AWS リージョン内の複数のアベイラビリティーゾーン間で自動的にレプリケートすることによって、高い可用性とデータ堅牢性を実現します。

データモデル

Amazon DynamoDB のデータモデルは次のとおりです。

  • テーブル … データ項目のコレクションです。リレーショナルデータベースのテーブルが行のコレクションであるのと同様です。各テーブルのデータ項目の数に制限はありません。Amazon DynamoDB はスキーマレスです。テーブルのデータ項目の属性および属性数は同じである必要はありません。各テーブルにはプライマリキーが必要です。プライマリキーは、単一属性キー、または 2 つの属性が組み合わされた「複合」属性キーです。プライマリキーはテーブル内の各項目を一意に識別するので、プライマリキーに指定する属性はすべての項目で存在していなければなりません。
  • 項目 … プライマリキーまたは複合キー、および任意の数の属性で構成されます。個別の項目に関連付けられる属性の数に明示的な制限はありませんが、1 つの項目の合計サイズ (すべての属性名と属性値を含む) は 400 KB を超えることはできません。
  • 属性 … データ項目に関連付けられる各属性は属性名(「Color」など)と 1 つの値(「Red」など)または値セット(「Red、Yellow、Green」など)で構成されます。各属性のサイズに明示的な制限はありませんが、1 つの項目の合計サイズ(すべての属性名と値を含む)が 400 KB を超えることはできません。

項目のパーティションキーは、そのハッシュ属性とも呼ばれます。ハッシュ属性という用語は、DynamoDB が内部のハッシュ関数を使用し、パーティションキーの値に基づいてパーティション間でデータ項目を均等に分散することに由来しています。項目のソートキーは、レンジ属性とも呼ばれます。レンジ属性という用語は、ソートキー値で並べ替えられた順に、DynamoDB が同じパーティションキーを持つ項目どうしを物理的に近くに保存する方法に由来しています。

  • キーバリューデータモデル(KVS)

Amazon DynamoDB では、キー値のデータ構造がサポートされます。各項目 (行) はキー値のペアになっており、テーブル内の項目の属性に必要なのはプライマリキーのみで、プライマリキーが各アイテムを一意的に識別します。 DynamoDB はスキーマレスです。各項目の属性 (列) の数に制限はありません。プライマリキーのクエリに加えて、グローバルのセカンダリインデックスおよびローカルのセカンダリインデックスを使用してプライマリキー以外の属性をクエリすることもできます。

  • ドキュメントデータモデル

Amazon DynamoDB では、ドキュメントの保存、クエリ、更新がサポートされます。AWS SDK を使用すると、JSON ドキュメントを直接 Amazon DynamoDB に保存するアプリケーションを構築できます。この機能によって、JSON ドキュメントを挿入、更新、取得するための新しいコードの作成を軽減でき、数行のコードだけでネスト化された JSON クエリのような強力なデータベース操作を実行できます。

プライマリーキーとクエリ

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

  • 「プライマリーキー = パーティションキー」の場合

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

  • 「プライマリーキー = パーティションキー + ソートキー」の場合

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

セカンダリインデックス

グローバルセカンダリインデックスとは、パーティション、またはパーティション/ソートキーを含んでいるインデックスで、テーブルのプライマリキーとは異なります。

テーブル内のデータに効率的にアクセスするため、Amazon DynamoDB はプライマリキー属性用にインデックスを作成して維持します。このため、アプリケーションはプライマリキーの値を指定することで、迅速にデータを取得することができます。しかし多くのアプリケーションでは、プライマリキー以外の属性を使って、データに効率的にアクセスできるようにするセカンダリ(または代替)キーを 1 つ以上設定することで、メリットが得られることがあります。これに対応するために、1 つのテーブルで 1 つ以上のセカンダリインデックスを作成して、それらのインデックスに対してクエリリクエストを実行することができます。

Amazon DynamoDB は、次の 2 種類のセカンダリインデックスをサポートしています。

  • ローカルセカンダリインデックス

テーブルとパーティションキーは同じですが、ソートキーが異なるインデックスです。あたかも、パーティションキーとソートキーの他にもう一つ別のソートキーを追加できるのと同等です。ローカルセカンダリインデックスは、ローカルセカンダリインデックスのすべてのパーティションの範囲が、同じパーティションキーを持つテーブルパーティションに限定されるという意味で “ローカル” です。

ローカルセカンダリインデックスを使用すると、一般的なクエリを簡単にコスト効率のよい方法で実行できます。ローカルセカンダリインデックスを使用しない場合は、多数の項目を取得し、結果をフィルタリングする必要があります。つまり、アプリケーションには、より幅広い属性をベースにした、より柔軟なクエリを使用できます。

パーティション内の特定の項目 (同一のパーティションキーを共有する項目) を検索する場合は、ローカルセカンダリインデックスを呼び出す前に、DynamoDB は単一のパーティションキーを共有するすべてのオブジェクトを取得し、結果をフィルタリングします。例えば、顧客 ID 注文のタイムスタンプのパーティションソートスキーマを使用して、DynamoDB テーブルに顧客注文データを保存する e コマースアプリケーションがあるとします。LSI がない場合、“顧客 X によって行われた、出荷日が過去 30 日間のすべての注文を出荷日別に並べ替えて表示する” という質問の答えを見つけるには、Query API を使用してパーティションキー “X” を持つすべてのオブジェクトを取得し、結果を出荷日で並べ替え、古いレコードを除外することが必要でした。

ローカルセカンダリインデックスにより、この処理が簡略化されます。「出荷日」属性でインデックスを作成し、このクエリを効率よく実行して、必要な項目だけを取得します。これにより、特定の基準を満たす項目だけが取得されるため、クエリのレイテンシーとコストが大幅に減少します。さらに、結果をフィルタリングするためのカスタマーロジックを作成する必要がないため、アプリケーションのプログラミングモデルが簡略化されます。この新しいセカンダリインデックスを ‘ローカル’ セカンダリインデックスと呼びます。理由は、このインデックスがパーティションキーとともに使用され、パーティションキーバケット内をローカルに検索できるためです。そのため、以前はパーティションキーとソートキーを使用して検索することしかできなかったのに対し、現在ではソートキーの代わりにセカンダリインデックスを使用して検索することもできます。これにより、効率的に実行できるクエリに使用可能な属性の数が増加します。

  • グローバルセカンダリインデックス

グローバルセカンダリインデックス – テーブルとはパーティションキーまたはパーティション/ソートキーが異なるインデックスです。あたかも、もう 1 組のパーティションキーとソートキーを追加できることと同等です。グローバルセカンダリインデックスは、インデックスに関するクエリが、すべてのパーティションにまたがり、表内のすべての項目を対象とする可能性があるため、「グローバル」と見なされます。

グローバルセカンダリインデックスは、一意でない属性をサポートしているため、テーブル内の非キー属性に対するクエリを有効にすることで、クエリの柔軟性が向上します。

プライマリキーが UserId (パーティション) と GameTitle (ソート) で構成されている DynamoDB テーブルに、プレーヤーの情報を保存するゲームアプリケーションを検討してみましょう。項目には、TopScoreTimestampZipCode などの属性名が付けられています。テーブルの作成時、プライマリキーに関する暗黙的なインデックス(プライマリインデックス)を提供します。このプライマリキーにより、DynamoDB は効率的なクエリをサポートし、特定ユーザーのすべてのゲームに関するハイスコアを返すことができます。

ただし、アプリケーションが特定のゲームに関するユーザーのハイスコアを必要とする場合にプライマリインデックスを使用すると、テーブル全体のスキャンが必要になり、効率が悪くなります。その代わり、パーティションキー要素として GameTitle を、ソートキー要素として TopScore を指定してグローバルセカンダリインデックスを使用することにより、アプリケーションは、ゲームのハイスコアを短時間で取得できます。

データモデルの実例

次の図は、いくつかの項目と属性の例を含む、People という名前のテーブルを示しています。

People テーブルについて、以下の点に注意してください。

  1. テーブルの各項目には一意の識別子があります。これは、テーブルの他のすべての項目からその項目を区別するプライマリキーです。People テーブルで、プライマリキーは 1 つの属性 (PersonID) で構成されます。
  2. プライマリキー以外、People テーブルはスキーマレスです。つまり、属性またはデータ型を事前に定義する必要はありません。各項目は、独自の固有の属性を持つことができます。
  3. 属性のほとんどはスカラーです。つまり、1 つの値のみを持つことができます。文字列と数値はスカラーの一般的な例です。
  4. 項目の一部には、入れ子の属性 (Address) があります。DynamoDB は深さが最大 32 レベルの入れ子の属性をサポートします。

以下は、音楽コレクションを継続して追跡するために使用できる、Music という名前の別のサンプルテーブルです。

Music テーブルについて、以下の点に注意してください。

  1. Music のプライマリキーは 2 つの属性 (Artist および SongTitle) で構成されます。テーブルの各項目にはこれら 2 つの属性が必要です。Artist および SongTitle の組み合わせにより、テーブルの各項目が他のすべての項目から区別されます。
  2. プライマリキー以外、Music テーブルはスキーマレスです。つまり、属性またはデータ型を事前に定義する必要はありません。各項目は、独自の固有の属性を持つことができます。
  3. 項目の 1 つに、入れ子の属性 (PromotionInfo) があります。これには、入れ子の他の属性が含まれます。DynamoDB は深さが最大 32 レベルの入れ子の属性をサポートします。

セカンダリインデックスの実例

前に示した Music サンプルテーブルでは、Artist (パーティションキー) または Artist および SongTitle (パーティションキーとソートキー) によってデータ項目にクエリを実行できます。Genre および AlbumTitle によってデータにクエリを実行する場合はどうでしょうか。これを行うには、これらの属性にインデックスを作成し、Music テーブルのクエリと同様に、インデックスにクエリを実行できます。

次の図は、GenreAlbumTitle という新しいインデックスがある Music サンプルテーブルを示しています。

GenreAlbumTitle インデックスについて、以下の点に注意してください。

  1. 各インデックスはテーブルに属します。これをインデックスの基本テーブルと呼びます。前述の例では、Music が GenreAlbumTitle インデックスの基本テーブルです。
  2. DynamoDB はインデックスを自動的に維持します。基本テーブルの項目を追加、更新、または削除すると、DynamoDB はそのテーブルに属するすべてのインデックスの対応する項目を追加、更新、または削除します。
  3. インデックスを作成するときは、基本テーブルからインデックスにコピーまたは射影される属性を指定します。少なくとも、DynamoDB は基本テーブルからインデックスにキー属性を射影します。これは GenreAlbumTitle のケースで、Music テーブルのキー属性のみがインデックスに射影されます。

GenreAlbumTitle インデックスにクエリを実行し、特定のジャンルのすべてのアルバム (たとえば、すべての Rock アルバム) を検索できます。また、インデックスにクエリを実行して、特定のジャンル内のすべてのアルバムのうち、特定のアルバムタイトル (たとえば、タイトルが文字 H で始まるすべての Country アルバム) のみを検索することもできます。

高可用性と耐障害性

Amazon DynamoDB は、データを 3 つの異なるアベイラビリティゾーン(AZ)に同期データレプリケーションを自動的に実行することによって高可用性と耐障害性を保証します。ストレージは、必要に応じて高速な SSD に対して自動的にパーティショニングされます。これにより、個人のコンピューターや設備レベルの障害からもデータを守ることができます。

結果整合性

データの書き込みでは、3 つのレプリケーションのうち 2 つ目に書き込まれた時点で ACK (更新が承認)されます。逆に読み込みでは、デフォルトでは結果整合性(必ずしも一貫性が保証されているわけではなく読み込んだクライアントによっては値が異なることもある)とシンプルなデータベース操作に基づいて膨大なデータに対して低レイテンシーな処理を実現します。なお、オプションで一貫性を保証する読み込み操作もサポートされますが、トレードオフが発生するだけではなく、NoSQL データベースにおける結果整合性だけで十分なケースがほとんどです。

  • 結果的に整合性のある読み込み (デフォルト) – 結果整合性のあるオプションを選択すると、読み込みスループットが最大限に向上します。ただし、結果的に整合性のある読み込みには、最新の書き込み結果が反映されない可能性があります。データの全コピーの整合は通常 1 秒以内に行われます。短時間後に読み込みを繰り返すことによって、更新されたデータが返されます。
  • 強い整合性の読み込み – Amazon DynamoDB には結果整合性のある読み込みに加えて、お客様のアプリケーションまたはアプリケーションの要素が必要とする場合に、強い整合性のある読み込みをリクエストするための、柔軟性と制御が用意されています。強い整合性のある読み込みの結果には、読み込みの前に適切な応答を受け取ったすべての書き込みが反映されています。

スケーリング

Amazon DynamoDB は、完全マネージド型の NoSQL データベースサービスであり、高速で予測可能なパフォーマンスとシームレスな拡張性が特長です。Amazon DynamoDB を使用すると、分散データベースの運用と AWS にスケーリングするための管理負荷を軽減できます。顧客はハードウェアのプロビジョニング、設定と構成、レプリケーション、クラスターのスケーリングなどについて心配する必要がありません。理論的には容量に制限はありません。

プロビジョニングされたスループット

Amazon DynamoDB のインスタンスをデプロイメントする際に、お客様が考慮しなければいけないこと特記事項は、プロビジョニングされたスループットだけです。つまり、データベースに対する Read/Write のスループットのキャパシティをあらかじめ割り当てることです。読み込みが激しいワークロードでは読み込みスループットの値を高めに、書き込みが膨大なワークロードでは書き込みスループットの値を高くします。テーブルサイズを拡大したりプロビジョニングされたスループットを増やすと、データのパーティション化や再パーティション化、追加サーバ容量のプロビジョニングが Amazon DynamoDB により自動的に行われます。プロビジョニングされたスループットの値は Amazon DynamoDB の料金に反映されます。

Amazon DynamoDB の実例

「ソーシャル画像共有アプリ」の例を今後、紹介する予定です。しばらくお待ちください。

Amazon DynamoDB Streams とは

DynamoDB Streams は、DynamoDB テーブルのデータ変更イベントをキャプチャするオプションの機能です。これらのイベントに関するデータは、ほとんどリアルタイムに、イベントの発生順にストリームに表示されます。

各イベントはストリームレコードによって表されます。テーブルでストリームを有効にすると、DynamoDB Streams は次のいずれかのイベントが発生するたびに、ストリームレコードを書き込みます。

  • 新しい項目がテーブルに追加された場合、ストリームはすべての属性を含む項目全体のイメージをキャプチャします。
  • 項目が更新された場合、ストリームは項目で変更された属性について、「前」と「後」のイメージをキャプチャします。
  • テーブルから項目を削除する場合、ストリームは項目が削除される前に項目全体のイメージを取得します。

各ストリームレコードには、テーブルの名前、イベントのタイムスタンプ、およびその他のメタデータも含まれます。ストリームレコードには 24 時間の有効期間があり、その後はストリームから自動的に削除されます。

DynamoDB のユースケース

多くのアプリケーションでは、DynamoDB テーブルに保存された項目の変更を、変更の発生時にキャプチャできると役立ちます。ユースケースは次のとおりです。

  • ある AWS リージョンのアプリケーションが、DynamoDB テーブルのデータを変更します。別の AWS リージョンの 2 番目のアプリケーションがそのデータ変更を読み込み、データを別のテーブルに書き込みます。このとき、元のテーブルと同期されたレプリカを作成します。
  • 人気のモバイルアプリは、1 秒あたり数千件の更新速度で、DynamoDB テーブルのデータを変更します。別のアプリケーションは、これらの更新に関するデータをキャプチャして保存し、モバイルアプリの使用状況メトリクスをほぼリアルタイムで提供します。
  • グローバルなマルチプレーヤーゲームには、データを複数の AWS リージョンに保存するマルチマスタートポロジがあります。各マスターは、リモートリージョンで発生した変更を使用および再現することにより同期されます。
  • アプリケーションは、友人の 1 人が新しい画像をアップロードするとすぐに、グループ内のすべての友人のモバイルデバイスに通知を自動送信します。
  • 新しいお客様がデータを DynamoDB テーブルに追加します。このイベントにより、新しいお客様にようこそメールを送信する別のアプリケーションが起動されます。
  • DynamoDB ストリームを使用して、DynamoDB テーブルに対するすべての変更を Amazon Redshift などのデータウェアハウスツールに同期させて、リアルタイム分析を行うことも可能です。DynamoDB は Amazon DynamoDB Logstash Plugin によって Elasticsearch と統合されるため、開発者が DynamoDB コンテンツにフリーテキスト検索を追加することも可能です。

DynamoDB の詳細

DynamoDB Streams は、DynamoDB テーブル内の項目レベルの変更の時系列シーケンスをキャプチャし、この情報を最大 24 時間ログに保存します。アプリケーションは、このログにアクセスし、データ項目の変更前および変更後の内容をほぼリアルタイムで参照できます。

DynamoDB ストリームは、Amazon DynamoDB テーブル内の項目に加えられた変更に関する情報の順序付けされた情報です。テーブルでストリームを有効にすると、DynamoDB はテーブル内のデータ項目に加えられた各変更に関する情報をキャプチャします。

アプリケーションがテーブル内の項目を作成、更新、または削除するたびに、DynamoDB Streams は変更された項目のプライマリキー属性を付けてストリームレコードを書き込みます。ストリームレコードには、DynamoDB テーブル内の単一の項目に加えれたデータ変更についての情報が含まれています。ストリームレコードが追加情報(変更された項目の前後のイメージ)をキャプチャするようにストリームを設定できます。

DynamoDB と DynamoDB Streams のエンドポイント

AWS では、DynamoDB と DynamoDB Streams に別個のエンドポイントが維持されます。データベースのテーブルとインデックスを使用するには、アプリケーションが DynamoDB エンドポイントにアクセスする必要があります。DynamoDB Streams レコードを読み込んで処理するには、アプリケーションが同じリージョンの DynamoDB Streams エンドポイントにアクセスする必要があります。

要件によっては、アプリケーションは、DynamoDB エンドポイント、DynamoDB Streams エンドポイント、または両方に同時にアクセスできます。両エンドポイントに接続するには、アプリケーションは、DynamoDB 用と DynamoDB Streams 用の 2 つのクライアントをインスタンス化する必要があります。

DynamoDB と AWS Lambda によるトリガー

DynamoDB Streams は AWS Lambda と共に使用してトリガーを作成できます。これは、ストリームで関心のあるイベントが発生するたびに自動的に実行されるコードです。たとえば、会社の顧客情報を含む Customers テーブルがあるとします。新規の各顧客に、歓迎の E メールを送信するとします。そのテーブルでストリームを有効にし、そのストリームを Lambda 関数に関連付けます。Lambda 関数は、新しいストリームレコードが表示されるたびに実行されますが、Customers テーブルに追加された新しい項目を処理するのみです。EmailAddress 属性を持つ項目について、Lambda 関数は Amazon Simple Email Service (Amazon SES) を呼び出してそのアドレスに E メールを送信します。

このシナリオを以下に図で示します。

ストリームの読み込みと処理 … ストリーム、ストリームレコード、シャドーとは

ストリームを読み込んで処理するには、アプリケーションが DynamoDB Streams エンドポイントに接続して API リクエストを発行する必要があります。

ストリームは、ストリームレコードで構成されています。各ストリームレコードは、ストリームが属する DynamoDB テーブル内の 1 件のデータ変更を表しています。各ストリームレコードには、レコードがストリームに発行された順序を反映したシーケンス番号が割り当てられます。

ストリームレコードは、グループ(つまり、シャード)に整理されます。各シャードは、複数のストリームレコードのコンテナとして機能し、これらのレコードへのアクセスと反復処理に必要な情報が含まれています。シャード内のストリームレコードは 24 時間後に自動的に削除されます。

シャードはエフェメラルであり、必要に応じて自動的に作成および削除されます。また、任意のシャードは複数の新しいシャードに分割できます。これもまた自動的に行われます (親シャードが 1 つの子シャードのみを持つ場合もあります)。アプリケーションが複数のシャードからレコードを並列処理できるように、シャードは親テーブルで高レベルな書き込みアクティビティに応じて分割される場合があります。

ストリームを無効にすると、開かれているシャードは閉じられます。

DynamoDB Streams Kinesis Adapter を使用したストリームレコードの処理

シャードには系列 (親と子) があるため、アプリケーションは子シャードを処理する前に、必ず親シャードを処理する必要があります。これにより、ストリームレコードも正しい順序で処理されるようになります。DynamoDB Streams Kinesis Adapter を使用している場合、これは自動的に処理されます。アプリケーションは、シャードとストリームレコードを正しい順序で処理し、新しいシャード、期限切れのシャード、およびアプリケーションの実行中に分割されたシャードを自動的に処理します。

トリガーに加えて、DynamoDB Streams は AWS リージョン内および AWS リージョン間のデータレプリケーション、DynamoDB テーブル内のデータのマテリアライズされたビュー、Amazon Kinesis のマテリアライズされたビューを使用したデータ分析など、数多くの強力なソリューションを可能にします。

DynamoDB クロスリージョンレプリケーション

DynamoDB クロスリージョンレプリケーションを使用すると、DynamoDB テーブル(マスターテーブル)の同一コピー(レプリカ)を複数の AWS リージョンに保持できます。テーブルのクロスリージョンレプリケーションを有効にすると、そのテーブルの同一コピーが別の AWS リージョンに作成されます。そのテーブルに対する書き込みは、すべてのレプリカに自動的に反映されます。

クロスリージョンレプリケーションは、次のような場合に使用できます。

  • 効率的な災害対策 … 複数のデータセンターにテーブルをレプリケートすることで、あるデータセンターで障害が発生した場合に、別のリージョンの DynamoDB テーブルを使用するように切り替えることができます。
  • 読み込みの高速化 … お客様が複数のリージョンに分散している場合に、最寄りの AWS データセンターの DynamoDB テーブルを読み込むことでデータ配信を高速化できます。
  • トラフィック管理の簡単化 … レプリカを使用すると読み取りワークロードを複数のテーブルに分散できるので、マスターテーブルの読み込み容量の消費を抑えられます。
  • リージョン間移行の簡単化 … 別のリージョンにリードレプリカを作成し、そのレプリカをマスターに格上げすることで、そのリージョンにアプリケーションを簡単に移行できます。
  • ライブデータの移行 … リージョン間で DynamoDB テーブルを移行するには、移行元リージョンのテーブルのレプリカを移行先リージョンに作成します。移行元と移行先のテーブルが同期されたら、移行先リージョンに書き込むようにアプリケーションを切り替えます。