Slide 1
Slide 1 text
大規模タイトルを
ノーメンテで運用するコツ
西川 蒼太郎
Slide 2
Slide 2 text
氏名 ：
部署 ：
● 2020年度新卒入社（4年目）
● 運用タイトルのサーバーエンジニアとして
バリバリ運用開発中
● 最近のマイブームはシュークリームを肴に
白ビールを飲むこと
西川 蒼太郎
2
自己紹介
技術基盤本部 第2バックエンドエンジニア部
第1グループ 第3チーム
Slide 3
Slide 3 text
今日お話する内容
3
ノーメンテナンス運用
（ノーメンテ）
Slide 4
Slide 4 text
今日お話する内容
ノーメンテ・・・？
Slide 5
Slide 5 text
コロプラのノーメンテ主義（引用）
Slide 6
Slide 6 text
要するに
● ユーザー体験を損ねないように
● ノンストップでアップデートをリリースする
ということ
コロプラのノーメンテ主義（引用）
Slide 7
Slide 7 text
● メンテあり・なしのリリースフローの違い
● ノーメンテを実現する手法
○ 様々なリリース手法
○ リリーススケジュールの組み立て
今日お話する内容
7
Slide 8
Slide 8 text
※インフラ周りの話はあまりしません
※一部PHPのコードが登場しますが、雰囲気で理解してもらえればOKです
今日お話する内容
Slide 9
Slide 9 text
9
メンテあり・なしの
リリースフローの違い
Slide 10
Slide 10 text
（前提）モバイルゲームにおける機能開発
サーバ
アプリ
10
サーバーエンジニア担当
クライアントエンジニア担当
Slide 11
Slide 11 text
（前提）モバイルゲームにおける機能開発
サーバ
for v1.0
アプリ
v1.0
アプリ
v2.0
11
ストアで公開 デプロイ（更新）
サーバ
for v2.0
新機能入り
新機能入り
サーバーエンジニア担当
クライアントエンジニア担当
Slide 12
Slide 12 text
メンテありの
リリースフローの例
Slide 13
Slide 13 text
メンテありのリリースフローの例
サーバ
for v1.0
13
アプリ
v1.0
Slide 14
Slide 14 text
メンテありのリリースフローの例
サーバ
for v1.0
14
①メンテナンス開始
❌
アプリ
v1.0
Slide 15
Slide 15 text
メンテありのリリースフローの例
サーバ
for v1.0
15
サーバ
for v2.0
②デプロイ
❌
アプリ
v1.0
Slide 16
Slide 16 text
メンテありのリリースフローの例
サーバ
for v1.0
アプリ
v2.0
16
❌
アプリ
v1.0
③ストアで公開
サーバ
for v2.0
Slide 17
Slide 17 text
メンテありのリリースフローの例
サーバ
for v1.0
17
アプリ
v2.0
サーバ
for v2.0
④メンテナンス終了
メンテ明けと同時に
古いアプリが使えなくなる
アプリ
v1.0
Slide 18
Slide 18 text
● サーバーは常に1つのバージョンだけが運用される
● アプリとサーバーのバージョンは常にマッチする
※あくまで一例なので、タイトルによっては異なる可能性もあります
メンテありのリリースフローの例
Slide 19
Slide 19 text
ノーメンテの
リリースフロー
Slide 20
Slide 20 text
ノーメンテのリリースフロー
サーバ
for v1.0
アプリ
v1.0
20
Slide 21
Slide 21 text
ノーメンテのリリースフロー
サーバ
for v1.0
アプリ
v1.0
アプリ
v2.0
21
①ストアで公開
Slide 22
Slide 22 text
ノーメンテのリリースフロー
アプリ
v1.0
22
サーバ
for v1.0
アプリ
v2.0
②デプロイ
サーバ
for
v1.0~2.0
Slide 23
Slide 23 text
ノーメンテのリリースフロー
アプリ
v1.0
23
サーバ
for v1.0
アプリ
v2.0
サーバ
for
v1.0~2.0
③古いサーバーが
フェードアウト
Slide 24
Slide 24 text
ノーメンテのリリースフロー
サーバ
for v1.0
アプリ
v1.0
24
アプリ
v2.0
サーバ
for
v1.0~2.0
④特定のタイミングで
古いアプリが使えなくなる
Slide 25
Slide 25 text
● 「ローリングアップデート」という手法でデプロイを行うため
○ 複数のサーバーをちょっとずつアップデートしていく方式
○ ちょっとずつアップデートしていくので、当然新旧が混ざる
● ローリングアップデートのメリット・デメリット
○ 無停止でサーバーのバージョンアップができる（＝ノーメンテ！）
○ ただし新旧サーバーが混ざるので管理は大変
○ 詳細について今回は割愛
補足：なぜ新旧サーバーが混ざるのか？
カナリア
サーバ
新サーバ 新サーバ 旧サーバ
Slide 26
Slide 26 text
● アプリ・サーバーのバージョンが複数存在しうる
○ 『新しいサーバー』に『v1.0 と v2.0 の両方のアプリ』からアクセスが来るし、
『古いサーバー』にも『v1.0 と v2.0 の両方のアプリ』からアクセスが来る
○ アプリもサーバーも常に後方互換性を担保しなくてはいけない
● Q. どうしてこんなことになるのか？
○ A. 「メンテナンス」という「切り替えタイミング」を設けることができないため
○ つらい！
● じゃあどうするか？
○ 様々な手法でリリースタイミングをコントロールする！
ノーメンテのリリースフロー
Slide 27
Slide 27 text
27
リリースを
コントロールする
Slide 28
Slide 28 text
● 様々なリリース手法
○ アプリバージョンによるリリース
○ 日時によるリリース
○ FutureRelease
○ データによるリリース
● 実際にリリーススケジュールを組んでみる
リリースをコントロールする
Slide 29
Slide 29 text
様々な
リリース手法
Slide 30
Slide 30 text
● リクエストからアプリバージョンを受け取り、
任意のバージョン以上の時だけ処理を行うという手法
● たとえば以下のようなケースに効果的
○ バージョンごとに受け取るリクエストの値が変化するとき
○ バージョンごとに違うレスポンスを返したいとき
// リクエストからアプリバージョンを取得する
$requestVersion = $request->getVersion();
// 対象バージョンを設定する
$targetVersion = '1.1.0';
if ($requestVersion >= $targetVersion) {
// 「アプリバージョン」>=「対象バージョン」なら処理を行う
// NOTE: 本当はもっと適切にバージョン文字列を比較する方法がありますが、今回は割愛
}
バージョンによるリリース
Slide 31
Slide 31 text
● リクエスト日時を基準として、
リリース日時以降の時だけ処理を行うという手法
● 主なケースは以下の通り
○ あらかじめリリース日時を告知したい時
○ デプロイ時に新旧サーバーの処理を混ぜたくない時
// リクエストが着信した日時を取得する
$requestDateTime = $request->getDateTime();
// リリース日時を設定する
$targetDateTime = new DateTime('2023-10-24 19:00:00');
if ($requestDateTime >= $targetDateTime) {
// 「リクエスト日時」>=「リリース日時」なら処理を行う
}
日時によるリリース
Slide 32
Slide 32 text
FutureRelease
● コロプラ独自の FutureRelease というリリース手法もある
○ 「アプリバージョン」と「リリース日時」の合せ技
● アプリ側のリリースタイミングをサーバー側で管理できる！
サーバ
②新Ver対応
デプロイ
アプリ
①新Ver
リリース
④フラグ返却 ③リリース日時
到達
32
新機能
リリース
Slide 33
Slide 33 text
● データそのものに開始日時を持たせる手法
○ 親データが開始するまで、紐づくデータがすべてリリースされない
データによるリリース
イベント
開始：10/30 19:00
終了：11/13 11:00
キャラB
キャラA
スキルA
スキルB
スキルC
スキルD
33
開始：11/06 19:00
10/30 19:00 時点
初めから開放
Slide 34
Slide 34 text
● データそのものに開始日時を持たせる手法
○ 親データが開始するまで、紐づくデータがすべてリリースされない
○ リリース日時を超えると、紐づくデータが自動でリリースされる
データによるリリース
イベント
開始：10/30 19:00
終了：11/13 11:00
キャラB
キャラA
スキルA
スキルB
スキルC
スキルD
34
11/06 19:00 以降
New
New
Slide 35
Slide 35 text
実際に
リリーススケジュールを
組んでみる
Slide 36
Slide 36 text
● 様々なリリース手法があることは分かった
● Q. 実際には「どのリリース手法」を「どんな時」に使うのか？
○ A. ケースバイケース
○ 1つのイベントをリリースするために複数の手法を組み合わせることが多い
○ 各セクションへのヒアリングが必須
実際にリリーススケジュールを組んでみる
Slide 37
Slide 37 text
各セクションにヒアリング
クライアント
エンジニアさん
10/30 19:00 から
新イベントを開始したい
です
既存機能を改修しました
新しいバージョンのアプリでは
リクエストパラメータが
変わります
イベント開始と同時に
新しいUIを表示したいです
イベント開始と同時に
パラメータの計算方法を
修正したいです
プランナーさん
Slide 38
Slide 38 text
各セクションにヒアリング
クライアント
エンジニアさん
10/30 19:00 から
新イベントを開始したい
です
既存機能を改修しました
新しいバージョンのアプリでは
リクエストパラメータが
変わります
イベント開始と同時に
新しいUIを表示したいです
イベント開始と同時に
パラメータの計算方法を
修正したいです
プランナーさん
↓データリリース
↑日時リリース
↓バージョンリリース
↑FutureRelease
Slide 39
Slide 39 text
リリーススケジュールを組み立てる
データリリース
イベント開始
日時リリース
パラメータ計算方法
の修正
バージョンリリース
リクエスト改修
FutureRelease
新UIの表示
新バージョンアプリ公開
イベントデータを DB に insert
サーバーデプロイ
イベント開始
Slide 40
Slide 40 text
● リリース作業の大半はサーバーエンジニアの担当
○ ＝リリース作業の全体を見通すのはサーバーエンジニアの役目
○ ＝スケジュールの組み立てはサーバーエンジニアが牽引する
● サーバー観点のチェックは必須
○ それぞれのリリース手段は適切か？
○ リリース手順に漏れは無いか？
○ データミスはないか？
ノーメンテリリースはサーバーのオペレーションに懸かっている！
リリーススケジュールを組み立てる
Slide 41
Slide 41 text
まとめ
Slide 42
Slide 42 text
まとめ
● コロプラはノーメンテ主義です
● でもノーメンテのリリースは大変
○ リリースタイミングのハンドリングが重要
● 様々な手法でリリースコントロールを行っています
○ バージョン、日時、データなどなど
○ サーバーエンジニアの腕の見せ所！
42
Slide 43
Slide 43 text
まとめ
ノーメンテ運用は大変ですが、
どんな時でもユーザーが24時間ゲームを楽しめるように
日々頑張っています！
43