【レポート】遊戯王ニューロンにおける Amazon SageMaker の活用 大規模画像データの MLOps 基盤構築 #CUS-45 #AWSSummit

【レポート】遊戯王ニューロンにおける Amazon SageMaker の活用 大規模画像データの MLOps 基盤構築 #CUS-45 #AWSSummit

Clock Icon2021.05.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

データアナリティクス事業本部@札幌の佐藤です。

本記事では2021/05/11~12に行われた AWS Summit Online 2021 のオンラインセッションレポートとなります。

現役で遊戯王の大型大会に参加している私にとっても身近のアプリである「遊戯王ニューロン」に関する内容であるため興味深い内容でした。

セッション概要

株式会社コナミデジタルエンタテインメント 制作支援本部 技術開発部 プログラマー 田中 秀和 氏

昨年6月にリリースされた遊戯王オフィシャルカードゲーム公式アプリケーション「遊戯王ニューロン」のカメラ検索機能では、物体検出・画像分類モデルを利用したカード画像認識処理を実現しています。約10000種類のカード分類のための学習モデルの生成や、大量の学習データの生成・精度評価等の処理のパイプライン化にAmazon MWAAとAmazon SageMakerを活用しました。課題に対するアプローチや実例・Tipsと、AI/ML@Tokyo #7での発表にアップデートを加えた内容を紹介いたします。

アジェンダ

  • 遊戯王ニューロンについて
  • 既存学習システムにおける課題
  • Amazon SageMaker を軸とした MLOps 基盤の構築

レポート

遊戯王ニューロンについて

遊戯王OCG初の公式アプリケーションです。
2017年に研究開発が開始され、2018年にAmazon SageMakerが試験運用、2019年にMLOps基盤の構築がスタートされました。

今回のセッションでは、Amazon Sage MakerやMLOps基盤の構築前の課題と、それに対し対応した内容をお話されています。

遊戯王ニューロン

私はこのアプリケーションをYu-Gi-Oh! World Championship2019(遊戯王WCS2019)内の試合の中で実際に使われていることで存在を知りました。
(今改めて見ると、現在とかなり画面のUIが異なっているように見えますね)

その後、2020年6月29日にリリースとなりましたが、プレイヤー目線でも今まで不便に感じていたカードを調べる手間がかなり減ったと感じています。

大規模大会の参加時、自分のデッキにどのようなカードが何枚存在しているかなどを証明するためにデッキシートを提供します。
ニューロンがリリースするまでは第3者が提供するものに手動で入力、もしくはカードイラストが見える状態で写真撮影をした状態での提出でした。

ニューロン登場からは、自分のデッキを画像認識して登録、それを共有するだけで済むようになりました。

遊戯王ニューロンの開発・運用体制

開発にあたっては、機械学習サイドと、ニューロン自体のアプリケーション開発再度の2チーム体制で実施

  • 学習モデルの開発・運用をしている技術開発部
  • 遊戯王ニューロンのアプリケーションを開発・運用している制作チーム

3~4週間のスケジュールで学習モデルのアップデートを行っているようです。
(現在の遊戯王の新規カードの収録サイクルは大体1ヶ月程度のため、かなりの短期間でアップデートが必要ということだと思います)

リリースサイクルについては、学習データの生成の前処理、そのご学習を行う学習終了まで10日程度かかる想定とのこと。
その後テストとして、実際のカードを使ってテストをし精度の高いものを採用し、最後のIOSなどのフォーマットに変換し実機テストを実施しているそうです。

既存学習システムにおける課題

Amazon Amazon SageMaker導入前の各工程における課題

Amazon Amazon SageMaker導入前は、新しくリリースされるカードの画像の前処理を行い、データストレージに保存。
画像データのサーバに格納し学習を開始し、並行しバックアップのためローカル上でも実施しています。
学習完了後、学習済みモデルをコピーし精度テストを行いモデル変換を行っていました。

そのなかでサイクルがプロダクトのリリースサイクルに必ずしも最適化されておらず、研究開発当初のシステム構成に引きずられ、作業範囲が複雑化、プロジェクト規模の拡大、各州工程の複雑化によって様々な問題が発生していたようです。

  • 学習データが数十GBと大きく、コピーなどを実施するためディスク容量を圧迫するため、コストがかかる点
  • モデルの最適化、非常に多いクラス分類を実現するための学習の複雑化
  • 作業の属人化や性能改善などの作業サイロ化

学習における課題

学習のアルゴリズムなどのアップデートや、学習フローが変更された場合の修正コストにたいし、柔軟に対応できるシステムや設計が必要だが、既存システムでは柔軟な対応が困難であった。

また複雑になるにしたがって、アドホックでの作業が増えたり、マニュアルでの作業が増えていき、作業や時間コストなどの問題が発生していました。

各工程間のパイプライン化も行っていなかったため、工程間に無駄な時間が発生してしまっていた。
また問題があった場合は迅速にリカバリーが必要でした。

データにおける課題

カードの種類が1万種のため、リリースのたびにサイズが増加。ディスク容量を圧迫する問題があったようです。

バックアップも含め並列に学習する必要があるため、毎回コピーが必要である点や、重みデータについてもディスク容量を圧迫している状態だったようです。

運用における課題

学習環境の構築や、メンテナンスコストがかかってしまう点や、CPUやHDDに物理的な障害リスクがあったようです。

学習するためのソースコードについては社内Gitにあるようですが、カード情報が更新されたときにすぐにデプロイできるようにする必要がありました。
カード情報は定期的に更新されるために、そのたびに分類モデルも最新化、すぐに更新できる必要がありました。

なるべく無駄な時間を使わず、問題があった場合でも復帰して作業を継続できるようにする、有識者がいなくても学習が実施できなければならないのが課題でありました。

Amazon SageMaker を軸とした MLOps 基盤の構築

課題に対するアプローチ

学習における課題へのアプローチ

  • 学習処理については、Amazon SageMaker を利用
  • 各工程間処理のパイプライン化については、Amazon Managed Workflows for Apache Airflow を利用
  • 学習や推論結果の通知、推論結果の集計については、AWS lambda や Amazon EventBridge を利用

データにおける課題へのアプローチ

  • 大規模な学習データの読み込みやI/O高速化については、Amazon Amazon FSx for Lustre を利用
  • 学習データや学習済みモデルやテストデータの配置については、 Amazon S3

運用における課題

  • 学習環境のプロビジョニングについては、 AWS CloudFormation を利用
  • 前処理・学習・後処理のDockerイメージ管理については、Amazon ECR を利用

AWS Cloud環境での学習

Amazon SageMaker のインスタンスタイプをml.p2.xlargeからml.p3.2xlargeに変更、ファイルシステムをAmazon S3から Amazon FSx for Lusterに変更することで学習開始時の読込速度を高速化することが可能になったそうです。

コスト面についても、スポットインスタンスを活用することで70%のコスト削減に成功したとのことです。
一方でスポットインスタンスを活用することで割込み処理が発生する際に学習がストップしてしまうこともあったそうです。
そのため、エポック終了ごとにモデルファイルをAmazon S3に保存、割り込みから復帰後にデータをAmazon S3からダウンロードして再開できるようにしていたそうです。(制限の緩和も実施)

学習処理状況の把握と情報共有

モニタリング通知の情報共有をSlack上で通知していたが、技術開発部と制作チーム間で行っていたが各チーム間で学習処理での管理の対象が異なっていたそうです。
技術管理部ではモデルの精度や学習状況などを知りたく、制作チーム側はいつ学習が終わるのか、そのファイルの配置場所を知りたいということが関心対象だったそうです。

関心の違うものをどのように共有するのがよいのかを考えていたそうです。

モニタリング・ログ

  • 学習中のモデル制度・ログのモニタリングとして、Amazon SageMaker Expertiments を利用(技術開発部向け)
  • 学習の進捗状況の確認・共有や、学習処理の完了ステータスの通知として、Slack を利用(技術開発部・制作チーム向け)
  • 詳細なログとして Amazon CloudWath を利用

学習・推論結果の通知

AmazonCloudWatchイベントをトリガ、LambdaからSlackへ通知を行うような処理を実装していたそうです。
スポットインスタンスの割り込み発生や、学習にかかった費用モデルの費用を確認できるので便利とのこと。

感想

チーム単位で必要としている情報が違うというのは、どのプロジェクトでもあり得る情報だなと感じました。

遊戯王はソリッドビジョンというものが原作にあるため、カードを認識するということに力入れていると感じています。
その一端にかつてあったデュエルターミナル(カードに2次元バーコードある)や2011年にwii用のソフトとして発売された「遊☆戯☆王5D's Duel Transer」で付属のデュエルスキャナーを利用してカードをスキャンしてゲームで利用する仕組みがありました。

今後もさらにカードゲームが楽しくなるような仕組みに期待したいです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.