DynamoDBの設計｜基礎を学ぶ - ゆめさくコード

このレッスンでできるようになること

シナリオの中から「キー設計の問題」「キャッシュの問題」「容量モードの問題」を切り分けて、DynamoDB まわりの選択肢を正しく振り分けられるようになります。

要件の文から入る

あるゲーム会社がプレイヤーの状態を DynamoDB に保存しています。テーブルのパーティションキーはゲームのタイトル ID で、人気タイトル1本にアクセスが偏っています。負荷が高い時間帯にスロットリングが発生し、一桁ミリ秒の読取応答を保てません。またイベント開催時だけ書込が10倍に跳ね、次のイベントの規模は事前に読めません。

この文には論点が3つ埋まっています。偏りはキー設計、応答時間は読取キャッシュ、読めない急増は容量モードです。DynamoDB の設問は、症状の言葉がそのまま打ち手に対応します。

パーティションキーの設計

DynamoDB はパーティションキーのハッシュ値でデータを分散します。だからキーの値の種類が少なかったり、特定の値に集中したりすると、一部のパーティションだけが熱くなってスロットリングが起きます。これがホットパーティションです。

判断は単純で、値がばらけるキーを選ぶことに尽きます。上のシナリオならタイトル ID ではなくプレイヤー ID をパーティションキーにし、タイトル ID はソートキーや属性に回します。値の種類がどうしても少ないときは、キーの末尾に一定範囲の乱数を足して分散させる書き方もあります。

また、パーティションキー以外の属性で検索したいという要件が出たら、グローバルセカンダリインデックスを追加します。「テーブル全体をスキャンして絞り込む」という選択肢は、動きはしますが読取を大量に消費するので、設問ではほぼ誤答です。

DAX とキャッシュの線引き

打ち手	効くもの	選ぶ要件語
DAX	DynamoDB の読取だけを、マイクロ秒台まで速くする	「アプリを改修せずに読取を高速化」「同じ項目が繰り返し読まれる」
ElastiCache	任意のデータをキャッシュする。取得と失効はアプリが書く	「計算結果やセッションもまとめて置きたい」
読取キャパシティの追加	スロットリングの解消	「容量不足で失敗している」

DAX は DynamoDB 専用のキャッシュで、既存の呼び出しをほぼそのまま使えるのが利点です。「アプリケーションの変更を最小限に」という制約が付いた読取高速化の設問では、DAX が正解になりやすいと覚えてください。逆に、書込を速くしたい、という要件には効きません。キャッシュは読取の話です。

容量モードの選び方

モード	向く状況	要件語
プロビジョニング済み	負荷の形が読めて安定している	「一定の負荷」「予測できるトラフィック」
オンデマンド	予測できない・急に跳ねる・新規で実績がない	「事前に見積もれない」「スパイクがある」「新規サービス」

プロビジョニング済みでも Auto Scaling を付ければ追従できますが、追従には多少の時間がかかります。「一瞬でゼロから跳ね上がる」「規模が事前に読めない」と書かれていればオンデマンドです。

要件語から構成への対応表

要件の言い回し	選ぶもの
特定のキーにアクセスが偏る	パーティションキーの見直し(分散するキーにする)
キー以外の属性で検索したい	グローバルセカンダリインデックス
アプリを変えずに読取をさらに速く	DAX
トラフィックが予測できない	オンデマンドキャパシティ
項目の変更を他の処理へ流したい	DynamoDB Streams
古いデータを自動で消したい	有効期限(TTL)属性

よくある引っ掛け

引っ掛け1、ホットパーティションをキャパシティの追加で解こうとする。 全体の容量を増やしても、偏りが解消しなければ熱いパーティションは熱いままです。「特定のキーに集中している」と書かれているのに容量を足す選択肢は落とします。

引っ掛け2、書込の高速化に DAX を持ち出す。 DAX は読取キャッシュです。書込のレイテンシを下げる要件には効きません。

まとめ

偏りの症状はキー設計の問題。まず分散するパーティションキーを疑う
キー以外での検索はグローバルセカンダリインデックス。スキャンで解かない
「アプリを改修せずに読取を速く」は DAX
「予測できない」「急に跳ねる」はオンデマンドキャパシティ