インフラ

バックアップの圧縮形式を変更して CPU 使用率を改善する

インフラ

はじめまして。技術部プラットフォームグループの sugy です。

私は主に弊社で運用しているカラーミーショップというサービスのインフラ周りの担当をしています。 本記事では、カラーミーショップのバックアップサーバでデータ圧縮形式を変更して CPU 使用率を改善した話を書きます。

経緯

カラーミーショップではサービス利用者の方々の大切なデータをお預かりしているのですが、システムの可用性の確保のためにそれらのデータのバックアップを行っています。しかし、しばらくバックアップサーバの CPU 使用率が高い状態が継続していました。この状態が更に進むとバックアップ処理が完了する前に次のバックアップ処理が開始されてしまい慢性的なリソース不足になる懸念がありました。

バックアップデータは各サービス提供用サーバから、バックアップ用サーバにデータを同期した後、アーカイブ・圧縮して AWS S3 に転送・保管するようにしていました。その処理の中でどの処理が CPU バウンドな処理なのか調査・把握ができていませんでしたが、アーカイブファイルの圧縮処理が支配的だろうと考えていました。

バックアップサーバの CPU 使用率の上昇の対応としては、サーバハードウェアのスケールアップによる解決という方法もあるのですが、今回はソフトウェア的に改善の余地があるのか、圧縮形式の変更を試してみることにしました。

圧縮形式の選定

今回のケースではどのような圧縮形式を利用するのがよいか考えてみたところ、1. 圧縮スピートが速くなる. 2. 圧縮後のファイルサイズは現状よりあまり大きくならない. という条件に合う圧縮形式がよいだろうと考えました。 圧縮スピードが速くなるということは、それだけ CPU コアを専有している時間が短くなるということなので、CPU 使用率の問題を緩和する効果があります。また、アーカイブファイルを S3 に保存しているので、S3 の利用量が肥大化しないことも考慮しました。

なお、圧縮形式を変更する前は gzip を利用していました。バックアップ処理のデータのアーカイブには tar コマンドを利用していて tar czf foo.tar.gz /path/to/foo のようなお馴染みの利用方法です。

これらの条件で、圧縮形式を比較しているページなどを参考に検討しました。検討した結果、gzip より圧縮スピードが速く圧縮後のデータサイズが大きく変わらない圧縮形式の Zstandard(zstd) を利用することにしました。(詳しい方には今更感があるとは思いますが..)

圧縮形式の変更

圧縮形式を変更するには tar--use-compress-program (-I) オプションで指定するだけでした(※1)。また、OS に CentOS を利用しているので、必要なパッケージは yum install zstd でインストール出来ました(※2)。zstd パッケージは epel レポジトリにあります。とても簡単ですね。

tar cf foo.tar.zst --use-compress-program=zstd /path/to/foo

余談ですが、tar--use-compress-program にはオプションを含むコマンドを指定することができなかったので、zstd の利用スレッド数を指定したい場合は、環境変数のZSTD_NBTHREADSを指定する必要がありました。

  • ※1: 最新の GNU tar (v1.31以上)には --zstd オプションがあるようですが、CentOS7 の base レポジトリの tar パッケージはそこまでバージョンが上がっていません。

  • ※2: 実際には構成管理ツールから yum コマンド実行してインストールしています。

結果

圧縮形式を変更したところ、想定取り CPU 使用率が下がり余裕がある状態となりました。 いとめでたし。

下のグラフはバックアップサーバの CPU 使用率のメトリクスです。

CPU使用率のグラフ

まとめ

バックアップデータの圧縮形式を gzip から zstd に変更することで、サーバの CPU 使用率を下げることができました。バックアップ方法にもよると思いますが、今回のケースでは容易に変更することができ問題を改善することが出来ました。