DynamoDB オンデマンド vs プロビジョンドキャパシティ
DynamoDB はスループットを2通りに課金します。オンデマンドはリクエストごとに課金し、 使った分だけ支払い、ゼロまでスケールします。プロビジョンドは、使っても使わなくても 支払う固定の読み取り/書き込みレートを、はるかに低い単価で予約します。誤ったほうを選ぶのは、 払いすぎる最も簡単な方法の1つです。
監査ログがこの選択を具体的にします。監査の書き込みは急増的で予測できません。夜間は 静かで、顧客が一括操作を実行したりインシデントが数千件のイベントを生んだりすると洪水に なります。そのトラフィックの形こそが、決定のすべてです。
DynamoDB はオンデマンドとプロビジョンドキャパシティのどちらを使うべきですか?
オンデマンドはリクエストごとに課金してゼロまでスケールするので、急増する、新しい、あるいは 予測できないトラフィックには安全なデフォルトです。プロビジョンドは固定の読み取り/書き込み レートをはるかに低い単価で予約し、持続的で安定したトラフィックがその予約を十分に使い切る ときにだけ有利になります。ボリュームが実証済みで予測可能でない限り、オンデマンドを 選びましょう。
- オンデマンド = リクエストごとに課金、ゼロまでスケール。 計画すべきキャパシティは なく、読み取り/書き込みの単価は高いですが、トラフィックが発生したときにだけ支払います。
- プロビジョンド = 安定したレートを予約し、常に支払う。 レートを十分に使い切っていれば 単価はずっと安いですが、遊休キャパシティのコストも負担します。
- 急増する、あるいは未知のトラフィックにはオンデマンドが向く。 安定して予測可能で 大量のトラフィックにはプロビジョンド (必要ならオートスケーリングと併用) が向きます。
- モードは切り替えられますが、上限は非対称です。プロビジョンドからオンデマンドは 24 時間あたり4回までに制限され、オンデマンドからプロビジョンドは無制限です。リクエスト ごとに切り替えるスイッチではありません。
問題：使わないキャパシティに払う
プロビジョンドキャパシティでは、たとえば毎秒 1,000 書き込みユニットにコミットします。 監査ログが平均で毎秒 50 書き込みでも、インシデント日のピークに合わせてプロビジョンド すれば、24 時間ずっと 1,000 分を支払って、その 20 分の1しか使いません。代わりに平均に 合わせてプロビジョンドすると、インシデント日の洪水はスロットリングされます。書き込みが 拒否されるのです。
つまり固定キャパシティは、急増するトラフィックに悪いトレードを強います。常に払いすぎるか、 プロビジョンドが足りず、最も肝心なときに書き込みを落とすか。オンデマンドはまさにその トレードを取り除くために存在します。
2つのモードの仕組み
オンデマンドは、実際に消費した読み取り・書き込みリクエストユニットに課金し、設定すべき キャパシティはありません。直前のトラフィックのピークの2倍までのスパイクを即座に受け止め、 アイドル時にはゼロまでスケールします。短い ウィンドウ内でその2倍のジャンプを超えると、立ち上がる間はスロットリングすることもあります。 その伸縮性の代わりに、リクエストごとに割増しを支払います。
プロビジョンドは、毎秒あたりの読み取りキャパシティユニット (RCU) と書き込みキャパシティ ユニット (WCU) の数を予約します。単価ははるかに低いですが、使っても使わなくても予約に 継続的に支払います。それを超えると、オートスケーリングが有効で設定した範囲内でキャパシティ を拡大しない限り、DynamoDB はスロットリングします。ただしオートスケーリングは数分かけて 反応するので、急なスパイクは追いつく前にやはりスロットリングし得ます。
分岐点は使用率です。おおまかに言えば、持続的で予測可能なトラフィックがプロビジョンド キャパシティを十分に使い切るならプロビジョンドが価格で勝ちます。トラフィックが急増的、 バースト的、あるいは未知なら、遊休の予約に課金しないオンデマンドが勝ちます。
具体例：監査ログの請求
監査ログは平均で毎秒約 50 イベントを書き込みますが、インシデント時には数千まで急増し、 読み取りトラフィックははるかに低くなります (コンプライアンスのエクスポート、たまの調査)。 各イベントは小さく、優に 1 KB 未満です。
プロビジョンドでは、バーストに合わせて予約するか (24 時間 365 日それに支払う)、あるいは インシデント日の洪水をスロットリングするリスクを負うしかありません。監査の書き込みを落とす のに最悪のタイミングです。オンデマンドでは、静かな時間帯はほとんど何もかからず、直近の ピークの2倍までのバーストは設定なしで吸収されます。実際に起きた書き込みの分だけ支払います。
このワークロードにはオンデマンドが正しいデフォルトです。一般則：新しいテーブルや急増する テーブルはすべてオンデマンドで始め、予約を使い切れるほどトラフィックが安定していると実証 されて初めてプロビジョンドに移りましょう。
自分の数値を入れてみてください。毎秒の読み取り/書き込み、アイテムサイズ、ストレージを 入れて、1リージョンでの2つのモードを並べて確認できます。
無料利用枠を適用したマルチリージョンの全体像には、 DynamoDB 料金計算ツールを使ってください。
DynoTable でやってみる
キャパシティの決定は実際の数値から始まります。アイテムはどれくらい大きいか、いくつあるか、 どれだけ速く書き込まれているか。それらを推測することが、テーブルがミスプロビジョンされる 原因です。
サンプルのイベントを、それが実際に消費する RCU/WCU に変換するには、 アイテムサイズ計算ツールにかけましょう。それから 決定を実際のテーブルで裏付けます。DynoTable はテーブルのメタデータ——アイテム数とサイズ——を 表示し、代表的なアイテムを調べて正確にサイジングできるようにします。
落とし穴と次のステップ
- モードの切り替えはレート制限があり、しかも非対称。 プロビジョンドからオンデマンドは 24 時間あたり4回まで、オンデマンドからプロビジョンドは無制限です。回すダイヤルではなく、 熟慮した決定として扱いましょう。
- オートスケーリングは即時ではない。 数分かけて反応するので、プロビジョンドでの鋭い スパイクはキャパシティが増える前にスロットリングし得ます。真にバースト的なトラフィック には、オンデマンドのほうがスパイクをうまく処理します——直前のピークの2倍まで即座に。 それを超えるスパイクがあると分かっているなら (ローンチやセール)、テーブルに事前に ウォームスループットを設定してバーストの余裕をあらかじめプロビジョンドしておきましょう。
- ホットパーティションはモードに関係なくスロットリングする。 オンデマンドでさえ パーティションごとの上限があります。偏ったキーは、テーブルがキャパシティに余裕が あるように見えてもスロットリングし得ます。ホットパーティション を参照。
- はそれ自身のキャパシティを持つ。 各インデックスは別々に課金され、 プロビジョンドが不足するとベーステーブルの書き込みをスロットリングし得ます。 GSI がベーステーブルの書き込みをスロットリングする理由 を参照。
キャパシティモードは、1リージョンでテーブルを運用するのに払う額を決めます。次は、 DynamoDB グローバルテーブルでそれを複数リージョンに レプリケートすることです。
キャパシティモードにコミットする前に、DynoTable をダウンロードして、 テーブルの実際のサイズとアイテム数を読み取りましょう。