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

＼積極的に技術発信を行なっております／

▽ Twitter/COLOPL_Tech
https://twitter.com/colopl_tech

▽ connpassページ
http://colopl.connpass.com

▽ COLOPL Tech Blog
http://blog.colopl.dev

Transcript

1. 開発から運用への 切替えで起きること
2. 2 • 2020年に新卒入社 • 経歴: ユージェネのローンチ直前からサービス終了まで担当最 近までは白猫プロジェクトでの運用担当 • 現在: 新作タイトル • 趣味: 音楽 楽器 キャンプ 今年のサマソニいきたかった😭 氏名　 ： 部署名 ： 岡村 ごう 技術基盤本部 第1バックエンドエンジニア部 第1グループ 第1チーム 自己紹介
3. アジェンダ 1. ローンチ前後の働き方の違い 2. ソーシャルゲームの運用の特色 3. ローンチ前に準備したこと 4. ローンチ後に顕在化した課題とその取り組み 3
4. ローンチ前後の 働き方の違い 4
5. 5 ローンチ前後の働き方の違い ~ 言葉の定義 ~ 開発 ゲームを作り出すプロセス • 新機能の企画実装 • システムの設計 • コンテンツ制作 • テスト 運用 ゲームを維持・管理するプロセス • サーバーのメンテナンス • バグ修正 • コンテンツのリリース • マーケティング施策の実施
6. 6 ローンチ前後の働き方の違い~ 業務内容の比重 ~ 開発 運用 運用 開発 ローンチ前 ローンチ後 ローンチ前後で業務内容の比重が変わります。 弊社では新しい体験を提供し続けることを目指しているため、ローンチ後でも開発が続きます。 • アセットやデータの更新がアップデートのメイン • さらに、コア体験から変わる新機能の追加を積極的行っている
7. ソーシャルゲームの 運用の特色 7
8. 8 ゲーム制作の現場では、非常に多くの職種が関わって開発しています また数ヶ月後の施策まで開発を並行して実装をするため、ローンチ前と比べて全体の人数が増える (弊社では、新コンテンツのリリースサイクルは 2週間毎 (1ヶ月に2回) がスタンダード) 運用の特色 ~ コミュニケーションのコスト高め ~ • エンジニア ◦ クライアントエンジニア ◦ サーバーエンジニア ◦ インフラエンジニア • デバッガー • CX (カスタマーエクスペリエンス) • マーケティング etc .. • プロデューサー • ディレクター • プランナー • 2Dデザイナー ◦ イラスト・UI など • 3Dデザイナー ◦ モデル・エフェクト モーション など • シナリオライター • サウンドクリエイター
9. 9 　　=> 詳しくは、COLOPL Tech 勉強会 「ゲームバックエンドを支えるノーメンテナンス運用」を実施しました！ 運用の特色 ~ ノーメンテの考慮コストがある ~
10. 10 ソーシャルゲームは、イベント開始前などはアクセス数が急上昇する傾向があります。 前後の負荷の見積もりとスケール対応、監視業務が必要です。 運用の特色 ~ 監視 ~
11. 11 ちなみに.... サーバーの監視にはさまざまなツールを用いています。 • Grafana ◦ CPU利用率、rps (request / 1sec)、APIエラー率を表示して、負荷や障害の監視をする • Datadog ◦ API毎の latency を表示して、性能の悪化が起きてないかなど監視する 運用の特色 ~ 監視 ~
12. ローンチ前に 準備したこと 12
13. 13 ゲームのバックエンドの負荷はローンチ直後に最も急激にスパイクします。 ローンチ直後は最もサービスを停止したくないタイミングなので、負荷試験は特に重要です。 • 負荷に弱い処理/仕様の洗い出しと改修 • Cloud Spanner のウォームアップ 弊社ではLCE (Launch Coordination Engineering) チームと連携して対応を行なっています。 　　=> 詳しくは、大規模モバイルゲームのローンチを支える技術 を実施しました！ 準備したこと ~ 負荷試験 ~
14. 14 ローンチの数ヶ月前に社内ベータを行っています。 実際の運用を想定して2週間ほど行っています。 • お知らせでのユーザーコミュニケーション • イベントなどのデータの更新 • KPI (ユーザー動向) ログ の集計 • (その道のプロである社員に遊んでもらい意見を募り、ブラッシュアップする目的もあり) そして、いろんな問題が起きるので😭 順次対応していきます。 • 意図通りにマッチングが動作しなかったり • バグ調査に役立つログがなかったり ◦ ↑ を手っ取り早くみるツールが実装されてなかったり • 安定しない通信や突然のサスペンドによる不具合 準備したこと ~ 社内ベータ ~
15. 15 特定のロジックなどを管理ツールから停止する機能を実装しました。 ローンチ時や新機能のリリースの際は、想定外の理由で不具合が起きることがあります。 その際に迅速に機能を止めることでサービスへの影響を小さくすることができます。 具体的には以下のようなロジックに仕込んでいます。 • 課金に関わるロジック • 新規ユーザー登録 • ランキング • フレンド • プレゼント受け取り 準備したこと ~ 緊急停止機能 ~
16. 16 オミット機能要素の削除などを行っていました。 • ゲーム制作は特にスクラップ&ビルドをするため、不要なものが放置されている場合がある • 新規メンバーの学習コストを減らす • ローンチ後にコードを削除するにはリスクが伴う また、QAでは見きれないデータの再チェックとダミーデータの削除なども行いました。 データ更新での修正では確認工数が大きいので、チェックは特に大事です。 • 報酬が設計通りか、異常な個数になっていないか、 • 存在しないID設定していないか • それに伴って不要なデータがないか 準備したこと ~ その他 ~
17. ローンチ後に 顕在化した課題と その取り組み 17
18. 18 どんなに備えていてもローンチ後に判明するバグは沢山あります。 ローンチ後の2ヶ月間程は重大なバグが定期的に発見され、都度修正を行っていました。 中でも記憶に残っているものを紹介します。 • インクリメント処理が重複するバグ ◦ インクリメント数を static 変数にキャッシュして、まとめて更新するという仕組み ◦ API内部でリトライの考慮がされておらず … ▪ Spanner (DB) はトランザクション内部でリトライされる前提のアーキテクチャ • redisのメモリ使用量が線形に増えていくバグ ◦ TTLが無期限になっていた 顕在化した課題とその取り組み ~ バグ 😭😭😭 ~
19. 19 運用をしていく中で発見する問題もあるため、各種改善を行っていました。 • 更新頻度の多いデータを使い回せる設計に再実装する ◦ データ設定の工数が高いことがわかったので簡単にする対応 ▪ 例: イベントデータ、報酬データ、ステージデータ ◦ ローンチ前はダミーデータを利用していたので気づきにくい問題 ◦ ローンチから時間が経つにつれて修正しづらくなるので重要 • 定常的に起きる作業の権限委譲 / 自動化 ◦ 月毎の集計 (ランキングなど) ◦ お知らせ画像の反映 ◦ アプリのサポートバージョン変更の反映 顕在化した課題とその取り組み ~ 運用の改善 ~
20. 20 • ローンチ前後の働き方の違い ◦ 業務内容の比重の違い • ソーシャルゲームの運用の特色 ◦ コミュニケーションコスト増、ノーメンテ、監視・見積もり • ローンチ前に準備したこと ◦ 負荷試験、社内ベータ、緊急停止機能 • ローンチ後に顕在化した課題とその取り組み ◦ (本番で初めて発覚する)バグ、運用の改善 まとめ
21. ありがとうございました 21