自動車部品メーカーが、工場の IoT センサーデータ（構造化 JSON、毎時 2GB）と設備保守ログ（非構造化テキスト・PDF）を組み合わせた予防保全 RAG システムを Amazon Bedrock Knowledge

Question

自動車部品メーカーが、工場の IoT センサーデータ（構造化 JSON、毎時 2GB）と設備保守ログ（非構造化テキスト・PDF）を組み合わせた予防保全 RAG システムを Amazon Bedrock Knowledge Bases で構築しています。要件は以下の通りです。
・5TB の過去データの初回一括取り込み
・毎時の差分データをインデックスに自動反映
・センサー数値の正規化と機器 ID の標準化を前処理として必須実施
・フルマネージドで運用負荷を最小化
上記を満たす最適なデータパイプラインアーキテクチャはどれですか。

Accepted Answer

正解: AWS Glue ETL ジョブで正規化・標準化の前処理を実施した後に処理済みデータを S3 へ保存し、Bedrock Knowledge Bases のデータソースに S3 を指定してスケジュールド同期（毎時）を設定する。AWS Glue ETL はフルマネージドのサーバーレス ETL サービスであり、センサー数値の正規化・機器 ID 標準化などの大規模前処理を管理不要で実行できます。処理済みデータを S3 に保存した後、Bedrock Knowledge Bases の S3 データソースにスケジュールド同期（毎時）を設定することで差分の自動取り込みが実現します。初回 5TB の一括処理と継続的な差分更新の両方に対応し、サーバー管理不要でフルマネージド要件を満たします。

選択肢AのEventBridgeスケジューラー + Lambdaは Lambda の最大実行時間（15 分）の制約があり、5TB 初回一括処理や大規模な ETL 前処理が困難です。Glue と比較してコード保守負荷も高くなります。
選択肢CAmazon Kinesis + OpenSearch への直接ストリーミングは Bedrock Knowledge Bases を使用せず独自ベクターインデックス管理が必要となり、フルマネージド要件を満たしません。
選択肢DのGlue Streaming + SageMaker Processing Jobsの組み合わせはコンポーネントが分散してアーキテクチャが複雑化し、Bedrock Knowledge Bases の一元管理という利点を損なって運用負荷が増大します。

Answer

EventBridge スケジューラーで毎時 Lambda を起動し、S3 の差分ファイルを前処理・チャンキングして Bedrock Knowledge Bases の StartIngestionJob API でインデックスを更新する — Lambda の最大実行時間は 15 分であり 5TB の初回一括前処理には不向き。また差分管理ロジックを自前で実装する必要があり Glue ETL と比較してコード量・保守負荷が増大するため、フルマネージド要件を完全には満たさない。

Answer

Amazon Kinesis Data Streams でセンサーデータをリアルタイム取り込みし、Amazon Data Firehose で変換・整形後に OpenSearch Service のベクターインデックスへストリーミング書き込みする — Kinesis + OpenSearch への直接ストリーミングは Bedrock Knowledge Bases を迂回するため、Knowledge Bases のフルマネージドな埋め込み生成・インデクシング機能を活用できない。ベクターインデックスの独自管理が必要で運用負荷が増大する。

Answer

AWS Glue Streaming ETL でセンサーデータをリアルタイム処理し、SageMaker Processing Jobs で PDF を個別に前処理して、それぞれ異なるベクターストアに格納し Bedrock Knowledge Bases から参照する — Glue Streaming ETL と SageMaker Processing Jobs を別々に運用し複数ベクターストアに格納する構成はコンポーネントが増えてアーキテクチャが複雑化し、Bedrock Knowledge Bases のフルマネージドな一元管理という利点を失って運用負荷が増大する。

解説

解説