DOP弾力性に優れたクラウドソリューション複数選択
あるスタートアップがAmazon DynamoDBのプロビジョニング済みキャパシティ（書き込み500 WCU）でSNS投票アプリケーションを運用しています。先月、著名人の投稿がバイラル化した際に10秒以内に書き込みトラフィックが通常の50倍に急増し、ProvisionedThroughputExceededExceptionエラーが多発してアプリケーションが停止しました。トラフィックパターンはまったく予測不可能です。コストを最適化しながらこの問題を根本的に解決する最適な組み合わせはどれですか？（2つ選択）
ADynamoDBをオンデマンドキャパシティモードに切り替え、事前のキャパシティ計画なしに任意の急増トラフィックを処理できるようにする
✓ 正解
DynamoDBオンデマンドキャパシティモードは事前の計画なしに過去ピークの2倍まで即座にスケールし、それ以上のトラフィックにも自動対応します。予測不可能な50倍スパイクへの根本解決策です。Exponential BackoffとJitter付きリトライはAWS SDK推奨パターンで、スロットリング発生時に複数クライアントが同時リトライして輻輳が悪化するサンダリングハード（thundering herd：大量クライアントの同時リトライによる過負荷）問題を防ぎます。
BDynamoDB Auto Scalingを有効化してターゲット使用率を40%に設定し、スケールアップの応答速度を最大化する
DynamoDB Auto Scalingのスケールアップには実際のトラフィック増加から数分のラグがあり、10秒以内の50倍急増には対応できません。
Cアプリケーション側にExponential Backoff（指数バックオフ）とJitter（ジッター）付きのリトライロジックを実装し、スロットリング時の輻輳（ふくそう：過負荷による混雑状態）を緩和する
✓ 正解
DynamoDBオンデマンドキャパシティモードは事前の計画なしに過去ピークの2倍まで即座にスケールし、それ以上のトラフィックにも自動対応します。予測不可能な50倍スパイクへの根本解決策です。Exponential BackoffとJitter付きリトライはAWS SDK推奨パターンで、スロットリング発生時に複数クライアントが同時リトライして輻輳が悪化するサンダリングハード（thundering herd：大量クライアントの同時リトライによる過負荷）問題を防ぎます。
DDynamoDB DAXクラスターを追加してキャッシュレイヤーを実装し、書き込みスループットを向上させる
DAX（DynamoDB Accelerator）はインメモリ読み取りキャッシュです。書き込み操作はDAXを経由せずDynamoDBへ直接書き込まれるため、書き込みスループット問題を解決しません。
EDynamoDBのプロビジョニング済みキャパシティをピーク予測値の3倍に事前増設し、定期的に見直す
ピーク予測値の3倍を事前プロビジョニングすることは、予測不可能なトラフィックには過剰コストを招き、かつ予測を超えるスパイクには依然対応できません。
解説
DynamoDBオンデマンドキャパシティモードは事前の計画なしに過去ピークの2倍まで即座にスケールし、それ以上のトラフィックにも自動対応します。予測不可能な50倍スパイクへの根本解決策です。Exponential BackoffとJitter付きリトライはAWS SDK推奨パターンで、スロットリング発生時に複数クライアントが同時リトライして輻輳が悪化するサンダリングハード（thundering herd：大量クライアントの同時リトライによる過負荷）問題を防ぎます。
選択肢BのDynamoDB Auto Scalingのスケールアップには実際のトラフィック増加から数分のラグがあり、10秒以内の50倍急増には対応できません。
選択肢DのDAX（DynamoDB Accelerator）はインメモリ読み取りキャッシュです。書き込み操作はDAXを経由せずDynamoDBへ直接書き込まれるため、書き込みスループット問題を解決しません。
選択肢Eのピーク予測値の3倍を事前プロビジョニングすることは、予測不可能なトラフィックには過剰コストを招き、かつ予測を超えるスパイクには依然対応できません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →