Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

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

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

E704514df1d69d511c4c74771a40c8f5?s=128

COLOPL Inc.

June 17, 2022
Tweet

More Decks by COLOPL Inc.

Other Decks in Technology

Transcript

  1. ノーメンテナンス運用実現のための ノウハウ 1

  2. 自己紹介 佐藤佑史(Yushi Sato) 2016年新卒入社 サーバーエンジニア 担当歴:「クイズRPG 魔法使いと黒猫のウィズ」、「白猫プロジェクト」 現在:運用タイトルで機能、効率化モジュール開発 2

  3. メンテナンスとは 直訳すると 「保守」、「維持」 コロプラにおいては システムに故障や不具合が生じることなく 正常な状態が維持されるようにするための 手入れによるユーザが遊べないシステム停止 3

  4. なぜメンテナンスを行うのか? • 機能リリース、アップデート • マスターデータ反映 • 不具合拡大防止、修正 • データベースバックアップ •

    機材点検 など 4
  5. ノーメンテナンス主義 「前項目をシステム停止無しに実現」 理由 常に遊べて嬉しい メンテナンスでガッカリを回避 具体的には できるだけメンテナンス無しで運用 必要になっても対象を絞ってメンテナンス 5

  6. ノーメンテナンスのために • 3種の機能リリース方式 • デプロイフロー • マスターデータ反映 • メンテが止む終えない場合の対処 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. 3種類の機能リリース方式 ・アプリトリガー方式 新アプリバージョンにより機能解放 ・フラグトリガー方式 サーバーの対象機能用フラグにより解放 ・データトリガー方式 対応バージョン付きデータにより解放 17

  18. アプリトリガー方式リリース 新バージョンアプリで即機能リリース Server ①新Ver対応 デプロイ アプリ ②新Ver リリース 機能リリース タイミング

    18
  19. フラグトリガー方式リリース 対象機能解放用フラグを受け取り機能リリース Server ②新Ver対応 デプロイ アプリ ①新Ver リリース 機能リリース タイミング

    ③指定時刻 到達 ④APIでフラグ返却 19 ※ホーム強制遷移時刻 と合わせ、ホーム移動 時に機能リリース
  20. データトリガー方式リリース 対応バージョン付きデータで機能リリース Server ②新Ver対応 デプロイ アプリ ①新Ver リリース 機能リリース タイミング

    ※新Verのみ ⑥対応Ver付きデータ返却 Database ③データ投入 ④指定時刻 到達 ⑤データ返却 20
  21. リリース方式の事前決定が重要 アプリトリガー方式 新機能 21 フラグトリガー方式 データトリガー方式 盛り上げ必要? データのバージョンで リリース可能? いち早く届けたい?

  22. 4種類の環境 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