概要
- 中小企業の情シスが、オンプレのNAS数台にある、数百TBの社外秘データを全てクラウドストレージサービスに移行しました。2021～22年の作業内容について、2023年に記します。
- 移行先はAWS S3とBoxです。S3に業務データ、Boxにバックオフィスのファイルたちを置いています。
- 移行後も引き続きオンプレNASの運用は続いています（後述します）
背景
納品物として動画・音声を大量に扱う中小企業の情シス兼プログラマです。
データというのは形式が様々で、バックオフィスのExcelやPDF、SEのパワポやTXTファイルだけでなく、むしろ実際に収録室で収集したデータである動画ファイル・音声ファイルがかなり容量を食っています。
近年は高解像度で動画を撮影することもあり、1日で数百GB、NASの容量が埋まるということも珍しくありません。
ということで、オンプレNAS複数台で数百TBのデータを運用していたのですが、2020年初頭からのあれやこれやで2020年4月から全社テレワーク。収録チームだけは会社に出社することになりましたが、テレワークが始まって約3年経過した2023年3月現在、出社率は10～20%といったところでしょうか。特にWeb開発部門の出社率の低さはすさまじく、年に数える程度、という形になっています。
当初はテレワークしている自宅から、YAMAHA RTX1210で構築したVPN経由で、（会社内NAS）→RTX1210→（インターネット回線・VPN）→自宅PC、という感じでデータを見に行っていました。
ただ、だんだんとテレワークが基本の勤務スタイルという形になっていくと、むしろクラウドメインで、オンプレNASはあくまでもワンシーズンだけの置き場、という考え方になっていきました。
また、NASの容量問題もありました。
先述の通り、1日で数百GB、それこそ1か月で数十TBの容量を消費するということもザラです。RAID5 or RAID6でNASを組んで、なおかつオンプレで別のNASにバックアップをつなげて、UPSもつなげて……とやっているといくらあってもお金が足りません。
それに、オンプレNASというのは、弊社のデータ容量だと1台100万は軽く超えていきますし、欲しいときに「今すぐ」欲しいだけ容量を増やしたい！というニーズには答えられません。中小企業なので、情シスは常に人もお金も足りていません。
ということで、2019年以前から使用していたAmazon S3、および新規に契約するBox.comのサービスを利用することになったのでした。
全部Boxでいけるか？→ダメでした
最初はNASの全てのデータをBoxに移行する、という話で進めていました。BoxのプランはBusiness Plusなので、現在は1ファイルのアップロードサイズ上限は15GBになりましたが、移行を検討していた当時はまだ1ファイル5GBでした。
そのため、さっそく壁にぶつかってしまいます。
音声データはいいのですが、動画データが明らかにこの上限に引っかかってしまいます。分割すればよいのでしょうが、それをいちいちやる手間が面倒でした。またできるだけオリジナルファイルは分割せず、そのまま残しておきたい、という要望が業務部門からありました。ということですべてBoxはNGです。
そもそも、Boxは明らかにアップロードの帯域を絞っているところがあり、社内インターネット回線を上り・下りともに速度向上させても、アップロード速度は変わりませんでした。Box APIを使っても同様でした。
ということで、Boxはバックオフィスの書類群の置き場、ということになりました。Box Driveを使えばそれこそ外付けHDDのように使えますしね。たまにラグが発生して同じファイルを複数人で開いていると面倒なことになりますが。
業務データは結局Amazon S3に
BoxがNGなので、業務データのバックアップはすべてAmazon S3に移行となりました。ただし、先述の通りNASを全廃することはできません。
結局、S3へのデータアップを非エンジニアができない、という問題が残っていますし、収録したデータをいろいろプログラムで処理することを考えると、一時的な置き場としてのNASはやはり不可欠です。都度都度インターネット回線の帯域を圧迫するのも、回線の無駄遣いですから。
AWSの方に相談して、Amazon FSx for Windows File Serverというのがありますよ、とアドバイスを頂戴したのですが、弊社の場合計算してみるとこれだけで月20万以上飛んでいく計算になります。
他にも、専用線引いたらいいんじゃないですか？というアドバイスを頂きました。テレビ東京さんの事例とセットです。
テレビ東京さんはデータ量が13PB、年600TBずつ増えるというのが驚きですが、弊社はこれよりずっとず〜〜〜っと小さい会社なのに、年100TBくらい増えたことがありました。ただ、こちらの専用線を使ったソリューションも、コスト計算をしたら、年間数百万から、ということになってしまい、お見送りです。
AWS Snowファミリーも存在は知っていましたが、定期的に転送することを考えると、こちらも条件に合わずです。
また、DELL PowerScale（旧EMC Isilon）という、「使うデータはSSDの上の方に、使わないやつはHDDの下の方に、すべてよしなにやってくれるやつ」を営業の方からご提案されたのですが、これも弊社の場合導入に最低2000万はかかります。中小企業でストレージに2000万はちょっと無理ではないか、ということでこちらもお流れに。
結局、オンプレNASとS3とBox.comでなんとかやりくりする、という形になりました。
データの流れ
2023年3月現在、大まかに書くと、下記のパターンになります。
収録室でデータが発生する（収録機器のSDカードなど）
→SDカードをPCに挿して、オンプレNASに転送
→オンプレNASは、別のオンプレNASにバックアップをかけている
→また、Synology NASのCloud Syncという機能で、夜間にオンプレNASからAmazon S3にデータがコピーされる。これは、オンプレNAS→S3の一方向のみのsync。
→Amazon S3は、アップロードされてから1日経つと、ストレージクラスがStandard（標準）から、Glacier Instant Retrievalに変更になる。これで、コストが5分の1になる（2023年3月現在）。
→オンプレNASのデータは、閑散期になったら人手で削除。S3上にデータは毎日差分を転送しているので、削除するだけでよい。
また、将来的には、以下のパターンになることを期待しています。
- オンプレNASの人手削除をやめて、アップロードして一定の時間（例えば、半年とか）が経過したら、自動で削除するshell scriptを書いて、cronで設定する。
- Amazon S3のライフサイクルルールも、ストレージクラスの変更だけではなく、一定期間（例えば、5年とか）が経過したら、自動で削除するものを追加する。
これで、だいぶ情シスの人手を排除することができます。
問題は、弊社の場合はこのデータというのは社外秘の資産なので、どの期間取っておくのか？という合意形成を役員含めて行っていくことです。
ただ、先述の通り既にデータが数百TBに達しており、全てをAmazon S3 Glacier Instant Retrievalにしたところで、毎月数十万円が飛んでいきます。そのため、経営判断を行う役員にレクチャーが必要です。
S3へのデータ移行
ここからは実務的な話です。
S3への転送は、AWS CLIをNASと同一ネットワークにあるUbuntuに入れて、そこからaws s3 syncコマンドで同期していきました。
aws s3 cpというコマンドもあり、一見そちらが良さそうに見えますが、データ量が多いと途中でコケることがあるんですね。
- s3 cp→単にデータをそっくりコピーする。なので、例えば100ファイル転送中に80ファイル成功して途中で転送がコケても、また新たに100ファイル転送してしまう。
- s3 sync→syncの名の通り同期を試みる。なので、100ファイル中80ファイル成功して途中で転送してコケると、差分の20ファイルだけ転送してくれる。
全データはそれこそ数百TBあったので、1フォルダ（数百GB単位）ごとに転送を行いました。aws s3コマンドには--exact-timestampsというオプションがあり、タイムスタンプを見て違うものは都度転送してくれます。。そのため、例えばローカルの/Users/username/workspace/target/というフォルダを中身ごと、s3のhogehogetargetというバケットに転送する場合は、
aws s3 sync /Users/username/workspace/target/ s3://hogehogetarget --exact-timestamps
と打てばOKです。
--deleteオプションというのもあり、これは同期先にはあるが同期元にはないファイルを削除してくれるコマンドです。こちらは、使ったり使わなかったりなので、省略します。
帯域幅設定も忘れずに
AWS CLIの設定値がデフォルトのままだと、せっかく立派なインターネット回線を契約していてももったいないことになってしまいます。
なので、こちらの設定もいじっておきましょう。
cf. AWS CLI S3 Configurationを試したら想定以上にaws s3 syncが速くなった話
nohupを使って24時間働いてもらう
今回はサーバ室内のUbuntuで全て転送しましたが、先述の通り私はテレワークをしており、このUbuntuには社内ネットワークにVPN接続後、SSH接続でログインしていました。
すると、普通にコマンドを打つと、このSSH接続が切れるとコマンド自体も終了してしまうんですね。
毎日これのために会社に行くのもアホらしいですから、nohupコマンドを使いました。これで、SSH接続が切れてログアウトしてしまっても、最後まで処理をしてくれるのです。
つまり、最終的なコマンドはこうなります。
nohup aws s3 sync /Users/username/workspace/target/ s3://hogehogetarget --exact-timestamps &
野良NASと野良ストレージを絶滅させる
数週間かかって、数百TBのデータをオンプレNASからS3に転送しました。
これらと並行して、野良NASと野良ストレージを社内から一層しました。
野良NAS
「容量が足りないから来週までに100TB頼む」みたいな話で調達された、スタンドアローンのNASが数台あったので、業務用の社内ネットワークとは別のネットワークを立てて、そちらにぶら下げることにしました。インターネットにつながっているので、こちらも会社に行かなくても中身がVPN接続で見られます。
放置されていたと見えて、NAS内は数年前のデータが大量に残っていたので、これらも全てSynology Cloud Syncを使ってS3行きとなりました。
野良ストレージ
社内セキュリティ指針でUSBメモリを業務で使用することは、サーバールーム内などのごく限られた条件を除いて禁じられているのですが、それでも収録用のカメラに入れるSDカードや、データを収録機器から吸い出してNASに送るための外付けSSD（インターネット回線を引けない部屋がある）などが大量にありました。調査をする中で、台帳にない（！）ストレージがたくさん見つかりました。
もちろん、台帳に追記し、古いものについては破壊処分しました。インシデントの元なので、できればこういった持ち運びできる記憶媒体自体業務から排除したいのですが、これは難しそうですね・・・。
最後に、ストレージについては管理台帳だけではなく、購入・分配・廃棄までを担う人員を選び、その方にストレージ当番ということでご担当いただくことになりました。
ノウハウをWeb上のドキュメントに書いておくのは当たり前なのですが、実際に毎日出社して物理的な実体をすぐ見られる人員というのを配置するのが重要です。
参考資料
- ぐるなびさんのぐるなびにあった２億ファイルをAWSにデータ移行しましたという記事は大変参考になりました。こちらは20TBですが、ファイル数が2億（！！！）とのことです。弊社の場合は1ファイル数十GBという動画ファイルがそれなりにあったので、ファイル数でいうと全然これよりも少ないです。