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

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

Shun Takagiwa
October 02, 2021

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

原本はこちら(登壇当日の動画も埋め込んでます)
https://docs.google.com/presentation/d/1-eGkBHpMVGjvOhrDpJfvPHX1AasXtHunAmYJHEJLtaY/edit?usp=sharing

Shun Takagiwa

October 02, 2021
Tweet

More Decks by Shun Takagiwa

Other Decks in Technology

Transcript

  1. © 2021 LayerX Inc.
    LayerX インボイスのAI-OCRを支える
    非同期処理アーキテクチャ
    高際 隼
    株式会社LayerX
    DX事業部
    AI-OCRチーム Lead
    AWS Dev Day Online Japan 2021
    E-2

    View Slide

  2. © 2021 LayerX Inc.
    2
    このセッションでお伝えしたいこと
    ✅ 重く、突然急増しやすいAI-OCRの処理を分散するため、
      どのようにAWSを活用したか
    ✅ AWSの活用によって、顧客にどのような価値が生じたか
    ❌ 一方で、AI-OCRの処理の中身や、読み取り精度向上の
      具体的な方法については話さない

    View Slide

  3. © 2021 LayerX Inc.
    3
    自己紹介
    高際 隼(たかぎわ しゅん) @shun_tak
    2018年8月、株式会社LayerXに参画
    現在、DX事業部にてAI-OCRチームのLeadを担当
    サーバーサイドJava→Node.js→Goと経験し、
    Goも結構好きになってきました
    AWSもよくいじります!
    好きなAWSサービスはオートスケーリングです!
    LayerXは技術や事業だけでなく、組織やカルチャーなど
    どんなトピックでも深いディスカッションができ、
    学びの多い環境でありがたいです。
    同僚に感謝!

    View Slide

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

    View Slide

  5. © 2021 LayerX Inc.
    5
    会社概要
    すべての経済活動を、デジタル化する。
    ※ アセットマネジメントの DX
    ※電子投票
    企業のDX
    金融のDX
    行政のDX

    View Slide

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

    View Slide

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

    View Slide

  8. © 2021 LayerX Inc.
    8
    LayerXインボイスとは
    企業A 企業B
    売り手・受注者 買い手・発注者
    請求書を発行
    請求書を受け取り
    会計・支払処理
    受け取った請求書の処理を効率化するサービスです

    View Slide

  9. © 2021 LayerX Inc.
    9
    ライブデモ

    View Slide

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

    View Slide

  11. © 2021 LayerX Inc.
    11
    プロダクト
    AI-OCRによる自動読取
    仕訳の自動入力補完・振込データ自動生成
    会計システムとシームレスに連携
    AI-OCRによる稟議の自動下書・申請補助
    購買申請との紐付けで予算管理
    Slack連携でSlackで承認が完結
    請求書の処理は「経理」だけで終わらない。支払申請する「現場」のための LayerX ワークフローも提供
    AWS利用料
    支払申請
    ソフトウェア
    ライセンス
    購入申請
    どちらも手入力ゼロの起点となる AI-OCRを備えている

    View Slide

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

    View Slide

  13. © 2021 LayerX Inc.
    13
    LayerXの開発スタイル
    お客様に価値を届け続けることにこだわる
    ● 🙆 顧客価値を作れてこそのアーキテクチャ
    ● 🙅 エンジニアの満足を追求
    動くものを素早く提供し、フィードバックをすぐに反映
    ● 運用負荷を下げ、サービス開発に集中するため、マネージドサービスや SaaSを徹底活用
    参考(LayerXエンジニアブログより)
    ● LayerX インボイスの紹介と開発風景
    ● 「時間・学び・セキュリティ」新規プロダクト開発で意識したことーAWSイベント登壇を終えてー

    View Slide

  14. © 2021 LayerX Inc.
    14
    AI-OCRの開発で大切にしている指標
    お客様の価値につながる指標を大切に
    ● 読み取り精度  → 手入力ゼロに直結
    ● 読み取り速度  → 遅かったら手入力した方がいい
    ● 同時実行数   → まとめて処理したい需要に応える
    ● 可用性     → いつでも処理できる
    ● インフラコスト → お求めになりやすい価格
    直近では読み取り精度が課題
    ● 新規導入が急増している
    ● 新しいパターンの請求書がどんどん出てくる
    本講演では、読み取り速度、同時実行数、可用性、インフラコストの改善について紹介

    View Slide

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

    View Slide

  16. © 2021 LayerX Inc.
    16
    AI-OCRの処理の概要
    請求書ファイル
    前処理 文字認識 意味付け
    入力画像内の「文字」と
    「位置情報」を読み取る
    読み取った「文字」に
    意味を与える
    例)支払金額:500,000円
      支払期日:2021/02/28
    後処理
    読み取れた!

    View Slide

  17. © 2021 LayerX Inc.
    17
    AI-OCRの処理の技術的に難しいところ
    処理が重い
    ● 全部の処理が終了するまで請求書 1件あたり数秒かかる
    ● それぞれの処理が互いに影響して遅くならないようにしたい
    処理件数が急増しやすく、いつ来るかわからない
    ● 100枚単位でアップロードされることがよくある
    ● 長期トレンドでは平日昼間や月末月初の負荷が高いが、分単位では予測不可能
    ○ オートスケーリングでも間に合わない可能性
    ○ 予めサーバ台数を確保してもいいが、いつ来るかわからないのでコスパも悪くなる
    請求書ファイル
    前処理 文字認識 意味付け 後処理
    読み取れた!

    View Slide

  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

    View Slide

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

    View Slide

  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で制御
    実際はもっと多くのステップ
    と処理の分岐もあるよ
    請求書ファイル
    前処理 文字認識 意味付け 後処理
    読み取れた!

    View Slide

  21. © 2021 LayerX Inc.
    21
    machineryとは?
    machineryはgoで利用可能な、分散メッセージ受け渡しに基づく、非同期タスク管理フレームワーク
    SQS ECS
    メッセージ
    受信
    非同期処理
    SQS
    メッセージ送


    ここで動くのが
    machinery
    メッセージブローカーとして、 SQSはもちろん、RedisやAMQPなども利用可能
    メッセージに応じて異なるタスクを実行するだけでなく、遅延実行したり、
    エラーのリトライ時にはタイミングや回数の制御もでき、多段タスクや並列タスクの実行も可能
    更に、タスクの定期的な実行も可能
    参考:https://github.com/RichardKnop/machinery

    View Slide

  22. © 2021 LayerX Inc.
    22
    コードレベルの実装( machinery)
    送受信するメッセージ本文の構造 タスクの登録
    受信したメッセージの Nameとマッチしたら
    指定の関数が実行される
    メッセージの送信

    View Slide

  23. © 2021 LayerX Inc.
    23
    コードレベルの実装( AWS SDK Go - Lambda Invoke)
    Lambda関数の実行(同期呼び出し)

    View Slide

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

    View Slide

  25. © 2021 LayerX Inc.
    25
    デモ

    View Slide

  26. © 2021 LayerX Inc.
    26
    実装上の注意点
    ● Amazon SQS
    ● AWS Lambda
    ● machinery

    View Slide

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

    View Slide

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

    View Slide

  29. © 2021 LayerX Inc.
    29
    実装上の注意点(machinery)
    ● 実行される関数の引数と送信メッセージの Argsは
    個数と順番が常に一致する必要がある
    ○ 後方互換性を保って変更する
    ○ 変更したい場合、まず新たなタスクを登録し
    古いジョブはすべてのメッセージ消費後に削除
    ● machinery もそれなりに負荷が上がる
    ○ オートスケーリングの設定を忘れずに
    タスクの登録(再掲)
    受信したメッセージの Nameとマッチしたら
    指定の関数が実行される
    メッセージの送信(再掲)

    View Slide

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

    View Slide

  31. © 2021 LayerX Inc.
    31
    今後の課題
    ● 処理のワークフローが複雑になってきた
    ● 非同期処理の状況を可視化したい
    ● より柔軟なリトライ制御をしたい
    まだまだ他にも課題だらけです …

    View Slide

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

    View Slide

  33. © 2021 LayerX Inc.
    33
    PR
    LayerX インボイスは受け取った請求書の処理を効率化するサービスです!
    ぜひ経理の方にご紹介ください!
    https://www.layerx.jp
    わたしたちはまだまだ発展途上です。採用も募集中です!
    https://layerx.co.jp/jobs
    Meetyにてカジュアル面談も受付中!
    AWSについて語り合いましょう!
    https://meety.net/matches/RObgMkZfUBJd

    View Slide

  34. View Slide

  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

    View Slide