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

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

本記事では、この新規 MySQL インスタンス構築の長期化という課題を解決するために新卒1年目エンジニアが行った、Percona XtraBackup for MySQL（以下、XtraBackup）の xbstream 機能を活用した高速化手法の検討・検証結果をご紹介します。このアプローチにより、従来の最大24倍という大幅な速度向上を実現し、DB 運用の安定性が向上させることができました。

XtraBackup 活用や I/O 特性を踏まえたチューニングの実践的な技術として参考にしていただければ幸いです。また、新卒1年目でもこれだけの課題に挑戦することのできる環境があることも感じていただけると思います。

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

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

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

• primary: 更新を受け付ける唯一のインスタンス
  • 単一の MySQL クラスターに1台のみ存在
• replica: 参照クエリの負荷分散用インスタンス
  • 参照負荷に応じた台数存在する
  • 参照クエリのみを受け付ける
• backup: 定期バックアップ取得用インスタンス
  • cron で mysqldump によるバックアップ取得を定期的に実施
  • 新規 MySQL インスタンス構築時には、データの復元元となる

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

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

現在は、backup インスタンスで定期的に取得している mysqldump 形式のデータを利用して新規インスタンスを構築しています。

新規インスタンス構築

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

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

1. backup インスタンスから新規インスタンスへバックアップ転送
   • rsync で行う
2. 新規インスタンスでバックアップデータをリストア
3. backup - 新規インスタンス間でレプリケーションを繋ぐ
   • バックアップ実行時以降に発生した変更を取り込む
4. primary - 新規インスタンス間でレプリケーションを繋ぐ

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

• インスタンス構築開始時に backup インスタンスにバックアップデータが存在する必要がある
• backup インスタンスへの追従を挟むことで、primary インスタンスの負荷を軽減している

定期バックアップ

定期バックアップは毎日1回取得され、完了まで数時間、長いものでは10時間以上を要します。mysqldump でデータを出力し、シングルスレッドの gzip で圧縮しているため、処理に時間がかかる傾向があります。

既存手法の課題

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

課題1: 構築時間の長期化

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

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

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

課題解決の方向性

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

1. リストア処理の高速化: ボトルネックであるリストア時間を大幅に短縮する
2. バックアップデータに依存しない構築: 定期バックアップのスケジュールに縛られず、いつでも構築を開始できる仕組みを作る

Percona XtraBackup

これらを実現するツールとして、Percona XtraBackup for MySQL（XtraBackup）を採用しました。 XtraBackup の他に mydumper/myloader なども検討しましたが、XtraBackup に速度面で劣ると判断し採用を見送りました。

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

特徴

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

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

仕組み

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

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

使用方法

バックアップ

xtrabackup --backup コマンドにより、データディレクトリ、redo ログの保存が実行でき、バックアップが完了します。

リストア

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

1. データディレクトリの展開(xbstream コマンド)
   • この段階では XtraBackup 独自のディレクトリ構成に展開される
   • これにより、設定に依存せずリストア可能なバックアップとしている
     • データディレクトリのディレクトリ構成は my.cnf 中の設定に依存
2. redo ログの適用(xtrabackup --prepare コマンド)
3. データディレクトリの書き戻し( xtrabackup --copy-back コマンド)
   • この段階で MySQL のデータディレクトリの構成となる

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

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

xbstream は tar のような複数のファイルを単一のアーカイブファイルとしてまとめる、アーカイブフォーマットです。ただし、xbstream では、単一のファイルを複数のチャンクへ分割しアーカイブファイルに格納します。このため、tar と異なり複数のファイルを同時に読み書き可能です。これにより xbstream ではディスク I/O 帯域を最大限活用できます。

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

手法案

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

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

既存の mysqldump をそのまま XtraBackup に置き換える案です。圧縮には高速な zstd を使用します。定期バックアップそのものを高速化し、構築不可時間を短縮するアプローチです。

メリット・デメリット

• メリット
  • mysqldump より高速かつ低負荷
  • 構築不能な時間が短縮される
• デメリット
  • 「バックアップ実行中は構築できない」という制約は解消されない
  • ロールフォワードの時間は mysqldump と変わらない

xbstream を利用した XtraBackup 方式

xbstream の特性を活かし、バックアップデータ（静的ファイル）を経由せず、オンデマンドでインスタンス構築を行う案です。これにより、いつでもインスタンス構築可能となるほか、ロールフォワード時間の短縮が見込めます。

直接コピーによる構築プロセス

backup インスタンスで xtrabackup --backup --stream=xbstream を実行し、そのストリームを SSH 経由で新規インスタンスへ転送、即座に xbstream -x -C で展開します。

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

展開後、xtrabackup --prepare で redo ログを適用し、MySQL として起動可能な状態にします。これにより、実質的にデータディレクトリをそのままネットワーク経由でコピーしているのと同等の処理となります。

転送と圧縮の検討

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

メリット・デメリット

• メリット
  • mysqldump より高速かつ低負荷
  • 直近のデータをコピーするため、ロールフォワード時間が短い
  • ネットワーク転送とディスク書き込みが同時に進むため効率が良い
  • 定期バックアップを利用せず、いつでも構築可能
• デメリット
  • インスタンス構築中、primary - backup 間レプリケーションの一時停止が必要
    • XtraBackup の「バックアップ中はレプリケーションの停止が必要」な制約のため
    • 複数インスタンスを同時構築する際、排他制御が必要となる

検証結果

xbstream 方式の効果を実機で測定しました。

検証内容と環境

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

実験環境

• インスタンスタイプ: AWS EC2 i3en.3xlarge
• ストレージ: NVMe 7.5TB
• ネットワーク帯域: 25Gbps

ツールバージョン

• MySQL: 5.7.27
• XtraBackup: 2.4.29-1
• mysqldump: 5.7.27

データ復元時間の大幅な短縮

検証の結果、mysqldump 方式と比較して所要時間を約 1/24 に短縮できました。

• 1TB の環境で、約1時間で構築完了
• 3TB になっても、3時間未満で完了する見込み

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

また、XtraBackup を利用する2方式でも、xbstream 方式が定期バックアップ利用方式の約 1/2 の所要時間となり、より高速化できることが確認できました。

定期バックアップ時間の改善

今回の課題解決には直接影響はしませんが、参考として XtraBackup と mysqldump の定期バックアップ自体の実行時間・バックアップデータのサイズも検証しました。

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

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

なぜ xbstream 方式がこれほど速いのか、技術的な要因は I/O の扱い方にあります。

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

xbstream を用いたストリーミングにより、バックアップデータの転送とそのデータディレクトリへの展開を同時に行えます。

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

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

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

対して xbstream による直接転送では、ネットワークから受け取ったデータをそのまま展開先へ書き込むため、「バックアップデータの読み込み」がなくなりディスクの負荷が大幅に減少します。実際の Disk Utilization の値が以下です。1つ目の図が定期バックアップ利用方式、2つ目が xbstream 方式となっています。ここから定期バックアップ利用方式では Disk Utilization が 100% なのに対して、xbstream 方式では 50% 前後と余裕があることがわかります。

この結果、「展開データの書き込み」のスループットが約2倍に向上し、「データディレクトリ展開」の速度向上に繋がりました。実際の Disk Throughput が以下です。先ほどと同様に定期バックアップ利用方式、xbstream 方式の順で並んでおり、書き込みがオレンジで上側、読み込みが黄色で下側となっています。定期バックアップ利用方式では読み込みが発生しており書き込みの Disk Throughput が 220MiB/s 程度なのに対して、xbstream 方式では 500MiB/s と倍以上の差が出ています。

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

まとめ

今回、Percona XtraBackup の xbstream 機能を活用することで、従来の mysqldump 比で最大24倍のインスタンス構築速度を達成しました。

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

おわりに

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

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