イベント続きでもミスらないライブサービスゲーム公式サイト運用システム開発

by gree_tech

Embed

Start on current slide

Slide 1

Slide 1 text

イベント続きでもミスらないライブサービスゲーム公式サイト運用システム開発株式会社WFS プリンシパルエンジニア藤田貴大

Slide 2

Slide 2 text

藤田貴大株式会社WFS プリンシパルエンジニア組み込みエンジニアとしてネットワーク機器の開発に携わったのち、2012年にグリー株式会社（現：グリーホールディングス株式会社）入社。インフラ、Webゲーム開発を経て、2016年から Wright Flyer Studios（現：株式会社WFS）にてQA エンジニアとして開発基盤の整備等を担当。 2017年からネイティブゲームのサーバーエンジニアとして、ゲーム開発のほか新技術導入などを進めている。 2

Slide 3

Slide 3 text

アジェンダ ● はじめに ● ことのはじまり ● 改善に向けた整理 ● 新しいツール作成 ● 導入後 ● まとめ 3

Slide 4

Slide 4 text

はじめに 4

Slide 5

Slide 5 text

公式サイト更新システムの紹介弊社で運用しているゲームの公式サイトを更新するシステム SlackによるChatOpsを用いたワークフローについて紹介させていただきます 5

Slide 6

Slide 6 text

ことのはじまり 6

Slide 7

Slide 7 text

1 7

Slide 8

Slide 8 text

開発メンバー @everyone 公式サイトに、明日発表予定の新イベント情報が載ってるんですが 8

Slide 9

Slide 9 text

開発メンバー @everyone 公式サイトに、明日発表予定の新イベント情報が載ってるんですがえ？ 9

Slide 10

Slide 10 text

本来、翌日の公式生放送と同時に公開されるはずの新イベントが公式サイトに載ってしまっていることが判明まだ出してはいけない情報ライブサービスゲームにおいて情報公開のタイミングは極めて重要特に今回は生放送での発表も控えていたため、大きな問題に生成AIで作成したイメージ画像です 10

Slide 11

Slide 11 text

予定されていた公式サイト更新スケジュール当日、もともとはこのようなスケジュールになっており公開準備がすすめられていました 10/1 イベント情報公開1 10/3 10/2 イベント情報公開2 11

Slide 12

Slide 12 text

差し込みの修正があった急な情報公開2の修正依頼があったため、その確認作業などが実施されました 9/30 10/1 イベント情報公開2 の修正イベント情報公開1 10/3 10/2 イベント情報公開2 12

Slide 13

Slide 13 text

もともとの公式サイトの構成公式サイトリポジトリ Object Storage (開発サイト用) CDN 開発メンバー Object Storage (本番サイト用) CDN お客様デプロイジョブ 13

Slide 14

Slide 14 text

その時の公式サイト更新の流れ 1 2 3 4 5 6 制作会社から ZIP形式で納品指定フォルダに納品物を上書き保存手順書に従いデータをアップロード Jenkinsで開発サイトを更新開発サイトで更新部分をチェック Jenkinsで本番サイトを更新 gitのclone フォルダ (mainブランチ) PR作成/セルフマージで mainへ反映リポジトリの mainブランチ HEADをデプロイリポジトリの mainブランチ HEADをデプロイ 14

Slide 15

Slide 15 text

Slide 16

Slide 16 text

わかりますね？ 16

Slide 17

Slide 17 text

差し込みの修正があった急な情報公開2の修正依頼があったため、その確認作業などが実施されました 9/30 10/1 イベント情報公開2 の修正イベント情報公開1 10/3 10/2 イベント情報公開2 17

Slide 18

Slide 18 text

差し込みの修正があった 10/3に出るはずの急な情報公開2の修正依頼があったため、その確認作業などが実施されました情報が出てしまった 9/30 10/1 イベント情報公開2 の修正イベント情報公開1 10/3 10/2 イベント情報公開2 18

Slide 19

Slide 19 text

もともと想定されていた更新作業 10/1 10/3 情報公開1 情報公開2 git更新 (情報公開1) git更新 (情報公開2) 開発サイト更新開発サイト更新本番サイト更新本番サイト更新 19

Slide 20

Slide 20 text

実際の更新作業 9/30 10/1 10/3 情報公開2 差し込み確認情報公開1 情報公開2 git更新 (情報公開2) git更新 (情報公開1) git更新 (情報公開2) 開発サイト更新開発サイト更新開発サイト更新本番サイト更新本番サイト更新 mainブランチのHEAD (情報公開2+1)をそのまま本番サイトに公開 20

Slide 21

Slide 21 text

問題の背景高頻度の更新弊社のライブサービスゲームではイベント時にお客様に楽しんでいただくため情報公開を分割して連続更新することがありますタイトな時間制約情報公開を公式生放送にあわせるため夜や休日に更新作業が発生する場合もあります連続更新が想定されていない更新システム更新が直列的にしか実施できないため運用チームが公開直前に更新作業を実施しています 21

Slide 22

Slide 22 text

技術的な整理 JenkinsがmainブランチのHEADしかデプロイできなかった公開直前までgitの更新ができない構造的な制約が存在 PullRequestが機能していなかった更新作業が公開直前にしか実施できないためレビューの余裕がつくれなかった Gitのアップロードツール化サイト更新システムのアップローダーとして存在していた 22

Slide 23

Slide 23 text

改善に向けた整理 23

Slide 24

Slide 24 text

公式サイト運用チームへのヒアリング担当者について公式サイトの更新は公式サイト運用チームのメンバーが実施エンジニア職ではない更新タイミングについて短期間に連続で更新作業が発生する夜や休日のこともあるタイミングを生放送終わりに合わせたりしたい 24

Slide 25

Slide 25 text

目指すべきところはわかっている ● QA体制を整える ● PullRequestのレビューを機能させる ● 上記が、事前に、並行して実施できる 25

Slide 26

Slide 26 text

CMSに移行は難しい公式サイト運用チームも開発チームも多くのリソースは割けない特に、運用のために定常的にリソースを確保するのは難しい現状の Object Storage + CDN での公式サイト運用は運用リソースという点では望ましい QAやレビューを考えた時、Git/GitHubを使うことは望ましい 26

Slide 27

Slide 27 text

ヘッドレスCMSも今回求めるものは見当たらず Object Storage + CDN の構成は実現できるが QAやレビューを含めたワークフローを実現させるものではない 27

Slide 28

Slide 28 text

人員の問題がある公式サイト運営チームはエンジニア職ではない開発チームからも十分にサポートできない中で専門外のソフトウェアやサービスの習熟は難しいでも、Gitを使うことは手放したくない 28

Slide 29

Slide 29 text

新しいツールを作ろう 29

Slide 30

Slide 30 text

改善の目標 ● エンジニア以外のメンバーが ● サポートの手薄な夜間・休日でも ● 「十分にレビューされたコンテンツ」を ● 「複数回連続して」安全にデプロイできる状態を作る 30

Slide 31

Slide 31 text

改善の目標 ● エンジニア以外のメンバーが ● サポートの手薄な夜間・休日でも ● 「十分にレビューされたコンテンツ」を ● 「複数回連続して」安全にデプロイできる状態を作る Githubを中心としたワークフローを構築するエンジニアがずっと慣れ親しんできた道具を横展開する 31

Slide 32

Slide 32 text

Gitワークフローはシンプルに PullRequest 開発ブランチメインブランチ追加・修正レビュー/QA マージ 32

Slide 33

Slide 33 text

改善の目標 SlackによるChatOpsでワークフローを進行 ● エンジニア以外のメンバーが ● サポートの手薄な夜間・休日でも ● 「十分にレビューされたコンテンツ」を ● 「複数回連続して」安全にデプロイできる状態を作る 33

Slide 34

Slide 34 text

Githubの作業をSlackから実行運用メンバー運用メンバー @運用Bot 開発ブランチ作成イベント第一弾_20260101 @運用Bot QAサイトにデプロイイベント第一弾_20260101 運用メンバー運用メンバー @運用Bot PR作成イベント第一弾_20260101 @運用Bot マージイベント第一弾_20260101 ブランチ名については後ほど改めて説明 34

Slide 35

Slide 35 text

Slack上で作業することで ● 全員が使い慣れているSlackを使うことができる ● 進行状況が自動的に可視化される ● サポートが必要なトラブルもSlack上で起こる 35

Slide 36

Slide 36 text

Slackで作業を進められる PR作成 QAサイト更新コンテンツ更新開発ブランチ作成マージ 36

Slide 37

Slide 37 text

Slackで作業を進められる PR作成 QAサイト更新コンテンツ更新マージ開発ブランチ作成結局難しいのでは？ 37

Slide 38

Slide 38 text

管理スプレッドシート導入入力欄コマンド施策名1 デプロイ日時ブランチ作成コマンド PR作成コマンド施策名2 デプロイ日時ブランチ作成コマンド PR作成コマンドデプロイ日時については後ほど改めて説明 ● 手順書にしたがって、すべてのコマンドをコピー＆ペーストで実行できる 38

Slide 39

Slide 39 text

ここまで ● GithubのPRレビューのワークフローを SlackのChatOpsで進行できる ● コピー＆ペーストで実行できる 39

Slide 40

Slide 40 text

改善の目標 ● エンジニア以外のメンバーが ● サポートの手薄な夜間・休日でも ● 「十分にレビューされたコンテンツ」を ● 「複数回連続して」安全にデプロイできる状態を作るここまでは作った 40

Slide 41

Slide 41 text

改善の目標 ● エンジニア以外のメンバーが ● サポートの手薄な夜間・休日でも ● 「十分にレビューされたコンテンツ」を ● 「複数回連続して」安全にデプロイできる状態を作るここに工夫が必要でした 41

Slide 42

Slide 42 text

Githubを使ったワークフローが進められるようになった ● 複数のブランチを並行進行もできるようになった施策3 施策2 施策1 42

Slide 43

Slide 43 text

今回の事故は防げない ● マージ順が保証できない施策3 施策2 施策1 ここで事故発生 43

Slide 44

Slide 44 text

Githubの作業をSlackから実行（再掲）運用メンバー運用メンバー @運用Bot 開発ブランチ作成イベント第一弾_20260101 @運用Bot QAサイトにデプロイイベント第一弾_20260101 運用メンバー運用メンバー @運用Bot PR作成イベント第一弾_20260101 @運用Bot マージイベント第一弾_20260101 ブランチ名については後ほど改めて説明 44

Slide 45

Slide 45 text

管理スプレッドシート導入（再掲）入力欄コマンド施策名1 デプロイ日時ブランチ作成コマンド PR作成コマンド施策名2 デプロイ日時ブランチ作成コマンド PR作成コマンドデプロイ日時については後ほど改めて説明 ● 手順書にしたがって、すべてのコマンドをコピー＆ペーストで実行できる 45

Slide 46

Slide 46 text

ブランチ名ルールの導入ブランチ名をルール化しましたイベント第一弾_2026122412 施策名施策が公開される年月日時 2026年12月24日12時に公開される施策 46

Slide 47

Slide 47 text

ブランチ名のルールで実現したいこと ● マージされる順番を保証 ● 自分より日付が前のブランチが未マージだとテストが失敗する施策3_2026010300 施策2_2026010200 ❌ _02が未マージ ❌ _01が未マージ施策1_2026010100 ✅ 47

Slide 48

Slide 48 text

順番にマージできる ● マージされる順番を保証 ● 自分より日付が前のブランチが未マージだとテストが失敗する施策3_2026010300 施策2_2026010200 ❌ ✅ _02が未マージ _01がマージ済み施策1_2026010100 48

Slide 49

Slide 49 text

順番にマージできる ● マージされる順番を保証 ● 自分より日付が前のブランチが未マージだとテストが失敗する施策3_2026010300 ✅ _02がマージ済み施策2_2026010200 施策1_2026010100 49

Slide 50

Slide 50 text

順番にマージできる ● マージされる順番を保証 ● 自分より日付が前のブランチが未マージだとテストが失敗する施策3_2026010300 施策2_2026010200 施策1_2026010100 50

Slide 51

Slide 51 text

ついでにマージコミットにタグ施策1_2026010100 施策2_2026010200 施策3_2026010300 51

Slide 52

Slide 52 text

HEADではなく、指定のコミットをデプロイ運用メンバー運用メンバー @運用Bot ステージングデプロイイベント第一弾_20260101 @運用Bot 本番デプロイイベント第一弾_20260101

Slide 53

Slide 53 text

改善の目標 ● エンジニア以外のメンバーが ● サポートの手薄な夜間・休日でも ● 「十分にレビューされたコンテンツ」を ● 「複数回連続して」安全にデプロイできる状態を作る 53

Slide 54

Slide 54 text

Slackでデプロイが簡単にできるようになったが運用メンバー @運用Bot 本番デプロイイベント第一弾_20260101

Slide 55

Slide 55 text

単独でフライングする可能性が残る運用メンバー 2025/12/31 @運用Bot 本番デプロイイベント第一弾_20260101 事前にきちんと準備ができたとしてフライングしてしまうのは防げない

Slide 56

Slide 56 text

ReleaseApprovals.txt 公式サイトのリポジトリに置かれている1行のテキストファイル内容は、日時分 2026010112 このファイルが意味するのは、”このコミットはこの時刻以降いつでもデプロイしてよい”ということデプロイシステムは、このファイルの時刻より前にデプロイが実施された場合エラーになって停止します 56

Slide 57

Slide 57 text

PRのレビューで、デプロイタイミングの合意が取れる PRのレビューで、コンテンツそのものと、コンテンツの情報公開タイミングの両方を同時にapproveできる例えば、生放送終了後の公開を意図したコンテンツの場合生放送開始時刻などこれ以降の公開であれば許される時刻にしておくことでデプロイタイミングの自由度を確保しつつ、事故のリスクを低減できる 57

Slide 58

Slide 58 text

改善の目標 ● エンジニア以外のメンバーが ● サポートの手薄な夜間・休日でも ● 「十分にレビューされたコンテンツ」を ● 「複数回連続して」安全にデプロイできる状態を作る 58

Slide 59

Slide 59 text

改善の目標 ● エンジニア以外のメンバーが ● サポートの手薄な夜間・休日でも ● 「十分にレビューされたコンテンツ」を ● 「複数回連続して」安全にデプロイできる状態を作るイベント続きでもミスらないライブサービスゲーム公式サイト運用システムを導入 59

Slide 60

Slide 60 text

導入後 60

Slide 61

Slide 61 text

導入後公開タイミングのミスは発生していません導入後しばらくは、開発メンバーが本番サイトデプロイに立ち会っていましたが現在は、運用チームだけで本番デプロイが実施されています 61

Slide 62

Slide 62 text

まとめ 62

Slide 63

Slide 63 text

公式サイトで公開タイミングの問題が発生 ● ● ● イベントが大切なライブサービスゲームでは公式サイトが短期間に複数回更新されることがしばしばあるワークフローがそれに対応できていなかった適切なツールも見つからなかった公式サイト更新システムを作った ● ● 公式サイトを短期間に複数回、安全に更新できるようになった導入後、最初に発生したような問題は発生しなくなった 63