はじめに

当ブログは2025/8/5,6に東京ビッグサイトにて行われたセッションレポートとなります。

タイトル：Nintendo Music を支える技術
登壇者：ニンテンドーシステムズ株式会社 システム開発部・チーフ 灘友 良太氏 、システム開発部 相馬 啓佑氏

セッション概要

ゲーム音楽配信アプリ Nintendo Music のサーバーレスなインフラ周りの技術と、Dataflow を用いたメディア処理、楽曲制作に関する取り組みについて、お話されておりました。

セッション内容

当該ブログではインフラ周りの技術にフォーカスをあてて記載しております。

求められている要件

40ヵ国以上へ当該アプリを公開されているため、グローバルな各地域において、どの時間帯でも常に安定させる必要があったとのこと。これはグローバルならではの要件であると感じました。アクセスが多いタイミングがどの時間帯でも訪れる可能性がある環境として、常に安定したパフォーマンスを出す必要があるとのことでした。

Google Cloud への期待値

突発的なアクセスにおいても事前準備無しに負荷に耐えきることができるサービスを提供でき、常に安定したユーザー体験が提供できること、これらを踏まえて、 Google Cloud の Cloud Run を採用されたとのことです。

サーバーの構成

構成のご説明時に、マネージドであり、スケールが容易に行えることについて、多くお話しされておりましたので、軸になったのはその点と、CDN でのキャッシュ、Cloud Run 上でのメモリキャッシュを活用し、アクセスの高速化を図ったとのことです。

CDN のキャッシュについて

CDN ではキャッシュコントロールヘッダーを利用し、高速にデータ提供を行うような仕組みとなっており、主にお気に入りなどは、キャッシュを利用していたと、お話されておりました。

メモリキャッシュについて

メモリキャッシュとして以下が挙げられておりました。

これらのキャッシュを用いて、キャッシュにないリソースのみ Firestore へのアクセスを行わせることで、高速化、コストに関する最適化を行われたとのことです。Cloud Run 自身にメモリキャッシュを行わせる、というところが、こういったセッションでも、聞く機会がなく、勉強になりました。

性能評価について

負荷試験で性能評価を行われ、GKE で並列実行させ、Pod 制限の増減で負荷を調整されたとのことです。負荷試験は以下2つで行われ、それぞれ想定ケースについても触れられておりました。

  • スパイク的アクセス
    • 0 から突然に増える形で実施
    • 10分間に秒間3万アクセスまでのスパイク
  • 常時アクセスによる負荷

スパイク的アクセスについては、チューニングせずとも安定していたものの、メモリーエラーなどはおきていたりしたため、最終的に少しのチューニングで解決できたとのこと。Cloud Run では、0スケールでもある程度は耐えられると思っておりましたが、やはり、メモリーキャッシュなどそういったエンジニアリングでの考慮でかなり高負荷に耐えられているんだなぁと感じました。

また常時アクセスによる試験も定めた SLO が満たせている状態であったとのことです。

セッションまとめ

マネージド且つサーバーレスで構築できたことで、運用負荷が低い状態且つ、今回はキャッシュにより高いパフォーマンスを実現できたとのことでした。

まとめ

今回のような構成については、多くのケースで有用な構成であると感じました。Cloud Run のパフォーマンスはもちろんですが、メモリーキャッシュをもたせる部分においても触れられており、クラウドのみならず、そのうえで動かす技術についても多く語られており、このセッションを聞いて Google Cloud のドキュメントのみで得られない知見を発表いただいたと感じました。私もこの先の案件で活かしたいと思うのと同時に、登壇等においては、そういった聴講者が聞きたいところに届くような登壇を行いたいと感じました。