【要約】Stena Expenseの検知アーキテクチャ ── Go × Python × gRPCで不正検知を実現する仕組み [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
経費データは形式が多様で、検知ロジックも複雑である。また、検知プロセスが多段階にわたるため、各ステップの状態管理やエラーハンドリングが困難である。さらに、検知結果が大量になる場合、中間プロセスでのデータ中継によるメモリ消費や通信遅延がシステム全体のボトルネックとなる課題があった。
// Approach
Goのモノリスでドメインロジックとワークフローを管理し、PythonのPredictorを分離。gRPCコールバックを採用することで、検知結果をPredictorからControllerへ直接バッチ送信し、中継コストを削減した。また、Pickleを用いたモデルの動的ロードにより、アプリの再デプロイなしでの検知モデル更新を可能にした。
// Result
言語ごとの強みを活かした開発体制と、検知モデルのライフサイクルをアプリケーションから分離した運用を実現。大量の検知結果を効率的に処理しつつ、検知精度の改善を迅速に行える、スケーラビリティと運用性を両立したアーキテクチャを構築した。
Senior Engineer Insight
> 言語の特性を活かした適材適所の設計は極めて合理的だ。特に、gRPCコールバックによるデータ中継の排除は、大規模データ処理におけるメモリ効率とレイテンシの観点から高く評価できる。中間プロセスを介さず直接Controllerへ結果を流し込む設計は、実戦的な判断と言える。ただし、Pickleによる動的ロードは、信頼できるソースのみを扱うというセキュリティ上の厳格な管理が前提となる。また、分散環境での状態遷移をGoのドメインモデルで厳密に管理する設計は、不整合を防ぐための堅実なアプローチである。