高速化とイベント駆動という「裏方強化」の話
DynamoDBは、そのままでも十分速い。
が、もっと早くなるらしい…
DAXは“近道を用意する”仕組み
DAX（DynamoDB Accelerator） を有効にすると、
DynamoDBの前段にインメモリキャッシュが置かれる。
奥の倉庫（DynamoDB）まで毎回取りに行くのではなく、
受付横の棚（DAX）からサッと渡される、そんな構図。
- 読み取り専用の高速化
- レスポンスはミリ秒 → マイクロ秒単位
- アプリ側の実装変更は最小限
性能だけ見るとかなり魅力的だけど、
この棚、とにかく高い。
需要が急に増えたから一時的に使う、というよりは、
「常に大量アクセスが来る前提」の現場向け。
スパイク対策というより、常設の近道という印象に落ち着いた。
DynamoDB Streamsは“動き出す合図”
一方で、DynamoDB Streams は速さの話ではない。
テーブルへの
- Put
- Update
- Delete
こうした変更をきっかけに、
「今、何か起きたよ」というイベントを外に流す仕組み。
この通知を受けて、Lambdaが自動で動く。
DBが黙って保存するだけでなく、
自分から合図を出す側に回る。
イメージとしては、
- DynamoDB：受付
- Streams：呼び出しベル
- Lambda：裏方スタッフ
誰かが来た瞬間に、
裏で処理が走り出す。
DynamoDBはただの保管場所じゃなかったんだ！
SAA的に押さえておきたいポイント
ここで、試験目線でも一度整理しておく。
DAXが向いている場面
- 読み取り頻度が非常に高い
- レイテンシがビジネス要件に直結する
- キャッシュ整合性をある程度割り切れる
「RDS + ElastiCache」のDynamoDB版、
くらいの立ち位置で覚えると混乱しにくい。
DynamoDB Streamsが効いてくる場面
- DB変更をトリガーに処理したい
- 非同期で後続処理を流したい
- イベント駆動アーキテクチャを組みたい
SQSやEventBridgeと並んで、
「疎結合を作るための部品」という印象が強くなった。
速くするか、動かすか
DAXとStreamsは、
同じDynamoDBの機能だけど、
向いている方向はまったく違う。
- DAX：速く返す
- Streams：次を動かす
ここを混ぜて考えると混乱するけれど、
役割を分けると急に見通しが良くなった。
この辺りでようやく、
DynamoDBが「ただのNoSQL」ではなく、
システムの起点にもなれる存在だと感じ始めた。
まだ設計で使いこなせる段階ではないけれど、
少なくとも、
「速いDB」以上のものが詰まっているのは分かってきた。