■貴社の事業概要と髙瀨様のお役回りを教えてください。

髙瀨氏（以下、髙瀨）：弊社では、Update Entertainment ということを掲げています。クリエイターの届けたいものを世界中のファンに届け、そのファンからの応援でクリエイターが活動をしていける社会を作りたいと思っています。そのために、SPWN というプラットフォームを展開しています。

SPWN は一方的なエンタメの提供でなく、クリエイターとファンをつなぐハブのような存在であり、クリエイターにとって良き理解者でマネジメントなどを行い、ファンにとって新しいエンタメの体験を提供し推活を助けてくれるような存在です。SPWN を軸にして、多方面からの Update Entertainment に取り組んでいます。

私はコンテンツ企画本部のマネージャーをしています。コンテンツ企画本部は、社内が持っているコンテンツを取り扱う事業部で、主に自社事業と新規事業に取り組んでいます。

■Google Cloud のインフラ基盤を見直すことになった経緯を教えてください。

髙瀨：弊社は AI を活用し、映像などのクリエイティブなものを生み出すために Google Cloud を使っています。東京と大分の2箇所に事業所を持っているので多拠点で作業を実行できることはもちろんなのですが、Spot VM を使うなどコストを抑えることも重要視しています。それでも改善したい悩みが多々ありました。そんな時に grasys さんと出会い、改善に向けて一緒に取り組んでもらうことになりました。

■どのような課題があったのでしょうか。

髙瀨：特に改善したいと考えていた課題は4点ありました。まずはストレージの実装問題です。作業者1人につき1台の VM を使い、ストレージにはそれぞれの VM のローカルディスクを使っていました。複数の作業者で同じモデルを使用しているにも関わらず、別々のストレージを使っていたので効率が悪くコストもかかっていました。

2点目は処理能力と速度です。処理する画像数が多ければ多いほど重くなり、メモリの問題にぶつかります。そのせいで途中で処理が止まるということがありました。また、処理中は他の作業を行えないため、処理にかかる時間が作業者の作業効率に直結していました。メモリをカスタムした VM を使っていましたが、それ以上あげたいとなるとインスタンスタイプをあげるしかなかったので、コストを維持したまま改善できる方法はないかと模索していました。

3点目は Spot VM の中断です。可能な限りコストを抑えることを重視していたので、Spot VM は非常に魅力的なソリューションでした。一方で、処理中のリソースが終了してしまうと強制的に中断してしまうので、処理をやり直す必要があり、Spot VM を使う上で避けては通れない問題がありました。

最後に、非エンジニアでも管理できるフローの構築です。私たちのチームは元々 3D ライブなどを作るチームのメンバーで構成されており、クラウドインフラに明るいメンバーはいません。エラーが発生した場合などは違うチームのエンジニアに頼る必要がありました。最低限は、チーム内でエラーの状況確認をできる程度にはなりたいと考えていました。

■現在の取り組みを教えてください。（2024年8月2日時点）

grasys：現在も試行錯誤している途中ではありますが、バルス様にも使ってもらい PoC のような形で検証をしながら構成の見直しをしており、既存の処理を自動化して効率化するアプローチをとっています。Spot VM については、オンデマンド VM と選べるようにして処理の安定化を図っています。その分、必要な時だけインスタンスを作成する仕組みにしてコストを抑える工夫をしています。

まず、作業と処理を行う VM は大元の VM から複製する形にして、水平展開ができるようにしました。従来は処理中に作業を行えないアイドリングタイムが発生してしまっていましたが、作業する VM を切り替えることでアイドリングタイムなしで作業を継続できるようになりました。この VM は業務時間中は明示的に停止するまで停止しないようにしますが、業務時間外であれば画像処理タスクが空であれば自動で削除されるようにしてコストを抑えています。

また、ストレージは Cloud Storage バケットで共通化させています。参照モデルや処理されたデータの保存先を1箇所に集約することで、課題となっていた効率性やコストの問題を大きく改善できました。

処理の自動化には Workflows を使っています。スプレッドシートに使用者などを追記することをトリガーとして Workflows をスタートさせ、作業用の VM が自動で作成されるようにしています。こうすることで必要最低限の VM のみ稼働させることができるようになりました。

髙瀨：この構成の一番いいところは、処理環境も含めて、最新の状態を複数の VM で複製、共有出来ることだと思っています。ベースイメージさえメンテナンスしておけば、複数の作業者が都度作業環境をアップデートすることを意識せず、画像処理の作業に集中することができます。熟練度の違うスタッフが作業に当たる際に、とても良い仕様になっていると感じました。また、各 VM 毎のディスク保持コストが大きかったということもご指摘いただき、結果として大きなコスト削減にもつながると考えています。

■プロジェクト中に直面した課題はありましたか。また、どのように対応しましたか。

grasys：まず、当初検証した構成では作業用の VM と処理用の VM を分け、処理が発生する時のみ自動で処理用の VM が作成されるようにしていました。しかし、自動で起動させる VM の立ち上がりとモデル参照に時間がかかりすぎるという問題がありました。

これに対して、予め用意しておいたイメージから処理用 VM を作成して時間を短縮させることなど検討しましたが、最終的には大元の VM から作業用 VM を複製して、その VM で画像処理まで一貫して行うことにしました。こうして処理用 VM の立ち上がりとモデル参照に時間がかかる点を同時にクリアしました。

次に、抱えていた課題としても挙げられていたストレージの問題を解消する必要がありました。当初は各作業用 VM にローカルディスクをつけて、それぞれのローカルディスクへ参照モデルや処理されたデータを保存していました。これに対して、参照モデルや処理されたデータを1箇所に集約することで解消を図りました。NFS でディスクのマウントをして、Cloud Storage で参照モデルや処理されたデータを共有する仕組みにしています。Cloud Storage バケットは処理データの置き場としてもコストパフォーマンスが高いです。

■プロジェクトの結果、どのような成果が出ていますか。

髙瀨：コストと作業効率の面で成果が出ました。時期によって作業量が変わるので同一な状態での比較はできていませんが、旧環境の時に比べ新環境の使用量が7.0倍に伸びたのに対し、ランニングコストは4.9倍の増加に留まりました。（旧環境、新環境ともに異なる時期の30日間の数値で比較しており、新環境には一部旧環境の費用も含まれています）

従来はコストを優先し Spot VM を使っていましたが、今では Spot VM とオンデマンド VM を選択できるようになりました。Spot VM が中断しそうな日はオンデマンド VM を選択することで、Spot VM が中断してしまって作業ができない状況を回避できるようになりました。これまでは月に1〜2回、それぞれ5時間程度 Spot VM が中断してしまう状況が発生しており、それが作業者の手を止めることになってしまっていたので作業効率の面でも大幅に改善されました。

新環境ではオンデマンド VM の使用量が全体の5割以上を占めるにも関わらずコストを抑えられているので、大きな成果だと思います。

grasys：当初課題として挙げられていた4点について、ストレージの共通化や処理の自動化、処理中のみ VM を起動する仕組みを取り入れることによって、Spot VM が中断してしまう問題の解消と同時にコスト面でも改善ができました。拡張性の高さとしても十分にあると思います。

髙瀨：拡張性の観点では、作業者や拠点が増えても事業自体を広げていきやすいだろうと思っています。また、先ほど複数の作業者が都度作業環境をアップデートすることを意識せず、画像処理の作業に集中することができるようになったことをお伝えしました。その他にも、アップロードとダウンロードをする場所が一つになったことで、よりリアルタイムに作業者間での成果物の共有ができるようになったと反響がありました。

■今後、grasys にはどのようなことを期待していますか。

髙瀨：今回の検証を通して、今まで使っていたものがもっと快適になる方法があるんだなと実感しました。弊社はインフラを使ってクリエイティブを実現していく会社なので、今後もこういうことしたいんですという要望にインフラ面からどんどんアドバイスいただけると嬉しいです。引き続きよろしくお願いします。

■最後に grasys から一言。

grasys：こちらこそ、よろしくお願いいたします。バルスさんの当初の構成のように、コスト面も考慮されているし簡潔で大きな問題はない、という構成を取っているインフラは世の中に結構ありそうだと思っています。技術がどんどん進歩していく流れに乗って、エンドユーザーがより快適になったり、開発者の手間を省いていけるような提案をこれからもしていきたいと考えています。

本記事は、2024年8月2日に Google Cloud Next Tokyo ’24にて登壇した内容を元にしていますが、その後の進展により一部修正・加筆をしています。