EatSmartシステム部ブログ

ウェブサイトの開発や運営に関する情報です。

rsyncで行ったデータ移行のまとめ

今回は、インフラ再編に伴って行ったクスパの画像データ移行について 内容をまとめていきます。対象となる画像は、クスパ上にあがる先生ブログの画像や各種レシピ、レッスンに使われる 画像などトータルで約500GBの容量でした。

rsyncについて

画像データの移行は、rsyncを使って全て行いました。 まず、rsyncの基本的な説明になりますが異なるホスト間でフォルダやファイルの同期を取ることを目的に使われるコマンドになります。コマンドプロンプト上などで、以下のように使うのが基本形です。
rsync (オプション) 同期元/  同期先/ 
同期元配下のディレクトリを同期先配下へ同期する。

オプション(実際に使用したもの)
-a アーカイブモード。(同期元のパーミッション、グループ情報、シンボリックリンクを保持したまま同期)
-v 進行状況(処理中のファイル名)の詳細を表示する
-z データの圧縮。画像以外のデータ移行に使用した
-n dry-runモード(実際には同期しないでテスト的に動作確認のみ行う)
--exclude 特定のディレクトリを除いて同期。同期不要なファイルに使用した
--bwlimit ファイルの転送速度に制限をかける

実際に新環境への移行に際し、使用したコード例

上記の説明を踏まえて、いくつか使用例になります。 試験的にまずは、検証環境でdry-runしてテストを行いました。以下、比較的容量の大きいblogディレクトリを同期した場合になります。

rsync -avn 同期元IP:/mnt/nfs/cspa/image/upload/blog /mnt/nfs/cspa/image/upload

実行結果

root@同期先:/mnt/nfs/cspa/image/upload
sent 1,429,790 bytes received 12,238,281 bytes 321,601.67 bytes/sec
total size is 18,145,045,475 speedup is 1,327.55 (DRY RUN)

途中の結果を記載していませんがdry-run中にblog配下のどういった画像データがコピーされるのかがログに出力されます。コマンド自体の誤りも、dry-runの際に確認できるので便利でした。

検証環境で問題がなかったので、最終的に複数のジョブに分け、Jenkinsでバッチ処理にしました。 以下のように、ディレクトリ単位でグループ化しています。

ssh -l root 本場移行先IP 'rsync -av 移行元IP:/data/export/cspa/image/upload/blog /var/share/cspa/image/upload'
ssh -l root 本場移行先IP 'rsync -av 移行元IP:/data/export/cspa/image/upload/lesson /var/share/cspa/image/upload'
ssh -l root 本場移行先IP 'rsync -av 移行元IP:/data/export/cspa/image/upload/lesson_information /var/share/cspa/image/upload'

この際の反省点として、転送の容量が大きいものには、同期中の負荷軽減のために転送速度の制限オプションを付加すべきでした。(-avの後に--bwlimit=1024と例えば設定すると、1MB/secの転送速度になります。)

画像の移行確認について

ファイル、ディレクトリの使用容量をduコマンドを使って確認します。

root@本場移行先:/mnt/cspa/image/upload# du -h --max-depth 1

実行結果

171G ./blog
87G ./lesson
67G ./lesson_information
808K ./recommend
608M ./ec
(以下、省略)
オプションの説明
-h(--human-readable) 認識しやすい単位に変換して出力
-s(summarize) ディレクトリの合計サイズを出力
--max-depth 集計するディレクトリの階層を指定する

個別にファイルサイズを確認したい場合には、以下で確認できます。

root@本場移行先:/mnt/cspa/image/upload# du -sh blog

実行結果

171G  blog

振り返り

以上になりますが、普段使用したことがなかったコマンドであったため、色々調べたり、聞きながら新しいことを 知れてよい機会でした。ファイルの階層を間違うと事故になるので、やはりdry-runなどで事前の検証が大事だなと 感じました。検証と本番環境では、転送時間に差がある場合があるので、本番環境で早めに小さい単位で行い、トータルの同期時間を見積るのが吉だと思いました。