ある製造会社は、工場内の10,000台の機械センサーからリアルタイムのテレメトリデータを収集し、Amazon Kinesis Data Streamsに送信しています。データエンジニアリングチームは以下の処理を継続的に実行するパイプラインを構築する必要があります。
・Kinesis Data Streamsから継続的にデータを読み取る
・Amazon S3に保存された機械マスタデータでエンリッチメントを行う
・異常値フィルタを適用する
・Parquet形式でAmazon S3へ継続的に出力する
チームはAWS Glueの既存スキルを活かし、サーバーレスでインフラ管理を最小化したいと考えています。この要件を最もよく満たすソリューションはどれですか？
A
Amazon Managed Service for Apache Flinkを使用してカスタムJavaアプリケーションを開発し、Kinesis Data StreamsからS3へ出力する
Amazon Managed Service for Apache FlinkはKinesis Data Streamsとの統合が可能ですが、カスタムJavaアプリケーションの設計・開発・デプロイが必要でGlueの既存スキルを流用できません。専用クラスターの管理も発生しサーバーレスという要件も満たしません。
B
AWS Glue ストリーミングETLジョブを使用してKinesis Data Streamsから継続的に読み取り、変換後にParquet形式でS3へ出力する
✓ 正解
AWS Glue ストリーミングETLはKinesis Data Streamsをネイティブサポートし、Apache Spark Structured Streamingベースのマネージド継続処理を提供します。既存のGlue PySpark/Scalaスキルを活用でき、S3マスタデータを使ったエンリッチメント・フィルタリング・Parquet出力をサーバーレスで実装できます。
C
AWS Lambda関数をKinesis Data Streamsのトリガーとして設定し、S3マスタデータを参照して変換後にS3へ書き込む
Lambda関数はKinesis Data Streamsのトリガーとして設定可能ですが、最大15分の実行時間制限とメモリ制約があります。10,000台のセンサーからの大規模ストリームを継続的に変換・エンリッチメントするには処理能力と持続性が不十分であり、大規模ETLには適しません。
D
Amazon Data Firehoseに切り替え、Lambda変換を使用してParquet形式でS3に出力する
Amazon Data FirehoseはKinesis Data Streamsと別サービスであり切り替えにはアーキテクチャ変更が伴います。Lambda変換には6MBのペイロード制限があり、S3マスタデータとの複雑なエンリッチメント処理を実装するには制約が大きく最適ではありません。
解説
AWS Glue ストリーミングETLは、Kinesis Data StreamsおよびMSKをソースとしてネイティブサポートし、Apache Spark Structured Streamingベースのマネージドな継続処理を提供します。既存のGlue PySpark/Scalaスキルをそのまま活用でき、S3上の参照データを使ったエンリッチメント・異常値フィルタリング・Parquet出力をサーバーレスで実装できます。
選択肢AのAmazon Managed Service for Apache Flinkはカスタムコード開発・デプロイが必要でGlueスキルを活用できず、運用負荷も高い。
選択肢CのAWS Lambdaは最大15分の実行時間制限とメモリ制約があり、大規模センサーストリームの継続的な変換・エンリッチメントには不向き。
選択肢DのAmazon Data FirehoseはLambda変換の6MBペイロード制限があり、S3マスタとの複雑なエンリッチメント処理には制約が生じる。