©MIXI ©MIXI ソーシャルゲームの長期運用
 を目指すための SRE の取り組み - 10 周年を⽬指すコトダマンの場合 - ⼤野⼀樹 @i2tsuki

22 ©MIXI 自己紹介
 - 大野一樹(@i2tsuki_)
 - 2024 年 株式会社 MIXI 中途入社
 - 開発本部 CTO 室 SRE グループ
 - いろんな案件に SRE 支援する部署
 - 普段は関西でリモートで働いています
 - 最近は Go の Otel 実装などやってます
 - ソーシャルゲームを担当するのは新卒以来


©MIXI 今⽇のおはなし ソーシャルゲーム に SRE は必要か?

©MIXI ソーシャルゲーム の歴史は SRE より古い ソーシャルゲーム に SRE は必要か?

5 ©MIXI ソーシャルゲームと SRE - ソーシャルゲームの歴史は SRE よりも古い
 - 会社のプロダクトを振り返っても SRE 本の登場以前にある
 2013 2009 mixi アプリ
 (サンシャイン牧場 など..)
 2016

6 ©MIXI ソーシャルゲームと SRE - ソーシャルゲームのライフサイクルは一般的な Web サービスより短い
 - 初期開発コストや運営コストが高い(3D モデル、エフェクト、ライセンス)
 - ヒットしなければ回収できないので継続が厳しい (信頼性 <<<< 収益性)
 - (ただし)ヒットさせること自体が難しくなっている..
 - 負荷対策
 - Web サービスと違ってローンチ時の負荷が一番高いことが多い
 - キャンペーンや新機能で負荷が増えることがある
 => 信頼性は初期やその後の負荷に対して、重点が置かれることが多い
 7 年前にソーシャルゲームに関わった時は念入りに負荷試験を担当していた


©MIXI 負荷対策以外の信頼性について考える時の要素は? ソーシャルゲームのサービス構成振り返り

8 ©MIXI ソーシャルゲームのサービス構成振り返り - リスマホアプリ(クライアント)とサーバが API 通信する
 - クライアントとサーバが API 通信する
 - サーバ障害が発生するとデータが取得できず遊べない
 - ソーシャル要素がある(ランキング、ギルド、レイドバトル etc..)
 - 協力プレイ、同時プレイの機能がある、早いレスポンス性が求められる
 - スタミナ、ガチャ、キャラ育成、課金アイテムの要素がある
 - 定期購入、アイテム配布、通知の機能がある


©MIXI 信頼性の損失があってもユーザ補填で対応できる..? 有料アイテムがもらえるならユーザさんもうれしい..?? ソーシャルゲームのサービス特徴

©MIXI そんなことはない!! 遊べないことはユーザさんの機会損失になる 信頼性の損失があってもユーザ補填でなんとかできる..?

©MIXI 信頼性について考える時の要素 ソーシャルゲームのライフサイクルと信頼性⽬標

12 ©MIXI ソーシャルゲームのライフサイクルと SRE の導⼊フェーズ ベータ ローンチ時 運用期 (撤退期) SLO (リクエストの信 頼性目標) 90 % 95 % 99 % ?? % SRE の範囲 安定して デプロイ できる 負荷調整 障害対応 - 障害対応 - コスト最適化 - ミドルウェアのアップデート - 脆弱性対応 - 新機能のためのサーバ構築 - 増え続けるデータへの対応 - データ分析のためのデータ収 集、漏れを防ぐ - パフォーマンスリグレッションの 検知 - 遅いクエリの最適化 - アプリケーション通知の監視 データの 保全 制作物の 保管 ドメイン の保持

©MIXI 運⽤期のソーシャルゲームにとっての信頼性

14 ©MIXI 運⽤期のソーシャルゲームにとっての信頼性 - ユーザさんにサービスを提供し続ける
 - プレイの機会損失を回避する
 - サービスを終了せざるを得ない状況を回避する
 (経営健全化、データロストを防ぐ etc..)
 - ユーザさんの資産(キャラ、アイテム etc..)を外部から守る
 - 不具合による不公平感を与えない
 - 遊び続けられる安心感がある


©MIXI サービス実例

©MIXI

©MIXI 『コトダマン』6周年記念プロデューサー＆ディレクターインタビュー｜10周年を迎えるための基盤改修と原点回帰 | ファミ通App【スマホゲーム情報サ イト】https://app.famitsu.com/20240527_2235977/

©MIXI 1 年前に SRE チームが発⾜!! (SRE チームがない以前はローンチ時の状態だったと⾔える) 10 周年を迎えるために..

19 ©MIXI 10 周年を迎えるための SRE チーム - 1 年前の SRE チームが発足当時
 - 現状の問題把握から着手
 - システム構成&デプロイの仕組みがわからない、 IaC できていない
 - ステージングと本番環境以外の環境がない(変更を試せる場所がない)
 - 解決するためにやったこと
 - システム構成のドキュメント化、 IaC 、アラートの整理やっていく
 - IaC を整理した後にインフラをお試しできる開発環境を構築
 目の前の問題を解決するまでチーム発足当時は信頼性に注目できなかった!!


20 ©MIXI 10 周年を迎えたサービス信頼性への注⽬ - サービス障害、不具合と改善への取り組み
 - サーバが過負荷になって、リクエストの処理が滞留する
 => 計測ができていない => 信頼性の計測と改善が必要
 - アイテムを受け取ることができない、特定の処理でフリーズする
 => エンジニアによる原因の調査 => 可観測性を向上させる
 - キャラクターの名前や属性が意図しているものと異なっている
 => マスターデータ作成時の人為的なミス => デプロイフローの改善が必要
 


©MIXI 最近の SRE チームの活動 10 周年を迎えるため、信頼性に貢献する

22 ©MIXI 10 周年を迎えるための SRE チームの活動 - リクエストに対する SLI の定義と計測
 - 別のモニタリングサービスを利用していたが、有効に活用できていなかった
 - New Relic APM を導入して SLI を定義して簡単に計測できるようになった
 
 
 
 
 
 
 => 処理時間を特定のパスの処理時間を対象に SLI を計測できる
 レイテンシの目標設定

23 ©MIXI 10 周年を迎えるための SRE チームの活動 アラートのルールの管理
 - HCP Terraform で一元管理
 - PullRequest でアラートの変更 の意思決定が記録できる
 - SLO に応じた閾値の見直し


24 ©MIXI - 可観測性の向上
 - New Relic APM の利用(アプリケーションのトレーシング)
 
 
 
 
 
 
 
 
 10 周年を迎えるための SRE チームの活動

25 ©MIXI - 可観測性の向上
 - 構造化ログの実装
 - サーバエンジニアに実装してもらって New Relic に集約
 
 
 
 10 周年を迎えるための SRE チームの活動

26 ©MIXI - マスターデータのデプロイフローの改善
 - マスターデータは大量の .xlsx で管理している
 - 手元で SQL に変換して Git リポジトリにコミットしてデプロイしていた
 
 
 
 10 周年を迎えるための SRE チームの活動 変換する .xlsx ファイルを選べる..

27 ©MIXI - マスターデータのローカルビルドで発生していたこと
 - 一部の .xlsx だけコンバートしてプッシュ
 - .sql ファイルを直接編集してプッシュ(.xlsx と整合性が取れなくなる)
 
 
 10 周年を迎えるための SRE チームの活動

28 ©MIXI - マスターデータのデプロイフローの改善
 - 人がローカルでツールを動かして変換するプロセスをやめる
 - GitHub Actions 化することで人間が介入する余地をなくす
 10 周年を迎えるための SRE チームの活動

29 ©MIXI - その他の SRE 活動
 - IaC の改善
 => Ansible の冪等性の確保、 HCP Terraform の導入
 冪等性がないと、意図した変更かどうかがわからない
 冪等性がないサードパーティの Ansible モジュールの冪等性を保証する
 
 
 
 - アラートの整理: 本当に必要なアラートだけにする
 - Amazon Aurora MySQL クラスターのアップデート
 10 周年を迎えるための SRE チームの活動 $ ansible-playbook -t setup ./setup.yml --ssh-common-args='xxx' -e @./group_vars/test.yml --diff --check (snip) 10.xxx.xxx.xxx : ok=176 changed=9 unreachable=0 failed=0 skipped=56 rescued=0 ignored=1 10.xxx.xxx.xxx : ok=177 changed=12 unreachable=0 failed=0 skipped=55 rescued=0 ignored=1 10.xxx.xxx.xxx : ok=177 changed=12 unreachable=0 failed=0 skipped=55 rescued=0 ignored=1 


30 ©MIXI - 最初は動くだけで良かったが長期運用を目指すと変化しないといけない
 - SLI, SLO
 - リリース時はリリースして顧客反応を見ることが大事
 => 長期運用では信頼性の観点で、顧客満足度に繋がる
 - Observability
 - リリース時は機能がすくないし、生のログだけで追えていた
 => 機能が増えるとログだけではわからない、再現ができない
 - マスターデータ
 - リリースから年月を経てデータ数が多くなっていく
 => 決まったリリースフローを踏ませたり、高速化する
 10 周年を迎えるための SRE チームの活動振り返り

31 ©MIXI - 更なる改善を目指した SRE 活動
 - SLI だけで計測できない信頼性の計測
 - バグやマスターデータの不具合の信頼性への影響は計測が難しい
 - 不利益を受けたユーザ数、機会損失の計測をしないといけない
 => エンジニア: ログから影響範囲を調査、必要であれば補填対応をする
 => SRE: 定性的なデータとしてチケットにまとめて振り返られるようにする
 (例: 全体の n % のユーザが影響を受けた、時間の範囲など定量化する)
 - 信頼性に寄与している要素を観測する
 => リファクタリング、機能の改善(廃止)の検討&提案
 - クライアントサイドモニタリングの検討
 10 周年を迎えるための SRE チームの活動振り返り

32 ©MIXI まとめ今後の課題 - ソーシャルゲームに SRE は必要か?
 - 信頼性はすべての事業にとって必要 => ソーシャルゲームも例外でない
 - サービスのフェーズによって必要な信頼性指標や SRE 目標は異なる
 - ローンチ時は SRE の必要性は低いかもしれないが、長期運用には必須!!
 - それぞれのサービスにあった信頼性指標の設計が必要なので設計する
 - 信頼性にコミットできる組織づくり
 - 現状では信頼性の範囲をいくらでも広くできてしまう
 - SRE チームがなんでも運用部隊になってしまう
 - SRE チームは信頼性に対するエンジニアリングの専門家集団!!
 => 信頼性に対するエンジニアリングについて広報活動をする