MySQL構築速度が24倍に！XtraBackupによる劇的パフォーマンス改善 [DeNAインフラSRE]

こんにちは。今年（2025年）8月から IT 基盤部第二グループに配属された、新卒1年目の若松です。

IT 基盤部では、日々多くのサービスを支える MySQL を中心とした大規模なデータベース群を運用しています。その中で、新規 DB インスタンスの構築に時間がかかることは、システム全体の可用性に関わる大きな課題でした。万が一、故障したインスタンスの復旧中に別の障害が発生した場合、DB リソースが不足し、サービス停止につながるリスクがあるためです。

本記事では、この新規 MySQL インスタンス構築の長期化という課題を解決するために新卒1年目エンジニアが行った、Percona XtraBackup for MySQL（以下、XtraBackup）の xbstream 活用や I/O 特性を踏まえたチューニングの実践的な技術として参考にしていただければ幸いです。また、新卒1年目でもこれだけの課題に挑戦することのできる環境があることも感じていただけると思います。

大規模 DB 運用におけるインスタンス構築の課題

DeNA の DB 運用体制とバックアップの役割

DeNA では、安定したサービス提供のために MySQL データベースを3つの役割のインスタンスによる構成を基本として運用しています。

primary: 更新を受け付ける唯一のインスタンス 単一の MySQL クラスターに1台のみ存在

replica: 参照クエリの負荷分散用インスタンス 参照負荷に応じた台数存在する

backup: 定期バックアップ取得用インスタンス cron で mysqldump

新規 MySQL インスタンス構築時には、データの復元元となる backup インスタンスが必要です。

とくに backup インスタンスは、データの保全と迅速な復旧を担う重要な役割を持っています。

既存の mysqldump による新規インスタンス構築プロセス

現在は、backup インスタンスで定期的に取得している mysqldump データベースダンプファイルを転送し、リストアして新規インスタンスを構築しています。

バックアップデータをリストアした上で、ロールフォワードすることで新規インスタンスを構築します。

具体的な手順は以下の通りです。

backup インスタンスから新規インスタンスへバックアップ転送 rsync で行う

新規インスタンスでバックアップデータをリストア

backup - 新規インスタンス間でレプリケーションを繋ぐ バックアップ実行時以降に発生した変更を取り込む

primary - 新規インスタンス間でレプリケーションを繋ぐ

ここでのポイントは以下の2点です。

インスタンス構築開始時に backup インスタンスにバックアップデータが存在する必要がある

backup インスタンスへの追従を挟むことで、primary インスタンスの負荷を軽減している

定期バックアップは毎日1回取得され、完了まで数時間、長いものでは10時間以上を要します。mysqldump によるフルダンプでは、大規模データベースほど処理に時間を要し、その間 DB リソースが占有されるため、運用上のボトルネックとなっていました。

これまでのプロセスには、運用上無視できない課題がありました。

あるプロジェクトでは、新規インスタンスの構築に約1.5日を要していました。時間の大部分は論理バックアップデータのリストア処理（SQL の実行）が占めています。これほど時間がかかると、復旧作業中に予期せぬ多重障害が発生した場合、リソース不足に陥りサービスの継続が困難になる恐れがあります。

課題2: バックアップ実行中の構築不可

前述の通り、定期バックアップ実行中はデータが不完全なため、当チームの現在の運用では新規インスタンスの構築を開始できません。これにより作業可能な時間帯が制限され、緊急時の対応スピードが鈍化する要因となっていました。例えば、定期バックアップに 16時間かかる場合、24時間中の16時間 (2/3 の時間) でインスタンス構築ができない状態となります。

ここまでの課題を踏まえ、以下の2点を行うことで課題の解決を目指しました。

リストア処理の高速化: ボトルネックであるリストア時間を大幅に短縮する

バックアップデータに依存しない構築: 定期バックアップのスケジュールに縛られず、いつでも構築を開始できる仕組みを作る

Percona XtraBackup

これらを実現するツールとして、Percona XtraBackup for MySQL（XtraBackup）を採用しました。 XtraBackup の他に mydumper

XtraBackup については、以下の記事でも詳細な解説が行われているため、是非ご覧ください。

XtraBackup は、高速な物理バックアップ・リストアが可能です。

また、primary インスタンスからバックアップを取得する場合には、運用中の DB に対してノンブロッキングで実行可能です。これにより、サービスへの影響を最小限に抑えられます。ただし、DeNA で用いているようなレプリカからバックアップを取得する場合には、レプリケーションの停止が必要となります。

基本的には、MySQL のデータディレクトリを物理的にコピー（ダンプ）します。

しかし、このままではバックアップ中の書き込みの反映状況がファイルによって異なり、データ不整合が発生した状態となってしまいます。XtraBackup はこの不整合を redo ログにより解決します。redo ログは MySQL がクラッシュ時のデータ復元に用いるログです。redo ログには直近に発生した DB への書き込みがリプレイ可能な形式で記録されています。XtraBackup では、これをリストア前に適用することで解消し、バックアップデータを修復します。これにより、単なるファイルコピーに近い速度でのバックアップ・リストアが可能となります。

xtrabackup --backup

以下の3段階でリストアできます。

データディレクトリの展開(xbstream

この段階では XtraBackup 独自のディレクトリ構成に展開される

これにより、設定に依存せずリストア可能なバックアップとしている データディレクトリのディレクトリ構成は my.cnf

redo ログの適用(xtrabackup --prepare

データディレクトリの書き戻し( xtrabackup --copy-back

この段階で MySQL のデータディレクトリの構成となる

アーカイブフォーマット xbstream

今回鍵となったのが、XtraBackup 独自のストリーム処理と並列処理が可能なアーカイブフォーマット xbstream

この「ストリーム処理可能」かつ「並列処理可能」という特性を活かすことで、劇的な高速化が期待できます。

XtraBackup を用いた新規 MySQL インスタンス構築方法として、2 つのパターンを検討しました。

定期バックアップ利用の XtraBackup 方式

デメリット 「バックアップ実行中は構築できない」という制約は解消されない

ロールフォワードの時間は mysqldump

xbstream を利用した XtraBackup 方式

backup インスタンスで xtrabackup --backup --stream=xbstream

ssh $backup_server "xtrabackup --backup --stream=xbstream" | xbstream -x -C $target_dir

展開後、xtrabackup --prepare

転送にはセキュリティと既存インフラとの親和性から SSH を使用します。netcat 等はセキュリティリスクなどを考慮し見送りました。圧縮については、主な使用環境となる AWS の広帯域ネットワークであり、圧縮・解凍のスループットがボトルネックとなる懸念が強いことから、無圧縮としました。

直近のデータをコピーするため、ロールフォワード時間が短い

ネットワーク転送とディスク書き込みが同時に進むため効率が良い

定期バックアップを利用せず、いつでも構築可能

デメリット インスタンス構築中、primary - backup 間レプリケーションの一時停止が必要 XtraBackup の「バックアップ中はレプリケーションの停止が必要」な制約のため

複数インスタンスを同時構築する際、排他制御が必要となる

primary / backup の構成を構築した上で、replica を新たに構築する想定で、構築時間の計測を行いました。また、XtraBackup は仕組み上バックアップ取得中の書き込み量にも実行時間が影響を受けるため、sysbench で秒間100トランザクションの負荷をかけながら計測しています。

インスタンスタイプ: AWS EC2 i3en.3xlarge

ストレージ: NVMe 7.5TB

ネットワーク帯域: 25Gbps

XtraBackup: 2.4.29-1

検証の結果、mysqldump

1TB の環境で、約1時間で構築完了

3TB になっても、3時間未満で完了する見込み

これにより、緊急時のリカバリ時間が劇的に短縮され、可用性が大きく向上します。

また、XtraBackup を利用する2方式でも、xbstream

今回の課題解決には直接影響はしませんが、参考として XtraBackup と mysqldump

この結果、XtraBackup への置き換えにより、実行時間を 1TB で約 1/16、3TB で約 1/22 に短縮できることが分かりました。また、この際バックアップデータのサイズもほとんど変わらないことが確認できました。

高速化の要因：I/O 特性を活かした最適化

要因 1: 転送と展開のパイプライン処理

この 2 つの処理は、ネットワーク I/O（ネットワーク入出力）とディスク I/O（ディスク入出力）という異なるハードウェアリソースを主に使用するため、同時に実行することでリソースを有効に活用できます。

要因 2: ディスク I/O の効率化

通常のバックアップ方式（一度ファイルに落とす方式）では、データディレクトリへのバックアップデータ展開（図中の「データディレクトリ展開」）の際に「バックアップデータの読み込み」と「展開データの書き込み」が発生します。

この結果、「展開データの書き込み」のスループットが約 2 倍に向上し、「データディレクトリ展開」の速度向上に繋がりました。実際の Disk Throughput（ディスクスループット）が以下です。先ほどと同様に定期バックアップ利用方式、xbstream

今回は、AWS の広帯域ネットワークを用いており、ディスク I/O がボトルネックとなっていたため、この I/O 削減が速度向上に直結したと思われます。

今回、Percona XtraBackup の xbstream

ネットワーク I/O とディスク I/O の特性を理解し、ストリーミング処理でボトルネックを解消したことが、この結果に繋がりました。これにより、緊急時の復旧スピード向上と、運用オペレーションの柔軟性確保の両立が可能となりました。

DeNA IT 基盤部では、インフラ運用の効率化と安定化に向けた改善を日々続けています。本記事が、MySQL 運用における可用性向上やパフォーマンス改善のヒントになれば幸いです。

また、DeNA には新卒1年目であってもチャレンジングな課題に取り組める環境があることも感じていただければ幸いです。

最後まで読んでいただき、ありがとうございます！この記事をシェアしていただける方はこちらからお願いします。