\積極的に技術発信を行なっております/
▽ Twitter/COLOPL_Tech https://twitter.com/colopl_tech
▽ connpassページ http://colopl.connpass.com
▽ COLOPL Tech Blog http://blog.colopl.dev
開発から運用への切替えで起きること
View Slide
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