Slide 1
Slide 1 text
ノーメンテナンス運用実現のための
ノウハウ
1
Slide 2
Slide 2 text
自己紹介
佐藤佑史（Yushi Sato）
2016年新卒入社
サーバーエンジニア
担当歴：「クイズRPG 魔法使いと黒猫のウィズ」、「白猫プロジェクト」
現在：運用タイトルで機能、効率化モジュール開発
2
Slide 3
Slide 3 text
メンテナンスとは
直訳すると
「保守」、「維持」
コロプラにおいては
システムに故障や不具合が生じることなく
正常な状態が維持されるようにするための
手入れによるユーザが遊べないシステム停止
3
Slide 4
Slide 4 text
なぜメンテナンスを行うのか？
● 機能リリース、アップデート
● マスターデータ反映
● 不具合拡大防止、修正
● データベースバックアップ
● 機材点検 など
4
Slide 5
Slide 5 text
ノーメンテナンス主義
「前項目をシステム停止無しに実現」
理由
常に遊べて嬉しい
メンテナンスでガッカリを回避
具体的には
できるだけメンテナンス無しで運用
必要になっても対象を絞ってメンテナンス
5
Slide 6
Slide 6 text
ノーメンテナンスのために
● ３種の機能リリース方式
● デプロイフロー
● マスターデータ反映
● メンテが止む終えない場合の対処
6
Slide 7
Slide 7 text
アプリとの並行アップデート
Server
アプリ
アプリ
7
リリース デプロイ
Server
新機能入り
新機能入り
サーバーエンジニア担当
クライアントエンジニア担当
Slide 8
Slide 8 text
メンテ有りのアップデートフロー例
Server
for v1.0
アプリ
v1.0
8
Slide 9
Slide 9 text
メンテ有りのアップデートフロー例
Server
for v1.0
アプリ
v1.0
アプリ
v1.1
9
①リリース
Slide 10
Slide 10 text
メンテ有りのアップデートフロー例
Server
for v1.0
アプリ
v1.0
アプリ
v1.1
10
①リリース
②メンテナンス開始
❌
❌
Slide 11
Slide 11 text
メンテ有りのアップデートフロー例
Server
for v1.0
アプリ
v1.0
アプリ
v1.1
11
①リリース
Server
for v1.1
③デプロイ
②メンテナンス開始
❌
❌
Slide 12
Slide 12 text
メンテ有りのアップデートフロー例
Server
for v1.0
アプリ
v1.0
12
アプリ
v1.1
①リリース
③デプロイ
Server
for v1.1
④メンテナンス終了
②メンテナンス開始
Slide 13
Slide 13 text
アップデートフローの差異①
Server
for v1.0
アプリ
v1.0
アプリ
v1.1
13
①リリース
③デプロイ
Server
for v1.1
④メンテナンス終了
1. アップデート順は
リリース方式に依存
②メンテナンス開始
Slide 14
Slide 14 text
アップデートフローの差異②
Server
for v1.0
アプリ
v1.0
アプリ
v1.1
14
①リリース
③デプロイ
Server
for v1.1
④メンテナンス終了
2. 可用性を保ちデプロイ
1. アップデート順は
リリース方式に依存
②メンテナンス開始
Slide 15
Slide 15 text
アップデートフローの差異③
Server
for v1.0
アプリ
v1.0
アプリ
v1.1
15
①リリース
③デプロイ
Server
for v1.1
④メンテナンス終了
2. 可用性を保ちデプロイ
for v1.0~1.1
1. アップデート順は
リリース方式に依存
3. 新旧アプリに対応
②メンテナンス開始
Slide 16
Slide 16 text
メンテ無しでのアップデートフロー
Server
for v1.0
アプリ
v1.0
アプリ
v1.1
16
可用性を保ちデプロイ
Server
for
v1.0~1.1
アップデート順は
リリース方式に依存
新旧アプリに対応
Slide 17
Slide 17 text
３種類の機能リリース方式
・アプリトリガー方式
新アプリバージョンにより機能解放
・フラグトリガー方式
サーバーの対象機能用フラグにより解放
・データトリガー方式
対応バージョン付きデータにより解放
17
Slide 18
Slide 18 text
アプリトリガー方式リリース
新バージョンアプリで即機能リリース
Server
①新Ver対応
デプロイ
アプリ
②新Ver
リリース
機能リリース
タイミング
18
Slide 19
Slide 19 text
フラグトリガー方式リリース
対象機能解放用フラグを受け取り機能リリース
Server
②新Ver対応
デプロイ
アプリ
①新Ver
リリース
機能リリース
タイミング
③指定時刻
到達
④APIでフラグ返却
19
※ホーム強制遷移時刻
と合わせ、ホーム移動
時に機能リリース
Slide 20
Slide 20 text
データトリガー方式リリース
対応バージョン付きデータで機能リリース
Server
②新Ver対応
デプロイ
アプリ
①新Ver
リリース
機能リリース
タイミング
※新Verのみ
⑥対応Ver付きデータ返却
Database
③データ投入
④指定時刻
到達
⑤データ返却
20
Slide 21
Slide 21 text
リリース方式の事前決定が重要
アプリトリガー方式
新機能
21
フラグトリガー方式
データトリガー方式
盛り上げ必要？
データのバージョンで
リリース可能？
いち早く届けたい？
Slide 22
Slide 22 text
４種類の環境
Dev
開発
Stg
検証
Prod
本番
RC
？
22
Slide 23
Slide 23 text
RC環境
RC（Release Candidate）
・APPサーバのみ特別
・DBなどは本番のものを参照
・デバッグユーザのみアクセス可
RC
リリース候補版
23
Slide 24
Slide 24 text
RC環境を用いた動作確認
RC
Server
Prod
Server
Prod
DB
User
Debug
User
RC
Prod
①リリース予定版デプロイ
24
③デプロイ
②開発者チェック
Slide 25
Slide 25 text
Prod環境でのアップデート
Canary
Server
Server Server Server
25
最初にデプロイ
↓
Canary
Server
Server Server Server
順番にデプロイ
①カナリアリリース
②ローリングアップデート
Slide 26
Slide 26 text
マスターデータとは？
全ユーザ共通のゲームの構成要素に関するデータ
・キャラクター、武器、スキルなど
・量が多く、追加頻度も高い
・データベース管理
26
Slide 27
Slide 27 text
マスターデータのリリース
ガチャ
7/1 0:00 ~ 7/15 0:00
キャラ
キャラ
スキル
スキル
スキル
スキル
New
New
27
ルートは時限設定
Slide 28
Slide 28 text
マスターデータの誤り検知
スプレッドシート反映ツール
28
Slide 29
Slide 29 text
メンテが止む終えない場合の対処
EmergencyStopper
緊急時の部分的メンテナンス
29
Slide 30
Slide 30 text
まとめ
・ノーメンテナンス運用のノウハウを一部紹介
・特にリリース手順を具体的に紹介
・後日ブログにて本発表のまとめを掲載予定
30