Q13 — AWS SAA-C03 第16章

第 13/100 問 | ← 第16章

Q1213. ある企業が、モバイルアプリから大量のデータを処理するサーバーレスアプリケーションを構築しています。このアプリケーションでは、AWS Lambda関数を使用してデータを処理し、Amazon DynamoDBテーブルに保存します。企業は、アプリケーションが障害から回復でき、レコードを1件も失うことなく処理を継続できるようにする必要があります。これらの要件を満たすソリューションはどれですか？

正解: A. Lambda関数を、Amazon Simple Queue Service（Amazon SQS）キューを用いたデッドレターキュー（DLQ）で設定します。Lambdaがデッドレターキューから失敗したレコードを再試行するよう設定し、指数バックオフアルゴリズムを実装した再試行メカニズムを使用します。

解説

サーバーレスアプリケーションが障害から回復し、レコードを1件も失うことなく処理を継続できるようにするには、最も適切なソリューションは以下の通りです： A. Lambda関数を、Amazon Simple Queue Service（Amazon SQS）キューを用いたデッドレターキュー（DLQ）で設定します。Lambdaがデッドレターキューから失敗したレコードを再試行するよう設定し、指数バックオフアルゴリズムを実装した再試行メカニズムを使用します。 分析： ・Amazon SQSを用いたデッドレターキュー（DLQ）： 　障害処理：Lambda関数がレコードの処理に失敗した場合、そのレコードをデッドレターキュー（DLQ）に送信できます。Amazon SQSは、完全に管理されたメッセージキューイングサービスであり、失敗したレコードを一時的に保存するDLQとして使用可能です。 　メッセージ保持：SQSは、最大14日間（設定可能）メッセージを保持するため、後続のタイミングでこれらのレコードを再処理できます。 ・指数バックオフを用いた再試行メカニズム： 　指数バックオフ：再試行時に指数的に遅延を増加させるアルゴリズムを実装することで、短時間に集中する再試行によるシステム過負荷を回避できます。これにより、一時的な障害からの回復時間を確保できます。 　信頼性：DLQとSQS、および指数バックオフを組み合わせることで、障害発生時にもレコードを確実に保持・再処理でき、データ損失なしに処理を継続できます。 他の選択肢が不適切な理由： B. Lambda関数をAmazon Data Firehoseからレコードを読み取るように設定し、障害時にFirehoseのレコードを再再生する： 　Firehoseの設計：Amazon Kinesis Data Firehoseは、ストリーミングデータをAmazon S3、Amazon Redshift、Amazon OpenSearch Serviceなどの宛先へ配信する目的で設計されています。Lambda関数内の処理失敗に対するレコードの「再再生」機能は提供されていません。 　再試行メカニズムの欠如：Firehoseには、Lambda処理文脈における失敗レコードの再試行をサポートする組み込み機能はありません。 C. 失敗したレコードの保存にAmazon OpenSearch Serviceを用い、そこから再試行する： 　不適切なユースケース：Amazon OpenSearch Service（旧Elasticsearch Service）は、検索および分析用途を主目的としており、Lambdaからの失敗レコードの保存・再試行には適していません。 　複雑さ：OpenSearch Serviceを用いた再試行機構の実装は、不要な複雑さを追加し、このサービスの本来の用途から外れます。 D. 失敗したレコードの保存にAmazon SNSを用い、SNSトピックから再試行する： 　SNSの設計：Amazon SNSは、アプリケーション間（A2A）およびアプリケーション対人（A2P）の通信向けに設計された完全マネージド型のメッセージングサービスであり、失敗レコードの保存・再試行には適していません。 　再試行のためのメッセージ保持機能の欠如：SNSトピックは、サブスクライバーへの即時配信を目的としており、再試行のためにメッセージを保持する機能はありません。 まとめると、選択肢Aは、Amazon SQSを用いたデッドレターキューと指数バックオフを活用した再試行メカニズムにより、サーバーレスアプリケーションにおける障害耐性とデータ損失防止という両方の要件を堅牢かつ信頼性高く満たすソリューションです。