初めまして、クロス・ヘッド株式会社の新山と申します。
Windowsのファイルサーバーをクラウド環境に移行しようと考えたとき、気になるのは「速度」ですよね。今までLAN環境で利用していたファイルサーバーをクラウドに移行する場合、クラウドに移行すると通信がインターネットを経由することになります。そのため、ファイルを開くのが遅くならないだろうか、リプレイス後にユーザー部門からクレームが起きないだろうかと不安に感じる方もいらっしゃるでしょう。

そのような速度の問題に対する一つの解決策として、ファイルサーバーをクラウドに持ちつつも、頻繁にアクセスするデータのみをローカルに持つ、というファイルサーバーのハイブリット構成による運用が考えられます。AWSではこのような構成に効果的な、「Amazon FSx ファイルゲートウェイ」と呼ばれるサービスがあります。このサービスは、オンプレミス環境からAWSストレージへ接続する際のキャッシュ機能を提供するものです。

今回のコラムでは「FSx for Windows Server」と「Amazon FSx ファイルゲートウェイ」を利用したオンプレミス/クラウドのハイブリット環境で検証を行い、実際に分かったパフォーマンスと落とし穴についてご紹介させて頂きます。検証結果であるパフォーマンスについては、あくまでも当社検証時点での結果となりますので、参考までにご確認ください。

1.FSx for Windows File Serverとは

Amazon FSx for Windows File Server は、AWSが提供されるマネージド型ストレージサービスです。互換性があるという訳ではなく、実際にWindowsワークロードにより提供されているマネージドサービスになるため、ファイルシステムはNTFSが採用されており、VSSによるファイルデータのバージョニングや、ActiveDirectoryでのアクセス権管理が可能となっています。

○Amazon FSx for Windows File Server

2.FSx ファイルゲートウェイとは

Amazon FSx ファイルゲートウェイは、FSxに存在するファイルデータに対するキャッシュ機能を提供するためのサービスです。オンプレミスの施設からクラウド内 Amazon FSx for Windows File Server への低レイテンシーと効率的なアクセスを提供するために、仮想アプライアンスの形式で提供されています。皆様がオンプレミス環境に保有している、VMware ESXiやHyper-V等の仮想基盤の上で動かすことが可能です。ログインの際にAmazon Linux 2 AMIの文字が見えるため、LinuxOSベースのアプライアンスのようです。

○ファイルゲートウェイ

3.検証環境の構成

検証は主に2つの目的を達成するために行いました。
1. キャッシュサービスが介入することでの性能向上
2. ファイルゲートウェイを経由する通信における制約確認

検証構成は下記の通りです。今回は当社検証環境を準備し、実際に物理とクラウドの間で検証してみました。

• 検証サイト
  ・VMホストマシン
  HP ProLiant DL20 Gen9(CPU: 4 CPUs x Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz , メモリ: 32 GB)
  ・VMゲストマシン1（ファイルゲートウェイ）
  CPU: ４vCPU、メモリ: 16GB、ディスク: システムディスク: 80GB, キャッシュディスク: 150GB
  ・VMゲストマシン2（クライアント）
  OS: Windows Server 2022、CPU: 2vCPU、メモリ: 12 GB
  ・インターネット回線
  フレッツ光ネクストファミリー ※回線速度計測サイトの結果では、下り90Mbps、上り80Mbps程度。

• AWS Cloud
  ・FSx for Windows File Server
  ストレージタイプ：HDD、ハードディスク容量：2TB、スループットキャパシティ 32MB/秒

4.ファイルアクセス速度

確認する内容としては、ファイルのアップロードとダウンロードの速さに違いが出るか、という点です。以下のパターンについて検証を行いました。

• ファイルサイズパターン：1MB、100MB、500MBの3種類のExcelファイルデータ。
• アクセスパターン：アップロード、ダウンロード、ファイルオープンの3つの時間。ファイルオープンは、FSx上のあるExcelファイルを開き終わるまでの時間です。

ファイル検証結果は下表の通りです。

左側緑色の列がFSxへの直接接続、右側青色の列がファイルゲートウェイ経由です。
結論としてはファイルゲートウェイが存在する方が、FSxへのアクセスは高速化することができました。ただし、ファイルサイズが小さい状態では、それほど大きな影響は見受けられません。そのため、取り扱うデータサイズが比較的大きい場合に、ファイルゲートウェイを利用したハイブリット構成が効果的と言えそうです。また、ファイルゲートウェイ経由の場合でも、1回目の通信においてはFSxへ直接接続した場合とほとんど変わらない結果となっています。こちらは、最初の通信ではキャッシュされる前の状態のため、差が出ていないようです。2回目からはキャッシュ機能により高速アクセスが可能となっています。

5.ファイルゲートウェイの落とし穴

続いては、検証の際に判明した制約事項、落とし穴についての紹介です。色々と確認できたことはありましたが、特に大きいと感じた要素を3つご紹介させて頂きます。

性能要件

ファイルゲートウェイアプライアンスは仮想プロセッサ4つ、予約済メモリ16GB、ハードディスク領域80GiBを必要とします。本番稼働のシステム環境ではそこまで問題にならないかもしれませんが、小さくはない性能要件を求めているとは思います。
○ファイルゲートウェイのセットアップ要件

意外と高い

利用料金がファイルゲートウェイの稼働時間に対して課金されますが、これが0.69USD/時間かかります。月730時間稼働することを想定すると、503.70 USDです。1USD=140円計算にすると、毎月約70,000円強かかる計算になります。これだけの支出となると、ファイルゲートウェイを入れた方が良いのか、インターネット回線を見直すべきか、十分に検討する必要があると考えます。

ファイル名の文字数に制限がある

ある意味、ファイルゲートウェイを介在させることによる影響として、Windows環境を利用する際に最も影響する要素ではないかと思います。当社でも検証したところ、2byte文字（日本語等）が85文字前後を超えて含まれるファイルは、ファイルゲートウェイ経由では取り扱いができないことが確認できています。これは恐らく、ファイルゲートウェイアプライアンスのOSがLinuxベースであることに起因していると推測されています。Linuxの場合はファイルシステムで採用されている文字コードがUTF-8、Windowsの場合はShift_JISを採用していることから、この2つの文字コードの間で日本語の取り扱いが異なることが原因で生じていると考えられます。そのため、Windowsの世界だけでデータを取り扱う場合には生じない、ファイル名の文字数という弊害が生じてしまう訳です。

※あくまでも当社検証の結果から導き出した仮説となります。

6.落とし穴の回避策は事前のアセスメント

今まで見てきた3つの落とし穴は、環境の事前調査、いわゆるアセスメントにより軽減・回避が可能と考えられます。
アプライアンスの性能を確保するためには、所有しているハードウェアに十分な余裕があるか、ハードウェアの耐用年数は未だ残されているか、等。ファイル名の長さについては、ファイルサーバー調査用のツール等を活用して調査することで確認することができます。また、ほとんどアクセスされていないデータをアーカイブ先に移行することや、重複ファイルを排除することで、AWS環境におけるファイルサーバーのストレージ容量を小さくすることができるかもしれません。アセスメントはコスト最適化にも役立ちます。事前のアセスメントは、ファイルサーバーをクラウドに移行する際に是非取り組みたいステップの一つです。

7.まとめ

如何でしたでしょうか。ファイルゲートウェイの効果とデメリットについて、いくつかピックアップしてご紹介させて頂きました。ファイルゲートウェイを活用することで、ファイルへのアクセスパフォーマンスは向上します。しかし、仮想アプライアンスが間に入ることのデメリットも存在することに気を付けなければなりません。
当社では既存ファイルサーバーのアセスメントから、ファイルデータの移行、ファイルサーバーの運用までを総合支援するサービス「デジタル・ワゴン for ファイルサーバー」を提供しております。当社のファイルサーバーはどこに移行したらよいだろうか、本当に移行できるのだろうかとお悩みの方は、是非お問合せください。

クロス・ヘッド関連サービス
　

※Cloud Compassはクロス・ヘッド㈱が運営するクラウドサービスです。