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

by Shun Takagiwa

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

© 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

Slide 19

Slide 19 text

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

© 2021 LayerX Inc. 21 machineryとは？ machineryはgoで利用可能な、分散メッセージ受け渡しに基づく、非同期タスク管理フレームワーク SQS ECS メッセージ受信非同期処理 SQS メッセージ送信 ↑ ここで動くのが machinery メッセージブローカーとして、 SQSはもちろん、RedisやAMQPなども利用可能メッセージに応じて異なるタスクを実行するだけでなく、遅延実行したり、エラーのリトライ時にはタイミングや回数の制御もでき、多段タスクや並列タスクの実行も可能更に、タスクの定期的な実行も可能参考：https://github.com/RichardKnop/machinery

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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