ピクシブ社エンジニアが語る、機械学習基盤とその技術　「GCPバッチ基盤」「リアルタイムの推論基盤」「ノートブック開発環境」整備の裏側

登壇者の自己紹介とアジェンダの紹介

sugasuga氏：こんにちは。今日は、ピクシブの機械学習基盤に関する発表をいたします。

まずは自己紹介から始めさせてください。自分は、機械学習チームでエンジニアをしているsugasugaといいます。サブで採用・広報活動にも関わっています。最近の趣味は、トレーニングです。

今日お話しすることは、（スライドを示して）こちらを予定しています。機械学習基盤について。そして、基盤で使われている技術について。運用してみて感じたメリットとデメリットについてお話しします。

大規模なデータの効率的な処理、機械学習サービスの展開のしやすさ、効率的な開発などに課題があった

本題に移る前に、導入として、どういったところで機械学習が活用されていて、なぜ機械学習基盤が必要かについてお話しします。

活用されている場面としては、違反検知、レコメンド、広告、3Dなど多岐にわたります。ここでは、「pixiv」でレコメンドがどのように使われているかを紹介します。

トップページに「おすすめ作品」枠というものがあります。これは、ユーザー一人ひとりにパーソナライズされた作品をレコメンドする枠になっています。

さらに、作品ページのタブには、関連作品枠と呼ばれるものがあります。これは、その作品を見ているのであれば、この作品も好むであろうという作品をレコメンドしている枠です。

そしてレコメンドはpixivだけではなく、他のサービスでも積極的に活用されています。例えば、クリエイターの創作活動を支援するプラットフォームである「FANBOX」では、ユーザーに対しておすすめのクリエイターをレコメンドする機能が提供されています。

ほかにも、「BOOTH」「ピクシブ百科事典」「pixivコミック」「pixivision」「VRoid Hub」など、さまざまなサービスでレコメンドが活用されています。

さまざまなサービスで活用されているレコメンドですが、1ヶ月間のレコメンドの表示件数は、いったいどのぐらいなのでしょうか？

2023年の平均的な月のデータによれば、約110億件のレコメンドが表示されています。

投稿作品総数が約1.3億件、総登録ユーザー数が約9,800万人とあり、国内でも有数の規模のデータなんじゃないかなと思っています。こういったデータに対して、自分たちはかつて、オンプレミス基盤で機械学習技術を使っていました。

しかし大規模なデータの効率的な処理や、機械学習サービスの展開のしやすさ、あとは効率的な開発などに課題があり、それらを解決する基盤を作成する必要がありました。

基盤その1　GCPバッチ基盤

実際に、それらの課題を解決するために開発した3つの基盤について説明いたします。

まず1つ目の基盤として、GCPバッチ基盤というものがあります。現在のバッチ基盤は、「Google Kubernetes Engine」上で構築されています。そのため、必要な時に必要な分だけリソースを確保できるようになりました。

また「Digdag」というワークフローツールを使っており、バッチの状態の可視化、失敗時の通知、バッチの依存関係の記述などができるようになりました。

例として、レコメンドを計算するバッチを挙げます。Digdagがバッチジョブを発行します。最初にデータの集計を行い、次に機械学習モデルの学習、レコメンド候補の生成、レコメンドデータの出力の順で処理が進行します。いずれかのステップで失敗した場合「Slack」に通知が飛ぶようになっています。

以前はできなかった一時的に高性能なリソースを借りて、その分だけ料金を支払ったり、複数同時に実行して時間内に処理を終わらせるということができるようになりました。この基盤によって大規模なデータを効率的に処理できるようになりました。

基盤その2　リアルタイムの推論基盤

2つ目の基盤として、リアルタイムの推論基盤を紹介させてください。

バッチ基盤は、GPU、TPUなど、潤沢なリソースを使い、数時間かけて処理を行う場合に使われます。対して、こちらのリアルタイム推論は、ユーザーからのリクエストがあった場合など、数秒以内にレスポンスを返すために使われています。

一例として、タグのおすすめ機能があります。これは、クリエイターの方が作品を投稿した際に、投稿された作品に対しておすすめのタグを返却するという機能になっています。

こういった機能以外にも現在機能を開発しています。機械学習チーム内で機械学習を活用したサービスが作りやすくなったかなと感じています。

以前は、オンプレのリソースが限定されていたり、自分たちが自由にいじれる基盤がなかったため、機械学習のサービスを展開するハードルが非常に高い状態でした。しかし現在は、この基盤のおかげでサービスの展開がしやすくなり、取れる選択肢が広がったと感じています。

基盤その3　ノートブック開発環境

3つ目の基盤として、ノートブック開発環境についてお話しします。

機械学習エンジニアは、PythonをWebブラウザ上で実行できる「Jupyter Notebook」というツールを使うことが多いです。（スライドを示して）こんな感じで、中身を確認しながら逐次的にスクリプトを実行できます。

以前のオンプレ基盤の時は、都度、環境構築を行ったりしていて大変でした。また、ほかのユーザーがGPUリソースを使っていないかを気にしたり、ストレージを圧迫しないように後片付けなどをきちんと行なわなければならないというのがつらいところでした。

現在は、「GCP」の「Vertex AI Workbench」を使うことにより、マネージドなノートブック開発環境を使用しています。ボタン数回のクリックで自由にリソースを選択でき、環境が構築されます。リソースやストレージの競合を気にする必要がなくなりました。使わなくなれば気軽に破棄できます。

Vertex AI Workbenchを使うことで、効率的に開発を行えるようになりました。

ここまで、GCP上での基盤を紹介させていただきました。実をいうと、以前のオンプレの仕組みを全部GCPに移行しているというわけではありません。紹介できていないような、既存の便利な機能や仕組みを一緒に資産として活用しているというかたちになっています。

基盤で使われている技術を紹介

次に、2つ目の項目である、基盤で使われている技術についてお話しさせてください。主に「なんでピクシブがこの技術を使っているの？」という観点から紹介します。

「どうやってインフラ管理を行うか？」についてです。

インフラ管理は、ピクシブで標準の「Terraform」を使いました。チーム内外で経験がある人が多く、ノウハウもあったので、気軽に使うことができました。

「どうやって認証を行うか？」についてです。

弊社の場合、オンプレサーバーからつなぐ必要があるため、アプリケーションとの間には、認証を挟む必要があります。サーバーと開発者にはアクセスを許可したいが、一般のユーザーのアクセスは制限したいという要件がありました。

自分たちは、「IAP」と呼ばれるリバースプロキシを使って認証を行っています。ピクシブは、「Google Workspace」を使っていて、開発者全員がGoogleアカウントを持っているので、そのアカウントを認証に使います。設定もかなり楽でした。

サーバー側のサービスアカウントと、開発者のGoogleアカウントをまとめて管理できるのもうれしい点なのかなと感じています。

「なんでGKEを使っているの？」についてです。

GKEの管理は大変だと思いますが、自分たちは、この基盤がポータブルである必要がありました。なにかしらの理由でオンプレや「AWS」に移行する可能性があったからです。

実際に今、コスパが悪い一部分をオンプレに移行するという話があります。また、今でこそ一部対応されているのですが、「Cloud Run」などでは使えないような機能がGKEにはありました。そのため自分たちは、GKEを使うという判断をしました。

「どうやってKubernetesのマニフェストを管理しよう？」についてです。

「Kubernetes」の設定を記述するためにマニフェストファイルを準備する必要があります。開発環境と本番環境とステージング環境ごとに準備すると、大量のyamlファイルが爆誕します。

そうすると、更新する時に変更箇所が多くなり、ミスが入り込む可能性が高くなります。自分たちはそういった問題を減らすために「Kustomize」というツールを使って、DRY原則に則り環境管理を行っています。

その他として、ワークフローツールの選定、エラー通知、クラスタ監視、CI/CDの設定や軽量化、あとは機械学習特有の継続的学習についてなどを考えつつ、基盤を構築しています。

もし詳細が気になる方がいましたら、「Ask the Speaker」まで聞きに来てください。

手戻りや調整が少ない・やれることが増える・マネージドサービス固有の問題を避けやすい　基盤を運用して感じたメリット

では、最後の項目である、実際に基盤を運用してみて感じたメリット、デメリットについてお話しします。

まずは、運用してみて感じたメリットです。

1つ目のメリットは、自チーム内でプロジェクトが完結するため、手戻りや調整が少ないことです。企画、アルゴリズム作成、基盤変更、バックエンド変更、レポーティングなど、自チーム内でプロジェクトが完結するので、どこがボトルネックになりそうかなどを見積もって、手戻りを減らせているかな、と感じています。

具体的には、めっちゃいいアルゴリズムを作ったのですが、弊社のデータ量だったり、料金面的に「ちょっと無理っすね」みたいな手戻りが比較的少ないのかなと感じています。

やれることが増えるのもメリットの1つだと感じています。機械学習領域でやりたいことをエンジニアリングで解決することで、やれることを増やすことができます。

具体的には、以前はできなかった高度な機械学習モデルを使うために、GCP基盤を変更して実験を行うということが今はできるかなと感じています。また、オンプレマシンの調達を待たずに素早く実験が回せます。

副次的な作用として、インフラチームに負担がかかりにくくなっているのではないのかな、と僕は願っています。

最後の項目としては、マネージドサービス固有の問題を避けやすいというのもあると思っています。実際に、比較的自分たちでコントロールできる部分が多いGKEを使っているから問題を解決できたよねという事例があります。

具体的にはGKEから割り当てられたCPUと「PyTorch」の相性がおそらく悪く、デプロイの時に、時々CPU負荷が異常に高まるという問題が起きていました。

チーム内ではこれを、デプロイガチャと呼んでいました。チーム内で操作を行い、割り当てられるマシンの変更を加えたことによって解決しました。

マネージドな部分が多いサービスとかでは解決はできなかったんじゃないかなと思っていて、こういった問題を少し避けやすいと思っています。

機械学習領域に割く時間の減少・オンボーディングコストが高くなる　基盤を運用して感じたデメリット

これまでメリットについて話しました。次は、運用してみて感じたデメリットについてお話しします。

これはメリットの裏返しなのですが、やれることが増えた結果、機械学習領域に割く時間が減りました。1人の人間はやはり分身ができないので、インフラ領域やソフトウェアエンジニアリング領域の仕事が増えれば、相対的に機械学習領域に割く時間が減ってしまいます。

想定していたことながら、個人的には思ったより時間が減ってしまったなという印象があります。あとは、インフラばかりいじりすぎていて、時々「機械学習エンジニアとは？」みたいな気持ちになることもあります。

また、オンボーディングコストが高くなってしまうというのもあると思っています。Kubernetes、Terraform、GCP、GitLab CIなど、いろいろなツールがあります。

自分たちのチームは、人材の入れ替わりが激しいわけではないので、ゆっくり習得してもらう想定になっています。オンボーディングしやすくするために機械学習エンジニアにもGoogle Cloudの研修を受けてもらうなどの取り組みを行っています。

運用していく中で感じるデメリットはありましたが、基盤を作ってよかったなと感じています。

GCPで機械学習基盤を構築中

最後です。ピクシブは、GCPで機械学習基盤というものを構築しています。今後もユーザーやクリエイターのために機械学習技術基盤を活用していきます。

今回のような基盤以外の事例など、社内ブログ「pixiv inside」に掲載しています。気になる方は、見ていただけますと幸いです。

では、最後までご清聴ありがとうございました。

（会場拍手）