ゲームは今や据え置き機だけでなく、スマホやPCなど多様なデバイスを使って、オンラインでどこでも誰とでも遊べるような世界に広がってきています。
それに伴い、ゲームを開発する環境や運用を行うゲーム会社の環境も変わってきています。
昨今のゲーム開発運用における状況と課題感、またその解決方法の一つとなる「オブザーバビリティ」について解説したいと思います。

前提

今回はゲームの開発よりも運用をメインに絞って解説したいと思います。
(開発に関してはまた別途解説したいと思います)
仮の設定として下記のような自社でスマホゲームを運用している体制をイメージしています。
※あくまで1例のため、特定の開発チームを想定したものではありません

ゲームのオンライン化に伴う状況の変化

ゲームといえばアナログなものから据え置き機、スマホ、PCと様々なデバイスでも遊べるようになっています。またネットに繋がり世界中の人といつでもどこでも遊べるゲームもたくさんリリースされ、ユーザの選択肢は無限に広がっている状況です。
その一方で、毎日のように新しいタイトルがリリースされる状況で運営や開発費を回収できるヒット作を作っていくことが難しくなってきています。
注目のタイトルもリリース初日や大型アップデート明けにトラブルが発生し遊べないことで大きな機会損失になり、それが原因でユーザが離れてしまうということもよく聞く話です。
ゲームをリリースするまでには多くの時間とお金と人が費やされていますので、当然ゲーム会社の運営チームも対策を講じます。

ゲーム運用を行う際の主な課題

ここで対応すべき課題として考えられるものを2つあげたいと思います

(1)障害発生時の原因特定に時間がかかる
どれだけリリース前の開発段階でバグを対応しても、どうしてもバグによるエラーや想定外の問題は発生します。
それがお客様個人環境の問題なのか、アプリの問題なのか、バックエンドのサーバの問題なのか、どれくらい影響しているのかを迅速に把握し対応する必要があります。
しかし昨今のシステムマイクロサービス化及びマルチデバイス化はゲームにおいても起こっており、クライアント→ログインサーバ→ゲームサーバ→DBサーバといった単純な構成では構成されていません。
クラウドのマネージドサービスを駆使し負荷に耐えられるよう柔軟に拡縮する構成をとることも多いので調査箇所がどうしても増えてしまいます。

(2)開発運用に関わるエンジニアリソースの限界
売上の上がっているタイトルを除いては、開発および運用に関わるエンジニアリソースは少数精鋭で対応していることが多いです。そのため何かしら障害が発生した際は、迅速に切り分けて対応する必要がありますが、次のUpdateの準備も必要ですし、お客様からのお問い合わせのための調査などもあり、できる限り効率的に短時間で対応する必要があります。

これらの課題を解決するために、ゲーム会社の運用チームではどのような事ができるのでしょうか？

「オブザーバビリティ」という考え方

オブザーバビリティ（Observability）とは、オブザーブ（Observe）：「観測する」と、アビリティ（Ability）：「能力」を組み合わせた複合語で、日本語では「可観測性」あるいは「観測する能力」などと訳されます。システム上で何らかの異常が起こった際に、それを通知するだけでなく、どこで何が起こったのか、なぜ起こったのかを把握する能力を表す指標、あるいは仕組みを指します。

オブザーバビリティでは、アプリケーションの稼働に伴って生まれる膨大な情報の中から、内部状況を把握するためのデータを取得し、複雑なシステムの状態やアプリケーションの動きを可視化します。つまり、エラーという結果だけでなく、そこに至るまでの道筋を逆にたどって、どこにトラブルの原因があるのかを探り出すのです。そのため、予期せぬトラブルに対しても有効に機能します。

「オブザーバビリティ」について詳しくは下記ドキュメントもご参照ください

ではゲームを運用する上でなぜこのオブザーバビリティが必要なのでしょうか？
ゲームはユーザが遊んでこそ成立します。そのためユーザがどのように遊ぶのか、どう操作するのか、どのような要素があれば課金するのか、といった情報はとても重要です。
快適に遊べなければ他のゲームに移ってしまうので、その前にユーザが「何に困って」いて「何を求めているのか」を把握する必要があります。そもそも把握できていなければ解決もできないですね。

なのでゲームを運用する上でもオブザーバビリティはとても重要になります。
ユーザが困っている状況が「なぜ発生しているのか」
その状況の「原因は何なのか？」
解決するためには「どのように対処すればいいのか」
これらを迅速し把握し対処していくこと、これが「オブザーバビリティ」になります。

New Relic でできること

New Relicは、エンジニアがスタック全体をモニタリング、デバッグ、改善できるオールインワンのオブザーバビリティプラットフォームです。
フロントエンドからアプリケーション、インフラまで 一気通貫で システムを見ることができるため、多くのゲーム会社でご利用いただいています。New Relicを使うことでタイトルに関わるメンバー全員が一つのプラットフォーム上で情報を確認いただくことが可能です

フロントエンドエンジニア向け

今回スマホゲームを例にしていますが、New RelicのMobile AgentではUnityとUnreal Engineに対応しています。

それぞれアプリにSDKを導入いただくことで、アプリのパフォーマンス、エラー、ユーザーインタラクションなどに関する詳細な情報を確認いただくことが可能になります。
どういった端末でよくアクセスするのか、アクセスの傾向、クラッシュが発生した際にどのような操作を行っていたかなども確認いただくことが可能です。(スクリーンショットはUnityでエラーが発生した時の例です)

Qiitaの記事に導入手順をまとめていますので、参考にしてみてください！！

開発エンジニア向け

バックエンドのエンジニアの方はバックエンドで動くアプリケーションのパフォーマンスやエラー状況を確認いただけます。バックエンドで発生したエラーや遅延の状況からどの処理が原因なのか、その時に発行されたQueryやログも確認できます。
フロントエンドもSDKが入っていると紐付けて確認することができるので、ユーザがどのような操作をし、その時にどのような経路でAPIを叩きに行っているのかも確認する事が可能です。

APMは様々な言語に対応しています。

複数のアプリケーションにアクセスするような構成でも、どこでエラーが発生しているのか、その時にログも紐づけて確認する事が可能です。

インフラエンジニア向け

オンプレやEC2のような Virtual Machine 上に構成する場合でも、Infrastructure Agentを導入することで、これまで通りCPUやメモリを確認する事が可能です。
APMが入っている場合は、各Hostから対応するAPMに遷移する事も可能です。(もちろんAPMからHostへの遷移も可能です)

またAWS、Azure、GCPとは連携可能なため、マネージドサービスのメトリクスもNew Relic上でまとめて見ることができます。

PM向け

これらのデータを元にゲームの稼働状況やユーザの動向を把握するためのダッシュボードを作成することが可能です。
下図はあくまで例ですが、このようにシステムの状況を一覧化しておくことで、各担当との連携を強化しチーム一丸となってタイトル運用を行うためのツールとして活用いただけます。

事例紹介

事例１

実際に利用されている事例をご紹介します。
全世界同時配信のゲームをリリースした際に、世界中のユーザが快適にゲームを利用できているのか、システムの安定運用とサービス品質向上にNew Relicを活用されたワンダープラネット様の事例をご紹介します。

ユーザグループで登壇された際の動画もありますので、是非実際にワンダープラネット様がお話しされた内容もご覧いただければと思います。

事例２

世界3,900万ダウンロードを誇るスマホ向けリズムアドベンチャーゲーム『プロジェクトセカイカラフルステージ！ feat. 初音ミク』のサービス基盤の安定化にNew Relicを活用されたカラフルパレット様の事例をご紹介します。
システムの安定化やボトルネックの解消、そして負荷の高い周年イベントへの対応などにご活用されています。

まとめ

ゲームの運用においてオブザーバビリティが重要であることをご理解いただけましたでしょうか？
ゲーム運用を効率化しゲーム開発にリソースを割けるよう是非New Relicをご活用ください！！
まずは是非無料からお試しください！

無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！

New Relic株式会社のQiita Organizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。