大規模タイトルを ノーメンテで運用するコツ

Transcript

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