この記事はリクルート ICT統括室 Advent Calendar 2023 24日目の記事です。

はじめに

こんにちは、ICT統括室の金光 大貴です。
今年度のお仕事では、クラウドファイルサーバの構築及び移行を担当しておりました。
この記事では、「オンプレのファイルサーバから、SharePoint・Google Driveといったクラウドストレージへの移行PJ」「ローコードアプリによるオートメーション化で力技コミュニケーションからの脱却！～全社ファイルサーバのクラウド移行～」の裏でクラウドファイルサーバ構築/移行にあたって、どのような困り事があったのかお話ししたいと思います。

すでにAWS社にて修正された箇所もありますが、クラウド移行の参考としていただければ幸いです。

案件の経緯

オンプレファイルサーバが2024年2月にEOSLとなるにあたり、移行先として3つの選択肢がありました。
①SharePoint
②GoogleDrive
③Amazon FSx for NetApp ONTAP(以降　FSx for ONTAP)

その際、過去に私がオンプレファイルサーバのエンハンスメントや運用を担当していたため、FSx for ONTAPの構築及び移行を担当することになりました。

オンプレファイルサーバの規模感

オンプレファイルサーバは日々容量が増加し、移行前には膨大な規模となっていました。

容量：約1.1PB
共有ディスク：約2500個
ファイル数：約10億

更には、各共有ディスク毎にアクセス権限が付与されているという環境でした。

FSx for ONTAPとの出会い

PoC実施時はFSx for ONTAPがリリースされておらず、各種クラウドストレージの機能確認及び検証を実施していました。重複排除圧縮機能が無いものや、払い出した容量分のコストが発生するものなどがあり、どれも決め手がない状態でした。

そんな時AWSから、重複排除圧縮機能があり、容量は自動拡張、利用した分のみコストが発生するという、希望通りのサービスFSx for ONTAPがリリースされたため、直ちに検証を行いました。

問題発生①（NetBIOS）

FSx for ONTAPの検証を実施したところ、NetBIOS名に”#”が入っていると、ドメイン参加出来ないことが分かりました。※すでに本内容は修正済み。

当社ではNetBIOS名に”#”が入っている環境があり、一部環境でドメイン参加出来ず、構築が出来ない事象が発生しました。

関係各社と調整を行ったところ、OSの改修を実施いただけることとなり、FSx for ONTAPで進める方針となりました。

問題発生②（NetBIOS修正リリース切り戻し、リリース遅れ）

順調に検討や検証は進んでいたものの、問題解消に時間がかかり、いざリリースとなってもその数時間後に差し戻しとなり、更に数カ月経ってようやく正式リリースとなりました。

正式リリースされたタイミングでは、プロジェクトとしては当初の予定より4ヶ月程度遅れていました。

大幅に遅延してしまいましたが、検証の中ですでにコマンドや手順を準備していたため、正式リリースから1週間程度で構築を行うことが出来、辛うじてスケジュールに間に合わせることが出来ました。

急遽1.1PBの移行が必要に

当初8ヶ月程度時間をかけ移行を行う予定でしたが、諸事情により1.5ヶ月で約1.1PB移行する必要があり、急遽検証を行いました。

オンプレファイルサーバは非NetApp製品であったため、SnapMirrorは利用できず、オンプレ上にWindowsサーバを複数台構築し、Robocopyにてデータ転送する方法を取りました。

その際、多くの問題が発生しました。その中から大きな問題とその解決策をご紹介します。

問題：オンプレから、FSx for ONTAPへの転送速度を上げすぎると、Primary層が枯渇し書き込みができなくなる事象が発生しました。
FSx for ONTAPへ書き込まれた際、はじめにPrimary層へデータ格納され、その後Capacity層へデータが移動されます。
オンプレからPrimary層への書き込み速度より、Primary層からCapacity層へのデータ転送速度が遅かったため、Primary層が枯渇する事象が発生しました。

解決策：色々な観点で移行検証を行い、FSx for ONTAPのCPU使用率や利用状況によりPrimary層からCapacity層へのデータ転送速度が変化することが分かりました。なお、データ転送を止めるとPrimary層からCapacity層への転送速度は1GB/s程度となる事が分かりました。
上記結果から、移行方法として、2つの方法を検討しました。

①Primary層が枯渇しないよう、調整しながら転送を行う。
②転送速度を上げ、定期的に転送を停止する時間を設ける。

①では、目標期間の1.5ヶ月で転送を完了することが出来ない事が分かったため、②の方法を採用しました。転送期間が長期間になるため、10数時間転送を行い、数時間転送を停止するサイクルを自動的に実施できるようスクリプトを作成しました。
※本結果は検証時のものであり、必ずしも今後も同じ結果となるわけではありません。

結果、予定通り1.5ヶ月で移行を完了することが出来ました。

その後（1.1PBの削除と本番移行）

移行した1.1PBは暫定的なものだったため削除を行いました。（1週間待っても消えない時は不安になりましたが問題なく削除できました）
その後、予定通り2023年4月〜12月にかけて各利用者と調整の上で本番移行を実施しました。

本番移行は1.1PB転送時のナレッジもあり、特に大きなトラブルはなく移行することが出来ました。最終的には約700TB程度のデータをFSx for ONTAPへ移行しました。

オンプレからクラウドへの移行効果

実際にオンプレからクラウドへ移行、運用する中で感じた良かったこと/課題は以下となります。

• 良かったこと

クラウド移行の効果は大きく、日々のディスク故障対応や、適時実施しているバージョンアップ作業が無くなり”本当に実施したいこと”や”実施しなければならないこと”に注力することが可能となりました。
FSx for ONTAPは必要な量を必要な時に作成することが出来、利用分のみのコストが発生するため、急遽発生した1.1PBの移行も柔軟に対応することができたと思います。

• 課題

Managedサービスのため、入力規制されているコマンドが多々ありました。より詳細に調査するためにはAWSへ調査依頼をする必要があり、調査に時間がかかるケースもありました。
対応策としては、AWSへの入力規制コマンド緩和依頼や、我々が確認できた内容やコマンドを伝え、どこまで調査が行えたのか、切り分け結果を明確に伝え円滑に調査を進められるよう工夫を行いました。
また、詳細は割愛しますが、Managedサービスが故のトラブルもありました。

おわりに

FSx for ONTAP構築、データ移行時に発生した問題点や解決策の一部を紹介させて頂きました。

FSx for ONTAPリリース直後からサービスを利用したため、トラブルも多かったですが、良い経験ができたと思います。あまり例の無い大規模移行だったため、その他課題や解決策などについては、またどこか別の機会で紹介させてもらえればと思います。

リクルート ICT統括室 Advent Calendar 2023では、リクルートの社内ICTに関する記事を投稿していく予定です。もし興味があれば、ぜひ他の記事もあわせてご参照ください。