SQSとPipesで回す BedrockによるPDF解析

PDF解析のUXを向上させた話

JAWS茨城でLTしてきました

https://x.com/hashtag/jawsugibaraki?src=hashtag_click

Transcript

1. SQSとPipesで回す BedrockによるPDF解析 PDF解析のUXを向上させた話 株式会社KURUM（くるむ） 公式キャラクター くるむセンパイ
2. PROFILE 自己紹介 株式会社KURUM（くるむ）代表 （東京都渋谷区） 茨城県高萩市 出身 國井 弘一 くにい　 こういち 主な事業内容 WEBシステム開発 スマホアプリ開発 インフラ構築 Consulting Development Data WEBシステム開発 スマホアプリ開発 データ基盤 伴走型コンサル 2
3. 自己紹介 3 茨城県高萩市の 海の近くで育ちました 最近、映えスポットに なってるみたいです
4. 自己紹介 4 高校時代に水戸のライトハウスで ライブやりました 最近もたまに練習だけしてます
5. 今日話すこと 5 課題①: オンデマンドにLLMで画像解析を行うと、処理時間・同時実行数の問題がある 課題②: ユーザーに解析状態や結果をストレスなく表示する必要がある キューイング機構＋ジョブ管理＋ECS RunTask＋Bedrock 解決策
6. アーキテクト図 1.ファイルアップロード
 ユーザーがPresigned URLでS3に直接アップロード 2.Jobの保存 a.Auroraにジョブレコードを作成 （status=queued） 3.キューイング a.S3イベント→ SQSに メッセージ投入 4.キューを受け取ってバッチ実行 a.EventBridge PipesがSQSをトリガー b.ECS RunTaskを起動 5.ファイルをダウンロード a.RunTaskがS3からPDFを取得 6.解析実行 a.PDFをページ分割 → 画像化 → base64化 b.Bedrockに投げてJSONを取得 7.解析結果を保存 a.S3にJSON保存 b.Auroraに結果メタデータを登録 ECS API Aurora ジョブのステータス管理、 解析結果管理 ECS バッチ Bedrock S3 PDF保管用ストレージ SQS EventBridgePipe 6
7. 7 主要コンポーネントの設計ポイント
8. S3 ・Appサーバーに負荷をかけない 　 〇アップロード／ダウンロードは 一時URL（Presigned URL） を発行 　 〇クライアントが直接S3にアクセスする構成 ・データの扱い 　 〇元データは そのまま保存 　 〇プレビュー表示用に利用 ・アクセス制御 　 〇アカウントIDとオブジェクトを紐づけ 　 〇アップロードしたユーザーのみ閲覧可能になるように調整 8
9. Aurora 9 ・ジョブ状態管理 　 〇受付→実行中→成功/失敗。再実行やDLQ再投入時も冪等に追跡。 ・結果保存 　 〇S3の場所と要約/抽出値をメタデータ(JSON)で保持（本体はS3のまま）。 　 〇ページ単位の解析結果を保持。 　 〇解析不能ページの場合はエラー内容を格納することで再実行やトラブルシュートを容易化。
10. EventBridgePipe 10 ・コード管理不要 　 〇SQS → ECS RunTaskをコードレスで接続 ・データ整形 　 〇Input Transformer でSQSメッセージを整形してECSタスクに渡せるリトライ戦略 ・リトライ戦略 　 〇失敗時DLQ をマネージドで提供 ・バッチサイズ・並列数でスロットリング制御 　 〇何件まとめて処理するかを制御 　 〇RunTaskの同時実行数を制限してスパイク対策 ・可観測性 　 〇CloudWatch Logsに自動でイベントが出る
11. Bedrock 11 ・PDFをそのまま渡せない 　 〇事前に ページごとに分割 　 〇画像に変換 → base64化 してモデル入力に渡す ・プロンプト設計 　 〇「該当項目をJSONで返すように」明確に指示 　 〇出力フォーマットを固定し、後段処理がしやすい形に （※テキストでjson形式で返してもらいアプリ側でdecode ） ・構造化データの抽出と 　 〇Claude系で構造化抽出 　 〇将来的に別モデルに切り替えても「抽出器」として差し替えやすい
12. 12 処理の流れ
13. 処理のながれ - 解析実行 1.ファイルアップロード
 ユーザーがPresigned URLでS3に直接アップロード 2.Jobの保存 a.Auroraにジョブレコードを作成 （status=queued） 3.キューイング a.S3イベント→ SQSに メッセージ投入 4.キューを受け取ってバッチ実行 a.EventBridge PipesがSQSをトリガー b.ECS RunTaskを起動 5.ファイルをダウンロード a.RunTaskがS3からPDFを取得 6.解析実行 a.PDFをページ分割 → 画像化 → base64化 b.Bedrockに投げてJSONを取得 7.解析結果を保存 a.S3にJSON保存 b.Auroraに結果メタデータを登録 ECS API Aurora ジョブのステータス管理、 解析結果管理 ECS バッチ Bedrock S3 PDF保管用ストレージ SQS EventBridgePipe 13
14. 処理のながれ - 実行の状態確認 2.Jobの状態取得 1.ジョブの実行状態確認 フロントエンドからAPIを 定期的にポーリング ECS API Aurora ジョブのステータス管理、 解析結果管理 ECS バッチ Bedrock S3 PDF保管用ストレージ SQS EventBridgePipe 14
15. 処理のながれ - 解析実行 3. S3からPDF取得
 Presigned URLを発行して、元のPDFや 解析結果ファイルを取得 2.解析結果の取得 Auroraに保存されたメタデータ （S3キー、JSON結果など）を取得 ECS API Aurora ジョブのステータス管理、 解析結果管理 ECS バッチ Bedrock S3 PDF保管用ストレージ SQS EventBridgePipe 15 1.ジョブの実行結果取得
16. 16 まとめ
17. 実現できたこと ・ユーザーUX向上 　 〇時間のかかる解析処理でも、進行状況をリアルタイムに表示 　 〇Bedrockの制約（同時実行や処理時間）に引っ張られず安定稼働 ・堅牢な基盤 　 〇SQSでエラー時リトライをアプリから切り離し 　 〇S3のPresigned URLで安全に直接アップロード／ダウンロード 　 〇システムに負荷をかけずに重いファイル転送を実装 17 ・既存システムの流用 　 〇SQSだとLambdaと連携することが多いイメージだが、Pipesを使うことで 　 　 既存ECSタスクと連携することができた
18. 実現できたこと 従来OCR フォーマット依存 帳票ごとにレイアウトを定義しないと正しく認識できない。 文書種別の判定が困難 「それが目的の書類かどうか」といった文書分類までは行えない。 学習・準備コストが高い 機械学習ベースのアプローチもあるが、大量の教師データ準備や学習コストがかかる。 18 ・Bedrockによる開発工数の圧縮
19. ハマったポイント ・EventBridge Pipes 　 〇ECS RunTaskの詳細設定は マネコンから直接できない 　 〇CLI／IaC（CloudFormationやTerraform）で更新必須 ・RunTask起動のパラメータ調整 　 〇cpu / memory / networkConfiguration を誤ると起動失敗 　 〇IAMロール（実行ロール／タスクロール）の混同に注意 ・ローカル環境での開発 　 〇LocalStackのSQSのキューのサブスクライブはLambdaしか対応してないので再現が難しい 　 〇SQSをポーリングしてdocker runをしてバッチコンテナを起動することで対応 　 〇本番ECSでのECS Run Taskの起動引数はEventBridgePipeのトランスフォームでSQSの
 　 　 メッセージを加工調整できるためこの辺の環境差異で問題が起きることはない 19
20. 今後の課題 20 ・Job管理のスケール 　 〇Auroraで高頻度ポーリングしているため、DynamoDBやKVSへの移行検討余地あり ・ユーザー通知改善 　 〇完了時に Push通知 で即時伝える仕組みを導入 　 〇結果の画面反映を WebSocket化してストレスフリーに
21. \ ご清聴ありがとうございました / 21