複数の機械学習モデルが動くシステムをモデルごとにマイクロサービス化したお話

はじめまして。メルカリのAIチームでSysMLエンジニアをしているChicaです。
SysMLという言葉はあまり馴染みがないかもしれませんが、「Systems and Machine Learning」の略で、AIを実際にサービスに組み込むためのミドルウェア・インフラを整備することを言います。

メルカリではAIを使った多くのサービスが動いていますが、今回はその中でも特にたくさんの機械学習モデルが動いている違反出品検知システムをモデルごとにマイクロサービス化したお話を紹介します。

メルカリで動いている違反出品検知システムとは

メルカリには禁止されている出品物に記載しているように、出品していただくことのできない(例えば現金のような)アイテムが存在します。対象のアイテムが出品されてしまったときに、間違って購入されないようCS(カスタマーサポート)チームが監視しています。

AIチームでは、CSチームを補助するため、

• 禁止出品物Aかどうかを判定するためのModel A
• 禁止出品物Bかどうかを判定するためのModel B

というように違反出品検知を行うモデルがたくさん動くシステムを提供しており、一つでも違反を検知するとCSチームへ通知が行き、メンバーが確認するようになっています。

今までのアーキテクチャ

違反出品検知システムはKubernetes上で動いており、
マイクロサービス化以前は下図のようなモノリシックなアーキテクチャになっていました。

• Model A (scikit-learn)
• Model B (scikit-learn)
• Model C (TensorFlow)
• Model D (TensorFlow)

という4つのモデルがあった場合には
Model A, BはREST APIのサーバー内で推論が実行され、
Model C, DはTF Servingサーバーで推論されているような構成です。

はじめは1つのscikit-learnのモデルしかなかったため、このように推論部分がRESTサーバーと切り離されていない構成になっていました。しかしそこにモデルを増やすような改修を加えていったため、RESTサーバーの役割が重くなり更新時の作業が巨大化してきたことが問題になっていました。

これからもモデルが増えていく予定があるため、各モデルを個別でデプロイ可能になるようモデルのマイクロサービス化を進めることになりました。

マイクロサービス化後のアーキテクチャ

マイクロサービス化後は下図のような構成になりました。

以前は1つのサービスとして動いていたModel A, B, C, D は各々別のサービスとして動くようになり、
Proxyがその結果を集約して返しています。
エラーが発生したときの原因究明がしやすいよう中継・集約を行っているProxyにログの情報も集約するよう気をつけています。

今回のマイクロサービス化で、数日かかることもあったモデルの追加・更新作業も10分で終わるようになりました 。
また、以下のような利点も生まれました。

• モデルごとにpodの数やpodに割り当てるCPU数・メモリサイズを変更できる
• Istioを使ったモデルごとのABテストが可能に
• 一部モデルに不具合が発生しても全体をロールバックする必要がない

さいごに

今後も様々なモデルがメルカリに組み込まれていく中で、モデルの追加・更新がスムーズにできる環境を提供できるよう頑張っていきます 🙂