Q85 — AWS SAA-C03 第12章

第 85/100 問 | ← 第12章

Q885. ある企業が、オンプレミスのMySQLデータベースをAWSに移行したいと考えています。このデータベースには、クライアント向けアプリケーションから定期的にインポートが実行され、大量の書き込み操作が発生しています。企業は、このトラフィック量がアプリケーション内でパフォーマンス問題を引き起こしている可能性を懸念しています。ソリューションアーキテクトは、AWS上でどのようなアーキテクチャを設計すべきでしょうか？

正解: A. Provisioned IOPS SSDストレージを用いてAmazon RDS for MySQL DBインスタンスをプロビジョニングします。Amazon CloudWatchを使用して書き込み操作のメトリクスを監視し、必要に応じてProvisioned IOPSを調整します。

解説

オンプレミスのMySQLデータベースをAWSへ移行し、クライアント向けアプリケーションからの大量の書き込み操作に対応するためのアーキテクチャ設計において、ソリューションアーキテクトは以下の対応を行うべきです： A. Provisioned IOPS SSDストレージを用いてAmazon RDS for MySQL DBインスタンスをプロビジョニングし、Amazon CloudWatchで書き込み操作のメトリクスを監視して、必要に応じてProvisioned IOPSを調整する。 Provisioned IOPS（1秒あたりの入出力操作数）は、Amazon RDSが提供するストレージオプションであり、ユーザーがデータベースインスタンスに必要なIOPSレベルを明示的に指定できます。Provisioned IOPS SSDストレージを用いたAmazon RDS for MySQL DBインスタンスをプロビジョニングすることで、クライアント向けアプリケーションからの大量の書き込みワークロードを確実に処理できるパフォーマンスを確保できます。 また、Amazon CloudWatchを活用して書き込み操作に関するメトリクス（例：WriteIOPS、WriteLatency、WriteThroughputなど）を継続的に監視することで、パフォーマンスのボトルネックや潜在的な問題を早期に検出し、適切な対応を講じることができます。監視結果から、現在のProvisioned IOPS値がワークロードに不十分であると判断された場合は、IOPSを増加させるなどの調整を行うことで、最適なパフォーマンスを維持できます。 一方、選択肢B、C、Dは、大量の書き込み操作への対応という観点では推奨されません： 選択肢Bでは、General Purpose SSDストレージのRDSインスタンスに加え、ElastiCacheをフロントに配置する提案があります。ElastiCacheは読み取り負荷の軽減（キャッシュヒットによるDBアクセス削減）には有効ですが、書き込み操作そのもののパフォーマンス向上には直接寄与しません。また、キャッシュとデータベース間のデータ整合性を保つための追加設計や運用負荷が発生し、複雑さとリスクが増大します。 選択肢Cでは、MySQLからAmazon DocumentDB（MongoDB互換）への移行が提案されていますが、DocumentDBはNoSQLドキュメントデータベースであり、既存のMySQLスキーマ・アプリケーションとの互換性や移行工数、およびACID特性の担保といった観点から、単純な置き換えには不適切です。さらに、書き込み集中ワークロードへの最適化もDocumentDBの主な設計目的ではありません。 選択肢Dでは、Amazon EFSの利用が提案されていますが、EFSは共有ファイルストレージサービスであり、トランザクショナルなデータベースワークロード（特に高頻度のランダム書き込み）には設計されていません。低レイテンシー・高IOPSが求められるDBストレージとしての性能は不足しており、本ユースケースには不適切です。 以上より、MySQLデータベースのAWS移行において、大量の書き込み操作を確実に処理し、安定したパフォーマンスを確保するには、Provisioned IOPS SSDストレージを用いたAmazon RDS for MySQLの採用、CloudWatchによる書き込みメトリクスの監視、および必要に応じたIOPSの動的調整（選択肢A）が最も適切な設計です。