社内ファイルサーバーのクラウド移行　オンプレからAWS FSxへのマイグレーション事例

はじめに

当社の社内システム部門では長年、社内の開発環境やビジネスドキュメントの格納先としてオンプレミス（Windows 2012）のファイルサーバーと、外部からの接続や、自動バックアップ先としてクラウド(azure上のWindowsサーバー）を併用（ミラーリング）して運用してきました。 　

コロナ禍においてテレワーク/在宅勤務が全盛となり定着してきたこのところですが、当社にとってテレワーク中心の業務にシフトすること自体は、もともと在宅勤務（VPN）の仕組みがあったものを、利用者層やスペックを拡張することで対応していたこともあり、そのまま、azure上の仮想サーバーまたは東京本社設置のオンプレミスサーバーに自宅や他のオフィスからセキュアなVPNで接続するやり方で実現してきました。

一方で、当社のマーケティング／セールス部門やクラウドやマイグレーションビジネスを主体とする開発部門としては「クラウドマイグレーション」の一環としてAWSへの移行と活用を核とした「クラウドテレワークソリューション」を展開していることもあり、今回、社内システム部門だけでなく、AWSアーキテクトの部門も協力して、azure＋オンプレのハイブリッド環境からAWS環境への移行を行うこととなりました。

単にEC2による仮想サーバーを構築して移行するだけでは、同じパブリッククラウドであるazure環境と大きな違いがなくコスト的にもメリットが乏しいので、この機会に社内業務に利用しているファイルサーバーを、AWSが提供するFSxサービスに置き換えることを目的とした「クラウド移行プロジェクト」（社内システム部門（管理部門）とAWSアーキテクト部門が連携した社内プロジェクト）を立ち上げました。 

社内システム部門としてはWindowsおよびazure主体での運用でありAWSの経験が乏しい中、AWSアーキテクト部門のフォローを受けながら試行錯誤して構築した過程ではありますが、まだ国内にはFSxに関する情報は少ない状況なので、これからオンプレミスやクラウド（EC2などの仮想サーバー）からファイルサーバー機能をFSxに移行されたい方の参考になればと記事にしました。

前提と移行要件

移行前の環境

当社のオフィス（本社サーバールーム）に設置のオンプレミスWindowsサーバー群が主体で、バックアップとして夜間バッチで相互同期処理を行うことで、Azure+オンプレミスのハイブリッド環境で運用をしていました。

コロナ禍で顕在化してきた課題

コロナ初期において、テレワーク（在宅勤務者）の比率が低い頃は、出社して業務（オンサイト業務）の社員が多く、特に大きな問題は生じませんでした。その後、恒常的な在宅勤務が普及しテレワーク勤務比率が高くなるにつれて（当社の場合は７０％以上がテレワーク）、ネットワークなどの負荷が高くなり、Azure環境と社内ネットワークの通信が遅くなるケースが見受けられるようになりました。

当時の社内システムの現況と課題（ネットワーク、サーバー）

インフラとしての課題　

当社の社内用のサーバー群の保守ポリシーとしては、当社サーバールームに設置されたオンプレミスの運用サーバー群（当社は開発ベンダーなので、ドキュメント格納用のファイルサーバーだけでなくDBサーバー、webサーバー、開発環境をはじめ各種のサーバーがあります）とネットワーク機器については、各メーカーの保守契約が終了した時点で交換することを原則としています。

プロジェクト開始前としては、現在運用中のファイルサーバーが近々ハードウェア保守が切れること、および近い将来にWindows Server 2012R2もOSサポートが終了となることから、更新が遅かれ早かれ必要となる状況でした。

運用面の課題　

また、長い間、社内システム部門（管理部門の１部署）で社内のインフラ環境を保守してきた経緯もあり、下記の運用面の課題がありました。

• OSのパッチ適用などの臨時作業が多く、作業が属人化していた（どこの企業でも存在するケースですが、ベンダーである当社でもそうでした）
• 業務時間外でのパッチ適用が基本となるため、必然的に、土日休日出勤や夜間作業での対応が当たり前になっていた
• 接続しているストレージメディアに残量の余裕がなく、ファイル容量がどんどん圧迫、必要に応じて不使用の大容量ファイルを都度削除する運用となっていた

移行計画

オンプレ主体運用からクラウド主体運用への切替と、AWS FSxの選定まで

当社におけるサーバー移行などの社内インフラに関するイベントは準備、移行だけでなく各部門との調整にかなりの手間、労力、時間がかかっていました。そのため、今回の「クラウド主体への切り替え」にあたっては、このような運用上の課題やコスト面の課題を解決しつつ移行する、ということがプロジェクトに求められました。

• 「クラウド主体への切り替え」により将来的に社内調整に関わる工数をできるだけ削減することを考慮
• BCPの観点から、複数拠点にオンプレミスのサーバーを置いて相互バックアップするような運用をしてきたがクラウド上での一元管理を実現
• 仮想サーバー（EC2等）としてファイルサーバーをクラウド上で構築することは容易であるが、この場合アップデートなどのOSそのものの保守手間が発生する
• この手間を削減するためファイルサービスの適用を検討（この時点では、Azureファイルサービスが候補）
• AWSのFSxサービスが安価になったことにより、AWSも移行先の候補に。
• （からくりとしては、SSDのサービスだけでなくHDDストレージをサポートしたことで、大容量ストレージ契約時の課金コストパフォーマンスが劇的に高くなった）
• 移行計画においては、ランニングコスト（クラウド課金）が高騰しないように、当社の得意ソリューションを活用した運用設計の見直しを実施
• 更新が発生せず（参照のみ）、かつ利用頻度の著しく低い「過去の大容量ファイル：については、新たにオンプレミスサーバーのHDDに保存することとしました。

★クラウド移行先を選定する際に用いた比較表　

インフラ（利用料としての）ランニングコストや、その運用に携わる人員の人件費が主となる管理コストを抑えるには、オンプレミス主体運用からクラウド主体へ切り替えることにより実現できます。更にサービス利用料の観点からは、FSxのストレージサービスを安価なHDDを採用することで劇的なコスト削減につながります。

障害リスク対策（BCP観点）

• AWSにおいても障害が全く無いわけではありません。ただ、万一障害が発生するような状況においても極力利用するユーザに影響を与えないために、Multi-AZ構成を選択しました。
• 今回のプロジェクトのケースでは利用ユーザは当社の社員、派遣社員、および社内サーバーに接続するパートナー企業の技術者さんたちになります。
• Multi-AZ構成は、ホットスタンバイの待機系が本番系とは別区画で稼働するものであり、そのまま障害に強い特徴があります。
• また、従来はバッチ処理によるバックアップ運用でしたが、今回はバックアップ機能（FSx標準機能）のを活用することによるデイリーバックアップの実装を計画しました。
• コストはともかくオペレーションに関しては、容量枯渇時の対応がAWS管理画面から容易になる（従来はHDD追加購入、増設などの手間）ことも障害時の即時対応には利点になります。

移行フェーズ

移行時のトラブル

FSx移行の実現には現オンプレミスサーバーのストレージ上にある各部門や個人の大量のフォルダ・ファイルを移行する必要がありました。windowsバッチコマンドを作成して移行を計画・実行することとしました。単なるファイル・フォルダコピーではなく、当然のことながら部門単位、役職単位でのActive Directoryで設定した各種のロールに応じたファイル権限も再現する必要がありました。

ところが、ここで問題が発生します。物事は計画通りに進まないのが世の常で、高機能なwindowsコピーコマンドであるrobocopyの失敗がazure→FSxにおいて何度も発生しました。従来のcopyコマンドだと正常にコピーが可能なのですが、これではADのアクセス権限の同時移行ができないことになってしまいます。 

原因追求と対策

調査の結果、FSxのサービス自体は、一般的なドメイン（AD）配下のコンピューターの扱いではないことが判明しました。解決策としては、コピー元ファイルサーバーの全フォルダ・ファイルに対して、明示的にドメイン管理者のフルコントロール権限を一時的に付与し、ドメイン管理者権限で実行することでエラーは除去できました。ここはAWSソリューションベンダーとしての基本的な知見があったこともあり、無事に対応ができました。

運用フェーズ

移行完了後のトラブル

当社は国内に事業所が３拠点（東京、茨城、大阪）あり、テレワーク（個人宅）からのVPN接続に加えて、AWS環境（ならびにazure環境）へは３拠点からそれぞれ拠点間VPNを構成しています。

今回は、東京-AWS、茨城-AWS、大阪-AWS、そして従来のAzure-AWSの合計４つのVPNトンネルを新たに構築しました。（その他事業拠点間トンネルも従来からあり）

こうして移行が完了した後、実運用に入ったところ、大阪拠点-AWSのトンネル経由でアクセスするとタイムアウトが頻発する事態が発生しました。AWSのサポートに問い合わせたり事例確認をしたりと調査を進めましたが、ネットワーク環境が原因のこともあり難航しました。

一時はFSxの利用をいったん中断し、元の環境に戻すことも頭をよぎりましたが、他のVPNルーターでVPNトンネルを改めて設定しなおしたところ、速度が向上しました。根本的な解決とはなっていませんが、直面したトラブルについてはいったん解消しました。

対策ミスなど、反省点

• 大阪拠点からの速度改善策の一環として、スループットの速度アップを実施しました。当初の計画時の想定よりもかなり早い速度に変更して様子を見てみましたが、大きな速度改善にはつながりませんでした。
• 必要以上にスループットが大きい状態のAWSの設定のままだと膨大な課金が発生することもありますので、設定を元に戻しましたが、その過程においてFSxファイルへのアクセスができなくなるという障害を発生させてしまいました。５−１０分程度で自動復旧したとはいえ、業務時間内に発生させたのは社内システム部門としては大いなる反省点でした。

まとめ

導入後のメリットとまとめ

• プロジェクト開始当初、社内システム部門としては長年AzureとWindowsオンプレミスサーバの構成での運用を続けて来たこともあり、AWS関連の経験は乏しい状況でした。
• AWSアーキテクト部門との連携により、なんとか無事にFSxの導入が完了しました。
• この結果、社内システム部門としては運用上の長年の大きな課題でもあった「属人化した各種パッチの適用や保守メンテ作業」から解放されました。
• 結果として、社内システム部門の保守メンテナンスに関わる作業時間がほぼゼロになりました。
• 今まで保守作業にあてていた膨大な工数を、今後の戦略的ITなど、生産的な未来に向けた取り組みに活かすことが可能となりました。
• また、通信速度においては、実効速度も実際の利用者の体感速度も大きく向上しました。
• 利用者（当社の社員）の評価も上々であり、個々の作業効率が向上しました。

• 今後のMicrosoftサーバOSのサポート終了を睨み、さらにサーバ移行タスクが増える見通しのなか、AWS FSxは移行先の強力な選択肢となりうることがわかりました。
• （数年後には、Windows Server 2012及びWindows Server 2012 R2のサポートが終了します）
• ただし、移行前にきちんと課題や状況を整理し、運用設計することが非常に大切と実感しました。
• クラウド移行後の利用料が高騰しないための工夫も、検討しておく必要があります。
• 「全データを持って行かない（取捨選択）」ことも大きく運用コスト（利用料）削減につながります。
• たとえば、クラウド上のファイルサーバーに不要なもの（利用頻度の低い参照だけの過去データなど）はオンプレミスの大容量ストレージに保管することで容量節約が可能です。
• なお、当社は大きな伝送量ではないこともありVPNで構築しましたが、もっと大規模なファイル伝送をともなう業務に適用する場合はdirectConnectが必要になります。
• 運用開始後は、利用料が高騰しないための仕組みづくりもあわせて必要です（当社では利用者への啓蒙やチェック機能を実装しています）