オンラインでのサーバー切替事例紹介/ColoplTech-05-01

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

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

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

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

Transcript

1. オンラインでの サーバー切替事例紹介 2022年6月16日 曽我 光瑛 1
2. 自己紹介 曽我 光瑛 （Mitsuaki Soga） • 2018 年新卒入社 • ゲームインフラグループ所属 ◦ ゲームインフラの横断的な負荷対策やコスト最適化 2
3. 本日の内容 VM インフラの紹介 • 今までコロプラの勉強会や外部発表で紹介していたのは Kubernetes を利用した環境の話が多かった • VM 環境についての簡単に紹介 データベース切替の紹介 • メンテナンスを入れずに DB を別の DB に切り替える方法の紹介 クラウド切替の紹介 • メンテナンスを入れずにクラウド間でサーバーを移動させた 方法の紹介 3
4. VM インフラの紹介 4
5. VM インフラの構成 5 APP KVS DB realtime LB CDN サーバー ミドルウェア APP apache/nginx, PHP DB MySQL KVS Redis realtime Node.js • よくある LAMP 環境 • クラウドの VM サーバー上に構築 • これ以外にもログ取得用のサーバやバッチサーバなどが存在 • Kubernetes を利用する以前は基本的にこちらの構成
6. VM インフラ運用 普段の運用 • 負荷に合わせたスケールアップ、スケールアウト、スケールイン • ミドルウェアのアップデート コロプラでは、 ユーザーがプレイできないシステム停止を伴うメンテナンスなく運用することを ノーメンテナンスと定義 普段の運用は極力ノーメンテナンスで実施 6
7. ノーメンテナンスの概要 ノーメンテナンスでの対応 • 基本的に新しいサーバーを作成し通信先を切り替えればオンラインで移行可能 ◦ 新旧サーバーに同時にアクセスする時間があっても データの整合性に影響が無い • DB は新旧サーバー間のデータの整合性を取るための工夫が必要 7
8. データベース切替 8
9. データベースの構成 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
10. データベースの運用 10 運用作業 DB切替 DB replica の追加/スペック変更 - スキーマの変更 - ディスク容量増加 - ディスク容量削減 ◯ DB source スペック変更 ◯ MySQL バージョンアップ ◯ シャーディングの変更 ◯ • replica, standby, backup は現在の DB の構成に 新規の物を追加したり参照を切り替えるだけで 変更可能 • source だけは更新があるため、停止を含むよう な作業の際に工夫が必要 • DB 切替は新しい構成/設定にした新系統に 整合性を保ったまま切り替える方法
11. データベース切替 • 新しい 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
12. データベース切替の概要 • 新 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
13. 切替手順① • 新 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
14. 切替手順② • 新 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
15. 切替手順③ • 読み込みを新 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
16. 切替手順④ • 書き込みを新 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
17. クラウド切替 17
18. クラウド切替について クラウド切替 • オンラインゲームを動作させているサーバーの環境を移動させる ◦ オンプレミス -> クラウド ◦ クラウド -> クラウド • 全てオンラインで実施 ◦ ユーザーがプレイできないシステム停止を伴うメンテナンスを行わずに実施 • 同じ物を作ってアクセスを切り替える 18
19. クラウド切替手順 1. 新環境に旧環境と同じサーバーを構築 2. 新旧の間を VPN 接続し DB のレプリケーションを設定 3. 旧環境の APP アクセスを proxy 経由に変更 4. 新環境の DB の AUTO_INCREMENT を上げる 5. 旧環境のアクセスを全て新環境に向ける 6. DNS を変更し、新環境に直接アクセスが流れるようにする 19
20. クラウド切替① 20 APP KVS DB realtime LB CDN APP KVS DB realtime LB VPN Replication 1. 新環境に旧環境と 同じサーバーを構築 2. 新旧の間を VPN 接続し DB の レプリケーションを設定 • 必要であれば KVS にも レプリケーションを設定
21. クラウド切替② 21 APP KVS DB realtime LB CDN APP KVS DB realtime LB VPN proxy 3. 旧環境の APP アクセスを proxy 経由に変更 • LB の配下に proxy を追加 • アクセス切替の際に、一瞬で 切り替わるようにするため Replication
22. クラウド切替③ 22 APP KVS DB realtime LB CDN APP KVS DB realtime LB VPN proxy AUTO_INCREMENT を 上げる 4. 新環境の DB の AUTO_INCREMENT を上げる • DB 切替と同様の理由 • ここまでならまだ後戻りできる Replication
23. クラウド切替④ 23 APP KVS DB realtime LB CDN APP KVS DB realtime LB VPN proxy 5. 旧環境のアクセスを全て新環境 に向ける • haproxy の reload • これ以降は後戻り不可 Replication
24. クラウド切替⑤ 24 APP KVS DB realtime LB CDN APP KVS DB realtime LB VPN proxy 6. DNS を変更し、新環境に直接 アクセスが流れるようにする • 完全に切り替わるまで数日ほど 様子を見る • 切り替わり後 レプリケーション設定を削除 Replication
25. クラウド切替まとめ 今回の手順について • 同様の手順でオンプレミス、 クラウドに関わらず移行が可能 今回の手法のメリット / デメリット メリット • 並行運用を考慮する必要が無いこと デメリット • 後戻りが不可能であること • 短期間で実施しないとコストが嵩むこと 25
26. まとめ • コロプラではサービスの停止なくサーバーの変更を実施 ◦ データの整合性を保つための工夫 • 切替においてクリティカルなコマンドは一瞬なので事前の準備が大切 ◦ データに不整合が出た場合の対応の事前準備 ◦ 開発チームとの事前の打ち合わせやリハーサルをしっかりする 26