Q69 — AWS SAA-C03 第17章
第 69/89 問 | ← 第17章
Q1369. イベント会社が Amazon EKS 上に Web アプリケーションを展開しています。このアプリケーションは Amazon DynamoDB テーブルを使用しており、1,000 の読み取りキャパシティユニット(RCU)と 500 の書き込みキャパシティユニット(WCU)がプロビジョニングされています。アプリケーションは、この DynamoDB テーブルに対して最終的に一貫性のある読み取り(eventually consistent reads)を実行します。アプリケーションのトラフィックは通常は低水準ですが、時折急激に増加します。このようなトラフィックの急増時に、DynamoDB からスロットリングエラーが返され、結果としてエラーページがエンドユーザーに表示されます。ソリューションアーキテクトは、これらのエラーを削減するために何を行うべきでしょうか?
- A. DynamoDB テーブルをオンデマンドキャパシティモードに変更する。 ✓
- B. DynamoDB の読み取り専用レプリカを作成して、読み取りトラフィックを水平方向にスケールさせる。
- C. DynamoDB の予約済みキャパシティ(1,000 RCU および 500 WCU)を購入する。
- D. アプリケーションを設定して、DynamoDB クエリで強力に一貫性のある読み取り(strongly consistent reads)を使用する。
正解: A. DynamoDB テーブルをオンデマンドキャパシティモードに変更する。
解説
正解は A です。「DynamoDB テーブルをオンデマンドキャパシティモードに変更する」。 解説: 企業は、DynamoDB テーブルに固定で 1,000 RCU および 500 WCU をプロビジョニングしているにもかかわらず、トラフィックの急増時にスロットリングエラーを経験しています。これは、予測不可能なワークロードに対応するためのプロビジョニングされたキャパシティが不十分であり、ユーザー体験(エラーページ表示)を損なっていることを示しています。 ■ 選択肢 A が最適な理由:オンデマンドキャパシティモード ・DynamoDB がトラフィックに応じて自動的に読み取り/書き込みキャパシティをスケールアップ/ダウンするため、手動によるキャパシティ計画が不要です。 ・急激なトラフィック増加時にもスロットリングが発生しません(DynamoDB の内部バースト制限を超える極端なケースを除く。ただし、この制限は非常に高い水準です)。 ・予測不能なワークロードに対してコスト効率が良く、低トラフィック時は無駄なキャパシティ料金を支払う必要がありません(課金はリクエスト単位)。 ・アプリケーションが最終的に一貫性のある読み取りを使用している(これは強力に一貫性のある読み取りと比べて RCU 消費が半分)ため、オンデマンドモードにより、トラフィックピーク時でも十分なキャパシティが確保されます。 ■ 他の選択肢が不適切な理由: B. 「DynamoDB の読み取り専用レプリカを作成して、読み取りトラフィックを水平方向にスケールさせる」 → DynamoDB には RDS のような「読み取り専用レプリカ」機能はありません。グローバルテーブル(Global Tables)は、ディザスタリカバリやマルチリージョンアクセス向けのデータ複製機能であり、読み取り負荷分散の目的には使用できません。DynamoDB Accelerator(DAX)は読み取りキャッシュを提供しますが、キャパシティ不足によるスロットリングそのものを解決するものではありません。 C. 「DynamoDB の予約済みキャパシティ(1,000 RCU および 500 WCU)を購入する」 → 予約済みキャパシティは、安定的かつ予測可能なワークロードに対するコスト削減策であり、急激なトラフィック増加時のスロットリングを防ぐことはできません(プロビジョニングされたキャパシティを超えると、引き続きスロットリングが発生します)。また、大部分の時間でトラフィックが低い場合、無駄な支出につながります。 D. 「アプリケーションを設定して、DynamoDB クエリで強力に一貫性のある読み取りを使用する」 → 問題を悪化させます。強力に一貫性のある読み取りは、最終的に一貫性のある読み取りと比較して RCU 消費が2倍となるため、スロットリングのリスクがさらに高まります。根本原因(ピーク時のキャパシティ不足)には一切対処していません。 ■ 予測不能な DynamoDB ワークロードにおけるベストプラクティス: ・オンデマンドキャパシティモードを採用し、DynamoDB に自動スケーリングを任せること。 ・プロビジョニングモードを継続して使用する場合は、Auto Scaling を設定できますが、スケールアップに遅延があるため、ピーク初期には依然としてスロットリングが発生する可能性があります。 ・クエリの最適化(バッチ操作の活用、プロジェクションの使用、DAX によるキャッシュなど)も有効です。 ・強力に一貫性のある読み取りは、厳密な一貫性が必須でない限り避けるべきです(RCU 消費が2倍になるため)。 結論:選択肢 A は、以下の点で最も効果的かつシンプルな解決策です。 ・自動スケーリングによりスロットリングを完全に防止します。 ・プロビジョニングモードにおける Auto Scaling のように、手動での介入や監視が不要です。 ・予測不能なトラフィックに対してコスト効率が高く、「使った分だけ支払う」モデルです。 選択肢 B、C、D は、問題を解決しないか、むしろ状況を悪化させます。