CEDEC2022 セッションレポート インフラからアプリまで！アリスフィクションを全世界で安定稼働させる開発チームの裏側に迫る #CEDEC2022 #classmethod_game
こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。
CEDEC2022 を聴講しています。セッションレポートをまとめました。
セッション
タイトル : インフラからアプリまで！アリスフィクションを全世界で安定稼働させる開発チームの裏側に迫る
受講スキル：
特になし/ゲーム開発担当者
受講者が得られるであろう知見 :
オブザーバービリティを活用した障害対応の効率化や利用顧客環境から見た品質向上の方法
セッションの内容
ワンダープラネット株式会社が手がける、アリスフィクションは、全世界同時配信・同時運営されるパズルRPGゲームで、世界中のユーザーに安定したプレイ体験を届けることが求められました。
その裏にあるシステムを安定的に稼働させるためにワンダープラネットが取り組んだことはずばり、インフラからアプリまでシステム全体の品質を観測できるようにし、プロダクト開発チーム全員で品質向上に取り組めるようにすることです。
本セッションでは、New Relicを積極的に活用し、開発過程でプロダクト開発チームとSREチームがどのように連携しリリースに向けて取り組んだか、具体的な取り組みについてお話しします。
講演者プロフィール
梅津 寛子 様
所属 : New Relic株式会社
部署 : 技術統括 プロダクト技術部 ソリューションコンサルタント
開 哲一 様
所属 : ワンダープラネット株式会社
部署 : 執行役員 VPoE 兼 EDMO室長
レポート
よくあるゲーム開発・運用における課題
ゲームに繋がらない → ユーザー固有のものなのか？
ロードが遅い → いつも同じ機能なのではないか？
エラーが多発 → クライアント？ or サーバー？
ユーザーの状況が十分に把握できていないことが原因とのことです。
- 詳しい人だけが対応できる「属人化」は発生
- トラブル対応に関わる人数が多く情報が錯綜
- ユーザーからの問い合わせが不明瞭
結果解決に時間がかかり、ユーザーの不満が爆発するという問題が起きます。
オブザーバビリティ
クラウド活用が進みマイクロサービス化が浸透した結果、システムがより複雑化し従来のインフラ監視だけではサービス全体を迅速に把握できません。
障害対応に時間をかけるのではなく、本来である面白いゲームを作ることに注力できるよう開発段階からトラブルを迅速に対応できる環境作りが大切になってきます。
ワンダープラネット様の事例紹介
ワンダープラネット様 ミッション
ワンダープラネット様のお話
New Relic 導入背景
世界中のユーザーに快適なプレイ体験を届けたい！
しっかりと測って定量的に品質を改善し迅速に対処することが求められています。
- これまでのモニタリング環境
- インフラのモニタリング中心
- サーバーアプリ
- インフラモニタリングが起点
- スポットでの分析、時間もかかる
- モバイルアプリ
- クラッシュモニタリングのみ
- ユーザーの指摘から分析開始することが多かった
- システム全体の品質をモニタリングできていかなった
- ツールがプロダクト毎に統一されていなかった
オブザーバビリティの向上
いくつかの製品を調査した結果New Relicを採用。
- オブザーバビリティとのして機能を網羅、すべて一箇所で観測
- 費用体系がシンプル
- 日本語サポートが充実
アリスフィクションへの導入・活用
導入体制
SREチームがNew Relic導入を主導
New Relic社のオンボーディング支援を受けながら進めたとのことです。
- キックオフ
- 導入目的整理
- 導入機能の選定
- インストール支援
- Slack上の技術支援
- New Relic操作方法を学ぶ勉強会
- サーバーエンジニア全員で
アリスフィクションで活用している主な機能
APM
- APIレスポンスを快適に
- ボトルネックの特定を効率化したい
- サーバーアプリのパフォーマンスを常に監視したい
- PHPエージェントをインストールするだけでサーバーアプリのパフォーマンスがリアルタイムに集計される
- 集計の手間いらずは快適
- New Relicに必要な情報が揃っている
- APIの処理でどこがボトルネックになっているかが一目瞭然
- New Relicの画面をクリックするだけで特定可能
- リリース前の負荷試験においてAPIのボトルネック分析に大活躍
- スタックトレースからソースコードに飛べる
- リリース後も継続的な品質改善に貢献
ログ管理
- ログ収集、調査は難しい
- APIサーバーのアプリログをNew Relicに集約
- GUIで誰でもログ閲覧
- APIサーバーのアプリログをNew Relicに集約
- 複数サーバーのログが一箇所に集約されるのはありがたい
- GUIで調査、特定のスキルを必要としない
- エラーログの傾向を勝手に集計してくれる
- 不具合原因を素早く特定、対応することができた
- リアルタイム集計から頻度高いエラーを優先的に対応
- ユーザーIDでエラーログを絞り込むことが一瞬で可能
- リアルタイム集計から頻度高いエラーを優先的に対応
- クライアントエンジニアもNew Relic上でサーバーログを確認するようになった
AWSインテグレーション
- 同じツールで全てをモニタリングしたい
- CloudWatchのメトリクスをNew Relicでもモニタリング可能
- ワークロードが何かと便利
- リソースのグループ毎にアラートを設定できる
- アラートを仕掛けておくとシステムのどこに問題があるかを俯瞰できる
モバイルモニタリング
- ユーザーの端末上のパフォーマンスを測りたい
- 通信時間、ロード時間などユーザーの体験に影響を与える指標
- モバイルモニタリングのSDKを導入
- しかし、UnityのSDKは無かった
- Unityラッパーを自作
- 地球の裏側のユーザーもリアルタイムで観測できるように
- 特に海外リージョンではどのようなユーザー体験になっているのか？
ダッシュボード&アラート
- 目的に応じてダッシュボードを作成
- 機能を超えて時間範囲が連動する機能が便利
- アラートを設定しSlackに通知
- Slackにグラフが表示される
今後の取り組み
- SLI/SLOの導入
- チームで追っていくフロー・文化の確立
- 開発フェーズ早期からのモニタリング
- リリース直前になりがちなパフォーマンス・品質担保を早期に
- 後になればなるほど修正コストがあがる
- ユーザー+転送量課金なので開発環境にも気軽に入れやすい
発表者のまとめ
Q&Aセッション
Q：開発・運用において、基本リモートワークだったと思いますが、その中で開発を円滑に行うために気をつけたことは？
A：Slack中心、oViceでなにかあったらコミュニケーション、密にできていた。New Relicのような共通ツールを使うことで会話がスムーズにできた。
Q：オブザーバビリティを実現するにあたってこれまでと大きく監視方法が変わったを思いますが、開発メンバーの意識はどう変わりましたか？
A：システム全体を測る必要性の浸透に力を入れた。従来からAPMの重要性を感じているエンジニアもいた。ウェルカムだった。
Q：ゲームの品質を上げていくことが命題とのことですが、開発に力を入れるために今後取り込みたいことを教えてください
A：いかに面白いゲームをユーザーに届けるかが大切。品質上げるところはツールを使いエンジニアの時間を増やす。
以上、吉井 亮 がお届けしました。
