背景

皆さんはデータのバックアップをどのように圧縮しますか？
こちらのエントリーでは、高圧縮率で知られるXZ圧縮フォーマットについて簡単な検証結果をまとめたいと思います。

この検証をするきっかけになったのは、AWSのS3へのデータのバックアップ方法を模索することになったからである。
業務に関わるプロジェクト情報が入ったデータサーバーで2重のバックアップを行っていますが、
災害対策としてリモートサーバーへのバックアップも取ろうということになりました。
しかし、データの容量・通信量に応じてコストが発生するため、このコストを抑えるために検証を行いました。

ネットでリサーチすると、圧縮率や圧縮にかかる時間を検証した記事をいくつか発見しましたが、
データの種別が偏っていたりして、論理的な検証に近いものが多かった印象でした。

なので、業務で良くあるようなデータ種別で、どの程度の効果を得られるのかを検証してみたいと思います。

検証の目的

• 論理的な圧縮率より、実際の業務で発生するデータパターンで検証したい
• マシンの性能で左右されるので、厳密な検証結果を求めない。あくまでも「目安」を知ることが目的
• 調査結果から、実務での利用が現実的かどうかを考える

検証データ

/tmp/compress-test
├ design:    1.8GB
├ logs:      8.8GB
└ wordpress: 50MB

まずは、ディレクトリーにテスト用のデータを用意しました。
デザインデータには、PDFやAI、PSD、XD、PNGなどのデータを入れました。
より実践的な構造にするために、敢えて複数の種類を入れています。
デザイナーやディレクターから上がってきたデータという想定ですね。

ログデータには、WEBサーバーで日別に出力されたログファイルを8.8GB分用意しました。
サーバー運用では、これも良くあるパターンですね。

最後には、ソースコードが入ったデータですね。Wordpressのパッケージをデフォルト状態で用意しました。

検証方法

今回は、より実務に近づけられうように、XZのマルチスレッド版で検証します。
XZは、高圧縮率なだけに、圧縮時間がめちゃくちゃ長い。シングルスレッドで数百GBを圧縮するのは非現実的だったので、
マルチスレッドで検証していきますが、当然ながらマシンの性能に依存する話になります。

検証マシン

CPUは4コア8スレッドなので、今回の検証は8スレッドを使う形にしています。
読み書き速度がI/Oに影響するので、SSDであることを配慮しないければなりません。
また、メモリはDDR3なので、現在のDDR4に劣ることに踏まえなければならない。

検証環境

PIXZのインストール

$ brew install pixz

検証用コマンド

# 圧縮
$ tar -C 圧縮対象の親ディレクトリーパス -cf - 圧縮対象のディレクトリー名 | pixz -9 > 出力先ファイルのパス

# 展開
$ pixz -d -i 出力先ファイルのパス | tar zxf -

tarコマンドに絶対パスを指定した場合、圧縮ファイルに絶対パスが含まれてしまうので、対策として「-C」オプションを使っています。

検証を実施

デザインデータ

やはり、様々なデータ形式が含まれているからでしょうか。2分ほどで完了しましたが、1.8GBにしては遅いですね。
ファイルサイズは34%になりましたので、66%の圧縮率です。
圧縮に比べて、解凍は思っていたよりも早くて、びっくりしました。

ログデータ

テキストデータのみのログデータですが、8分もかかっています。デザインデータを見比べると、比例しているようにも見えますが、
ログデータの方が若干早いみたいです。圧縮後のデータは5%程度のサイズになり、なんと95%の圧縮率です！
そして、容量の割に解凍が高速ですね！

ソースコードデータ

最後にWordpressのソースデータですね。容量が小さいので、18秒ほどで完了しています。
圧縮後のサイズは18%ほどになり、82%の圧縮率です。
予想ではございますが、ログデータと違って、画像データが多少含まれていたことが原因な気がします。

検証結果

今回の検証は、あくまでも「目安」なので、MB単位で計算をしていたり、時間は小数点を省略したりと
厳格な検証結果ではありませんので、ご了承ください。

感想

上記の結果から、データの種類によって圧縮率や時間が変わることを把握できたのですが、
1つ疑問が残ってしまいます。今回はtarでアーカイブファイルを作ってから圧縮をしている状況なので、
アーカイブしている時点で圧縮率がtarに依存してしまうのでは？というものです。

もし、そうだとしたら、XZでの圧縮はデータの種別で変わるのではなく、tarの圧縮率によって変わっているだけ
という可能性も出てきます。こちらについては、引き続き検証が必要だと思いますが、
詳しい方がいらっしゃいましたら、ぜひ教えて下さい。

マシンへの負荷

圧縮を8スレッドで実行しましたが、圧縮中のCPU使用率は600〜800%でした。全コアが100%に近い状態だったので、
業務利用を踏まえると、割り当てるスレッド数の制限は必須でしょう。

また、VPSサーバーでの利用時には、高いCPU使用率で長時間稼働を続けた場合には、CPUの利用制限をかけられてしまう可能性があります。
※ 以前に「さくらVPS」でかけられてしまった経験があります。

EC2では、TインスタンスでCPUクレジットを早期に使い切ってしまう可能性があるため、CPUに負荷をかけない圧縮方法を検討した方が良いと思います。

圧縮率と時間

デザインデータで66%、ログデータで95%、ソースコードで82%と、圧縮率としては非常に満足のいく結果でした。
特にデザインデータは、圧縮しても容量をセーブできないことが多いので、これだったら使えそうです。

圧縮率は良いが、時間がかかりすぎる・・・
8スレッドも使って、この時間かー・・・ という感想ですね。
使えるリソースが限られた環境では、ちょっと難しいかもしれませんが、個人用途であれば色々と使い道がありそうですね。

解凍時間は、容量の割にそこそこ速いので、中程度の緊急性にも対応ができそうです。

厳密性が低い検証でしたが、目安を知りたい方に参考になればと思います。