Q37 — AWS SAP-C02 第2章

第 37/75 問 | ← 第2章

Q187. ある会社がマイクロサービスを AWS Lambda 関数として実行しています。 このマイクロサービスは、同時接続数に制限があるオンプレミスの SQL データベースにデータを書き込みます。Lambda 関数の呼び出し回数が多すぎると、データベースがクラッシュし、アプリケーションのダウンタイムが発生します。同社は、自社の VPC とオンプレミスのデータセンター間で AWS Direct Connect 接続を有しています。同社は、データベースのクラッシュから保護したいと考えています。 これらの要件を満たすソリューションはどれですか？

正解: A. データを Amazon Simple Queue Service (Amazon SQS) キューに書き込みます。 Lambda 関数を再設定してキューから読み取り、既存のデータベースに書き込むようにします。 データベースがサポートする接続数より少ない値に、Lambda 関数の予約済み同時実行数（reserved concurrency）を設定します。

解説

お手数をおかけして申し訳ありません。前回の回答における混乱についてお詫びいたします。ご指摘の通り、このシナリオにおいてデータベースのクラッシュから保護するという要件を満たすソリューションは以下の選択肢です： A. データを Amazon Simple Queue Service (Amazon SQS) キューに書き込みます。Lambda 関数を再設定してキューから読み取り、既存のデータベースに書き込むようにします。データベースがサポートする接続数より少ない値に、Lambda 関数の予約済み同時実行数（reserved concurrency）を設定します。 この選択肢が最も適している理由は以下のとおりです： 1. Amazon SQS：データを SQS キューに書き込むことで、Lambda 関数とオンプレミスの SQL データベースとの結合度を低減（デカップリング）できます。Lambda 関数は単にデータをキューに送信するだけで済み、データ処理の責任は別のコンポーネントに委ねられます。 2. Lambda 関数の同時実行制御：データベースがサポートする接続数より小さい値に予約済み同時実行数を設定することで、Lambda 関数の同時実行数を制御できます。これにより、データベースへの過剰な接続要求を防ぎ、クラッシュのリスクを低減できます。 3. スケーラビリティとフォールトトレランス：Amazon SQS は、高いスケーラビリティとフォールトトレランスを備えたメッセージングサービスであり、大量のメッセージを処理でき、障害発生時にもデータの耐久性を保証します。これにより、高トラフィック時でもデータが確実に処理されます。 選択肢 B（新しい Amazon Aurora Serverless DB クラスターの作成とデータ移行）は、既存のオンプレミスデータベースを別のデータベースソリューションに移行するものであり、今回のケースでは必ずしも必要ではありません。また、追加の複雑さを導入し、既存のオンプレミスデータベースを保護するという直接的な課題には対応していません。 選択肢 C（Amazon RDS Proxy DB インスタンスの作成）は、主に Amazon RDS データベースへの接続管理を目的としており、オンプレミスデータベースの保護には適用できないか、あるいは直接的な解決策とはなりません。 選択肢 D（データを Amazon SNS トピックに書き込み、その通知を受けて Lambda 関数を呼び出してデータベースに書き込む）は、多数の同時接続によるデータベースクラッシュを防ぐという目的には最も適していません。 したがって、提示された要件に基づき、選択肢 A が、Amazon SQS を用いて Lambda 関数とデータベースをデカップリングし、予約済み同時実行数を設定して同時接続数を制御することで、オンプレミス SQL データベースを実践的かつ効果的に保護する、最も適切な選択肢です。