AWS再入門ブログリレー DynamoDB編

2019.07.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2019』の21日目のエントリです。

このブログリレーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWSをこれから学ぼう!という方にとっては文字通りの入門記事として、またすでにAWSを活用されている方にとってもAWSサービスの再発見や2019年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

では、さっそくいってみましょう。本日のテーマは『Amazon DynamoDB』です。

目次

Amazon DynamoDBとは

サービス名にDBとある通りデータベースです。2012年1月にローンチされたサービスで、2012年3月から東京リージョンで利用可能となっています。

AWSではAmazon RDS、Amazon DocumentDB、Amazon Redshiftなど様々なデータベースサービスがあります。それぞれ特色がありますが、DynamoDBはNoSQLデータベースと言われるものになります。NoSQLといっても様々なタイプがありますが、DynamoDBはkey-valueデータベースおよびドキュメントデータベースになります。今ではAmazon DocumentDBがありますので、ドキュメントデータベースの役割はそちらが担うことになるでしょう。

key-valueデータベースとは

key-valueデータベースとは名前の通り、keyとvalueを対で保存するデータベースです。例えばユーザの情報を保存するテーブルを例にすると、ユーザを一意に識別するユーザIDがkey、ユーザ名などがvalueにあたります。このように非常にシンプルな構造になっているため高速な読み書き、スケーリングが可能となっています。RDBMSのようなテーブルをJOINするといったことはできません。

構成要素

  • テーブル スキーマやデータベースというテーブルをまとめる概念はありません。いきなりテーブルから作成していきます。
  • 項目
  • RDBMSでいうところの行、レコード
  • テーブルは項目を持つ
  • 属性
  • RDBMSでいうところの列
  • 項目は属性を持つ
  • スキーマレスなので項目ごとに異なる属性を持つことができ不揃いでも問題ありません。とは言っても何の考えもなしに属性を作成していると管理しきれないことにもなるので、スキーマ設計をすることをおすすめします。
  • プライマリキー
  • 項目を一意に識別するキー。テーブル内の2つの項目が同じプライマリキーを持つことはありません。
  • プライマリキーには次の2種類が存在
  • パーティションキー パーティションキーのみでプライマリキーを構成し、どのパーティションにデータを保存するか決定するものです。
  • パーティションキーとソートキー これは上記のパーティションキーに加えてソートキーも含めて一意とするものです。2つの組み合わせで一意になればよいのでパーティションキーの重複が許容されます。ソートキーによりソートされた状態でデータを保存しておくことができます。ソートされているのでクエリ時に絞り込みの条件とすることができます。
  • パーティションキー データの分散に使用されるキー
  • パーティション パーティションキーのハッシュ値に基づいてデータを格納する領域。DynamoDBはパーティションを分割することで高いパフォーマンスを実現しています。

その他にも構成要素はありますが、入門編のこの記事では割愛いたします。詳細は次のドキュメントをご参照ください。

DynamoDB コアコンポーネント - Amazon DynamoDB

パーティション

データを保存する領域でDynamoDBによって自動で管理されます。パーティションキーのハッシュ値によってどのパーティションにデータを保存するかを決定します。これによりパーティションキーを指定してデータを取得しようとしたとき、どのパーティションにデータが保存されているか瞬時にわかり、一気にデータの刈り込みができるようになています。内部ではさらに高度な機能が動いており、パーティション機能のおかげでデータが増えても10ミリ秒以下のレイテンシが維持されるようになっています。

読み込み/書き込みキャパシティーモード

DynamoDBは高速なデータベースということをうたっていますが、その性能を決定するのがキャパシティというものです。どのくらいの処理能力が必要か利用者が指定できるようになっています。現在、キャパシティの指定は次の2つのモードがあります。

プロビジョニングモード

1秒あたりの読み込みと書き込みの回数を指定します。確保したキャパシティに応じて課金が発生します。Auto Scalingを使用することができ、トラフィックの変動によりキャパシティを自動的に調整することができます。Auto Scalingであってもトラフィックのスパイクには対応できないので、そのような場合は後述のオンデマンドモードが有効です。プロビジョニングモードは次の条件に該当する場合、有効なオプションです。

  • アプリケーションのトラフィックが予測可能である
  • トラフィックが行ってした、または徐々に増加するアプリケーションを実行する
  • キャパシティの要件を予測してコストを管理できる

オンデマンドモード

オンデマンドモードでは事前にキャパシティを設定しません。この場合、使用した分だけ課金されます。

トラフィックに応じて瞬時にキャパシティが拡張、縮小されます。これを聞くとオンデマンドモード一択のように思えますが、料金的にプロビジョニングモードと比べて割高になります。オンデマンドモードは次の条件に該当する場合、有効なオプションです。

  • 不明なワークロードを含む新しいテーブルを作成する
  • アプリケーションのトラフィックが予測不可能である
  • わかりやすい従量課金制の支払いを希望する

バックアップと復元

バックアップと復元は次の2つの方法がサービスとして提供されています。

オンデマンドバックアップ

アーカイブ目的で任意のタイミングで実行するバックアップ機能です。AWS Backupを使用すると簡単に日次バックアップの取得が実現できます。バックアップや復元を実行しても、テーブルのパフォーマンスや可用性に影響はありません。

バックアップはテーブルのサイズに関わらず数秒で完了します。復元にかかる時間ですが、必ずしもテーブルのサイズに関連しているわけではありません。詳細は「復元」をご参照ください。

復元する場合、既存のテーブルに上書きすることはできないので、元のテーブルを削除するか別名で復元する必要があります。

ポイントインタイムリカバリ

ポイントインタイムリカバリ (PITR) 有効化すると継続的なバックアップを自動で取得し、過去35日間の任意の日時 (秒単位で指定可能) に復元可能です。アプリケーションの不具合や操作ミスによる上書き、削除から復元することができます。この機能を有効にしてもパフォーマンスや可用性に影響はありません。

35日間というのは固定されており変更不可ですので、もっと前に戻したいなどの要件がある場合は、オンデマンドバックアップを併用する必要があります。バックアップから復元する場合は既存のテーブルとは別のテーブルに復元する必要があります。

可用性と耐久性

  • データは3箇所のAZに保存される
  • ストレージは無制限
  • SLA 99.99%

DynamoDB 適合性ガイドライン

DynamoDBを評価の方法、移行を計画する方法をベストプラクティス含めてAmazon Web Services ブログに記事がありますのでそちらをご参照ください。

Amazon DynamoDB がニーズに合うかどうかを判断し、移行を計画する方法 | Amazon Web Services ブログ

その他の機能

DynamoDB ストリーム

DynamoDB ストリームとはテーブルへの追加、変更、削除を検知しストリームへリアルタイムに書き込みます。ストリームを読み込んで処理するには、アプリケーションが DynamoDB ストリーム エンドポイントに接続します。または、ストリームとLambdaを関連付けることによって、ストリームにデータが書き込まれるとLambdaが起動されイベントを処理することができます。

DynamoDB ストリームのユースケースは次のような場合です。

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

参考:DynamoDB ストリーム を使用したテーブルアクティビティのキャプチャ - Amazon DynamoDB

Amazon DynamoDB Accelerator

Amazon DynamoDB Accelerator (以下、DAX)とはフルマネージドのキャッシュサービスでDynamoDBの前段に置かれます。EC2、RDSの間にElastiCacheを置くのと似ています。通常、DynamoDBは1桁ミリ秒以下の応答時間ですが、DAXを利用するとマイクロ秒単位での応答が可能になります。

ユースケースとしては応答時間が非常に短いことが要求されるアプリケーションや、同じデータを短い期間に大量に読み込むアプリケーションなどの場合に有用です。

Amazon DynamoDB グローバルテーブル

グローバルテーブルとはマルチリージョンかつマルチマスターのデータベースを提供する完全マネージドなサービスです。ユースケースとしてはグローバルにアプリを提供しておりユーザが分散している場合やディザスタリカバリ要件がある場合などに利用できます。

テーブルを作成し、グローバルテーブルの設定を行うと、指定したリージョンに同一のテーブルが作成されます。他のリージョンとのデータは自動でレプリケートされます。グローバルテーブルで、新しく書き込まれた項目は、通常数秒以内にすべてのレプリカに伝達されます。作成時の注意点としてはテーブルが空である必要があります。データが入っているテーブルには設定できません。

DynamoDBでは、整合性のある読み込みをリージョン間で行うことはできません。データを書き込み、別のリージョンでそのデータを読み込んだ時に最新のデータが反映されていない場合があります。

書き込みの競合についてですが、ほぼ同時に異なるリージョンで同じデータに対して書き込みを行った場合、グローバルテーブルは最新の更新日時のデータを採用します。

次のブログを参考に簡単にこの機能を試すことができます。

DynamoDB Global Tableを試す #reinvent | DevelopersIO

DynamoDB Global Tableを試す #reinvent

まとめ

まとめるとAmazon DynamoDBは完全マネージド型、マルチリージョン、マルチマスタのデータベースで、レイテンシーを10ミリ秒未満に維持でき、組み込みのセキュリティ、オンデマンドバックアップと復元、ポイントインタイムリカバリ、インメモリキャッシュを備えているサービスになります。

明日 (7/31) はもこの 「Amazon SQS」編 です。お楽しみに!!

参考情報