Q52 — AWS SAA-C03 第17章

第 52/89 問 | ← 第17章

Q1352. ある企業は、Amazon Kinesis Data Streams と AWS Lambda 関数を用いてストリーミングデータを処理しています。このストリーミングデータは、インターネットに接続されたデバイスから送信されます。現在、スケーリングの問題が発生しており、シャードレベルの制御およびカスタムチェックポイント機能を実装する必要があります。これらの要件を満たすとともに、**最も低いレイテンシ**を実現するソリューションはどれですか？

正解: C. Lambda 関数のコードを、AWS Fargate 上で実行される Amazon ECS コンテナ内で実行します。コードを変更して Kinesis Client Library（KCL）を使用するようにします。

解説

正解は C です。Lambda 関数のコードを AWS Fargate 上で実行される Amazon ECS コンテナ内で実行し、コードを変更して Kinesis Client Library（KCL）を使用するというソリューションです。 【要件の確認】 ・シャードレベルの制御：各シャード単位でのデータ処理を明示的に制御可能であること。 ・カスタムチェックポイント：進捗状況の保存（チェックポイント）をアプリケーション側で手動で制御できること。 ・最も低いレイテンシ：ストリーミングデータ処理における遅延を最小限に抑えること。 【なぜ C が正解か】 KCL（Kinesis Client Library）は以下の機能を提供します： ・シャードレベルの制御：KCL を使用することで、アプリケーションが個別のシャードからデータを読み取り、並列性や負荷分散を細かく制御できます。 ・カスタムチェックポイント：Lambda の自動チェックポイント機能に依存せず、アプリケーション側で任意のタイミングでチェックポイントを明示的にコミットできます。これにより、正確な「一度だけ」処理（exactly-once processing）が保証されます。 ・低レイテンシ：AWS Fargate 上で長時間実行される KCL アプリケーションは、Lambda のコールドスタートによる遅延を回避でき、安定したパフォーマンスを提供します。 【他の選択肢が不適切な理由】 A：Kinesis Data Firehose → S3 → S3 イベント通知 → Lambda の構成は、Firehose がデータをバッチ処理するためレイテンシが高く、シャード管理やカスタムチェックポイントの制御ができません。 B：Kinesis と Lambda の間に SQS 標準キューを挟むと、シャードのコンテキストが失われ（シャードレベル制御不可）、Lambda の SQS 統合による自動チェックポイントに依存するためカスタムチェックポイントが不可能です。さらに、追加のホップ（Kinesis → SQS → Lambda）によりレイテンシが増加します。 D：SQS FIFO キューも同様にシャード情報を持たず、シャードレベル制御やカスタムチェックポイントに対応しておらず、順序保証によるオーバーヘッドでレイテンシが増加します。 【補足：Lambda の制約】 ・Lambda は自動チェックポイントのみをサポートし、カスタムチェックポイントはできません。 ・Lambda はシャードからデータを読み取りますが、シャードの割り当てや再バランスなどの管理は行えません。 ・コールドスタートにより、予期しないレイテンシが発生する可能性があります。 【KCL の利点】 ・長期間実行されるプロセスであるため、コールドスタートが発生しません。 ・シャードへの明示的な割り当てと、アプリケーション主導のチェックポイント管理が可能です。 ・低レイテンシかつ正確な「一度だけ」処理を必要とするユースケースに最適です。 【正解のアーキテクチャ（C）】 Kinesis Data Streams → Fargate 上で実行される KCL アプリケーション ・KCL ワーカーが割り当てられたシャードからデータを処理します。 ・カスタムチェックポイントにより、進捗をアプリケーション側で確実に管理します。 ・Fargate により、スケーラブルかつ低レイテンシな実行環境が提供されます。 【結論】 選択肢 C のみが、すべての要件（シャードレベル制御、カスタムチェックポイント、最も低いレイテンシ）を満たします。他の選択肢はいずれもレイテンシの増加、シャード制御の欠如、またはカスタムチェックポイントの不備のいずれかを抱えています。