はじめに
試験勉強した際のメモを自分用に記事化。
内容は公式や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機器が単位時間あたりに処理できるデータ量のこと
おわりに
引き続き追記します！
以上です。