Slide 1

Slide 1 text

オンラインでの サーバー切替事例紹介 2022年6月16日 曽我 光瑛 1

Slide 2

Slide 2 text

自己紹介 曽我 光瑛 (Mitsuaki Soga) ● 2018 年新卒入社 ● ゲームインフラグループ所属 ○ ゲームインフラの横断的な負荷対策やコスト最適化 2

Slide 3

Slide 3 text

本日の内容 VM インフラの紹介 ● 今までコロプラの勉強会や外部発表で紹介していたのは Kubernetes を利用した環境の話が多かった ● VM 環境についての簡単に紹介 データベース切替の紹介 ● メンテナンスを入れずに DB を別の DB に切り替える方法の紹介 クラウド切替の紹介 ● メンテナンスを入れずにクラウド間でサーバーを移動させた 方法の紹介 3

Slide 4

Slide 4 text

VM インフラの紹介 4

Slide 5

Slide 5 text

VM インフラの構成 5 APP KVS DB realtime LB CDN サーバー ミドルウェア APP apache/nginx, PHP DB MySQL KVS Redis realtime Node.js ● よくある LAMP 環境 ● クラウドの VM サーバー上に構築 ● これ以外にもログ取得用のサーバやバッチサーバなどが存在 ● Kubernetes を利用する以前は基本的にこちらの構成

Slide 6

Slide 6 text

VM インフラ運用 普段の運用 ● 負荷に合わせたスケールアップ、スケールアウト、スケールイン ● ミドルウェアのアップデート コロプラでは、 ユーザーがプレイできないシステム停止を伴うメンテナンスなく運用することを ノーメンテナンスと定義 普段の運用は極力ノーメンテナンスで実施 6

Slide 7

Slide 7 text

ノーメンテナンスの概要 ノーメンテナンスでの対応 ● 基本的に新しいサーバーを作成し通信先を切り替えればオンラインで移行可能 ○ 新旧サーバーに同時にアクセスする時間があっても データの整合性に影響が無い ● DB は新旧サーバー間のデータの整合性を取るための工夫が必要 7

Slide 8

Slide 8 text

データベース切替 8

Slide 9

Slide 9 text

データベースの構成 9 ● シンプルなレプリケーション ● tcp load balancer を利用することで 一部冗長化とオペレーションコスト削減 サーバー 用途 DB source データの書き込み DB replica tcp load balancer 経由で読み込みを処理 DB standby 社内ツールや調査クエリの実行用のレプリカ DB backup データディレクトリのスナップショットを取得 DB source DB replica tcp load balancer Write Read Replication DB backup DB standby APP

Slide 10

Slide 10 text

データベースの運用 10 運用作業 DB切替 DB replica の追加/スペック変更 - スキーマの変更 - ディスク容量増加 - ディスク容量削減 ◯ DB source スペック変更 ◯ MySQL バージョンアップ ◯ シャーディングの変更 ◯ ● replica, standby, backup は現在の DB の構成に 新規の物を追加したり参照を切り替えるだけで 変更可能 ● source だけは更新があるため、停止を含むよう な作業の際に工夫が必要 ● DB 切替は新しい構成/設定にした新系統に 整合性を保ったまま切り替える方法

Slide 11

Slide 11 text

データベース切替 ● 新しい DB に切り替える際に AUTO_INCREMENT のカラムを考慮しないと データ不整合が発生 11 DB source 新 DB source Replication INSERT … name = catra DB source 新 DB source Replication INSERT … name = catra INSERT … name = wiz 切替先の新 DB とレプリケーション 書き込み先を切替 id name 0980 arietta 0981 barron … … id name 0980 arietta 0981 barron … … id name 0980 arietta 0981 barron 0982 catra … … id name 0980 arietta 0981 barron 0982 wiz … … レプリケーションにより id が衝突 APP APP

Slide 12

Slide 12 text

データベース切替の概要 ● 新 DB の AUTO_INCREMENT の値を上げる ○ 内製ツールで INSERT & DELETE ○ AUTO_INCREMENT のカラムと別のカラムで複合インデックスがある場合は手動でクエリ実行 12 DB source 新 DB source Replication INSERT … 切替先の新 DB とレプリケーション DB source 新 DB source Replication INSERT … 新 DB の AUTO_INCREMENT を上げる DB source 新 DB source Replication INSERT … 書き込み先を切替 INSERT … INSERT … id = 1100 0980 … 0980 … 1100 0980 0981 … 0980 0981 … 1100 1101 0980 … 0980 … APP APP APP Replication INSERT

Slide 13

Slide 13 text

切替手順① ● 新 DB を構築し、新旧 source の間にレプリケーションを設定 ● 設定できたら backup / standby のデータ読み込みは新の方に向けて、旧の方は停止 13 DB source DB replica tcp load balancer Write Read Replication DB backup DB standby 新 DB source 新 DB replica Replication 新 DB backup 新 DB standby Replication APP

Slide 14

Slide 14 text

切替手順② ● 新 source で AUTO_INCREMENT 値を上げる ● どこかでレプリケーションのエラーが出たらこの時点で旧環境に切り戻し 14 DB source DB replica tcp load balancer DB backup DB standby 新 DB source 新 DB replica 新 DB backup 新 DB standby AUTO_INCREMENT を 上げる APP Write Read Replication Replication Replication

Slide 15

Slide 15 text

切替手順③ ● 読み込みを新 DB replica に切替 15 DB source DB replica tcp load balancer DB backup DB standby 新 DB source 新 DB replica 新 DB backup 新 DB standby APP Write Read Replication Replication Replication

Slide 16

Slide 16 text

切替手順④ ● 書き込みを新 DB source に切替え ● 旧 DB source の更新が止まったことを確認して新旧間のレプリケーションを停止する 16 DB source DB replica tcp load balancer DB backup DB standby 新 DB source 新 DB replica 新 DB backup 新 DB standby Write APP Write Read Replication Replication Replication

Slide 17

Slide 17 text

クラウド切替 17

Slide 18

Slide 18 text

クラウド切替について クラウド切替 ● オンラインゲームを動作させているサーバーの環境を移動させる ○ オンプレミス -> クラウド ○ クラウド -> クラウド ● 全てオンラインで実施 ○ ユーザーがプレイできないシステム停止を伴うメンテナンスを行わずに実施 ● 同じ物を作ってアクセスを切り替える 18

Slide 19

Slide 19 text

クラウド切替手順 1. 新環境に旧環境と同じサーバーを構築 2. 新旧の間を VPN 接続し DB のレプリケーションを設定 3. 旧環境の APP アクセスを proxy 経由に変更 4. 新環境の DB の AUTO_INCREMENT を上げる 5. 旧環境のアクセスを全て新環境に向ける 6. DNS を変更し、新環境に直接アクセスが流れるようにする 19

Slide 20

Slide 20 text

クラウド切替① 20 APP KVS DB realtime LB CDN APP KVS DB realtime LB VPN Replication 1. 新環境に旧環境と 同じサーバーを構築 2. 新旧の間を VPN 接続し DB の レプリケーションを設定 ● 必要であれば KVS にも レプリケーションを設定

Slide 21

Slide 21 text

クラウド切替② 21 APP KVS DB realtime LB CDN APP KVS DB realtime LB VPN proxy 3. 旧環境の APP アクセスを proxy 経由に変更 ● LB の配下に proxy を追加 ● アクセス切替の際に、一瞬で 切り替わるようにするため Replication

Slide 22

Slide 22 text

クラウド切替③ 22 APP KVS DB realtime LB CDN APP KVS DB realtime LB VPN proxy AUTO_INCREMENT を 上げる 4. 新環境の DB の AUTO_INCREMENT を上げる ● DB 切替と同様の理由 ● ここまでならまだ後戻りできる Replication

Slide 23

Slide 23 text

クラウド切替④ 23 APP KVS DB realtime LB CDN APP KVS DB realtime LB VPN proxy 5. 旧環境のアクセスを全て新環境 に向ける ● haproxy の reload ● これ以降は後戻り不可 Replication

Slide 24

Slide 24 text

クラウド切替⑤ 24 APP KVS DB realtime LB CDN APP KVS DB realtime LB VPN proxy 6. DNS を変更し、新環境に直接 アクセスが流れるようにする ● 完全に切り替わるまで数日ほど 様子を見る ● 切り替わり後 レプリケーション設定を削除 Replication

Slide 25

Slide 25 text

クラウド切替まとめ 今回の手順について ● 同様の手順でオンプレミス、 クラウドに関わらず移行が可能 今回の手法のメリット / デメリット メリット ● 並行運用を考慮する必要が無いこと デメリット ● 後戻りが不可能であること ● 短期間で実施しないとコストが嵩むこと 25

Slide 26

Slide 26 text

まとめ ● コロプラではサービスの停止なくサーバーの変更を実施 ○ データの整合性を保つための工夫 ● 切替においてクリティカルなコマンドは一瞬なので事前の準備が大切 ○ データに不整合が出た場合の対応の事前準備 ○ 開発チームとの事前の打ち合わせやリハーサルをしっかりする 26