メルカリのコンテナアーキテクチャを公開！利便性の高いアプリを実現する AWS 活用法

2019年8月30日。AWS Loft Tokyo にて、AWS におけるコンテナサービスの解説とともに、株式会社メルカリにおける AWS Fargate、Amazon EKS の活用についてお話しいただくイベント AWS Containers talk with Mercari が開催されました。

このレポートでは、前半パートで株式会社メルカリの中河宏文氏による「メルカリ写真検索における Amazon EKS の活用事例とプロダクトにおける Edge AI Technology の展望」の模様を、後半パートで株式会社メルカリ高橋三徳氏とアマゾンウェブサービスジャパン株式会社のソリューションアーキテクト塚田朗弘、原康紘による「Fireside Chat: merpay の AML/CFT(Anti-Money Laundering / Combating the Financing of Terrorism) 基盤における AWS Fargate 活用事例、その選定理由」の模様をお届けします。

世界でも有数のフリマアプリを運営するメルカリ社のノウハウ。「Docker コンテナ技術を自社に導入したい」「Amazon ECS、Amazon EKS、AWS Fargate をより適切に運用したい」と考えるスタートアップ企業の方々は必見です！

メルカリ写真検索における Amazon EKS の活用事例とプロダクトにおける Edge AI Technology の展望

前半パートでお届けするのは、株式会社メルカリの中河宏文氏による「メルカリ写真検索における Amazon EKS の活用事例とプロダクトにおける Edge AI Technology の展望」です。中河氏はまず、メルカリの写真検索機能とそのインフラの概要について解説しました。

株式会社メルカリ中河宏文氏

機械学習を用いて、利便性の高い画像検索を実現

メルカリの写真検索には、機械学習の技術が用いられています。基本的な写真検索の仕組みは：

Deep Neural Networks を使用して、商品画像から特徴ベクトルを取得
取り出した特徴ベクトルを Approximate Nearest Neighbor Index に追加して、画像 index を構築
検索時には、同じく商品画像から Deep Neural Networks を介して特徴ベクトルを取得し、Approximate Nearest Neighbor Index からベクトルが近いアイテムを似た商品として扱う

という流れになっています。

この仕組みを動作させるインフラとして、コンテナオーケストレーションツールの Kubernetes が用いられています。 Kubernetes には Custom Resource Definition という独自リソースを定義できる機能があり、その機能を使用して index の管理などを行なっているのです。

また、写真検索機能は Lykeion という内製の ML Platform 上に構築されています。下記の機能群は、 ML Platform 側の機能を使用しているそうです。

Training / Serving CRD & カスタムコントローラ
Training などを実行するコンテナベース・パイプライン
Training / Serving で使用するコンテナイメージ・ビルダー
モデルなどのアセットのバージョンを管理するモデル・レポジトリ

写真検索アーキテクチャの全貌

中河氏は写真検索の全体的なアーキテクチャについても解説します。写真検索では、ビジネスロジックを動作させているインフラの大部分を Kubernetes で抽象化させることで、環境の差異を吸収し、柔軟な構成を取れるようにしているのです。

各層で行われている処理を、中河氏は順を追って解説していきました。まずは Approximate Nearest Neighbor（ANN） indexing のトリガーとなる Training リソースの作成について。

Training リソースを定期的に Kubernetes の CronJob の Training クラスタ上で作成することが、indexing バッチ処理全てのトリガーとなります。

Training リソースが作成されると、Training カスタムコントローラが CRD リソースで設定されたコンテナベース・パイプラインを実行します。これにより、indexing に必要となるデータソースの取得や画像のダウンロード、特徴量の取得、 ANN index の構築といった各工程が、パイプラインとして実行されるのです。

「現状、ML のパイプラインは各工程で必要なライブラリのバージョンが違うなど、複雑な依存関係を持っています。依存している要素に変化があると、簡単に壊れてしまうような非常にナイーブなものです。その課題を解決し、ML システムの再現性を高めるためにこのようなアーキテクチャを採用しています。パイプラインは YAML で記述でき、各工程の入出力は Kubernetes 上の Persistent Volume に一時保存されるような形になっています。

また、メルカリのコンテナベースパイプラインでは Batch Execution as Custom Resource という仕組みを採用しています。全てのバッチ実行情報がCRDリソースとしてKubernetes上に残り、全く同じ処理を再実行できるため、バッチの再実行と障害復旧作業が容易になるという利点があるのです」と中河氏は言います。

次は、パイプライン内で実行している画像ダウンロード処理について解説していきます。Amazon S3 上にあるメルカリ・イメージストアから商品画像をダウンロードするこの処理は、パイプライン上では最も時間がかかっています。そのため、 Persistent Volume に画像を一定時間キャッシュし、再 index が必要なときでも素早くパイプラインを回せるように工夫しているとのこと。また、 Persistent Volume の実体は Amazon EBS を使用しています。

パイプラインで作成したアセットのアップロード処理では、パイプラインの成果物である特徴ベクトルと ANN index を、バージョン管理された状態でモデル・レポジトリに保存します。各 Training リソースはユニークな ID を持っているため、どのタイミングのパイプライン実行で作成されたものかを識別可能になっています。 ML Platform を使用するシステムで発生しがちな、アセットのバージョン管理問題を解決しているのです。

イミュータブルな設計にし、アーキテクチャ全体の再現性と安定性を高める

Serving イメージのビルドでは、モデル・レポジトリを Image Builder という daemon が監視しています。 Image Builder は index の新しいアセットがモデル・レポジトリに追加されると、自動で Serving イメージのビルドを行うようになっているのです。コンテナ・イメージは ANN Index などのサービングに必要なリソースを全て含んでいます。ビルドされたコンテナイメージは、自動でコンテナレジストリにプッシュされます。

Serving リソースの作成では、Image Builder はコンテナイメージをビルドした Serving カスタムリソースを Serving クラスタ上で作成します。 Serving カスタムコントローラは CRD リソースの設定をもとに、必要な Kubernetes の Deployment、Service など複数のリソース群を作成・管理しているのです。

こうした設計をとることで、なんらかの障害で一部リソースを再生成させる必要がある場合でも、簡単に復旧可能となっています。また、不要になったKubernetesリソース群の削除も一括して行えます。

最後はサービス・ディスカバリについて。この処理では、特徴ベクトルの抽出に必要な TensorFlow Serving と ANN index サービスに REST API から gRPC でアクセスする多段構成のアーキテクチャが採用されています。そして、ANN index サービスは Hourly、Daily、Monthly という異なる期間・粒度で自動的にデプロイされ続けています。REST API はサービスディスカバリー機能によって必要な期間の複数の ANN index サービス群を自動的に選択し、並列にアクセスする構成になっているのです。

このような流れで、写真検索の index は日々更新されています。設計における要点は「全てをコンテナベースのシステムで構成することで、アーキテクチャ全体をイミュータブルな設計にしていること」と中河氏は解説。そうすることで、システムの再現性と安定性を高めているのです。

「かつては Kubernetes といえば GCP というイメージがありましたが、 Amazon EKS も利便性が向上し、安定した運用ができるようになってきました。Amazon EKS の良い点としては素の Kubernetes に近いため、柔軟な構成が組みやすいこと。今後への期待としては、 Kubernetes について必要な事前知識が若干多いことでしょうか。

ですが、使い勝手の良い AWS のマネージドサービスを Kubernetes とともに使いたいユーザーが、 Amazon EKS の利用を躊躇（ちゅうちょ）する理由はもはやありません。ぜひ Amazon EKS を使用して柔軟な構成でサービスを構築してはいかがでしょうか」と、来場者に推奨していました。

Edge AI Technologyにおいて、いかにしてUXと実現可能性のバランスを取るか？

セッション後半では、クライアントデバイスのための AI Technology である Edge AI Technology についても中河氏は触れました。

Edge AI Technology を実現するには、考慮すべきことがいくつもあります。例えば、 Accuracy（正確さ）や Latency（遅延時間）、Energy consumption（エネルギー消費）、Model size（モデルのサイズ）などの項目は、トレードオフの関係にあります。目的の UX を達成するために、アルゴリズムとエンジニアリング両方の観点から、各項目のバランスを取る必要があります。

昨今では、ニューラルネットワークアーキテクチャ自体を自動で探索して構築する Neural Architecture Search (NAS) という手法が盛んに研究されています。Google が発表した MnasNet や、Facebook が発表した FBNet などが有名です。しかし、これらの手法は巨大な計算リソースを必要とするため、プロダクトのモデル開発で採用するには厳しいものがあります。

そこでメルカリでは Single-Path NAS という手法を用いて開発を進めています。これはマイクロソフトが発表した手法で、従来手法と比べて高速に探索と Training を行うことが可能になります。

「基本的に探索時間は探索空間とトレードオフの関係にあるのですが、MobileNet-V3 をベースに探索空間を設定し、Single-Path NAS などのリーズナブルな手法で探索を行うのが、計算リソースに制約がある環境における現実的な選択肢ではないでしょうか。

解決すべき課題は多いのですが、技術的にもビジネス的にも Edge AI Technology は面白い分野であるのは間違いありません。今後ともこの分野に注目していただけたら幸いです」と総括し、中河氏はセッションを終了しました。

中河氏の資料はこちらからご覧頂けます：

メルカリ写真検索における Amazon EKS の活用事例と プロダクトにおけるEdgeAI technologyの展望

Fireside Chat: merpay の AML 基盤における AWS Fargate 活用事例、その選定理由

後半パートでお届けするのは、株式会社メルカリ高橋三徳氏とアマゾンウェブサービスジャパン株式会社のソリューションアーキテクト塚田朗弘（akitsukada@）、コンテナスペシャリストソリューションアーキテクト原康紘（@toricls）による「Fireside Chat: merpay の AML 基盤における AWS Fargate 活用事例、その選定理由」です。

多種多様なデータの収集と解析が求められる AML 基盤において、AWS Fargate を導入した理由とは？そして、アーキテクチャ設計における技術選定の要諦について、3名が語り合いました。

多様なフォーマットのデータをどう収集する？

高橋：私は現在mercari R4D という研究開発部署にいますが、2018年まではメルペイに所属しており、AML / CFT と呼ばれるシステムを開発していました。 AML / CFT とは Anti-Money Laundering / Counter Financing of Terrorism の略で「アンチマネーロンダリング / テロ資金対策システム」のことを指します。反社会勢力への関与が疑われる方のシステム利用を防ぐための仕組みです。

例えば、メルペイアカウントを作っても問題ない人なのかを事前にチェックするためのユーザースクリーニングや、トランザクション履歴に不正な動きがあればアラートを発砲し、場合によってはアカウントの停止や送金のキャンセルなどを実施するトランザクションモニタリングなどを行います。

こうした仕組みは金融系サービスを扱ううえで必須です。そして、これらの処理を実現するには、お金の流れやトランザクション情報などを全て収集する必要があります。

塚田：この仕組みを構築するために、どのような設計思想のもとアーキテクチャを選定してきたのかを伺わせてください。AML 基盤の構成図がこちらですが、全体の流れをご紹介いただけますか？

高橋：さきほど、トランザクションデータを色々なところから集めているという話がありましたが、これはそのデータフローを示した図です。

メルカリやメルペイではシステムの Docker 化が進んでおり、かつビジネスロジックがどんどん細分化されていてマイクロサービスになっている状態です。マイクロサービスごとにさまざまなプラットフォームを使っていて、トランザクションデータの収集経路も Pub/Sub や Web API 経由だったり、データフォーマットも gRPC や CSV、さまざまな Result set だったりと、多種多様な色々な形式となっています。

これらを収集して、AWS Fargate 上に構築された Bridge Service に投入してデータを変換。そのデータを Amazon Kinesis に投げて、最終的に分散型データベースの Splunk に格納しています。AML 機能の核になるのは Splunk です。Splunk の定期バッチ機能を用いて、一定のルールの基づいて怪しいトランザクションを検知し、アラートを飛ばす仕組みになっています。

株式会社メルカリ高橋三徳氏

達成すべき目的は何か？からシステムを逆算する

原：さまざまな経路やデータ形式で入ってくる、というのはどのような経緯でこうなっているのでしょうか？

高橋：まず、前提として AML 基盤を構築するようになった経緯は、新興の金融系サービスが置かれている昨今の状況が大きく影響しています。例えば、日本の仮想通貨取引所において大きなトラブルが起きたことは何度かありますが、そのような事態を防ぐためにセキュリティの堅牢さが近年では特に重視されるようになっています。メルカリ、メルペイにおいてもそれは同様です。

原：私たちエンジニアは、このような仕組みを構築しようとした場合に、どうしてもインターフェースの統一をしたくなります。ですが、今回のケースではそれよりも金融機関として担保すべきセキュリティを最優先で考えて、「各サービスがトランザクションデータを送付可能な仕組みを早急に作る」ことの方が優先順位は高かった、ということですか？

高橋：まさにおっしゃる通りで、メルペイ関連の機能の大部分はマイクロサービス化されており、インターフェースは整えられてきています。ですが、メルカリの古い機能に関してはマイクロサービス化されていないものもあり、データを AML 基盤で利用することも想定されていません。だからこそ、このような形でデータ収集を行う方針になりました。

塚田：さきほど提示してくださった図では、Splunk は EC2 上に構築されているとありました。Splunk Enterprise を利用されているのだと思いますが、クラウドベースの SaaS サービスである Splunk Cloud の利用は検討しましたか？

高橋：Splunk Cloud も非常に利便性が高く魅力的ではありますが、私たちの用途に適さない部分がありました。

というのも、AML 基盤では Splunk の機能をフル活用しており、ルールやプラグインの更新頻度が高いです。Splunk Cloud では、これらを導入する場合には Splunk 社と連携する必要があります。このコミュニケーションにより開発のスピードが落ちてしまうのが難点でした。

それから、Splunk 社の中の人とも話したのですが、メルペイが要求しているくらいのパフォーマンスを Splunk Cloud が出せるのかはかなり検証が必要そうで。そういった点から、EC2 上に構築する方向性になりました。

塚田：Splunk を EC2 ではなく Docker 環境上に立てることは考えましたか？

Docker も考えましたが、この基盤では使用するストレージが非常に大きいんです。数百GB〜TBほどのストレージを利用する必要があります。Docker はユースケースとして適切ではないと考えて、EC2 を用いました。

塚田：良いですね。原さんもよく「何が何でもコンテナにすればいいというものではない」と言っていますよね。

アマゾンウェブサービスジャパン株式会社コンテナスペシャリスト SA 原康紘

原：はい。僕もこの技術選定には非常に同意します。今回話題になっているメルペイの AML 基盤において、Splunk に関連する部分はステートフルにならざるをえないですよね。かつ、ステートそのものがシステムのキーになるじゃないですか。だからこそ、優先度を考えると、ステートをいかに適切に保持するか、が技術選定の要点になりますよね。

最初にコンテナ技術ありきで検討するのではなくて、実現したいシステム要件をまず考えて、それを達成するために要素技術を選ぶというのが、正しい方法だと思います。

AWS Fargate を用いたのは、セキュリティ要件や管理の利便性ゆえ

塚田：ではメイントピックである、AWS Fargate についてもお話を伺いたいです。AWS 基盤の Bridge Service には AWS Fargate 起動タイプの Amazon ECS を活用されていますが、この理由を挙げていただければ。

高橋：当社もそうですが、現代の開発においては開発段階から標準的に Docker を使う企業が多くなっています。そのため、デプロイ先としてもコンテナを使うのは自然な流れですし、手軽に利用できる AWS Fargate は魅力的でした。

さらに、AML 基盤はセンシティブなデータをたくさん扱うため、求められるセキュリティ要件も高い。それも、AWS Fargate を選定した理由のひとつです。保守・運用において、なるべく各サーバに SSH でアクセスして作業することは避けたかったんです。だからこそ、SSH による接続が前提となっていない AWS Fargate は、求められる要件に合っていました。

アマゾンウェブサービスジャパン株式会社スタートアップ SA 塚田朗弘

塚田：Amazon ECS ではなく Amazon EKS を使うことは検討されましたか？

高橋：東京リージョンでの Amazon EKS サービス開始は2018年12月だったため、すでに AML 関連サービスは開発を開始しており、構成も決まっていました。また、当時はチーム内に Kubernetes に詳しいメンバーもいませんでした。

原：加えて、Kubernetes を AWS 上で利用する場合にはどうしても Kubernetes の中の世界（各種 Kubernetes リソース）と外の世界（AWS のサービス – Load Balancer や RDS など）を上手に繋ぎつつ扱う工夫をする必要があるので、そのためのコンポーネントを Kubernetes クラスタ上に配置・運用しなければいけないことも考慮が必要ですよね。

高橋：そうなんです。そうした管理の煩雑さがないことも、Amazon ECS を選んだ理由のひとつでした。

塚田：最後に AWS 全体に期待することがあればお伺いしたいです。

高橋：AWS は本当に欲しいものがなんでも揃っていて、適切なサービスを選べばシステムが達成すべき要件を実現できるようになってきています。選択肢の広さが大きな利点です。

欲を言えば、サービスの種類が多くなっていることで、どれをどのような観点で選べばいいかがわかりにくくなっていると思っていて。どれを使うべきか、より簡単にわかると嬉しいと感じています。

塚田：サービスの種類や情報量が多くなっていますから、適切なサービスをうまく取捨選択するのが難しいですよね。私たちソリューションアーキテクトはまさに、そういった課題を解決するために努力しています。

AWS Loft Tokyo の Ask An Expert（AWS のエキスパートである中の人に技術的な質問ができるカウンター）ではいつでも質問を受け付けていますので、よかったら会場のみなさんも、気軽に質問していただけたら嬉しいです。

後半の Fireside Chat で利用した資料はこちらからご覧頂けます：

merpay の AML 基盤における AWS Fargate 活用事例、その選定理由

AWS Startup ブログ

メルカリのコンテナアーキテクチャを公開！ 利便性の高いアプリを実現する AWS 活用法