“すぐに再生スタート”できる独自の配信技術から、“秒間3万リクエスト”にも耐える強いインフラまで

「Nintendo Music」の裏側に技術と工夫　快適な“ゲーム音楽体験”を届けるために

常時安定稼働を実現する、API周りのサーバー構成

　続いては、ゲーム音楽の「探索体験」を支えるAPI周りの技術だ。

　APIの提供では、3つの技術特性を重視している。ひとつ目は「常時安定した稼働」だ。Nintendo Musicは、40を超える国や地域で配信されているため、ユーザーのタイムゾーンはバラバラだ。ピーク時間帯は「通勤通学時間」や「お昼休み時間」だが、常にどこかの地域でピーク時間帯を迎えることになるため、常に安定したサービス提供を維持する必要がある。

常に安定した稼働が求められた

　2つ目は「突発的なアクセス増加への対応」だ。リリース直後や注目コンテンツの追加といった事前準備ができるケースだけでなく、突発的なアクセス増加にも対応しなければならない。3つ目は「安定したユーザー体験の提供」だ。Nintendo Musicの目的は、ゲーム音楽を楽しんでもらうことであり、ストレスなくアプリが利用できるよう、高速かつ安定したレスポンスも重視した。

　これらの特性を満たすインスタンスの起動速度やスケーラビリティを評価して、APIサーバーには、Google Cloudのサーバーレスコンテナ実行環境「Cloud Run」を採用している。

　保守工数削減やスパイク（アクセスの急増）対応の観点では、Cloud Runに加え、開発言語に「Go」を採用して、コンテナの迅速なスピンアップによるスケールの高速・安定化を図っている。また、永続層（データベース）には、マネージドかつスケールが容易なサーバーレスのNoSQLデータベース「Firestore」をDatastoreモード（従来のDatastoreと同様の動作をするモード）で利用している。

　また、安定したサービス提供の観点では、Cloud Runの前段に「Cloud Load Balancing」を導入した。IP Anycastによる高可用性・低遅延・高速応答に期待しての採用であり、TLS終端でラウンドトリップタイムの最小化も図れる。さらに、前段でもCDNを配置して、更新頻度が少ない曲のマスターデータやアセットをキャッシュ。一方で、ユーザーの視聴状況に応じて動的に生成されるデータや、自作のプレイリストといったキャッシュが利かせにくいものは、経路最適化だけに留めている。

API周りのサーバー構成

　永続層へのアクセスにおいては、Cloud Run上で「メモリキャッシュ」も活用する。「特にマスターデータ系のアクセスは、要求されるキーやエンティティの偏りが原因でHotspot（過度な負荷がかかる領域）が発生する懸念がある、この解決と永続層そのものへのリクエストを減らすために、メモリキャッシュも併用する」と灘友氏。

　具体的には、永続層からのリソースの取得を2段階に分けてキャッシュする方式をとる。第1段階では、取得したいリソースのIDを解決して、その解決されたIDを「ID Cashe」に入れる。このID解決に、Datastoreの「Keys Only Query」を利用するのが、2段階方式を採用した理由だ。射影クエリの一種であるKeys Only Queryは、エンティティのキーだけが返却される仕組みで、レイテンシとコストを低減できる。最初からID指定でリソースを要求するケースは、第1段階をスキップして、第2段階に進む。

メモリキャッシュの第一段階

　第2段階では、第1段階で処理・解決したID、もしくは直接指定されたIDに紐づくリソースを取得して「Resource Cashe」に入れる。そして、キャッシュにないリソースのみをFirestoreから直接取得する仕組みとなっている。「こうした戦略は、Cloud Run上のインスタンス毎にメモリキャッシュの状態が異なり、構成も複雑になるが、安定化とレスポンス速度の向上、コスト削減を実現できる」（灘友氏）

メモリキャッシュの第二段階