この記事はトラストバンクAdventCalendarの記事になります。
パブリテック事業部の大場です。
今期実施したデータ移行のやらかし記事です。
生温かい目でご覧ください。
1. 突然の危機的状況
2月に大きなリリースを実施し落ち着く間もなく、予定していたNetAppへのデータ移行作業に着手すると、すぐに非情な現実を見せつけられました…。
当初は「事前にrsyncで同期しておいて、当日に差分をコピーすれば問題ないよね」というような、なんとも甘い移行を計画している程度でした。
しかし、数億ファイル、数十TBというデータをそう簡単に移行できるわけがありません。
実際に試算したところ、rsyncに20日以上かかることが判明しました。
そしてさらに悪いことに、既存のストレージの空き容量が危機的状況で、全く時間的猶予がありませんでした。この点については、一時は使用率95%という状況になりましたが、不要なファイルを削除したり、仮想マシンを移動させたり、なんとか移行完了まで80%台をキープすることができました。
この状況から始まったデータ移行プロジェクトの舞台裏をお話しします。
2. 検証: XCPとmsrsync
膨大なデータを移行するツールを選定するために、NetApp公式の「XCP」とオープンソースの「msrsync」を検証しました。
a. XCP
まず着手したのは、NetApp公式ツール「XCP」の検証です。これは、大規模データ移行のために設計された高性能ツールで、公式のサポートも期待できます。初期同期では驚くべき速度を発揮し、期待を抱きました。
しかし、実際に進めてみると
-
キャッシュ問題: 小さいデータで検証をしていた際、非常に高速でとても期待しました。しかし、データを増やして検証すると一定のところから急激に速度が落ちることがわかりました。データ量が増えるとデータ移行が進むにつれキャッシュが溢れ、速度が徐々に低下するようでした。
-
小さいファイルのパフォーマンス: XCPは大きなファイルの移行には非常に優れていますが、小さなファイルが大量にある場合には速度が低下する傾向が見られました。
これにより、XCPは「大容量の一括データ移行」には有効そうですが、「細かいデータのコピー」には適さないという結果になりました。今回のデータは、まさにサイズの小さい大量のファイルのため、「XCP」は採用できませんでした。
b. msrsync
次に、rsyncを並列処理することが可能な「msrsync」を試しました。
- パフォーマンス向上と限界: 並列処理でコピー可能なため、小さなファイル群の移行速度が劇的に向上しました。サーバリソースをあげ、並列数を増やしましたが一定のところで性能は頭打ちになりました。
- 異常な動作: ネットワーク負荷が高まりプロセスが停止したり、サーバがハングしたりすることもありました。
msrsyncの並列処理能力は有効でしたが、並列数には限界がありどうやっても移行には2.5日かかる結果となりました。
3. 移行方法の決定
検証の結果、msrsyncを利用せざるを得ない状況でしたが、約2.5日間の停止を伴う移行は現実的ではありません。さらに、msrsyncが必ずしも安定動作するとは限らず、一度で成功する保証もありませんでした。
そこで、ユーザ影響を最小限に抑えるため苦肉の策として「データが完全に同期されていない状態でのサービス再開」を選択しました。平日に比べ利用者が少ないゴールデンウィーク(GW)を利用し、以下の計画で実施しました。
- GW前の平日分までをmsrsyncでコピー
- 切り替え後、GW中のデータは後から同期
一部のデータが参照できない状態でサービス再開することになってしまいましたが、なんとか運用停止時間を最小限に移行を完了しました。
4. 結論: 振り返りと教訓
膨大なデータ量を限られた時間で移行するという課題は非常にチャレンジングでしたが、同様の移行を検討する方には、次の点を強くお勧めします。
データ移行を甘く見てはいけない、早い段階でちゃんとした計画を!!
当たり前ですね…。
苦労の連続でしたが、チームも自分自身も多くの教訓を得ました。
5.さいごに
プロダクト開発・技術的課題解決などやりたいことがたくさんあります。 カジュアル面談歓迎です!少しでも興味を持っていただけたら是非ご連絡ください!
https://www.wantedly.com/companies/trustbank/projects