DynamoDBについて勉強
AWS 認定ソリューションアーキテクト ? アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。
今回もこの本を一読したうえで機能単位で勉強していく。
- DynamoDBとは
- ユースケース
- DynamoDBのデータ保存
- オンデマンドバックアップ
- DynamoDB Accelerator(DAX)
- DynamoDB Auto Scaling
- DynamoDB Streams
- グローバルテーブル
- 一時的なアクセス集中に耐えるために
DynamoDBとは
マネージドであり、キーバリュー型でデータを簡易に操作することができる機能。リージョンサービスのため、特定のAZ内で利用等はできない。（DynamoDBをマルチAZ構成するというものがそもそも不可能）
NoSQLデータベースサービス
NoSQLとは非DBMSの総称。通常のテーブルデータなどの構造データに加え、以下もサポートしている。
テスト的にはDynamoといえば非構造データ・半構造データであるということがメイン且つ、ユーザIDの情報が格納されるという話でよく出るイメージ。
逆にできないこと（向かないこと）は
- JOINやCOMMITなどの通常のRDBSで可能なもの
- 検索や結合など詳細な処理
- 大量のデータ読み書き（読み書きに対してコストがかかる）
キーバリューストア型
「数値」と「文字」でワンセットで保存される。文字は、単純に文字列だけではなく、JSONのような半構造データもいける。
ユースケース
DynamoDBのメリットは高い信頼性とパフォーマンスを維持できる点。主なユースケースは
- 大量データの収集・蓄積・分析するためのデータベースや、Hadoopとの連携などのビッグデータ
- データの高速処理が必要なアプリケーション
- 多数のユーザが一度にアクセスするようなアプリケーション処理
- ユーザ情報やゲーム、広告などのユーザ行動向けデータベース
- ユーザIDごとの複数の行動履歴管理などの単純に情報を蓄積するもの
- モバイルアプリのバックエンドや、バッチ処理時のロック、フラッシュマーケティング、ストレージのインデックスなど、バックエンドのデータ管理
モバイルゲームや広告配信システム、IoTのセンサーデータのデータベースなど可用性、大量データ処理（構造データ以外）に向いている。
ただし、複数テーブルの結合等通常のDBMSが得意なことは、DynamoDBは得意ではないので注意。
またアクセス頻度の低い古いレコードの保存は設計パターン上推奨されていない。
通常、データ取り込みシステムには以下が必要です。
・現在の時間に関連する新しいレコードを取り込むための高い書き込みスループット。
・最近のレコード用の低いスループット。
・古いレコード用の非常に低いスループット。
このようなイベントをすべて単一の DynamoDB テーブルに格納する場合、ホットパーティション (最新のレコード) とアクセス頻度の低いパーティション (古いレコード) があります。
アクセス頻度の低いパーティションは、プロビジョニングされた書き込み容量を、新しいレコードを保存しておきたいホットパーティションから逸らしてしまうため、最適ではありません
Amazon DynamoDB の大量の時系列データの設計パターン | Amazon Web Services ブログ
DynamoDBのデータ保存
3ヶ所のアベイラビリティゾーンで保存される。*1結果整合性モデル
S3と同様に結果整合性モデルを採用している。結果整合性とは、途中で整合性が崩れた状態になるが、十分な時間がたったら最終的には整合性が取れた状態になる。
即時反映はされない。
何故なら上で書いているように3ヶ所のアベイラビリティゾーン書き込みに行くため、処理完了までに多少なりとも時間差が発生する。
また、書き込み成功判断はアベイラビリティゾーン2ヶ所に書き込みが成功した場合のため、データのreadとwriteが多数行われると、情報の一貫性が取れていないアベイラビリティゾーンから取得しに行く可能性があるため、一貫性を取っていない。
ただし、それだとDBとして使い勝手が悪いので、一貫性を保ちたいのであれば、「Consistent Read」（読み取り一貫性）オプションが提供されている。
このオプションを利用することで書き込みが反映された最新データを参照するようになる。
使用するインデックス
ハッシュキーやレンジキー（複合キー）では検索条件を満たさない場合に利用する。インデックスを使用することで検索速度は上がるがその分課金も増える。
オンデマンドバックアップ
バックアップを取得する方法として、AWS Data Pipelineを使ったデータのエクスポート、インポートを使用することで実施が可能となる。任意のタイミングで利用叶おうな長期間データ保存用のバックアップとなる。
AWS Data Pipeline を使用して、DynamoDB テーブルから Amazon S3 バケット内のファイルにデータをエクスポートできます。
コンソールを使用して、Amazon S3 から同じまたは異なる AWS リージョンにある DynamoDB テーブルにデータをインポートできます。
AWS Data Pipeline を使用して DynamoDB データをエクスポートおよびインポートする - Amazon DynamoDB
異なるリージョンからでもインポートができるというのがポイントだと思う。
DynamoDB Accelerator(DAX)
DynamoDB用のインメモリキャッシュ。DynamoDBの間にDAXというキャッシュクラスターを設置することができるため、DynamoDBへのアクセスを行う前にキャッシュから情報を取得するということが可能になる。
キャッシュを置くことで1秒当たり100万回単位のリクエストの応答時間を数ミリ秒に短縮することが可能。
運用上アプリケーションの複雑性を減少させて容易に導入可能。
DynamoDB Auto Scaling
今回対応したDynamoDBのAuto Scalingは負荷に応じてwrite capacity units（書き込み容量ユニット）とread capacity units（読み込み容量ユニット）のスループットを上下できるものとなります。
[新機能] Amazon DynamoDBでAuto Scalingが可能に！ | Developers.IO
読込と書込の負荷をスケールできる機能。
読取（書込）の負荷が高い場合にどうするべきかというときに考え付く選択。
あるデータにアクセス集中するみたいな感じだとDAXを採用したほうが良い。
DynamoDB Streams
DynamoDBに対して追加、変更、削除の履歴をキャプチャできる機能。過去24時間以内のデータ変更履歴を保持。24時間を経過すると削除される。
操作が実施された順番でデータがシリアライズ（並ぶ）される。
ハッシュキーに基づいた変更は正しい順番で保存されるが、ハッシュキーが異なる場合は順番が前後する可能性がある。
inputはS3やKinesisやユーザのアプリケーションが多い。
DynamoDB のテーブルに対するすべての更新(Put, Update, Delete)が直近の24時間保持され、API 経由でアクセスできるようになります。
DynamoDB のテーブルの更新などのイベントがフックできるため、これをきっかけに別なテーブルに更新をかけたり、SNS で通知したり、用途に応じてさまざまな処理を行うことができます。
AWS Lambda と Amazon DynamoDB Streams を連係する | Developers.IO
ユースケース
データ更新をトリガーとしたアプリケーション機能やレプリケーションに活用が可能。DynamoDB Sreamsの使い所は、クロスリージョンレプリケーションやゲーム・ソーシャルサイト等でのユーザの集計・分析などのための非同期処理などとなります。
あるいはユーザが新しい写真をアップロードするとすぐにサークル内のすべての友人のモバイルデバイスに自動的に通知するモバイルアプリケーションの構築などが考えられます。
DynamoDB Streams - Qiita
クロスリージョンレプリケーション
DynamoDB Streamsによる変更のキャプチャをトリガーとして、クロスリージョンレプリケーションを実現する。
AWS リージョン間で自動的にレプリケートされるテーブルを作成できます。複数書き込みの完全にサポートされます。これにより、レプリケーションプロセスを管理することなく、グローバルユーザーベース用に高速かつ大規模にアプリケーションを構築できます。
クロスリージョンレプリケーション - Amazon DynamoDB
データ更新をトリガーとしたアプリケーション機能
データ更新に応じて通知処理などアプリケーション処理の実行などができる。
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern from Amazon Web Services Japan
グローバルテーブル
リージョン間で同期されるマルチマスターテーブルを作成可能。クロスリージョンレプリケーションに該当するもの。強い整合性モデルは使用不可となる。
一時的なアクセス集中に耐えるために
DynamoDBに対して一時的なアクセス集中が発生する場合対応できるケースとしては、- DynamoDB Accelerator(DAX)を利用
- ElastiCache を利用
- SQS→DynamoDBの構成にする
- AutoScaling→DynamoDBの構成にする
DAXとElastiCacheは基本的に高いため、費用対効果を求めるのであればSQSとAutoScalingで対応する。
SQS→DynamoDBの構成にする
大量データ処理時に知っておきたいAmazon DynamoDB活用テクニック4選 (2/3)：大規模プッシュ通知基盤大解剖（2） - ＠IT より引用
上記のようにDynamoDBの前にSQSをセットすることで、キューイング処理されて負荷を下げることが可能になる。
AutoScaling→DynamoDBの構成にする
次のステップは、前の図に示された Auto Scaling のプロセスをまとめたものです。
- DynamoDB テーブルの Application Auto Scaling ポリシーを作成します。
- DynamoDB は消費されたキャパシティーメトリクスを Amazon CloudWatch に発行します。
- テーブルの消費されたキャパシティーが一定期間中にターゲット使用率を超える（または下回る）と、Amazon CloudWatch はアラームをトリガーします。コンソールのアラームを表示し、Amazon Simple Notification Service (Amazon SNS) を使用して通知を受けることができます。
- CloudWatch アラームは Application Auto Scaling を呼び出してスケーリングポリシーを評価します。
- Application Auto Scaling は UpdateTable リクエストを発行し、テーブルのプロビジョニングされたスループットを調整します。
- DynamoDB は UpdateTable リクエストを処理してテーブルのプロビジョンドスループット性能を動的に増減し、ターゲット使用率に近づけます。
上記のようにCloudWatch AlermからAutoScalingを呼び出して、DynamoDBの読み込み・書き込みキャパシティを一時的に上げたり下げたりする（UpdateTable リクエスト）ことが可能。
