DynamoDBのオートスケーリング機能を有効にすると勝手に作成されるアラームについて調べてみた

お疲れさまです。サーバーレス開発部の新井です。

今回はDynamoDBのオートスケーリングに関する記事です。 実は以前から気になっていた、DynamoDBのオートスケーリング機能を有効にすると自動で作成されるCloudWatch Alarmsのアラームですが、それぞれの細かい役割について調べてみました。

• 参考サイトURL
• DynamoDB Auto Scaling によるスループットキャパシティの自動管理
• AWS CLIを使用したDynamoDB Auto Scalingの管理
• Amazon CloudWatch アラームの作成

オートスケーリングの有効化

マネージメントコンソールからDynamoDBのCreate Tableを実行します。 Use default settingsのチェックボックスをオンにすると、デフォルト設定でオートスケーリングが有効化されます。

• デフォルト値
• target utilization (ターゲット使用率): 70%
• minimum read capacity unit (最小RCU): 5
• maximum read capacity unit (最大RCU): 40,000
• minimum write capacity unit (最小WCU): 5
• maximum write capacity unit (最大WCU): 40,000
• same settings to global secondary indexes (GSIへ同様の設定): Yes

今回は対象外ですが、オートスケーリングを無効化してテーブル作成すると、Basic Alarmなるものが自動作成されます。 こいつは、キャパシティユニットの超過時に発火して、SNS トピックへの通知を行ってくれるアラームです。 デフォルトでは通知先の設定はされてないので、自分で入力する必要があります。

各アラームの役割について

以下が作成されたアラームです。CloudWatch Alarmsの設定値の詳細はこちらを参考にしてください。

Alarm High/Low

上記の画像の上半分のアラームです。 Read、Writeのそれぞれに上限閾値と下限閾値があるので合計4つ作成されています。

これらは、Read(読み込み)とWrite(書き込み)のConsumedCapacity(消費キャパシティ)が一定のしきい値を超えた際に、発火するアラームです。 アラームが発火すると、対象のテーブルのキャパシティのスケールを実行します。

では、実際にAlarm HighのConsumedReadCapacityUnitsについて見ていきましょう。こちらは、読み込みキャパシティユニットを上げるために使われるアラームです。

アラームが発火する条件として、1分ごとに集計されるConsumedWriteCapacityUnitsの合計(Sum)が2回連続で210CapacityUnitを上回った場合となっています。(※ただし欠損データはカウントしない)

1分間の合計消費読み込みキャパシティユニットが上限閾値が210なので、例えば1分おきに840KB(=210×4KB)のデータの読み込みを2回行えば、アラームが発火して読み込みキャパシティユニットの値が上がります。 で、この210が一体なにを基準に生成されているかというと、これがターゲット使用率です。 計算式としては、

(現在のプロビジョニングされたキャパシティ) × (60秒) × (ターゲット使用率) = 5 × 60 × 0.7 = 210

となります。

次にAlarm LowのConsumedWriteCapacityUnitsについて見ていきましょう。こちらは、書き込みキャパシティユニットを下げるために使われるアラームです。

アラームが発火する条件として、1分ごとに集計されるConsumedWriteCapacityUnitsの合計(Sum)が15回連続で150CapacityUnitを下回った場合となっています。(※ただし欠損データはカウントしない)

1分間の合計消費書き込みキャパシティユニットの下限閾値が150なので、例えば1分おきに150KB(=150×1KB)のデータ書き込みを15回行えば、アラームが発火して書き込みキャパシティユニットの値が下がります。 こちらの計算方法は、

(現在のプロビジョニングされたキャパシティ) × (60秒) × (ターゲット使用率-20%) = 5 × 60 × 0.5 = 150

となります。　(※ サポートに問い合わせたところ、具体的な計算例は、現時点での動作となる点に注意してくださいとのことでした。)

ProvisionedCapacity High/Low

上記の画像の下半分のアラームです。 Read、Writeのそれぞれに上限閾値と下限閾値があるので合計4つ作成されています。

これらはちょっと特殊なのですが、AWS CLIやSDKなどからUpdateTable APIを実行された場合など、オートスケーリング管理外からのテーブルへのキャパシティユニットの増減を検知するためのアラームです。 DynamoDBのオートスケーリングの仕様上、オートスケーリング管理外からのキャパシティの変更が行われた場合、上記のAlarm High/Lowのアラームの閾値が変更後のキャパシティ値に追従できません。 そのため、このアラームは現在のキャパシティ値を監視し、必要に応じてAlarm High/Lowのアラームの閾値をアップデートするために利用されます。

では、実際にProvisionedCapacity HighのProvisionedWriteCapacityUnitsについて見ていきましょう。こちらは現在の書き込みキャパシティユニットの上限状態を監視するためのアラームです。

アラームが発火する条件として、5分ごとに集計されるProvisionedWriteCapacityUnitsの平均(Average)が3回連続で5CapacityUnitを上回った場合となっています。(※ただし欠損データはカウントしない)

では試しに、AWS CLIから以下のコマンドを実行し、書き込みキャパシティユニットの値を変更してみます。

aws dynamodb update-table --table-name arai-test --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=10

実行直後、書き込みキャパシティユニットは10へ変更されましたが、アラームに変化はありません。 15分後に再度確認してみると、以下の様にアラームが発火し、Alarm High/Lowの書き込みキャパシティユニットを上げ/下げするアラームの閾値が適切に変更されていました。

まとめ

いかがだったでしょうか。

個人的には、DynamoDBのオートスケーリング機能について、より理解を深められましたかと思います。 特にProvisionedCapacity High/Lowのアラームの存在意義が当初よくわからなかったのでとても納得しました。

またオートスケーリングを有効化しているのに、APIなどの外部からのキャパシティユニットの変更を許可しているということは、オートスケーリング機能でカバーできないような

• 決まった時間帯による、事前のスケーリング
• スパイクの発生を検知した際の、事前のスケーリング

などを想定しているのかな？と思いました。

以上、どなたかの役に立てば幸いです。

お疲れさまでした！