バックアップ・圧縮・スキャン処理 Backup / compression / scans

原因ID dk-backup · 主担当 インフラチーム・サーバーインフラ · 副担当インフラチーム・DBインフラ

深夜のバックアップ、ログの圧縮、セキュリティスキャンがディスクを独占すると、ゲームサーバーの読み書きが詰まります。

なぜスケジュールされたバックアップ・圧縮処理が始まる → すると ディスクの帯域幅とIOPSの大半を占有 → 画面では 毎日同じ時刻にラグ

症状: カクつき, 入力遅延
要因: ストール, 遅延
誰に起きるか: サーバー全体
いつ: 一定の周期で
担当: 主担当 インフラチーム・サーバーインフラ · 副担当インフラチーム・DBインフラ
インフラチームの対応: サーバー機器・OS：バックアップ・圧縮・スキャン処理のI/O優先度を下げる、時刻の分散。DBサーバー：バックアップはレプリカで。
グラフでは: 周期的なスパイク · ディスク利用率、ディスク待ち時間
確認箇所: sar -dで過去数日の記録（/var/log/saの日別ファイル。sadcが-S DISKでディスク項目まで収集している必要あり）の%util・await・aqu-szを日付ごとに重ねて確認し、その時刻にpidstat -d 1でkB_rd/s・kB_wr/sが最も大きいプロセスを探して、cron・systemdタイマーのスケジュールと照合
該当する場合: 毎日同じ時刻にawaitと%utilが跳ね上がり、そのときバックアップ・圧縮・スキャンのプロセスがディスク読み書きの大半を占める
該当しない場合: 跳ね上がる時刻が日によって違うなら、スケジュールされた処理の可能性は低い。その時刻のI/Oの大半がゲームサーバー自身なら、保存・ログ側（dk-fsync、dk-sync-log）
確認手段: インフラのツールで確認（ゲームコード不要）

出典

ionice(1) — Linux manual page util-linux
idleクラスで動かした処理は、他のプログラムがディスクを使っていないときだけディスク時間を得る
Using Replication for Backups MySQL
レプリカを止めてバックアップしても、プライマリの運用には影響しない
sar(1) — Linux manual page sysstat
-d：日別の記録ファイル（デフォルトは/var/log/sa）のデバイスごとのawait・aqu-sz・%util、ディスク項目はsadcの-S DISKオプションで収集する必要あり
pidstat(1) — Linux manual page sysstat
-d：プロセスごとのkB_rd/s・kB_wr/s（1秒あたりのディスク読み込み量・書き込み量）