「共闘ことばRPG コトダマン」 SREチーム流 アプリのユーザー体験向上を支えるオブザーバビリティ

本資料は、#CEDEC2024 にて登壇したコトダマンSREチームによる発表資料です。

第13会場 8月21日(水) 16:40 〜 17:40 レギュラーセッション
「共闘ことばRPG コトダマン」 SREチーム流 アプリのユーザー体験向上を支えるオブザーバビリティ
https://cedec.cesa.or.jp/2024/session/detail/s66615c6e2d6aa/

セッション概要：
今年で6周年を迎えた「共闘ことばRPG コトダマン」の運営では、以下のようなゲーム運用における課題に直面していました。
・負荷増大によるユーザー体験の悪化を観測できていない
・運用移管の背景もあり、インフラの構成管理や監視設定が不明瞭
・本番障害（バグ）の調査コストの肥大化
SREチームの立ち上げやオブザーバビリティの実現、上記の課題解決への取り組みをご紹介します。
同様の課題をお持ちの方はもちろん、オブザーバビリティをご存知ない方もぜひご参加ください。

Transcript

1. ©MIXI 「共闘ことば RPG コトダマン」 SREチーム流 アプリのユーザー体験向上を支えるオブザーバビリティ 2024/08/21 CEDEC 2024 デジタルエンターテインメントオペレーションズ本部 コトダマン事業部 エンジニアグループ ⽥中 恭友 デジタルエンターテインメントオペレーションズ本部 コトダマン事業部 エンジニアグループ SREチーム 清⽔ 悠⼀
2. 2 ©MIXI SAMPLE TEXT ⽥中恭友 ⾃⼰紹介 コトダマン事業部 エンジニアマネージャー 2018年 ミクシィ（現 MIXI）新卒⼊社 ソーシャルゲームのサーバー開発を経て 2022年 エンジニアマネージャーへ就任 清⽔ 悠⼀ コトダマン事業部 SREチーム リーダー 複数の業界でサーバーサイドをメインに フルスタックな経験を経て、 2023年MIXI⼊社
3. 3 ©MIXI • 「共闘ことばRPG コトダマン」の紹介 • コトダマン運⽤における課題の紹介 • SREチームの発⾜と課題解決の道のり • New Relic導⼊による成果‧事例紹介 • まとめ ⽬次
4. 4 ©MIXI 「共闘ことばRPG コトダマン」とは 「ことば」で闘う新感覚 RPG
5. 5 ©MIXI 「共闘ことばRPG コトダマン」とは 2019年10月にミクシィ（現 MIXI）に運営移管 2024年4月に6周年を迎えました 画像引用元： https://www.sega.jp/topics/detail/190809_7/
6. 6 ©MIXI 開発組織の紹介（概要） レベルデザイン 施策 マーケティング イラスト プロダクトオーナー ディレクター プロデューサー 職種混合のスクラム開発チーム スクラム開発班 D スクラム開発班 C スクラム開発班 B スクラム開発班 A 世界観 etc… 開発チーム 運⽤チーム 実装済み機能を利⽤し各種イベントを実施するチーム
7. 7 ©MIXI 10周年を⽬指して • これからも末⻑くユーザーの皆さんに愛され‧遊んでもらえるタイトルでありたい • 娯楽が多様化し飽和している現代では、現状維持ではそれは叶わない • 機能開発‧新イベントのリリースを⾼速に‧継続して⾏っていく必要がある • 実装の内部品質と業務フローの効率化が鍵になると確信している
8. 8 ©MIXI コトダマン運⽤における課題 • 運営の⻑期化‧組織の拡⼤に伴って技術的負債が蓄積 • 運⽤移管の経緯もあり、把握できていない インフラ構成 / アプリ実装 も存在 • スクラム開発チームは新機能の開発が重視されがちで、負債解決は着⼿できない • → 本番環境でのバグ発⽣‧新規開発のスピード低下など多くの悪影響があった • 今回の発表では、とりわけオブザーバビリティ関連の課題に絞って紹介します
9. 9 ©MIXI エラー監視ツールを利⽤しているが、検知できていないエラーも多い 運⽤上の課題：障害発⽣の検知 実⾏時例外‧クラッシュなどは検知できるものの、「意図通りの挙動でない」バグは検知が難しい • 仕様と異なった挙動をするバグ • リソースロードに失敗して⽩抜きの画像が表⽰されてしまうバグ 報告駆動の調査となることで以下の問題が発⽣ • 初動が遅れる‧影響ユーザーが増える • 開発環境でのバグ再現に難航し、なかなか原因が特定できない • 影響規模がわからないため、対処の優先度づけが難しい ユーザーからの報告を持って初めて発⾒‧解決へと動き出すことも多かった
10. 10 ©MIXI • サービスの特性：特定のイベント開始直後に負荷がスパイクする • 季節性のイベント（周年イベントなど） • ⼈気IPとのコラボイベント • 事前のキャパシティプランニングによってサーバーのスケールアウトは完了済み • リリース直後は本番インフラのメトリクスを監視している • 体感でしか負荷の⼤⼩を語れない • CPU‧RAMの使⽤率 / load averageはわかるけれど、実際のユーザー体験への影響はあるのか？ 運⽤上の課題：ユーザー体験の観測不⾜ イベントを楽しみにしていたのに、 ゲームが重い！ メトリクスを見る限りではまだ余裕があるし、 自分の手元の端末では問題がないように見える... ユーザーさん
11. 11 ©MIXI • 「なんだか重い」というユーザー報告があっても原因がわからない • アプリケーションログを漁って予想を⽴て、スロークエリを調べて... • 「きっと最近触ったこのAPIが原因のはず」 • アプリケーションログから該当のAPIのものをgrepしたり、発⾏SQLを洗い出したり... • 原因と思われるものを特定‧修正したとしても、本当に直ったのか分からない 運⽤上の課題：ユーザー体験悪化の原因の特定 推測するな、計測せよ！ …と言いたいところだけれど、計測の手段がない / 困難だ！
12. 12 ©MIXI SREチームの発⾜ レベルデザイン 施策 マーケティング イラスト スクラム開発班 D スクラム開発班 C スクラム開発班 B スクラム開発班 A 世界観 etc… 開発チーム 運⽤チーム SREチーム 開発基盤を通した支援 運用ツールの改善による支援 こうした技術課題の解決に向けて SREチームを発⾜、23年春頃〜本格始動開始！
13. 13 ©MIXI 課題解決の戦略 1. 運⽤ガイドライン整理 a. コトダマンにおけるシステム運⽤のガイドラインを⾔語化 b. 整備当時の状況を踏まえて、Fit＆Gapを明確にし、対応優先度を整理 c. マイルストーンを作成し、環境整備から着⼿ 2. 監視設計の⾒直し（ナレッジ整備） a. 当時の利⽤サービス（Mackerel他）の継続可否整理 b. 監視設定はほぼ発⽣しない条件が多く、設定内容の背景は推測するしかなかった（ナレッジ⽋損） c. 当時の設定情報を棚卸し、監視観点、⽬的、対応事項（アラート条件）を整備 3. APM導⼊ a. インフラのメトリクス監視 b. アプリケーションパフォーマンスの計測 c. 棚卸しした監視条件も含め⼀元的に活⽤できる仕組みの導⼊
14. 14 ©MIXI 課題解決に向けて AsIs After CI/CD 本番 検証 dev アラート 監視 アプリケーション インシデント アラート 監視 インシデント 計測 本番環境の監視が中心（一部検証環境あり） ツールはバラバラ アプリログはサーバーにダイブIN → 　情報集約の手間と正確性に欠ける 網羅性が必要！
15. 15 ©MIXI 課題解決に向けて
16. 16 ©MIXI 導入関連 運用開始までの調整 PoC実施 開始 導入打診の 初報 導⼊に向けたキックオフから運⽤開始まで約２ヶ⽉で対応（PoC期間は約３週間ほど） 開発環境でインストール⼿順を構築し、PoCは本番サーバーを使⽤ PoCから本番運⽤開始まで 5月 6月 7月 8月 キックオフ MTG PoC実施 完了 本番運用 開始 契約完了 事務事項
17. 17 ©MIXI ❖ 本番環境の状態を可視化 ➢ ガチャ、クエストなどゲームイベントにおけるサーバー状況が時系列に把握できる ➢ アイドルが多い時間帯や負荷状況を⾒越した運⽤整備の⼀助となった ➢ ビジネスロジック、DBクエリレベルでパフォーマンスが⾒えるようになった。 ❖ 運⽤⾒直し ➢ サーバーの固定台数運⽤から動的運⽤へ（オートスケーリング） ➢ モニタリング強化に夜事前検知 ▪ リクエスト量に応じたアラート設計（95%ラインの超過継続監視） ▪ ビルドサーバーの容量監視 ➢ インシデント発⽣時の調査コスト削減 ❖ コスト削減 ➢ 250~300万/⽉程のランニング費削減効果 NewRelic導⼊による結果
18. 18 ©MIXI ❖ パフォーマンス指標：APDEX（※）を活⽤ ❖ ⾃動的に算出されるスコアを基準にパフォーマンス維持の取り組みを実施 活⽤事例：サービスレベルの定義 ※）ウェブアプリケーションやサービスのレスポンスタイムについて、ユーザー満⾜度を計測するための業界標準 サマリーレポート API別パフォーマンスレポート
19. 19 ©MIXI ❖ APMダッシュボードの活⽤によるアプリケーションの課題抽出 ❖ 24/365監視の再設計、Terraform管理でIaC化に貢献 活⽤事例：サービスレベルの定義 APMサマリ 監視設定の一覧
20. 20 ©MIXI ❖ APIサーバーのアプリケーションログを整理して構造化ログを導⼊した ❖ サーバー毎に調査が必要だったが、横断して⾏うことが可能になった。 活⽤事例：構造化ログの導⼊ 構造化ログの例
21. 21 ©MIXI ❖ NRQL活⽤による状態調査の容易性が向上 ❖ 運⽤上のDBアクセスを抑⽌する活⽤に繋がった。 活⽤事例：構造化ログの導⼊ NRQL利用のイメージ
22. 22 ©MIXI ❖ エンジニア同⼠のダッシュボード活⽤の幅を広げる ➢ 客観的な指標も踏まえた新規‧改善提案ができるようになる ➢ クライアントアプリへ活⽤を展開 ❖ ビジネスとアーキテクトの両⾯を意識したプロダクト開発につなげたい 将来の展望 エンジニア プランナー等 エンジニア プランナー等 現状 今後
23. 23 ©MIXI ❖ New Relic導⼊で変わったこと ➢ システム周りの情報発信元になった。 ➢ 客観情報を元に意⾒交換できるようになった。 ➢ リリース前後での傾向分析が容易になった。 ❖ 組織内への浸透に向けてやったこと ➢ SREからサーバーエンジニアへ気づきの共有 ➢ サマリーレポートの共有 ❖ 今後やりたいこと ➢ ビジネス指標とシステム指標を組み合わせたKPI設定 ➢ インシデント検知の精度向上 ➢ クライアント側の異常動作検知 まとめ