Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
大規模タイトルを ノーメンテで運用するコツ
Search
COLOPL Inc.
October 31, 2023
Technology
1
1.3k
大規模タイトルを ノーメンテで運用するコツ
COLOPL Inc.
October 31, 2023
Tweet
Share
More Decks by COLOPL Inc.
See All by COLOPL Inc.
怖くない!ゼロから始めるPHPソースコードコンパイル入門
colopl
0
10
大規模トラフィックを支える ゲームバックエンドの課題と構成の変遷 ~安定したゲーム体験を実現するために~
colopl
2
2.8k
長期運用プロジェクトでのMySQLからTiDB移行の検証
colopl
3
1.5k
ゲームを支えるバックエンドエンジニアのリアルを公開!
colopl
1
1.1k
コロプラ_SRE_LCE_ゲームバックエンド_性能との戦い
colopl
0
800
新卒3年目の ゲームバックエンドエンジニアが これまでに経験したこと
colopl
1
1.4k
サーバーサイドエンジニアの ゲーム企画との向き合い方
colopl
1
1.3k
大規模/長期運用プロジェクト が抱える課題への チーム、個人の取り組み
colopl
1
1.2k
令和時代の PHP Extension の 作り方 〜 FFI を添えて〜
colopl
0
1.5k
Other Decks in Technology
See All in Technology
社外コミュニティで学び社内に活かす共に学ぶプロジェクトの実践/backlogworld2024
nishiuma
0
260
普通のエンジニアがLaravelコアチームメンバーになるまで
avosalmon
0
100
株式会社ログラス − エンジニア向け会社説明資料 / Loglass Comapany Deck for Engineer
loglass2019
3
32k
10個のフィルタをAXI4-Streamでつなげてみた
marsee101
0
170
OpenAIの蒸留機能(Model Distillation)を使用して運用中のLLMのコストを削減する取り組み
pharma_x_tech
4
560
TSKaigi 2024 の登壇から広がったコミュニティ活動について
tsukuha
0
160
バクラクのドキュメント解析技術と実データにおける課題 / layerx-ccc-winter-2024
shimacos
2
1.1k
ずっと昔に Star をつけたはずの思い出せない GitHub リポジトリを見つけたい!
rokuosan
0
150
大幅アップデートされたRagas v0.2をキャッチアップ
os1ma
2
540
Fanstaの1年を大解剖! 一人SREはどこまでできるのか!?
syossan27
2
170
Opcodeを読んでいたら何故かphp-srcを読んでいた話
murashotaro
0
260
KnowledgeBaseDocuments APIでベクトルインデックス管理を自動化する
iidaxs
1
260
Featured
See All Featured
Code Review Best Practice
trishagee
65
17k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
17
2.3k
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Unsuck your backbone
ammeep
669
57k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Six Lessons from altMBA
skipperchong
27
3.5k
Code Reviewing Like a Champion
maltzj
520
39k
Facilitating Awesome Meetings
lara
50
6.1k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Building Better People: How to give real-time feedback that sticks.
wjessup
365
19k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.6k
Transcript
大規模タイトルを ノーメンテで運用するコツ 西川 蒼太郎
氏名 : 部署 : • 2020年度新卒入社(4年目) • 運用タイトルのサーバーエンジニアとして バリバリ運用開発中 •
最近のマイブームはシュークリームを肴に 白ビールを飲むこと 西川 蒼太郎 2 自己紹介 技術基盤本部 第2バックエンドエンジニア部 第1グループ 第3チーム
今日お話する内容 3 ノーメンテナンス運用 (ノーメンテ)
今日お話する内容 ノーメンテ・・・?
コロプラのノーメンテ主義(引用)
要するに • ユーザー体験を損ねないように • ノンストップでアップデートをリリースする ということ コロプラのノーメンテ主義(引用)
• メンテあり・なしのリリースフローの違い • ノーメンテを実現する手法 ◦ 様々なリリース手法 ◦ リリーススケジュールの組み立て 今日お話する内容 7
※インフラ周りの話はあまりしません ※一部PHPのコードが登場しますが、雰囲気で理解してもらえればOKです 今日お話する内容
9 メンテあり・なしの リリースフローの違い
(前提)モバイルゲームにおける機能開発 サーバ アプリ 10 サーバーエンジニア担当 クライアントエンジニア担当
(前提)モバイルゲームにおける機能開発 サーバ for v1.0 アプリ v1.0 アプリ v2.0 11 ストアで公開
デプロイ(更新) サーバ for v2.0 新機能入り 新機能入り サーバーエンジニア担当 クライアントエンジニア担当
メンテありの リリースフローの例
メンテありのリリースフローの例 サーバ for v1.0 13 アプリ v1.0
メンテありのリリースフローの例 サーバ for v1.0 14 ①メンテナンス開始 ❌ アプリ v1.0
メンテありのリリースフローの例 サーバ for v1.0 15 サーバ for v2.0 ②デプロイ ❌
アプリ v1.0
メンテありのリリースフローの例 サーバ for v1.0 アプリ v2.0 16 ❌ アプリ v1.0
③ストアで公開 サーバ for v2.0
メンテありのリリースフローの例 サーバ for v1.0 17 アプリ v2.0 サーバ for v2.0
④メンテナンス終了 メンテ明けと同時に 古いアプリが使えなくなる アプリ v1.0
• サーバーは常に1つのバージョンだけが運用される • アプリとサーバーのバージョンは常にマッチする ※あくまで一例なので、タイトルによっては異なる可能性もあります メンテありのリリースフローの例
ノーメンテの リリースフロー
ノーメンテのリリースフロー サーバ for v1.0 アプリ v1.0 20
ノーメンテのリリースフロー サーバ for v1.0 アプリ v1.0 アプリ v2.0 21 ①ストアで公開
ノーメンテのリリースフロー アプリ v1.0 22 サーバ for v1.0 アプリ v2.0 ②デプロイ
サーバ for v1.0~2.0
ノーメンテのリリースフロー アプリ v1.0 23 サーバ for v1.0 アプリ v2.0 サーバ
for v1.0~2.0 ③古いサーバーが フェードアウト
ノーメンテのリリースフロー サーバ for v1.0 アプリ v1.0 24 アプリ v2.0 サーバ
for v1.0~2.0 ④特定のタイミングで 古いアプリが使えなくなる
• 「ローリングアップデート」という手法でデプロイを行うため ◦ 複数のサーバーをちょっとずつアップデートしていく方式 ◦ ちょっとずつアップデートしていくので、当然新旧が混ざる • ローリングアップデートのメリット・デメリット ◦ 無停止でサーバーのバージョンアップができる(=ノーメンテ!)
◦ ただし新旧サーバーが混ざるので管理は大変 ◦ 詳細について今回は割愛 補足:なぜ新旧サーバーが混ざるのか? カナリア サーバ 新サーバ 新サーバ 旧サーバ
• アプリ・サーバーのバージョンが複数存在しうる ◦ 『新しいサーバー』に『v1.0 と v2.0 の両方のアプリ』からアクセスが来るし、 『古いサーバー』にも『v1.0 と v2.0
の両方のアプリ』からアクセスが来る ◦ アプリもサーバーも常に後方互換性を担保しなくてはいけない • Q. どうしてこんなことになるのか? ◦ A. 「メンテナンス」という「切り替えタイミング」を設けることができないため ◦ つらい! • じゃあどうするか? ◦ 様々な手法でリリースタイミングをコントロールする! ノーメンテのリリースフロー
27 リリースを コントロールする
• 様々なリリース手法 ◦ アプリバージョンによるリリース ◦ 日時によるリリース ◦ FutureRelease ◦ データによるリリース
• 実際にリリーススケジュールを組んでみる リリースをコントロールする
様々な リリース手法
• リクエストからアプリバージョンを受け取り、 任意のバージョン以上の時だけ処理を行うという手法 • たとえば以下のようなケースに効果的 ◦ バージョンごとに受け取るリクエストの値が変化するとき ◦ バージョンごとに違うレスポンスを返したいとき //
リクエストからアプリバージョンを取得する $requestVersion = $request->getVersion(); // 対象バージョンを設定する $targetVersion = '1.1.0'; if ($requestVersion >= $targetVersion) { // 「アプリバージョン」>=「対象バージョン」なら処理を行う // NOTE: 本当はもっと適切にバージョン文字列を比較する方法がありますが、今回は割愛 } バージョンによるリリース
• リクエスト日時を基準として、 リリース日時以降の時だけ処理を行うという手法 • 主なケースは以下の通り ◦ あらかじめリリース日時を告知したい時 ◦ デプロイ時に新旧サーバーの処理を混ぜたくない時 //
リクエストが着信した日時を取得する $requestDateTime = $request->getDateTime(); // リリース日時を設定する $targetDateTime = new DateTime('2023-10-24 19:00:00'); if ($requestDateTime >= $targetDateTime) { // 「リクエスト日時」>=「リリース日時」なら処理を行う } 日時によるリリース
FutureRelease • コロプラ独自の FutureRelease というリリース手法もある ◦ 「アプリバージョン」と「リリース日時」の合せ技 • アプリ側のリリースタイミングをサーバー側で管理できる! サーバ
②新Ver対応 デプロイ アプリ ①新Ver リリース ④フラグ返却 ③リリース日時 到達 32 新機能 リリース
• データそのものに開始日時を持たせる手法 ◦ 親データが開始するまで、紐づくデータがすべてリリースされない データによるリリース イベント 開始:10/30 19:00 終了:11/13 11:00
キャラB キャラA スキルA スキルB スキルC スキルD 33 開始:11/06 19:00 10/30 19:00 時点 初めから開放
• データそのものに開始日時を持たせる手法 ◦ 親データが開始するまで、紐づくデータがすべてリリースされない ◦ リリース日時を超えると、紐づくデータが自動でリリースされる データによるリリース イベント 開始:10/30 19:00
終了:11/13 11:00 キャラB キャラA スキルA スキルB スキルC スキルD 34 11/06 19:00 以降 New New
実際に リリーススケジュールを 組んでみる
• 様々なリリース手法があることは分かった • Q. 実際には「どのリリース手法」を「どんな時」に使うのか? ◦ A. ケースバイケース ◦ 1つのイベントをリリースするために複数の手法を組み合わせることが多い
◦ 各セクションへのヒアリングが必須 実際にリリーススケジュールを組んでみる
各セクションにヒアリング クライアント エンジニアさん 10/30 19:00 から 新イベントを開始したい です 既存機能を改修しました 新しいバージョンのアプリでは
リクエストパラメータが 変わります イベント開始と同時に 新しいUIを表示したいです イベント開始と同時に パラメータの計算方法を 修正したいです プランナーさん
各セクションにヒアリング クライアント エンジニアさん 10/30 19:00 から 新イベントを開始したい です 既存機能を改修しました 新しいバージョンのアプリでは
リクエストパラメータが 変わります イベント開始と同時に 新しいUIを表示したいです イベント開始と同時に パラメータの計算方法を 修正したいです プランナーさん ↓データリリース ↑日時リリース ↓バージョンリリース ↑FutureRelease
リリーススケジュールを組み立てる データリリース イベント開始 日時リリース パラメータ計算方法 の修正 バージョンリリース リクエスト改修 FutureRelease 新UIの表示
新バージョンアプリ公開 イベントデータを DB に insert サーバーデプロイ イベント開始
• リリース作業の大半はサーバーエンジニアの担当 ◦ =リリース作業の全体を見通すのはサーバーエンジニアの役目 ◦ =スケジュールの組み立てはサーバーエンジニアが牽引する • サーバー観点のチェックは必須 ◦ それぞれのリリース手段は適切か?
◦ リリース手順に漏れは無いか? ◦ データミスはないか? ノーメンテリリースはサーバーのオペレーションに懸かっている! リリーススケジュールを組み立てる
まとめ
まとめ • コロプラはノーメンテ主義です • でもノーメンテのリリースは大変 ◦ リリースタイミングのハンドリングが重要 • 様々な手法でリリースコントロールを行っています ◦
バージョン、日時、データなどなど ◦ サーバーエンジニアの腕の見せ所! 42
まとめ ノーメンテ運用は大変ですが、 どんな時でもユーザーが24時間ゲームを楽しめるように 日々頑張っています! 43