ソリューションアーキテクト対策_DynamoDB篇

はじめに

試験勉強した際のメモを自分用に記事化。
内容は公式やBlack Beltの写経ですので目新しいことはありません

DynamoDB

DynamoDBについて①

10KBとかの小規模データを保存・処理するのはNoSQLが最適。よってDynamoDBを選ぶのがベストプラクティス。
そしてスケーラブルでもある。
ちなみにDynamoDBはセッションデータやユーザー設定、メタデータなどを格納するのに最適なNoSQLDBとのこと。

DynamoDBについて②

リアルタイムのデータ集計処理に向いてる。
┗ AWS AppSync(アプリデータをリアルタイムで保存・同期するサービス)と組み合わせてリアルタイム処理機能を実装することが可能。
┗ EMR(Apache Hadoopを実行できるサービス)と組み合わせて、Dynamoに蓄積されたビッグデータを解析処理することができる。
┗ アプリケーションのWebセッションを管理することも可能。

DynamoDBのスケーリング

DynamoDBはオートスケーリングを設定できる。テーブルを作成するとデフォルトで有効化となる。

また、DAX(DynamoDB Accelerator)を有効化することで、キャッシュを利用したパフォーマンスが大幅に向上する。
ただしキャッシュを利用したキャッシュDBは高コストであるため、コスト最適という意味ではスケーリングが望ましい。
DAXを有効にしたDAXクラスターは、1つのみのプライマリノードと、0〜9個のリードレプリカノードを構成することができる。

以下はおまけ。

• DynamoDBグローバルテーブル
  マルチリージョンにマルチマスターデータベースをデプロイするための完全マネージド型のソリューション。
  高い冗長性を実現できる。

DynamoDBストリーム

DBに保存されたデータに対して追加・変更・削除が発生した時に履歴を保持する。通知も作れる。
保存期間は24h。超えたら削除される。
なのでメタデータの保存に最適。

DynamoDBのデータ不整合について

DynamoDBはデータを読み込む時、以下の整合性を選択できる。

• 結果整合性モデル
  読み込みスループットが最大限に向上する。ただし最新の書き込み結果が反映されない可能性がある。

• 強い整合性モデル
  読み込み前に適切な応答を受け取り、全ての書き込みが反映された状態となる。

DynamoDBがスパイクした時の改善策

コスト効率を加味する場合

アプリケーションのバックエンドのデータレイヤにDynamoDBを設定している場合。
SQSとLambdaを連携してDynamoDBへの書き込み処理を並列化することでスパイクを改善できる。

SQSキュー内のメッセージを処理する時は、Lambda関数を使用する。
Lambdaイベントソースマッピングは標準のキューおよびFIFOキューと連携することが可能。
SQSを使用し、タスクをキューに送信して非同期な処理を行うことで、アプリケーションの1つのコンポーネントからタスクを任せることができる。

DynamoDB DAX

DynamoDBは元々スケーラブルであるため、DAXを使用することで性能を向上させることができる。
ただしDAXはインメモリDBを利用するためコストが高い。
そのためSQSキューによって処理を分散する方が費用対効果は高い。

スパイクを改善できない対応策

グローバルインデックス(※1)を作成しつつDynamoDBをマルチAZに展開することで可用性を高めることはできるが、スパイクの改善には至らない。

(※1)インデックスに関するクエリが全てのパーティションに跨り、表内の全ての項目を対象とする可能性のあるクエリのこと

DynamoDBをプロビジョンドスループット性能(※2)へ変更することで、予測可能なデータ処理に対する割り当てを変更することが可能だが、スパイクの改善には至らない。

(※2)テーブルごとの読み取り(Read)と書き込み(Write)に対して、必要なスループットキャパシティを割り当てること。
スループットはコンピュータやNW機器が単位時間あたりに処理できるデータ量のこと

おわりに

引き続き追記します！
以上です。