Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

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

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

COLOPL Inc.

June 30, 2023
Tweet

More Decks by COLOPL Inc.

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide