ノーメンテナンス運用実現のためのノウハウ/ColoplTech-05-02

※資料内の参照リンクを選択し閲覧する場合は、ダウンロードをお願いいたします

＼積極的に技術発信を行なっております／
▽ Twitter/COLOPL_Tech
https://twitter.com/colopl_tech

▽ connpassページ
http://colopl.connpass.com

▽ COLOPL Tech Blog
http://blog.colopl.dev

Transcript

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