おはようございます、YASUです。
DVAの模擬試験で、「DynamoDBの書き込みが追いつかない時の解決策」を問う問題で迷いました。スロットリングやプロビジョニングという言葉の意味もあやふやだったので、今日は、シンプルに整理します。
結論
書き込みが足りない時は、まず「原因」を見ます。キャパシティ不足なら、WCUを増やすか、Auto Scalingかオンデマンドを使います。特定のキーに集中しているなら、パーティションキーの設計を見直します。DAXやバッチ書き込みは、書き込みのWCUの消費量を減らしません。
スロットリングとは
スロットリングは、処理できる量の上限を超えたリクエストを、サービス側が一時的に断る仕組みです。自分なりのイメージでは、満席のお店の入口で、「少しお待ちください」と断られる状態です。
DynamoDBでは、設定したキャパシティを超えると、リクエストが断られて、ProvisionedThroughputExceededExceptionというエラーが返ってきます。断られたリクエストは実行されないので、データも書き込まれません。アプリケーションは、少し待ってから、再試行します。
プロビジョニングとオンデマンド
- プロビジョニング:読み書きできる量(WCU・RCU)を、先に決めておく。アクセスが予測できる時に使う。安くなることがある
- オンデマンド:量を決めず、使った分だけ払う。アクセスが予測できない時に使う
お店の例えでは、プロビジョニングが「席数を先に決めておく」、オンデマンドが「お客さんの数に合わせて、席が増える」です。名前の中の「Provisioned」は、「あらかじめ決めておいた」という意味で、エラー名の意味もここから分かります。
書き込みが足りない時の解決策
- 設定したWCUが足りない:WCUを増やす、Auto Scalingを有効にする、オンデマンドに切り替える
- 特定のキーにアクセスが集中している:パーティションキーを分散させる。1つのキーに集中すると、他のパーティションに空きがあっても、スロットリングされる
- 一時的に急増する:指数バックオフで、待ってから再試行する。SQSで一度溜めて、少しずつ書き込む
- アイテムが大きい:WCUは、1KB単位で切り上げて消費されるので、サイズを小さくする
- GSIがある:GSIのキャパシティが足りないと、ベーステーブルの書き込みにも影響が出ることがある
書き込みには効かないもの
- DAX:読み取りのキャッシュなので、書き込みのWCUの消費量は変わらない
- バッチ書き込み(BatchWriteItem):AWSのドキュメントでは、バッチの中の各アイテムが、個別のPutItemまたはDeleteItemとして処理される。アイテムごとに、1KB単位に切り上げて計算されるので、WCUの消費量は変わらない。減るのは、ネットワークの往復の回数だけ
Auto Scalingの注意点
Auto Scalingは、使用量が目標値を超え続けてから動き、スケールアップにも数分かかります。そのため、急な増加には間に合わないことがあります。「急なスパイクに、自動で対応したい」という問題では、オンデマンドの方が合います。ただし、オンデマンドでも、トラフィックが急に増えすぎた時などは、スロットリングが起きることがあります。
まとめ
- スロットリングは、上限を超えたリクエストが、サービス側に断られること
- プロビジョニングは、容量を決めておく方式で、オンデマンドは、使った分だけ払う方式
- キャパシティ不足なら、WCUを増やす、Auto Scaling、オンデマンド。キーの集中なら、キー設計の見直し
- DAXとバッチ書き込みは、書き込みのWCUの消費量を減らさない
- Auto Scalingは急な増加に間に合わないことがあり、予測できない負荷には、オンデマンドが合う
「原因を見てから、解決策を選ぶ」という順番で整理すると、選択肢がかなり絞りやすくなりました。それでは、また明日!
コメント