【R&D DevOps通信】自社製OCRのキャッシュシステムについて

こんにちは、R&D Architect グループの八藤丸です。今回は自社製 OCR のキャッシュシステムを設計・実装するに当たって考えたことを紹介します。
同じグループの鈴木が最近 Cloud Composer を用いた転送パイプライン構築について過去の連載で紹介しているので、ぜひご覧ください。
buildersbox.corp-sansan.com

背景

多少簡略化していますが、キャッシュシステムを含む自社製 OCR の構成は以下のようになっています。

自社製 OCR 本体は GCP にあり、名刺データ化のための主要なマイクロサービスとキャッシュのデータストアである S3 は AWS にあります。
キャッシュシステムを利用することで、上流の工程で自社製 OCR を実行して、得られた結果をキャッシュとして保存することで、下流の工程で使いまわすことが可能になり、AWS ⇔ GCP 間の通信を極力減らすことにつながり、パフォーマンス・コスト面で恩恵を受けることができます。
S3 に保存されているキャッシュは、Key が「名刺ID + 名刺画像のSHA256ハッシュ値」で作られており、名刺画像の取り違えを防ぐようになっています。
キャッシュに別名刺の OCR 結果が貼り付くことを絶対に許容できないのですが、名刺ID だけでは検証などで同じ ID で別の名刺画像を流してしまう、といったケースが想定されたため、念には念を入れて、名刺画像データとしての一致も見られるようにハッシュ値を Key に付与したという背景があります。

キャッシュシステムを設計するに当たって考えたこと

.NET 6 + AWS (Lambda) の選定理由とハマりどころ

まず選定理由についてですが、以下3点あります。

キャッシュシステムを利用する側が .NET のシステムが多く、モデルを参考にすることができるというクライアント側の事情を考慮した
当時 .NET Core が出て軌道に乗って安定してきたタイミングということもあり、高速化に期待していた
Visual Studio などの周辺のエコシステムが充実していた

3についてですが、具体的には以下のような恩恵を受けることができました。

Dockerコンテナ、SAMテンプレート付きの雛形が用意されており、大枠が簡単に作れる
AWS Toolkit for Visual StudioによりGUIで簡単にデプロイできる*1
補完が効く

ハマりどころというほどでもないですが、相対的に世間一般に公開されている情報が少なかったため、公式のドキュメントで疑問点があった場合に答えを見つけるまでに時間がかかることがあったというちょっとした苦労はありました。

データストアに S3 を採用した理由

検討を始めた段階では、名刺ID でデータを引いてくる構成だったので、DynamoDB と S3 が候補に挙がりました。
両サービスでパフォーマンス・コスト検証してみた結果、パフォーマンスはどちらも目標に収まるものでしたが、OCR の結果は座標値・文字列などを含み、1レコードのデータサイズが大きいため、大量のデータを投入するとなると、DynamoDB は S3 と比較してコストがかかることがわかりました。
また、DynamoDB だとレコードサイズの上限である 400KB*2 に引っかかってしまうパターンがあったため、DynamoDB は今回のユースケースには適していないと判断しました。
そのため、最終的に S3 を採用することに決めました。
余談ですが、S3 には OCR 結果を JSON 形式で置いていて、.NET のコード内ではモデルにバインドせずにスキーマレス的に扱うことで、OCR 本体側でレスポンスに変更が発生した際にキャッシュシステム側に改修を加えることなくキャッシュに変更を反映できるようにしています。(OCR 本体側の更新が盛んなため、キャッシュの改修コストを抑えるための工夫です。)

マルチクラウドにどう向き合っているか

GCP にある自社製 OCR 本体と AWS にあるキャッシュシステム間の通信コストを抑えるために MessagePack*3 を採用しています。
MessagePack を使うことで、サイズの大きな画像データの容量を抑えることができるので、通信コストの削減には有効だったと考えています。
今後の改善案では、画像データのフォーマットを JPEG から WebP*4 にすることで、さらに画像データの容量を抑えるという案が出ていますが、こちらはまだ検討中の段階です。