20250920_ServerlessDays

Transcript

1. 1 © 2025 Japan Digital Design, Inc. Takuya Yo nezawa 2025.09.20 （ほぼ）フルサーバレスで挑む！ メガバンクの業務を支えていくRAGアーキテクチャ ServerlessDays Tokyo 2025
2. 2 © 2025 Japan Digital Design, Inc. 米澤 拓也 Software Engineer Technology & Development Div. and Corporate Culture室 プロフィール 前職ではCCoE、現職ではSoftware Engineer。 フロント/バックエンドの実装からインフラ構築など何でもやってます 証券系→銀行系 と 金融×IT なキャリアを歩んでいます 生息地：大阪 & 奈良、 趣味：キックボクシング/総合格闘技 --- Fin-JAWSの運営、AWS Community Builder (Serverless, 2023〜) JAWS DAYS 2024/2025、JAWS PANKRATION 2024運営 takuya_y0ne
3. 3 © 2025 Japan Digital Design, Inc. JDDの特徴 MUFGにおけるJDDの役割 Japan Digital Design株式会社（JDD）は、AI・CX・Tech領域を組み合わせ、 MUFGのDX活動に対するソリューションを提供します。 MUFGとの協業・人材交流やR&D機能を通じて、金融のイノベーションを先導し、 MUFGのお客様にとっての金融体験やMUFGの事業環境をアップデートし続けます。 顧客・自社の ビジネス課題 ソリューション R&D ドメイン知識 人材交流による 金融DX人材育成・ DXナレッジ向上 専門人材 開発インフラ データ分析基盤・クラウドIT環境 エンジニアリング・データサイエンス・デザイン
4. 4 © 2025 Japan Digital Design, Inc. だいたいはこの話です https://prtimes.jp/main/html/rd/p/000000002.000166343.html
5. 5 © 2025 Japan Digital Design, Inc. 01 業務課題
6. 6 © 2025 Japan Digital Design, Inc. 既存の業務プロセス 拠点営業員 照会ヘルプデスク 銀行内資料データ インターネット情報 ⋯ 照会結果 照会履歴 お題としてはよくある(?)照会業務、とても大変 メールで情報照会 手動検索 照会結果の返信 照会内容の記録
7. 7 © 2025 Japan Digital Design, Inc. 既存の業務プロセス 拠点営業員 国内 415 支店 照会ヘルプデスク 銀行内資料データ インターネット情報 ⋯ 照会結果 照会履歴 お題としてはよくある(?)照会業務、とても大変 担当 5 人 約 3 時間/件 2000 件/年
8. 8 © 2025 Japan Digital Design, Inc. 既存の業務プロセス 拠点営業員 国内 415 支店 照会ヘルプデスク 銀行内資料データ インターネット情報 ⋯ 照会結果 照会履歴 お題としてはよくある(?)照会業務、とても大変 約 3 時間/件 2000 件/年 年間 6000 時間が 照会業務に費やされる 担当 5 人
9. 9 © 2025 Japan Digital Design, Inc. 02 我々のアプローチ
10. 10 © 2025 Japan Digital Design, Inc. 我々のアプローチ 拠点営業員 照会ヘルプデスク ⋯ 重労働化していた照会業務をRAGシステム化 拠点営業員によるセルフサービスでの情報照会 RAG検索システム データレイク 照会履歴 照会結果 WEB経由で情報照会 照会に利用する 資料のメンテナンス
11. 11 © 2025 Japan Digital Design, Inc. AWS環境 機能概要（主要部分のみ） Azure環境 管 理 者 向 け 営 業 員 向 け 資料管理機能 チャット 問い合わせ機能 検索機能 【OCR】 Document Intelligence 【検索】 AI Search インデックス登録 【データレイク】 - 資料画像 - OCRテキスト - 資料要約 - 属性情報 検索/チャット 【回答結果】 - 資料ファイル - 要約内容 - 検索スコア etc アップロード Hybrid検索
12. 12 © 2025 Japan Digital Design, Inc. 実際の画面 検索機能 チャット機能
13. 13 © 2025 Japan Digital Design, Inc. 03 システムの話
14. 14 © 2025 Japan Digital Design, Inc. システム鳥瞰図（一番大きいスタック） トータルで400弱のリソース （Infrastructure Composerで表示 ）
15. 15 © 2025 Japan Digital Design, Inc. システム鳥瞰図（一番大きいスタック） トータルで400弱のリソース （Infrastructure Composerで表示 ）
16. 16 CONFIDENTIAL © 2025 Japan Digital Design, Inc. Lambda × 30 NodejsFunction × 6 PythonFunction × 24 SNS × 12 SQS × 10 ECS Service × 4 DynamoDB × 9 S3 Bucket × 10 Step Functions × 6 他リソースも含めると、計450 システムの主用コンポーネント VPC × 1 Bedrock CDK Stack×3
17. 17 © 2025 Japan Digital Design, Inc. システム構成（ざっくりver） CloudFront Private subnet WAF 銀行環境 ECS Service ALB Embedding Azure AI Search Document Intelligence ECS Service ALB Frontend ECS Service ALB Backend ECS Service ALB Search 資料要約作成 ⋯ SNS SQS 資料公開 ⋯ SNS SQS 資料削除 ⋯ SNS SQS 資料非公開 ⋯ SNS SQS S3 資料アップロード DynamoDB S3
18. 18 © 2025 Japan Digital Design, Inc. CloudFront Private subnet WAF 銀行環境 ECS Service ALB Embedding ECS Service ALB Frontend ECS Service ALB Backend ECS Service ALB Search 資料要約作成 ⋯ SNS SQS 資料公開 ⋯ SNS SQS 資料削除 ⋯ SNS SQS 資料非公開 ⋯ SNS SQS S3 資料アップロード DynamoDB S3 Azure AI Search Document Intelligence システム構成（ざっくりver） こちらのAzureサービスについて解説
19. 19 © 2025 Japan Digital Design, Inc. OCR対象画像 OCR解析結果 Document Intelligence ? Azureが提供するドキュメント解析 （OCR）サービス AWSで言うところのTextract ▪ 豊富な解析機能 テキスト、テーブル、チェックマーク、 などのテキスト読み取りだけでなく、 文章の構造解析も出来る。 プリセットも多数用意されている。 ▪ 豊富な言語対応 2025/09時点で約70もの言語に対応 この中に 日本語 もある！！ （精度もGood）
20. 20 © 2025 Japan Digital Design, Inc. Azureが提供するフルマネージドの検索サービス 内包のベクトルDB/クエリエンジンも含めてフルマネージド ▪ フィルタ処理・メタデータ管理が楽 メタデータ含め、AI Searchに全部突っ込んでおけば、 SDK（OData構文）経由でプロパティ毎にフィルタ可能 → KBで言うmetadataファイルの作成・メンテが不要！！ （現在12万超のオブジェクトをS3に保管） ▪ トラフィックパターンに応じたチューニング Read/Writeの量に応じて最適化が可能 本システムでは読み取りのトラフィックが圧倒的多数なので、 レプリカ数を増やして対応している AI Search ? https://note.com/japan_d2/n/n19463bbf8b72 https://note.com/japan_d2/n/n38e0085050b6 Vector Store Query Engine AI Search - 資料情報 - 属性情報 - ベクトル クエリ クエリ結果
21. 21 © 2025 Japan Digital Design, Inc. CloudFront Private subnet WAF 銀行環境 Azure AI Search Document Intelligence ECS Service ALB Frontend ECS Service ALB Backend 資料要約作成 ⋯ SNS SQS 資料公開 ⋯ SNS SQS 資料削除 ⋯ SNS SQS 資料非公開 ⋯ SNS SQS S3 資料アップロード DynamoDB S3 ECS Service ALB Search ECS Service ALB Embedding システム構成（ざっくりver） タイトルの"ほぼ"ではない部分がこれ これらのECSサービスは、 GPUや特定インスタンス上で動かす必要があるため、 EC2上で稼働している
22. 22 © 2025 Japan Digital Design, Inc. Private subnet WAF ECS Service ALB Embedding Azure AI Search ECS Service ALB Search 資料公開 ⋯ SNS SQS 資料削除 ⋯ SNS SQS 資料非公開 ⋯ SNS SQS DynamoDB S3 S3 資料要約作成 ⋯ SNS SQS Document Intelligence ECS Service ALB Backend ECS Service ALB Frontend CloudFront 銀行環境 システム構成（ざっくりver） ここからは 「資料アップロード〜資料要約作成」の 非同期処理について解説 資料アップロード
23. 23 © 2025 Japan Digital Design, Inc. ファイル加工やOCR、要約処理など、 検索対象資料の下準備を行う ▪ S3 PutEvent起点の非同期処理 将来的なFan-outを見越し、 SNS+SQSを基本セットとして採用。 （後からSNS挟むのは大変そう...） ▪ StepFunctionsの流量制御 SQS→SFn起動はEventBridge Pipesを 利用すれば直通できるが、流量制御の 観点でトリガー用Lambdaを設置。 （SFn内で利用するBedrockのクオータ抵 触回避） 非同期処理シリーズ アップロード用 バケット WEB 管理者 SNS SQS SFnトリガー用 Lambda EventBridge 加工後資材格納 バケット 資料情報管理 テーブル アップロード リクエスト Presigned URL Put Event 定期起動 メッセージ SFn実行状況チェック / SFn起動 永続化 資料要約作成SFn ⋯ 資料情報履歴 テーブル 記録 SQS残弾チェック / メッセージ取得 非同期処理の境界 資料アップロード処理 ~ 処理フロー ~
24. 24 © 2025 Japan Digital Design, Inc. ファイル加工やOCR、要約処理など、 検索対象資料の下準備を行う ▪ S3 PutEvent起点の非同期処理 将来的なFan-outを見越し、 SNS+SQSを基本セットとして採用。 （後からSNS挟むのは大変そう...） ▪ StepFunctionsの流量制御 SQS→SFn起動はEventBridge Pipesを 利用すれば直通できるが、流量制御の 観点でトリガー用Lambdaを設置。 （SFn内で利用するBedrockのクオータ抵 触回避） 非同期処理シリーズ SQS SFnトリガー用 Lambda EventBridge 資料アップロード処理 ~ 処理フロー ~ 資料要約作成SFn ⋯ 営業員向けチャット機能 & 要約作成SFnが Bedrockのクオータを共有している 営業員向け機能 に影響が出ない範囲で流量制御を実施 流量制御 Bedrock Service Quotas
25. 25 © 2025 Japan Digital Design, Inc. ▪ 失敗時は問答無用ロールバック 臭い個別処理※1 が多く含まれるステート マシンであるため、エラーハンドリング は必須。リトライ処理も手厚く設定。 SAGAパターンのような高度な補償処理 は不要と判断。 「成功する/ゼロに戻してリトライ」の 思想でフローを設計 非同期処理シリーズ 資料アップロード処理 ~ StepFunctions ~ 初期チェック処理 PDFをページごとにPNG化 ページ毎の要約結果を統合、 属性情報をBedrockで生成 失敗時処理 （神ロールバック+通知） 処理モード分岐 （テキストベース/画像ベース） ページ単位でバラした PNGの処理 - Azure OCR処理 - Bedrockで要約作成 ※ テキスト/画像 で処理内容は別 （※1） ・PDF → ページごとにPNGへ変換 ・Document Intelligence呼び出し ・MapState内でのBedrockコール ・Bedrockへの画像ファイル投込
26. 26 © 2025 Japan Digital Design, Inc. 非同期処理シリーズ MUFG 統合報告書・ディスクロージャー誌 バックナンバー より Document Intelligence でOCR処理 PNGデータ OCRデータ PNG/OCRデータを 併用して要約 （マルチモーダル） Bedrock
27. 27 © 2025 Japan Digital Design, Inc. 非同期処理シリーズ MUFG 統合報告書・ディスクロージャー誌 バックナンバー より AI Search 要約作成 チャンク化＋ ベクトル化して AI Searchに登録 OCR PNG 検索/ チャット Cognitoユーザー 属性情報
28. 28 © 2025 Japan Digital Design, Inc. みなさんが思っているであろうこと SFnの中にこんなにゴツいLambda達を配置して 改修時に挙動の担保難しくない？ まだ困っていない。 Lambdaごとにユニットテストを書いているため、 SFnレベルでの考慮事項は入出力設定のみに絞れる （むしろSFn内でLambdaを使う方がテスト/挙動担保しやすい気もしている）
29. 29 © 2025 Japan Digital Design, Inc. 04 日々のシステム運用
30. 30 © 2025 Japan Digital Design, Inc. 極力メンテナンスフリーに GPU処理が必要となる関係上、 ECS on EC2の利用が必須 ▪ ECSタスクのサイジング 1タスクで1インスタンスのリソースを すべて使い切るよう設定（CPU/Mem） スケーリングが必要な場合でもECSサー ビスのタスク数を上げ下げするだけでOK ▪ Bottlerocket※1の採用 コンテナ実行に特化したOS 脆弱性対応の負荷を下げるために ECS標準AMIから乗り換え gp2前提＋EBSが2つ必要など、 少しクセはあるが脆弱性は大幅削減 ECS on EC2の運用 EC2 (GPU) ECS Task × 1 ECS Service Bottlerocket ※1 https://github.com/bottlerocket-os/bottlerocket ALB テキストEmbedding用 ECSサービス EC2であるためタスク起動に少々時間が掛かるが、 リアルタイム性を求められない非同期処理なので問題なし EC2を運用しているという感覚は全くない 資料の要約結果 ベクトル化結果 [0.1, 0.4, 0.8, 0.7, 0.2, … , 1.0] "このページはxxxについて説明 しています。hogehoge..."
31. 31 © 2025 Japan Digital Design, Inc. 生エラーログ見るの辛いよね 日々のアプリケーション運用 単純な仕組みだが、エラー調査の負荷が大幅に削減 （Lambda部分も大した記述量ではない） エラー情報 集約テーブル ECS SNS エラーハンドリング Lambda Bedrock （Sonnet） エラー内容要約 エラー内容保存 通知 要約メール Logs Metrics Alarm アラート用 SNS Amazon Q （旧Chatbot） アラート用 チャンネル ▪ CW Logs + Lambda エラー内容の要約・保存・通知を行う Logsのサブスクリプションフィルターを 利用し、エラーログが流れたらLambda を起動する 基本的にはこちらを見ている ▪ CW Metrics + Chatbot Container Insightsで取得できる メトリクス＋Logsのパターンマッチ監視 閾値を超えた場合、SNS・AmazonQ経由 でSlackの専用チャンネルに通知 Logs＋Lambdaの経路で何かしらエラー が発生すると検知不能になるため別経路 として利用している。 （この方式だとロジック不要で実現可）
32. 32 © 2025 Japan Digital Design, Inc. 生エラーログ見るの辛いよね ▪ CW Logs + Lambda エラー内容の要約・保存・通知を行う Logsのサブスクリプションフィルターを 利用し、エラーログが流れたらLambda を起動する 基本的にはこちらを見ている ▪ CW Metrics + Chatbot Container Insightsで取得できる メトリクス＋Logsのパターンマッチ監視 閾値を超えた場合、SNS・AmazonQ経由 でSlackの専用チャンネルに通知 Logs＋Lambdaの経路で何かしらエラー が発生すると検知不能になるため別経路 として利用している。 （この方式だとロジック不要で実現可） 日々のアプリケーション運用 単純な仕組みだが、エラー調査の負荷が大幅に削減 （Lambda部分も大した記述量ではない） エラー情報 集約テーブル ECS SNS エラーハンドリング Lambda Bedrock （Sonnet） エラー内容要約 エラー内容保存 通知 Logs Metrics Alarm アラート用 SNS Amazon Q （旧Chatbot） 要約メール アラート用 チャンネル
33. 33 © 2025 Japan Digital Design, Inc. 今のところ辛くはない 大量のLambdaメンテ辛くない？ ▪ CDKでカスタムクラスを作成 Lambda関数において、強制したい プロパティを事前定義したカスタムクラス を作成しておく （ランタイムやトレース/ログ設定など） ランタイムの更新などが必要になっても、 カスタムクラスのプロパティだけ修正すれ ば全Lambda関数をまとめてアップデート 可能。 カスタムクラスを利用していない Lambda関数定義などはlintエラーで弾く （no-restricted-imports） 事前定義するプロパティ 事前定義プロパティを 抜いたProps定義 カスタムクラス定義
34. 34 © 2025 Japan Digital Design, Inc. 今のところ辛くはない 大量のLambdaメンテ辛くない？ ▪ CDKでカスタムクラスを作成 Lambda関数において、強制したい プロパティを事前定義したカスタムクラス を作成しておく （ランタイムやトレース/ログ設定など） ランタイムの更新などが必要になっても、 カスタムクラスのプロパティだけ修正すれ ば全Lambda関数をまとめてアップデート 可能。 カスタムクラスを利用していない Lambda関数定義などはlintエラーで弾く （no-restricted-imports） 色々差っ引いた結果、Lambdaのリソース定義はこれだけでOKに
35. 35 © 2025 Japan Digital Design, Inc. 05 金融グループにおける 各種要件を実現するために
36. 36 © 2025 Japan Digital Design, Inc. 通信経路 〜アプリケーション〜 セキュリティ 通信の入口を縛ることにより、 セキュリティ周りで考えないといけない ことを一気に減らす ▪① CloudFront（WEBアクセス） VPC Originsの活用でFrontend/Backend のALBをPrivate Subnetに配置 WAFで銀行環境IPからのアクセスに制限 ＋トラフィック検閲 ▪② Azure（AI Searchアクセス） ECS SearchサービスからAI Search内 インデックスへのクエリが走る AI Search側でアクセス元IPをNAT-GWに 固定 CloudFront Private subnet ECS Service ALB Frontend ECS Service ALB Backend ECS Service ALB Search Public subnet NAT-GW Azure AI Search Internet WAF 銀行環境 ① ② ゼロトラストの考え方もあるが、 アクセス元が明確な場合は やはりIPアドレス制限が効果的
37. 37 © 2025 Japan Digital Design, Inc. 通信経路 〜非同期処理〜 セキュリティ 通信のStepFunctions内で呼び出している Lambdaは、必要最低限な物のみVPC内で 起動 ▪ バケットへの資材アップロード 短命なアップロード用のPresigned URLを 発行する URL発行にはBackendサービス経由 （= Cognito認証が必須） ▪ StepFunctions（資料要約作成） Document Intelligenceへのアクセスが必 要なOCR処理LambdaのみVPC内で起動 それ以外のLambdaは、アクセス先が全て AWSサービスに限られるため※1、非VPC での実行で問題なし Public Subnet NAT-GW Azure Internet 資料要約作成SFn 初期処理 PNG分割 OCR処理 (on VPC) サマリ生成 Document Intelligence 属性予測 資料情報管理 テーブル アップロード用 バケット 加工済み資材 バケット Bedrock Private Subnet ※1 AWSのグローバルIPの空間はインターネットなのか？ https://tech.nri-net.com/entry/2021/05/10/085654 Presigned URL Cognito
38. 38 © 2025 Japan Digital Design, Inc. アプリケーション認証 セキュリティ・監査 Exceptionなどで Lambdaのロジックが落ちると ユーザーが軒並みログイン不可になるという事象が発生する トリガー導入の際は要注意 ▪ 行内EntraIDとCognitoを接続 Frontend/Backendアプリケーションの ログイン機構としてCognitoを採用 全支店展開後もCognitoの サービスクオータは全く問題なし （Rate of UserAuthentication requests） ▪ CognitoのLambdaトリガーを 設定し、ログイン履歴を収集 外部IdPとCognitoを接続する場合、 Cognito単品ではログ取得が不可能 Lambdaトリガーを設定し、 監査で必要なログイン履歴を取得 Cognito ログ記録用 Lambda 行内Entra ID 銀行環境 Backend ログイン履歴 テーブル Frontend Token サインアップ前トリガー 認証後トリガー ログイン
39. 39 © 2025 Japan Digital Design, Inc. データ変更の追跡 監査 ▪ DDB Streamを用いたロギング メインの情報管理用テーブルに加え、 監査用のDynamo Tableを作成。 Dynamo DB Streams → Lambdaの 統合で変更追跡を実施し、特定パターン にマッチする場合に記録を行う。 記録内容が増えても Alter Tableしなくて良い！！ 変更追跡の導入によりDynamoDBの 負荷上昇も考えなくて良い！！ ▪ TTLの設定 管理者向けに変更履歴ダウンロードを 備えており、履歴レコード増大によるパ フォーマンス影響を防ぐためにTTL属性 を設定。 （他の履歴保存テーブルもTTLを設定） 資料情報管理 テーブル 変更履歴 テーブル 履歴記録用 Lambda Stream （新旧イメージ） WEB 管理者 記録用に データの一部を整形 情報更新 保存
40. 40 © 2025 Japan Digital Design, Inc. 06 さいごに
41. 41 © 2025 Japan Digital Design, Inc. 少し未来の話を 大きい目線で見ると、 ベースのRAG検索部分を作っただけ。 今後は統計データといった非構造化データ×Text to SQLや 金融特化WEB検索エージェントの実現に向けて色々と検証中
42. 42 © 2025 Japan Digital Design, Inc. さいごに 上手いこと行った話が中心でしたが、 色々とハマった/辛かったポイントもあります ご興味がある方は懇親会やDay2でお声掛けください！
43. Thank you. 43 © 2025 Japan Digital Design, Inc.