Amazon DynamoDB
DynamoDBの概要
OLTP用途（≠OLAP）
- 大規模なパフォーマンス
- 一貫した1桁ミリ秒単位の読み取り/書き取りパフォーマンス
- ほぼ無制限のスループットとストレージ
- 大規模なスケーラビリティ
- 安全性と耐障害性
- 保存時のデータ暗号化
- グローバルレプリケーション
- 最大99.999%の可用性に関するSLA
- サーバレス
- 大規模環境でのパフォーマンスのスケールアップとゼロへのスケールダウンが可能
- ダウンタイムなし、メンテナンス時間なし、メンテナンスウインドウなし
- 従量制料金
- 他のAWSサービスとの統合
- ロギング、モニタリング、分析
- S3を使ったデータのインポート/エクスポート
- OpenSearchへのゼロETLが可能（OLTP→OLAP)
DynamoDBの詳細
データベースのスケーリング
従来のSQLではスケールアップ：スケールアップ限界がある
NoSQLではスケールアウト：理論上、上限なくスケールを拡張できる
通常、スケールアウトには様々な考慮点が発生するが、
DynamoDBでは利用する側はテーブルの操作のみを意識すればよく、
サーバの必要数やスケールなどについてマネージドで実施される
DynamoDBテーブル
TableにはItemsがある（RDBで言うところのレコード）
- Partition Key
- 指定は必須
- キーによる値へのアクセス
- データ位置の決定
- Sort Key
- 指定はオプション
- モデルに対して1：Nの関係
- 豊富なクエリ機能を実現
アイテムの分散（happy path）
アイテムはパーティションキーの順番には並んでおらず、
コンシステントハッシング（パーティションキーに対してHash関数をかけて分散）で分散されている
レプリケーション
データは常に1つのデータを3つのAZにコピーして保持している
スケールするサービス
- リクエストルーター
- ステートレスであり、どのルーターでも同じ動作をする
- 認証、認可、キャパシティを見てストレージへリクエストを渡す
- ストレージノード
- 1.5秒間隔でハートビートしており、リーダーとレプリカが即時に入れ替われる
整合性
DynamoDBは各レプリカは結果整合性となる
- 強い整合性での読み込み：リーダーノードにのみアクセスする
- 結果整合性での読み込み：リーダーかレプリカのどちらかにアクセスする(読み込みキャパシティコストを半分で利用できる)
Global Secondary Index
すべてのデータのスキャンが必要な場合、非キー属性に対するクエリの速度を上げる目的で利用
- ログプロパゲーター
- Index用のストレージノードへログを配信を行う
- バックエンドでIndex用のストレージノードの削除やPUTなどを実行する
Auto Admin
水平スケーリングにまつわる様々な動作を自動化している（DynamoDBの自動化されたDBA）
- テーブルとインデックスの作成
- テーブルとインデックスのプロビジョニング
- パーティションの分割
- パーティションの修復
キャパシティ管理
スループットを管理するトークンバケット
リクエストを処理できるだけのリソースをユーザーが持っているかを下記のトークンバケットにより確認する
- テーブルのトークンバケット
- それぞれのストレージノードでのトークンバケット
プロビジョンドモードとオンデマンドモード
- プロビジョンドモード：安定したワークロード
- 予めコンソール等で設定することが可能
- リザーブドキャパシティの利用が可能
- オンデマンドモード：予測不可能なワークロード
- 自動でキャパシティ計画、プロビジョニングが行われる
- 実行した読み取りと書き込みに対してのみ料金が発生
- 以前のピークの２倍までスケール可能
- スケールダウンが自動で行われることはない
Adaptive Capacity
- トラフィックの多いアイテムの分離は自動で行われる
- 一部のアイテムに負荷が集中した場合、パーティションを自動で分割
- さらに集中する場合、アイテム自体を分割