--- title: "GPU基盤の最適化で安定運用とコスト効率化を実現 | grasys（グラシス）" url: "https://www.grasys.io/case-studies/balus-gpu-optimization" description: "GPU の最適化により、インフラの安定化とコスト圧縮を同時に実現。また、ストレージの共通化と処理の自動化によって、作業効率の大幅な向上も達成しました。" --- バルス株式会社 # GPU基盤の最適化で安定運用とコスト効率化を実現 GPU の最適化により、インフラの安定化とコスト圧縮を同時に実現。また、ストレージの共通化と処理の自動化によって、作業効率の大幅な向上も達成しました。 ![GPU基盤の最適化で安定運用とコスト効率化を実現](/_astro/2770133a3b089b60229734b1c37ef5a1-scaled.B8OIGkYO_Z19H9Bc.webp) 公開日 2024年10月10日 更新日 2026年8月8日 著者 株式会社 grasys ## 導入事例の要約 課題 作業者ごとのローカルディスクによる重複コストや、処理中の待ち時間、Spot VMの中断、非エンジニアによる運用確認が課題となっていました。 支援 VMの複製・自動削除、Cloud Storage（GCS）によるストレージの共通化、Workflowsとスプレッドシートによる処理の自動化を進め、オンデマンドVMも選べる環境を整備しました。 成果 利用量が従来比7.0倍に増える中でも稼働コストを4.9倍に抑え、Spot VMの中断による作業停止の回避と成果物共有の効率化につながりました。 ## 事例の概要 ### ■貴社の事業概要と髙瀨様のお役回りを教えてください。 髙瀨氏（以下、髙瀨）：弊社では、Update Entertainment ということを掲げています。クリエイターの届けたいものを世界中のファンに届け、そのファンからの応援でクリエイターが活動をしていける社会を作りたいと思っています。そのために、SPWN というプラットフォームを展開しています。 SPWN は一方的なエンタメの提供でなく、クリエイターとファンをつなぐハブのような存在であり、クリエイターにとって良き理解者でマネジメントなどを行い、ファンにとって新しいエンタメの体験を提供し推活を助けてくれるような存在です。SPWN を軸にして、多方面からの Update Entertainment に取り組んでいます。 私はコンテンツ企画本部のマネージャーをしています。コンテンツ企画本部は、社内が持っているコンテンツを取り扱う事業部で、主に自社事業と新規事業に取り組んでいます。 ![Google Cloud Next Tokyo ’24で登壇する髙瀨氏](/_astro/IMG_3378-1024x683.BiFT27u8_Z13Xhtn.webp) Google Cloud Next Tokyo ’24で登壇する髙瀨氏 ### ■Google Cloud（GCP） のインフラ基盤を見直すことになった経緯を教えてください。 髙瀨：弊社は AI を活用し、映像などのクリエイティブなものを生み出すために Google Cloud（GCP） を使っています。東京と大分の2箇所に事業所を持っているので多拠点で作業を実行できることはもちろんなのですが、Spot VM を使うなどコストを抑えることも重要視しています。それでも改善したい悩みが多々ありました。そんな時に grasys（グラシス） さんと出会い、改善に向けて一緒に取り組んでもらうことになりました。 ![多拠点で画像処理を行うGoogle Cloud（GCP）構成](/_astro/6a427b6930387643449be772542b815b-2-1024x576.BCt51vjj_FLGVm.webp) ### ■どのような課題があったのでしょうか。 髙瀨：特に改善したいと考えていた課題は4点ありました。まずはストレージの実装問題です。作業者1人につき1台の VM を使い、ストレージにはそれぞれの VM のローカルディスクを使っていました。複数の作業者で同じモデルを使用しているにも関わらず、別々のストレージを使っていたので効率が悪くコストもかかっていました。 2点目は処理能力と速度です。処理する画像数が多ければ多いほど重くなり、メモリの問題にぶつかります。そのせいで途中で処理が止まるということがありました。また、処理中は他の作業を行えないため、処理にかかる時間が作業者の作業効率に直結していました。メモリをカスタムした VM を使っていましたが、それ以上あげたいとなるとインスタンスタイプをあげるしかなかったので、コストを維持したまま改善できる方法はないかと模索していました。 3点目は Spot VM の中断です。可能な限りコストを抑えることを重視していたので、Spot VM は非常に魅力的なソリューションでした。一方で、処理中のリソースが終了してしまうと強制的に中断してしまうので、処理をやり直す必要があり、Spot VM を使う上で避けては通れない問題がありました。 最後に、非エンジニアでも管理できるフローの構築です。私たちのチームは元々 3D ライブなどを作るチームのメンバーで構成されており、クラウドインフラに明るいメンバーはいません。エラーが発生した場合などは違うチームのエンジニアに頼る必要がありました。最低限は、チーム内でエラーの状況確認をできる程度にはなりたいと考えていました。 ![ストレージ、処理性能、Spot VM中断、運用フローの4つの課題](/_astro/7e8703c7e06fd0261f4473f7e28e8471-1-1024x576.nXg6iVo9_26Rly2.webp) ### ■現在の取り組みを教えてください。（2024年8月2日時点） grasys（グラシス）：現在も試行錯誤している途中ではありますが、バルス様にも使ってもらい PoC のような形で検証をしながら構成の見直しをしており、既存の処理を自動化して効率化するアプローチをとっています。Spot VM については、オンデマンド VM と選べるようにして処理の安定化を図っています。その分、必要な時だけインスタンスを作成する仕組みにしてコストを抑える工夫をしています。 ![画像処理VMと共有ストレージを組み合わせた目標構成](/_astro/d5faeb2db23bc29f8d298006af9d99dd-1-1024x576.DQeTYu8f_CUWj7.webp) まず、作業と処理を行う VM は大元の VM から複製する形にして、水平展開ができるようにしました。従来は処理中に作業を行えないアイドリングタイムが発生してしまっていましたが、作業する VM を切り替えることでアイドリングタイムなしで作業を継続できるようになりました。この VM は業務時間中は明示的に停止するまで停止しないようにしますが、業務時間外であれば画像処理タスクが空であれば自動で削除されるようにしてコストを抑えています。 また、ストレージは Cloud Storage（GCS） バケットで共通化させています。参照モデルや処理されたデータの保存先を1箇所に集約することで、課題となっていた効率性やコストの問題を大きく改善できました。 処理の自動化には Workflows を使っています。スプレッドシートに使用者などを追記することをトリガーとして Workflows をスタートさせ、作業用の VM が自動で作成されるようにしています。こうすることで必要最低限の VM のみ稼働させることができるようになりました。 髙瀨：この構成の一番いいところは、処理環境も含めて、最新の状態を複数の VM で複製、共有出来ることだと思っています。ベースイメージさえメンテナンスしておけば、複数の作業者が都度作業環境をアップデートすることを意識せず、画像処理の作業に集中することができます。熟練度の違うスタッフが作業に当たる際に、とても良い仕様になっていると感じました。また、各 VM 毎のディスク保持コストが大きかったということもご指摘いただき、結果として大きなコスト削減にもつながると考えています。 ### ■プロジェクト中に直面した課題はありましたか。また、どのように対応しましたか。 grasys（グラシス）：まず、当初検証した構成では作業用の VM と処理用の VM を分け、処理が発生する時のみ自動で処理用の VM が作成されるようにしていました。しかし、自動で起動させる VM の立ち上がりとモデル参照に時間がかかりすぎるという問題がありました。 これに対して、予め用意しておいたイメージから処理用 VM を作成して時間を短縮させることなど検討しましたが、最終的には大元の VM から作業用 VM を複製して、その VM で画像処理まで一貫して行うことにしました。こうして処理用 VM の立ち上がりとモデル参照に時間がかかる点を同時にクリアしました。 次に、抱えていた課題としても挙げられていたストレージの問題を解消する必要がありました。当初は各作業用 VM にローカルディスクをつけて、それぞれのローカルディスクへ参照モデルや処理されたデータを保存していました。これに対して、参照モデルや処理されたデータを1箇所に集約することで解消を図りました。NFS でディスクのマウントをして、Cloud Storage（GCS） で参照モデルや処理されたデータを共有する仕組みにしています。Cloud Storage（GCS） バケットは処理データの置き場としてもコストパフォーマンスが高いです。 ### ■プロジェクトの結果、どのような成果が出ていますか。 髙瀨：コストと作業効率の面で成果が出ました。時期によって作業量が変わるので同一な状態での比較はできていませんが、旧環境の時に比べ新環境の使用量が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 が中断してしまう問題の解消と同時にコスト面でも改善ができました。拡張性の高さとしても十分にあると思います。 髙瀨：拡張性の観点では、作業者や拠点が増えても事業自体を広げていきやすいだろうと思っています。また、先ほど複数の作業者が都度作業環境をアップデートすることを意識せず、画像処理の作業に集中することができるようになったことをお伝えしました。その他にも、アップロードとダウンロードをする場所が一つになったことで、よりリアルタイムに作業者間での成果物の共有ができるようになったと反響がありました。 ![提案構成によるストレージ共通化、処理自動化、Spot VM中断対策のメリット](/_astro/61ab1b123e3ca84d85a3d112e06af1d8-1024x576.D8mEzB2-_ZdpMOd.webp) ### ■今後、grasys（グラシス） にはどのようなことを期待していますか。 髙瀨：今回の検証を通して、今まで使っていたものがもっと快適になる方法があるんだなと実感しました。弊社はインフラを使ってクリエイティブを実現していく会社なので、今後もこういうことしたいんですという要望にインフラ面からどんどんアドバイスいただけると嬉しいです。引き続きよろしくお願いします。 ### ■最後に grasys（グラシス） から一言。 grasys（グラシス）：こちらこそ、よろしくお願いいたします。バルスさんの当初の構成のように、コスト面も考慮されているし簡潔で大きな問題はない、という構成を取っているインフラは世の中に結構ありそうだと思っています。技術がどんどん進歩していく流れに乗って、エンドユーザーがより快適になったり、開発者の手間を省いていけるような提案をこれからもしていきたいと考えています。 ![写真左からGoogle Cloud Next Tokyo ’24で登壇する角田と髙瀨氏](/_astro/2770133a3b089b60229734b1c37ef5a1-1024x683.DzrOxWlE_Z2ltYvR.webp) 写真左から、Google Cloud Next Tokyo ’24で登壇する角田、髙瀨氏 本記事は、2024年8月2日に Google Cloud Next Tokyo ’24にて登壇した内容を元にしていますが、その後の進展により一部修正・加筆をしています。 ### プロジェクト情報 #### 業種 ゲーム・エンターテインメント #### 支援領域 クラウド基盤・移行運用・最適化 Discover ## この内容に関連する課題・目標・技術 同じ文脈にあるサービスや実績を、別の視点から探せます。 ### 課題 - [性能・コストを最適化したい](/problems/performance-cost-optimization/) - [安定運用・障害対策を強化したい](/problems/reliability-incident-response/) - [業務システムを開発・自動化したい](/problems/business-system-automation/) ### 実現したいこと - [高負荷でも安定して動く構成にしたい](/outcomes/improve-performance-scalability/) - [クラウドの利用状況とコストを把握し、適正化したい](/outcomes/optimize-cloud-costs/) - [アーキテクチャとミドルウェアの妥当性を評価したい](/outcomes/assess-architecture-fitness/) - [定型業務をシステム連携・AIエージェントで自動化したい](/outcomes/automate-business-workflows/) ### 技術 - [Google Cloud（GCP）](/technologies/google-cloud/) - [Compute Engine（GCE）](/technologies/compute-engine/) - [Cloud Storage（GCS）](/technologies/cloud-storage/) - [Workflows](/technologies/workflows/) ## 同じような課題をお持ちではありませんか？ クラウドインフラやデータ活用について、grasys（グラシス）の専門チームが課題を伺い、最適な進め方をご提案します。 [資料請求](/document-request/)[お問い合わせ](/contact/) ## その他の事例 業種や支援領域の近い事例から順にご紹介します。 ![マルチテナント基盤の再設計で運用コストを約50％削減](/_astro/BNEtop.BATiixfE_1WLBMc.webp) 株式会社バンダイナムコエンターテインメント ### [マルチテナント基盤の再設計で運用コストを約50％削減](/case-studies/bandai-namco-entertainment-multi-tenant/) 業界 ゲーム・エンターテインメント サービス クラウド基盤・移行 / 運用・最適化 課題 複数のコンテンツを支える旧マルチテナント環境では、特定タイトルの高負荷がほかのタイトルへ影響する懸念や、コンテンツの増加に伴う運用負荷がありました。 支援 テナントを論理的に分離し、利用頻度の高い機能だけをスケールできる共通システムへ再設計するとともに、構成変更にも迅速に対応できる運用を整備しました。 成果 想定を超えるアクセスにも安定して対応でき、従来構成と比べてコストを約半分に抑えた共通基盤を実現しました。 ![GKE導入で前年比200％の急成長を支える基盤を実現](/_astro/original.D1BTDoJe_ZCbWyu.webp) 株式会社Live2D ### [GKE導入で前年比200％の急成長を支える基盤を実現](/case-studies/live2d-gke/) 業界 ゲーム・エンターテインメント サービス クラウド基盤・移行 / 運用・最適化 課題 nizimaの利用者急増による負荷の高まりや、複数の言語バージョンを扱うことによる開発速度の低下に加え、社内にインフラの専門家がいないことも課題となっていました。 支援 GKEによるコンテナ化とオートスケール可能な基盤を構築し、その後のインフラ運用も継続して支援しました。 成果 言語のバージョンアップやサービス開発を進めやすくなり、担当者の割り当て自由度が向上したほか、利用者増加時の負荷も解消されました。 ![Google Cloud（GCP）移行でアクセス急増に対応できる運用基盤を実現](/_astro/4b5c3867a35089362b4dcce6dd6ec09a.B1U5UFR2_GtQlI.webp) 株式会社ネイキッド ### [Google Cloud（GCP）移行でアクセス急増に対応できる運用基盤を実現](/case-studies/naked-google-cloud-migration/) 業界 ゲーム・エンターテインメント サービス クラウド基盤・移行 課題 FLOWERS by NAKEDのサイトに従来サーバーの許容量を超えるアクセスが集まる一方、社内だけでクラウド基盤を構築・運用するには人員が不足していました。 支援 Google Cloud（GCP）への移行とサーバーのチューニングに加え、アクセス増加時の即応やログを含む保守運用まで継続的に支援しました。 成果 海外アクセスやテレビ放映によるアクセス増加にも対応でき、少人数でのサーバー管理と社内スキルの標準化を進められるようになりました。 ![アクセス急増に耐えるメディア基盤を約6カ月でAmazon Web Services（AWS）へ移行](/_astro/S__27115546.euN4l4VC_Z2l69hH.webp) 合同会社コンデナスト・ジャパン ### [アクセス急増に耐えるメディア基盤を約6カ月でAmazon Web Services（AWS）へ移行](/case-studies/conde-nast-japan-aws-migration/) 業界 メディア サービス クラウド基盤・移行 / 運用・最適化 課題 Google Cloud（GCP）からAmazon Web Services（AWS）への移行に加え、通常の200〜300倍に達する突発的なアクセス、CMS作業への負荷影響、攻撃への備えが課題となっていました。 支援 設定を精査しながら段階的に移行し、キャッシュ、ロードバランサー、WAFを組み合わせた構成と24時間365日の監視体制を整備しました。 成果 約6カ月で全メディアの移行が完了し、大規模なアクセス急増時もメディアとCMSを安定して稼働できる基盤が整いました。 ![Google Cloud（GCP）移行で不正ログイン対策サービスの安定運用を実現](/_astro/S__27115553.BbGdc_6i_Z1Os9Fa.webp) Capy株式会社 ### [Google Cloud（GCP）移行で不正ログイン対策サービスの安定運用を実現](/case-studies/capy-google-cloud-operations/) 業界 IT・デジタルサービス サービス クラウド基盤・移行 / 運用・最適化 / セキュリティ 課題 顧客の急増に伴い、サービスの安定性と運用リソースが課題となっていました。停止を許容できないサービスのため、旧OSやソフトウェアも安全に更新する必要がありました。 支援 Google Cloud（GCP）への移行とスケールアウト可能な構成への刷新を進め、検証環境を使った段階的な更新や、監視・スクリプトによる運用を支援しました。 成果 アクセスが増えた際も安定してサービスを提供でき、最小限の停止でアップデートを進められる柔軟な運用基盤が整いました。 ![上場に向けたAmazon Web Services（AWS）基盤刷新で可用性とセキュリティを強化](/_astro/kh_grasys_02.BtefE4F7_Z1NJUmN.webp) ＩＡＣＥトラベル ### [上場に向けたAmazon Web Services（AWS）基盤刷新で可用性とセキュリティを強化](/case-studies/iace-travel-aws-infrastructure/) 業界 旅行 サービス クラウド基盤・移行 / 運用・最適化 / セキュリティ 課題 Smart BTMの成長に伴う性能低下や、IT専任者がいない中での運用負荷に加え、上場に向けてセキュリティと可用性を強化する必要がありました。 支援 マルチAZ、バックアップ、オートスケーリングを備えたAmazon Web Services（AWS）基盤を構築し、GuardDutyやSecurity Hub、最小権限、24時間監視を導入することで、安全に運用できる体制を整えました。 成果 高負荷時の応答低下を防げるようになり、脆弱性対応とセキュリティ確認の迅速化、運用担当者の手作業削減につながりました。 [導入事例一覧を見る](/case-studies/)