はじめに
Amazon DynamoDBを利用していると、よく耳にするオンデマンドキャパシティモード。
「自動スケーリングするらしいけど実際の仕組みはどうなっているの？」
「プロビジョンドキャパシティモードとの違いは？」
「バックアップやリストア時にはどんな挙動になるの？」
こうした疑問は現場でも頻繁に出ますが、公式ドキュメントだけでは断片的にしか分からず、意外と知られていない仕様も多いのが実情です。
そこで本記事では、オンデマンドキャパシティモードの基礎から、スケーリング挙動、リストア時の注意点、さらに事前ウォーミングによる実践的な対策までを網羅的に解説します。
対象読者
- DynamoDBを利用しているエンジニアやアーキテクト
- オンデマンドキャパシティモードの挙動を深く理解したい方
- 大規模アクセスやスパイクが発生するシステムを開発している方
記事を読むメリット
- オンデマンドキャパシティモードとプロビジョンドキャパシティモードの違いが明確になる
- スケーリングやリストア時の挙動について、現場で役立つ知識が得られる
- 事前ウォーミングや最大スループット設定といった大規模システム向けの実践的な設定項目を理解できる
キャパシティモードとは
DynamoDBでは、アプリケーションのワークロードに応じてスループットの管理方法を柔軟に選択できるよう、キャパシティモードを設定できます。
キャパシティモードには次の2種類があります：
- オンデマンドキャパシティモード（On-Demand Capacity Mode）
- プロビジョンドキャパシティモード（Provisioned Capacity Mode）
それぞれの特徴を以下に示します。
| 特徴 | オンデマンドキャパシティモード | プロビジョンドキャパシティモード |
|---|---|---|
| スループット設定 | 不要（自動でスケーリング） | 必要 |
| コストモデル | 従量課金型 | 定額課金型 |
| 1ユニットあたりの料金 | 高い | 安い |
| ユースケース | トラフィック変動が大きい、または不明なアプリ | 一定のトラフィックが見込まれるアプリ |
ここからは、案件で実際に利用したオンデマンドキャパシティモードを中心に、詳細を解説していきます。
オンデマンドキャパシティモードとは
DynamoDBのオンデマンドキャパシティモードは、事前にスループットを設定する必要がなく、アプリケーションのトラフィックに応じて自動的にスケーリングされるモードです。
このモードでは、アクセス負荷の変動に応じて必要なリソースが自律的にスケーリングされるため、突発的なトラフィックの急増にも柔軟かつ安定した対応が可能です。
スループットの考え方
オンデマンドキャパシティモードでは、スループットを RRU（Read Request Unit） とWRU（Write Request Unit） で定義します。その計算例を以下に示します。
-
RRU（Read Request Unit）
- 結果整合性読み取り: 8KBのアイテムを1リクエスト = 1 RRU
- 強整合性読み取り: 8KBのアイテムを1リクエスト = 2 RRU
- トランザクション読み取り: 8KBのアイテムを1リクエスト = 4 RRU
-
WRU（Write Request Unit）
- 標準の書き込み: 1KBのアイテムを1リクエスト = 1 WRU
- トランザクション書き込み: 1KBのアイテムを1リクエスト = 2 WRU
スループットのスケーリング
オンデマンドキャパシティモードでは、過去に到達したRRU/WRUのピーク値をウォームスループットとして保持し、それを基準にスケーリングが行われます。
-
自動スケーリングの特徴
- 前回ピークのウォームスループット（RRU/WRU）の最大2倍までは瞬時にスケーリング可能
- 前回ピークの30分以内にピーク時の2倍を超えるリクエストを受けるとスロットリングが発生する可能性がある
また、急激なトラフィック増加に備え、ウォームスループットをあらかじめ確保しておく事前ウォーミング機能も提供されています。
-
事前ウォーミングの特徴
- 事前ウォーミングで設定した値までスケーリング可能
- テーブル作成時や更新時に設定可能
- 現在のテーブルが保持しているウォームスループットと、新たに設定する事前ウォーミングの値との差分に対して、オンデマンドキャパシティモードの従量課金とは別で、一度限りの追加料金が発生する
スケーリング上限
オンデマンドキャパシティモードは自動でスケールしますが、下記2種類の上限を超えるリクエストはスロットリングされるため、必要に応じて上限値を引き上げなくてはなりません。
-
クォータ制限
- デフォルトで設定されているアカウント単位×リージョン単位のスループット上限
- 必要に応じてAmazon Web Services（AWS）サポートに申請することで引き上げ可能
-
最大スループット
- 想定以上にスケールしすぎないようにユーザ側で設定する上限値
- テーブル作成時や更新時に設定可能
リストア時のウォームスループットの挙動
DynamoDBテーブルをリストアする代表的な方法には次の2つがあります。
ただし、いずれの方法でもリストア後のテーブルにウォームスループットの値は引き継がれないという課題があります。
- PITR（Point-in-Time Recovery）
- テーブルを過去35日以内の任意の時点に復元
- AWS Backup
- バックアップスナップショットからの復元
ウォームスループットがリセットされることで、復元直後のテーブルではスロットリングが多発する恐れがあります。
そのため、以下のような手順で事前に対策を取ることが推奨されます。
- リストア対象のテーブルおよびGSIのウォームスループットを事前に確認・取得する
- バックアップを利用してテーブルを復元する
- 復元後に事前ウォーミングを実施し、テーブルおよびGSIのウォームスループットを引き上げる
まとめ
オンデマンドキャパシティモードは、予測困難なトラフィックにも対応できる柔軟で便利な仕組みです。
ただし、以下のような制約や特性を理解しておくことが安定運用には欠かせません。
- スケーリングは 過去ピークの RRU/WRU（ウォームスループット）を基準に行われる
- リストア後はウォームスループットがリセットされるため、スロットリングのリスクがある
- 事前ウォーミングや最大スループットの設定を活用することで、予期せぬ負荷増やコスト増を防げる
参考
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。