DynamoDBは「使った分だけ払う、目にも留まらぬNoSQL」 ⚡
キャパシティモードは「都度払い」か「月極」か
DynamoDBは読み書きの処理量と料金がガッツリ連動している。
-
オンデマンドモード
リクエスト数に応じた従量課金 -
プロビジョンドモード
事前に1秒あたりの読み書き量（キャパシティユニット）を設定
「読み放題プランか、使った分だけ払うプランか」という、
スマホの通信料金プランみたいな二択。
キャパシティユニットは「1秒あたりの体力」
プロビジョンドモードの単位。
リザーブドキャパシティなら100ユニット単位で1〜3年契約も可能。
-
RCU（Read Capacity Unit）
1RCU = 4KB × 2 / sec、初期値5 -
WCU（Write Capacity Unit）
1WCU = 1KB × 1 / sec、初期値5
読むのと書くのとでは、そもそも体力の消費量が違うという前提がある。
パーティションは「単一障害点をつぶす仕組み」
3つのAZへレプリケーションすることで、障害時の可用性を担保している。
これは単一障害点（SPOF）を排除するための設計であり、
パーティション自体の管理はAWSが担当してくれる。
「どこか一箇所がコケても全体が死なない」ように、
最初から複数の逃げ道が用意されている構造。
バックアップは「自動の保険」と「手動の保険」
-
ポイントインタイムリカバリ（PITR）
自動、過去35日まで秒単位で復元可能 -
オンデマンドバックアップ
手動、マネコンやAPIから完全バックアップを取得
普段は自動の保険（PITR）にお任せしつつ、ここぞという時だけ手動で完全版を残す、
という二段構えのイメージ。
S3へのエクスポート
PITRからS3へエクスポート可能。
ただし事前にPITRの有効化が必須なので、後から気づいても間に合わない。
一貫性の話は「速さ」と「正確さ」のトレードオフ
自動レプリケートの完了をもって処理完了扱いになるため、
一時的に古い情報を参照してしまう可能性がある。
-
結果整合性のある読み込み（デフォルト）
直後は更新が反映前の可能性があるが、時間経過で整合 -
強力な整合性のある読み込み
常に最新データを取得できるが、レイテンシーとコストが高い
「ちょっと古くてもいいから速く」か「多少待ってでも正確に」かを選ばせてくれる仕組み。
自動スケールは「何もしなくていい」が売り
データ量・トラフィック量に応じて自動でスケールアウトする。
ユーザー操作は一切不要、ダウンタイムもなし。
「気づいたら勝手に大きくなっていた」という、
運用側からすると一番ありがたいタイプの機能。
DynamoDB Streamsは「直近24時間の目撃者」
直近24時間のDB更新をログとして保存し、イベント駆動の処理に利用できる。
DBが変化に気づいて、自分から周囲に「今、更新あったよ」と教えてくれる仕組み。
DAX（DynamoDB Accelerator）は「専属の速達係」
DynamoDB向けのインメモリキャッシュ。
レスポンスをミリ秒からマイクロ秒まで短縮できる。
- 暗号化はクラスター作成時に「保管時」「転送時」を選択
- 途中から暗号化したい場合は一度クラスターの削除が必要
「後からやっぱり暗号化したい」は通用しない、という地味に刺さる注意点。
グローバルテーブルは「世界中に配置された分身」
DBを複数リージョンで運用できるサービス。
- 自動でレプリケーションされる
- 地理的に近いDBへアクセスが誘導される
- レプリケーション先のリージョンはユーザーが指定可能
「一番近くにいる分身が対応してくれる」ような感覚で、
グローバル展開のアプリと相性がいい。
まとめメモ ✍️
- キャパシティモードは「都度払い」か「月極」かの選択
- パーティションで単一障害点をあらかじめ排除
- バックアップは自動（PITR）と手動の二段構え
- 一貫性は「速さ」と「正確さ」のトレードオフ
- 自動スケールで運用の手間がほぼゼロ
- StreamsとDAXでイベント駆動・高速化にも対応
- グローバルテーブルで世界中に分身を配置できる
NoSQLというと自由すぎて掴みどころがない印象だったが、
裏側の作り込みは意外とガチガチに設計されているというのが今回の発見。