Upgrade to Pro — share decks privately, control downloads, hide ads and more …

LayerXインボイスのAI-OCRを支える非同期処理アーキテクチャ / AWS Dev Day Online Japan 2021

LayerXインボイスのAI-OCRを支える非同期処理アーキテクチャ / AWS Dev Day Online Japan 2021

7584a5da756f1ab14ed0cd1081a6acd5?s=128

Shun Takagiwa

October 02, 2021
Tweet

Transcript

  1. © 2021 LayerX Inc. LayerX インボイスのAI-OCRを支える 非同期処理アーキテクチャ 高際 隼 株式会社LayerX

    DX事業部 AI-OCRチーム Lead AWS Dev Day Online Japan 2021 E-2
  2. © 2021 LayerX Inc. 2 このセッションでお伝えしたいこと ✅ 重く、突然急増しやすいAI-OCRの処理を分散するため、   どのようにAWSを活用したか

    ✅ AWSの活用によって、顧客にどのような価値が生じたか ❌ 一方で、AI-OCRの処理の中身や、読み取り精度向上の   具体的な方法については話さない
  3. © 2021 LayerX Inc. 3 自己紹介 高際 隼(たかぎわ しゅん) @shun_tak

    2018年8月、株式会社LayerXに参画 現在、DX事業部にてAI-OCRチームのLeadを担当 サーバーサイドJava→Node.js→Goと経験し、 Goも結構好きになってきました AWSもよくいじります! 好きなAWSサービスはオートスケーリングです! LayerXは技術や事業だけでなく、組織やカルチャーなど どんなトピックでも深いディスカッションができ、 学びの多い環境でありがたいです。 同僚に感謝!
  4. © 2021 LayerX Inc. 4 会社概要 * 資本準備金含む 会社名 代表取締役

    創業 従業員数 資本金* 事業概要 関連会社 株式会社LayerX(レイヤーエックス) 福島 良典(東証一部上場企業 Gunosy創業社長) 2018年 8月1日 47名(25名エンジニア) 31億円 DX事業、金融事業、ブロックチェーン事業 三井物産デジタル・アセットマネジメント (三井物産、LayerX、三井住友信託銀行、 SMBC日興証券による合弁会社) すべての経済活動を、デジタル化する。
  5. © 2021 LayerX Inc. 5 会社概要 すべての経済活動を、デジタル化する。 ※ アセットマネジメントの DX

    ※電子投票 企業のDX 金融のDX 行政のDX
  6. © 2021 LayerX Inc. 6 アジェンダ プロダクト紹介 開発方針 アーキテクチャ •

    AI-OCRの処理の概要 • 技術的に難しいところ • 解決方法 • 実装 • 結果 • 実装上の注意点 今後の課題 まとめ
  7. © 2021 LayerX Inc. 7 アジェンダ プロダクト紹介 開発方針 アーキテクチャ •

    AI-OCRの処理の概要 • 技術的に難しいところ • 解決方法 • 実装 • 結果 • 実装上の注意点 今後の課題 まとめ
  8. © 2021 LayerX Inc. 8 LayerXインボイスとは 企業A 企業B 売り手・受注者 買い手・発注者

    請求書を発行 請求書を受け取り 会計・支払処理 受け取った請求書の処理を効率化するサービスです
  9. © 2021 LayerX Inc. 9 ライブデモ

  10. © 2021 LayerX Inc. 10 「手入力ゼロ」 で請求書処理が終わる 目指すビジョン

  11. © 2021 LayerX Inc. 11 プロダクト AI-OCRによる自動読取 仕訳の自動入力補完・振込データ自動生成 会計システムとシームレスに連携 AI-OCRによる稟議の自動下書・申請補助

    購買申請との紐付けで予算管理 Slack連携でSlackで承認が完結 請求書の処理は「経理」だけで終わらない。支払申請する「現場」のための LayerX ワークフローも提供 AWS利用料 支払申請 ソフトウェア ライセンス 購入申請 どちらも手入力ゼロの起点となる AI-OCRを備えている
  12. © 2021 LayerX Inc. 12 アジェンダ プロダクト紹介 開発方針 アーキテクチャ •

    AI-OCRの処理の概要 • 技術的に難しいところ • 解決方法 • 実装 • 結果 • 実装上の注意点 今後の課題 まとめ
  13. © 2021 LayerX Inc. 13 LayerXの開発スタイル お客様に価値を届け続けることにこだわる • 🙆 顧客価値を作れてこそのアーキテクチャ

    • 🙅 エンジニアの満足を追求 動くものを素早く提供し、フィードバックをすぐに反映 • 運用負荷を下げ、サービス開発に集中するため、マネージドサービスや SaaSを徹底活用 参考(LayerXエンジニアブログより) • LayerX インボイスの紹介と開発風景 • 「時間・学び・セキュリティ」新規プロダクト開発で意識したことーAWSイベント登壇を終えてー
  14. © 2021 LayerX Inc. 14 AI-OCRの開発で大切にしている指標 お客様の価値につながる指標を大切に • 読み取り精度  → 手入力ゼロに直結

    • 読み取り速度  → 遅かったら手入力した方がいい • 同時実行数   → まとめて処理したい需要に応える • 可用性     → いつでも処理できる • インフラコスト → お求めになりやすい価格 直近では読み取り精度が課題 • 新規導入が急増している • 新しいパターンの請求書がどんどん出てくる 本講演では、読み取り速度、同時実行数、可用性、インフラコストの改善について紹介
  15. © 2021 LayerX Inc. 15 アジェンダ プロダクト紹介 開発方針 アーキテクチャ •

    AI-OCRの処理の概要 • 技術的に難しいところ • 解決方法 • 実装 • 結果 • 実装上の注意点 今後の課題 まとめ
  16. © 2021 LayerX Inc. 16 AI-OCRの処理の概要 請求書ファイル 前処理 文字認識 意味付け

    入力画像内の「文字」と 「位置情報」を読み取る 読み取った「文字」に 意味を与える 例)支払金額:500,000円   支払期日:2021/02/28 後処理 読み取れた!
  17. © 2021 LayerX Inc. 17 AI-OCRの処理の技術的に難しいところ 処理が重い • 全部の処理が終了するまで請求書 1件あたり数秒かかる

    • それぞれの処理が互いに影響して遅くならないようにしたい 処理件数が急増しやすく、いつ来るかわからない • 100枚単位でアップロードされることがよくある • 長期トレンドでは平日昼間や月末月初の負荷が高いが、分単位では予測不可能 ◦ オートスケーリングでも間に合わない可能性 ◦ 予めサーバ台数を確保してもいいが、いつ来るかわからないのでコスパも悪くなる 請求書ファイル 前処理 文字認識 意味付け 後処理 読み取れた!
  18. © 2021 LayerX Inc. 18 解決方法 請求書のアップロードと保存が完了したら、残りは非同期処理 • Amazon SQSで残りの処理を切り離し、別サーバで処理

    • 重い処理は、呼び出しごとに個別の環境を素早く並列に起動し実行する AWS Lambdaを活用 • Amazon Elastic Container Service (Amazon ECS) はAWS Fargate上で稼働 SQS ECS Lambda S3 Aurora ECS 1. アップロード 2. 保存 3. メッセージ 送信 4. メッセージ 受信 5. 非同期処理 重い処理は分離 (同期呼び出し) ECS 処理状況 を記録 SQS 6. 次の処理へ SQS 受信 送信 ECS 処理状況 問い合わせ 参照 S3 Lambda S3
  19. © 2021 LayerX Inc. 19 アジェンダ プロダクト紹介 開発方針 アーキテクチャ •

    AI-OCRの処理の概要 • 技術的に難しいところ • 解決方法 • 実装 • 結果 • 実装上の注意点 今後の課題 まとめ
  20. © 2021 LayerX Inc. 20 インフラレベルの実装 ECS Lambda Aurora SQS

    S3 ECS Aurora ECS ECS Aurora Aurora ECS Aurora SQS SQS SQS SQS S3 S3 S3 S3 Lambda Lambda AWS Lambda 使わない処理もある 条件に応じて 異なるLambda関数を実行 非同期タスク管理は go のmachineryで制御 実際はもっと多くのステップ と処理の分岐もあるよ 請求書ファイル 前処理 文字認識 意味付け 後処理 読み取れた!
  21. © 2021 LayerX Inc. 21 machineryとは? machineryはgoで利用可能な、分散メッセージ受け渡しに基づく、非同期タスク管理フレームワーク SQS ECS メッセージ

    受信 非同期処理 SQS メッセージ送 信 ↑ ここで動くのが machinery メッセージブローカーとして、 SQSはもちろん、RedisやAMQPなども利用可能 メッセージに応じて異なるタスクを実行するだけでなく、遅延実行したり、 エラーのリトライ時にはタイミングや回数の制御もでき、多段タスクや並列タスクの実行も可能 更に、タスクの定期的な実行も可能 参考:https://github.com/RichardKnop/machinery
  22. © 2021 LayerX Inc. 22 コードレベルの実装( machinery) 送受信するメッセージ本文の構造 タスクの登録 受信したメッセージの

    Nameとマッチしたら 指定の関数が実行される メッセージの送信
  23. © 2021 LayerX Inc. 23 コードレベルの実装( AWS SDK Go -

    Lambda Invoke) Lambda関数の実行(同期呼び出し)
  24. © 2021 LayerX Inc. 24 結果 AI-OCRの処理の技術的に難しいところ(再掲) • 処理が重い •

    処理件数が急増しやすく、いつ来るかわからない 解決方法(再掲) 請求書のアップロードと保存が完了したら、残りは非同期処理 • Amazon SQSを活用し、請求書保存より先の処理を別サーバに分離 • 重い処理にAWS Lambdaを活用し、呼び出しごとに個別の環境を素早く並列に起動し実行 その結果 • 読み取り速度  → 処理件数が急増しても重くならない • 同時実行数   → 月初の大量アップロードも問題なくスケール • 可用性     → 運用初期にSQSを詰まらせたが、それ以降は無停止を実現 • インフラコスト → 実行した分だけ課金
  25. © 2021 LayerX Inc. 25 デモ

  26. © 2021 LayerX Inc. 26 実装上の注意点 • Amazon SQS •

    AWS Lambda • machinery
  27. © 2021 LayerX Inc. 27 実装上の注意点(Amazon SQS) • 可視性タイムアウト (Visibility

    timeout) とは ◦ SQSは分散システム → どこでどんなフェイルが発生するかわからない ◦ 処理に想定以上の時間がかかる場合、メッセージを再送信したい = 処理を再実行したい ◦ 処理が長引き、SQSの可視性タイムアウトで設定された時間を超えると、 そのメッセージは再度受信できるようになる(実質的にはメッセージの再送信) ◦ 想定以上に処理が長引く場合、可視性タイムアウトを延長するか (ChangeMessageVisibility API) 再実行に対して冪等な実装にする必要がある • メッセージを実際に受信しないと中身が見れない = その間、そのメッセージの受信はできなくなる ◦ メッセージが詰まった時に確認しづらい
  28. © 2021 LayerX Inc. 28 実装上の注意点(AWS Lambda) • Runtimeの制限 ◦

    最新のNode.js 16が動かない等 • リソースの制限 ◦ 前提知識:割り当てメモリの設定= CPUパワーの設定 ◦ 最近メモリ最大10GBに増えた! ◦ それでもCPUパワーが強力とは言えない ◦ GPU計算はできない • スロットリングを考慮 ◦ 指数関数的にリクエストが増えると同時実行数の制限に達することがある ◦ AWSアカウント×リージョンごとに制限(クオータ)を共有していることにも注意 ◦ 必要に応じて失敗時の制御を追加すべし
  29. © 2021 LayerX Inc. 29 実装上の注意点(machinery) • 実行される関数の引数と送信メッセージの Argsは 個数と順番が常に一致する必要がある

    ◦ 後方互換性を保って変更する ◦ 変更したい場合、まず新たなタスクを登録し 古いジョブはすべてのメッセージ消費後に削除 • machinery もそれなりに負荷が上がる ◦ オートスケーリングの設定を忘れずに タスクの登録(再掲) 受信したメッセージの Nameとマッチしたら 指定の関数が実行される メッセージの送信(再掲)
  30. © 2021 LayerX Inc. 30 アジェンダ プロダクト紹介 開発方針 アーキテクチャ •

    AI-OCRの処理の概要 • 技術的に難しいところ • 解決方法 • 実装 • 結果 • 実装上の注意点 今後の課題 まとめ
  31. © 2021 LayerX Inc. 31 今後の課題 • 処理のワークフローが複雑になってきた • 非同期処理の状況を可視化したい

    • より柔軟なリトライ制御をしたい まだまだ他にも課題だらけです …
  32. © 2021 LayerX Inc. 32 まとめ 課題 AI-OCRの処理は重く、処理件数も急増しやすい。タイミングは予測不可能 解決方法 請求書のアップロードと保存が完了したら、残りは非同期処理

    • Amazon SQSを活用し、請求書保存より先の処理を別サーバに分離 • 重い処理にAWS Lambdaを活用し、呼び出しごとに個別の環境を素早く並列に起動し実行 その結果 • 読み取り速度  → 処理件数が急増しても重くならない • 同時実行数   → 月初の大量アップロードも問題なくスケール • 可用性     → 運用初期にSQSを詰まらせたが、それ以降は無停止を実現 • インフラコスト → 実行した分だけ課金
  33. © 2021 LayerX Inc. 33 PR LayerX インボイスは受け取った請求書の処理を効率化するサービスです! ぜひ経理の方にご紹介ください! https://www.layerx.jp

    わたしたちはまだまだ発展途上です。採用も募集中です! https://layerx.co.jp/jobs Meetyにてカジュアル面談も受付中! AWSについて語り合いましょう! https://meety.net/matches/RObgMkZfUBJd
  34. None
  35. © 2021 LayerX Inc. 35 クレジット表示 JSON File by Burak

    Kucukparmaksiz from the Noun Project File by Tanvir Islam from the Noun Project Browser by Iga from the Noun Project