開発から運用への 切替えで起きること

2 ● 2020年に新卒入社 ● 経歴: ユージェネのローンチ直前からサービス終了まで担当最 近までは白猫プロジェクトでの運用担当 ● 現在: 新作タイトル ● 趣味: 音楽 楽器 キャンプ 今年のサマソニいきたかった😭 氏名　 ： 部署名 ： 岡村 ごう 技術基盤本部 第1バックエンドエンジニア部 第1グループ 第1チーム 自己紹介

アジェンダ 1. ローンチ前後の働き方の違い 2. ソーシャルゲームの運用の特色 3. ローンチ前に準備したこと 4. ローンチ後に顕在化した課題とその取り組み 3

ローンチ前後の 働き方の違い 4

5 ローンチ前後の働き方の違い ~ 言葉の定義 ~ 開発 ゲームを作り出すプロセス ● 新機能の企画実装 ● システムの設計 ● コンテンツ制作 ● テスト 運用 ゲームを維持・管理するプロセス ● サーバーのメンテナンス ● バグ修正 ● コンテンツのリリース ● マーケティング施策の実施

6 ローンチ前後の働き方の違い~ 業務内容の比重 ~ 開発 運用 運用 開発 ローンチ前 ローンチ後 ローンチ前後で業務内容の比重が変わります。 弊社では新しい体験を提供し続けることを目指しているため、ローンチ後でも開発が続きます。 ● アセットやデータの更新がアップデートのメイン ● さらに、コア体験から変わる新機能の追加を積極的行っている

ソーシャルゲームの 運用の特色 7

8 ゲーム制作の現場では、非常に多くの職種が関わって開発しています また数ヶ月後の施策まで開発を並行して実装をするため、ローンチ前と比べて全体の人数が増える (弊社では、新コンテンツのリリースサイクルは 2週間毎 (1ヶ月に2回) がスタンダード) 運用の特色 ~ コミュニケーションのコスト高め ~ ● エンジニア ○ クライアントエンジニア ○ サーバーエンジニア ○ インフラエンジニア ● デバッガー ● CX (カスタマーエクスペリエンス) ● マーケティング etc .. ● プロデューサー ● ディレクター ● プランナー ● 2Dデザイナー ○ イラスト・UI など ● 3Dデザイナー ○ モデル・エフェクト モーション など ● シナリオライター ● サウンドクリエイター

9 　　=> 詳しくは、COLOPL Tech 勉強会 「ゲームバックエンドを支えるノーメンテナンス運用」を実施しました！ 運用の特色 ~ ノーメンテの考慮コストがある ~

10 ソーシャルゲームは、イベント開始前などはアクセス数が急上昇する傾向があります。 前後の負荷の見積もりとスケール対応、監視業務が必要です。 運用の特色 ~ 監視 ~

11 ちなみに.... サーバーの監視にはさまざまなツールを用いています。 ● Grafana ○ CPU利用率、rps (request / 1sec)、APIエラー率を表示して、負荷や障害の監視をする ● Datadog ○ API毎の latency を表示して、性能の悪化が起きてないかなど監視する 運用の特色 ~ 監視 ~

ローンチ前に 準備したこと 12

13 ゲームのバックエンドの負荷はローンチ直後に最も急激にスパイクします。 ローンチ直後は最もサービスを停止したくないタイミングなので、負荷試験は特に重要です。 ● 負荷に弱い処理/仕様の洗い出しと改修 ● Cloud Spanner のウォームアップ 弊社ではLCE (Launch Coordination Engineering) チームと連携して対応を行なっています。 　　=> 詳しくは、大規模モバイルゲームのローンチを支える技術 を実施しました！ 準備したこと ~ 負荷試験 ~

14 ローンチの数ヶ月前に社内ベータを行っています。 実際の運用を想定して2週間ほど行っています。 ● お知らせでのユーザーコミュニケーション ● イベントなどのデータの更新 ● KPI (ユーザー動向) ログ の集計 ● (その道のプロである社員に遊んでもらい意見を募り、ブラッシュアップする目的もあり) そして、いろんな問題が起きるので😭 順次対応していきます。 ● 意図通りにマッチングが動作しなかったり ● バグ調査に役立つログがなかったり ○ ↑ を手っ取り早くみるツールが実装されてなかったり ● 安定しない通信や突然のサスペンドによる不具合 準備したこと ~ 社内ベータ ~

15 特定のロジックなどを管理ツールから停止する機能を実装しました。 ローンチ時や新機能のリリースの際は、想定外の理由で不具合が起きることがあります。 その際に迅速に機能を止めることでサービスへの影響を小さくすることができます。 具体的には以下のようなロジックに仕込んでいます。 ● 課金に関わるロジック ● 新規ユーザー登録 ● ランキング ● フレンド ● プレゼント受け取り 準備したこと ~ 緊急停止機能 ~

16 オミット機能要素の削除などを行っていました。 ● ゲーム制作は特にスクラップ&ビルドをするため、不要なものが放置されている場合がある ● 新規メンバーの学習コストを減らす ● ローンチ後にコードを削除するにはリスクが伴う また、QAでは見きれないデータの再チェックとダミーデータの削除なども行いました。 データ更新での修正では確認工数が大きいので、チェックは特に大事です。 ● 報酬が設計通りか、異常な個数になっていないか、 ● 存在しないID設定していないか ● それに伴って不要なデータがないか 準備したこと ~ その他 ~

ローンチ後に 顕在化した課題と その取り組み 17

18 どんなに備えていてもローンチ後に判明するバグは沢山あります。 ローンチ後の2ヶ月間程は重大なバグが定期的に発見され、都度修正を行っていました。 中でも記憶に残っているものを紹介します。 ● インクリメント処理が重複するバグ ○ インクリメント数を static 変数にキャッシュして、まとめて更新するという仕組み ○ API内部でリトライの考慮がされておらず … ■ Spanner (DB) はトランザクション内部でリトライされる前提のアーキテクチャ ● redisのメモリ使用量が線形に増えていくバグ ○ TTLが無期限になっていた 顕在化した課題とその取り組み ~ バグ 😭😭😭 ~

19 運用をしていく中で発見する問題もあるため、各種改善を行っていました。 ● 更新頻度の多いデータを使い回せる設計に再実装する ○ データ設定の工数が高いことがわかったので簡単にする対応 ■ 例: イベントデータ、報酬データ、ステージデータ ○ ローンチ前はダミーデータを利用していたので気づきにくい問題 ○ ローンチから時間が経つにつれて修正しづらくなるので重要 ● 定常的に起きる作業の権限委譲 / 自動化 ○ 月毎の集計 (ランキングなど) ○ お知らせ画像の反映 ○ アプリのサポートバージョン変更の反映 顕在化した課題とその取り組み ~ 運用の改善 ~

20 ● ローンチ前後の働き方の違い ○ 業務内容の比重の違い ● ソーシャルゲームの運用の特色 ○ コミュニケーションコスト増、ノーメンテ、監視・見積もり ● ローンチ前に準備したこと ○ 負荷試験、社内ベータ、緊急停止機能 ● ローンチ後に顕在化した課題とその取り組み ○ (本番で初めて発覚する)バグ、運用の改善 まとめ

ありがとうございました 21