DynamoDBのオンデマンドとプロビジョンドキャパシティ
DynamoDBはスループットを2通りで課金します。オンデマンドはリクエストごとに課金します — 使った分だけ支払い、ゼロまでスケールします。プロビジョンドは固定の読み書きレートを予約し、使うかどうかにかかわらず支払いますが、ユニットあたりの単価ははるかに安くなります。間違ったほうを選ぶことは、払いすぎる最も簡単な方法の1つです。
監査ログがこの選択を具体的にします。監査の書き込みは急峻で予測不能です。夜間は静かで、顧客が一括操作を実行したりインシデントが数千のイベントを生成したりすると洪水のようになります。そのトラフィックの形が、決定のすべてです。
DynamoDBのオンデマンドとプロビジョンドキャパシティ、どちらを選ぶべきか？
オンデマンドはリクエストごとに課金し、ゼロまでスケールするため、急峻・新規・予測不能なトラフィックへの安全な既定選択です。プロビジョンドは固定の読み書きレートを予約し、ユニットあたりの単価はずっと安くなりますが、持続的で安定したトラフィックが予約を十分に活用している場合のみ有利です。トラフィックが実証済みで予測可能でない限り、オンデマンドを選んでください。
- オンデマンド = リクエスト課金、ゼロまでスケール。 キャパシティの計画は不要です。読み書きごとの単価は高めですが、トラフィックが発生したときだけ支払います。
- プロビジョンド = 一定レートを予約し、常に支払う。 レートが十分に活用されればユニットあたりはるかに安くなりますが、アイドルなキャパシティのコストを負担します。
- 急峻/不明なトラフィック → オンデマンド。 安定して予測可能な大量トラフィック → プロビジョンド(任意でオートスケーリング併用)。
- モードは切り替え可能ですが、24時間あたりの回数には上限があります — リクエストごとに切り替えるトグルではありません。
問題:使わないキャパシティへの支払い
プロビジョンドキャパシティでは、例えば毎秒1,000の書き込みユニットをコミットします。監査ログが平均で毎秒50書き込みなのに、インシデント日のピークに合わせてプロビジョニングすると、1,000を24時間ずっと支払い、その20分の1しか使いません。代わりに平均に合わせてプロビジョニングすると、インシデント日の洪水でスロットリングが起き — 書き込みが拒否されます。
つまり固定キャパシティは、急峻なトラフィックに悪いトレードオフを強います。常に払いすぎるか、過少にプロビジョニングして最も重要なときに書き込みを落とすかです。オンデマンドは、まさにそのトレードオフをなくすために存在します。
2つのモードの仕組み
オンデマンドは実際に消費した読み取りおよび書き込みリクエストユニットに課金し、設定すべきキャパシティはありません — トラフィックのスパイクに即座に対応し、アイドル時にはゼロまでスケールします。その弾力性に対してリクエストごとにプレミアムを支払います。
プロビジョンドは毎秒のRead Capacity Units(RCU)とWrite Capacity Units(WCU)の数を予約します。ユニットあたりの単価ははるかに低いものの、使用の有無にかかわらず予約分を継続的に支払います。それを超えると、設定された範囲内でキャパシティを増やすオートスケーリングが有効でない限りDynamoDBはスロットリングします — もっともオートスケーリングは分単位で反応するため、突然のスパイクは追いつく前にスロットリングしうります。
分岐点は使用率です。おおざっぱに言えば、持続的で予測可能なトラフィックがプロビジョンドキャパシティを十分に活用するなら、価格でプロビジョンドが勝ちます。トラフィックが急峻、バースト的、または不明なら、アイドルな予約に課金しないオンデマンドが勝ちます。
実例:監査ログの請求
監査ログは平均で毎秒約50イベントを書き込みますが、インシデント時には数千までバーストし、読み取りトラフィックははるかに少なくなります(コンプライアンスエクスポート、たまの調査)。各イベントは小さく、1 KBを十分に下回ります。
プロビジョンドでは、バーストに合わせて予約する(24時間365日それを支払う)か、インシデント日の洪水をスロットリングするリスクを負う — 監査の書き込みを落とすには最悪のタイミングです — かのどちらかになります。オンデマンドでは、静かな時間帯はほとんどコストがかからず、バーストは自動的に吸収されます。発生した書き込みの分だけ正確に支払います。
このワークロードではオンデマンドが正しい既定です。一般的なルールは、新しいテーブルや急峻なテーブルはオンデマンドで始め、予約を活用できるほど十分に安定していると証明されてから初めてプロビジョンドへ移行する、というものです。
自分の数値 — 毎秒の読み書き、アイテムサイズ、ストレージ — を入力して、1つのリージョンについて2つのモードを並べて見てみましょう:
無料利用枠を適用したマルチリージョンの全体像については、DynamoDB料金計算ツールを使ってください。
DynoTableでの実践
キャパシティの決定は実際の数値から始まります。アイテムはどれくらいの大きさか、いくつあるか、どれくらいの速さで書き込まれているか。それらを当て推量することが、テーブルがミスプロビジョニングされる原因です。
サンプルイベントを実際に消費するRCU/WCUに変換するには、アイテムサイズ計算ツールで確認しましょう。次に、実際のテーブルで決定を裏付けます。DynoTableはそのメタデータ — アイテム数とサイズ — を表示し、代表的なアイテムを確認できるようにするので、正確にサイズを見積もれます。
落とし穴と次のステップ
- モードの切り替えにはレート制限があります。 オンデマンドとプロビジョンドの間を変更できますが、24時間あたりの回数には上限があります — 回すダイヤルではなく、熟慮した決定として扱ってください。
- オートスケーリングは即時ではありません。 分単位で反応するため、プロビジョンドでの鋭いスパイクはキャパシティが増える前にスロットリングしうります。真にバースト的なトラフィックには、オンデマンドがスパイクを直接吸収します。
- ホットパーティションはモードにかかわらずスロットリングします。 オンデマンドでもパーティションごとの制限があります — 偏ったキーは、テーブルがキャパシティに余裕があるように見えてもスロットリングしうります。ホットパーティションを参照してください。
- GSIは独自のキャパシティを持ちます。 各インデックスは個別に課金され、過少にプロビジョニングされているとベーステーブルの書き込みをスロットリングしうります — なぜGSIがベーステーブルの書き込みをスロットリングするのかを参照してください。
キャパシティモードは1つのリージョンでテーブルを運用するために支払う金額を決めます。次は、DynamoDB Global Tablesでそれをリージョン間にレプリケートします。
キャパシティモードを決める前にテーブルの実際のサイズとアイテム数を読み取るには、DynoTableをダウンロードしてください。