

新規のお客様へのAmazon FSx ファイルゲートウェイの提供は終了しました。FSx ファイルゲートウェイの既存のお客様は、引き続き通常どおりサービスを使用できます。FSx ファイルゲートウェイに似た機能については、[このブログ記事](https://aws.amazon.com/blogs/storage/switch-your-file-share-access-from-amazon-fsx-file-gateway-to-amazon-fsx-for-windows-file-server/)を参照してください。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# パフォーマンスと最適化
<a name="Performance"></a>

このセクションでは、ファイルゲートウェイのパフォーマンスを最適化するためのガイダンスとベストプラクティスについて説明します。

**Topics**
+ [FSx ファイルゲートウェイの基本的なパフォーマンスガイダンス](#performance-fgw)
+ [ゲートウェイのパフォーマンスの最適化](#Optimizing-common)
+ [S3 ファイルゲートウェイスループットの最大化](Performance-Throughput.md)
+ [SQL Server データベースバックアップ用の S3 ファイルゲートウェイの最適化](SQL-Backup-Best-Practices.md)

## FSx ファイルゲートウェイの基本的なパフォーマンスガイダンス
<a name="performance-fgw"></a>

このセクションでは、FSx ファイルゲートウェイVM 用にハードウェアをプロビジョニングするためのガイダンスを説明します。表に示されているインスタンスのサイズとタイプは例ですので、参考までにご覧ください。

最高のパフォーマンスを得るには、キャッシュディスクのサイズをアクティブな作業セットのサイズ合わせる必要があります。キャッシュに複数のローカルディスクを使用すると、データへのアクセスを並列処理することで書き込みパフォーマンスが上がり、IOPS が向上します。

**注記**  
エフェメラルストレージの使用はお勧めしません。エフェメラルストレージの使用については、「[EC2 ゲートウェイでのエフェメラルストレージの使用](ephemeral-disk-cache.md)」を参照してください。  
ファイルゲートウェイに接続するファイルシステム内の個々のディレクトリの推奨サイズ制限は、ディレクトリあたり 10,000 ファイルです。ファイルゲートウェイは、ファイル数が 10,000 個を超えるディレクトリでも使用できますが、パフォーマンスに影響する可能性があります。

以下の表で、*キャッシュヒット*の読み取りオペレーションは、キャッシュから提供されるファイルデータの読み取りです。*キャッシュミス*の読み取りオペレーションは、Amazon FSx for Windows File Server から提供されるファイルデータの読み取りです。

次の表は、FSx ファイルゲートウェイの構成の例を示しています。

### Windows クライアントでの FSx ファイルゲートウェイのパフォーマンス
<a name="performance-fgw-fsx-windows"></a>



- ** ルートディスク: 80 GB、io1 SSD、4,000 IOPS キャッシュディスク: 2 x 2 TiB NVME 最小ネットワークパフォーマンス: 10 Gbps CPU: 32 vCPU \| RAM: 244 GB **
  - **プロトコル:** SMBv3 - 1 スレッド / **書き込みスループット (ファイルサイズ 1 GB):** 162 MiB/秒 (1.4 Gbps) / **キャッシュヒット読み取りスループット:** 403 MiB/秒 (3.4 Gbps) / **キャッシュミス読み取りスループット:** 288 MiB/秒 (2.4 Gbps)
  - **プロトコル:** SMBv3 - 8 スレッド / **書き込みスループット (ファイルサイズ 1 GB):** 511 MiB/秒 (4.3 Gbps) / **キャッシュヒット読み取りスループット:** 571 MiB/秒 (4.8 Gbps) / **キャッシュミス読み取りスループット:** 567 MiB/秒 (4.8 Gbps)



**注記**  
パフォーマンスは、ホストプラットフォーム設定とネットワーク帯域幅によって異なる場合があります。書き込みスループットのパフォーマンスはファイルサイズとともに低下し、小さなファイル (32MiB 未満) で達成可能なスループットは最大 1 秒あたり 16 ファイルです。

## ゲートウェイのパフォーマンスの最適化
<a name="Optimizing-common"></a>

このセクションでは、ゲートウェイのパフォーマンスを最適化する方法について説明します。ガイダンスは、ゲートウェイへのリソースの追加およびアプリケーションサーバーへのリソースの追加に基づいています。

### ゲートウェイへのリソースの追加
<a name="Optimizing-vtl-add-resources-common"></a>

 以下の 1 つ以上の方法でゲートウェイにリソースを追加することで、ゲートウェイのパフォーマンスを最適化できます。

**より高性能なディスクの使用**  
ゲートウェイのパフォーマンスを最適化するために、Solid State Drive (SSD) や NVMe コントローラーなどの高性能のディスクを追加できます。また、Microsoft Hyper-V NTFS ではなく、ストレージエリアネットワーク (SAN) から直接 VM に仮想ディスクをアタッチできます。通常、ディスクパフォーマンスが向上すると、スループットおよび 1 秒あたりの入力/出力操作数 (IOPS) が改善します。ディスクの追加については、[追加のキャッシュストレージの設定](ConfiguringLocalDiskStorage.md) を参照してください。  
スループットを測定するには、`ReadBytes` および `WriteBytes` メトリクスを `Samples` Amazon CloudWatch 統計と共に使用します。たとえば、5 分間のサンプル期間の `ReadBytes` メトリックスの `Samples` 統計を 300 秒で割ると、IOPS がわかります。一般的なルールとして、ゲートウェイのこれらのメトリクスを確認する場合は、ディスク関連のボトルネックを示す低いスループットおよび低い IOPS トレンドを探します。  
CloudWatch メトリクスは、すべてのゲートウェイに使用できるわけではありません。ゲートウェイメトリクスについては、「[FSx ファイルゲートウェイのモニタリング](monitoring-file-gateway.md)」を参照してください。

**ゲートウェイホストへの CPU リソースの追加**  
ゲートウェイホストサーバーの最小要件は、4 つの仮想プロセッサです。ゲートウェイのパフォーマンスを最適化するには、ゲートウェイ VM に割り当てられている 4 つの仮想プロセッサが 4 つのコアによってサポートされることを確認します。さらに、ホストサーバーの CPU をオーバーサブスクライブしていないことを確認します。  
ゲートウェイホストサーバーに CPU を追加すると、ゲートウェイの処理能力が向上します。これにより、ゲートウェイはアプリケーションからローカルストレージへのデータ保存と、同時に FSx for Windows File Server へのデータアップロードの両方を並行して処理できるようになります。また、CPU を追加すると、ホストが他の VM と共有される場合に、ゲートウェイで十分な CPU リソースを利用できます。十分な CPU リソースを提供することによって、スループットを向上させる一般的な効果があります。  
Storage Gateway では、ゲートウェイホストサーバーで 24 個の CPU を使用することができます。24 個の CPU を使用すると、ゲートウェイのパフォーマンスを大幅に向上できます。ゲートウェイホストサーバーのゲートウェイ設定は次のように設定することを推奨します:  
+ 24 個の CPU。
+ ファイルゲートウェイ用に 16 GiB の予約済みの RAM
  + 16 TiB までのキャッシュ容量が使用可能な、ゲートウェイ用に予約された 16 GiB の RAM 領域
  + 16 TiB～32 TiB のキャッシュ容量が使用可能な、ゲートウェイ用に予約された 32 GiB の RAM 領域
  + 32 TiB～64 TiB のキャッシュ容量が使用可能な、ゲートウェイ用に予約された 48 GiB の RAM 領域
+ 準仮想化コントローラー 1 にアタッチされているディスク 1 (ゲートウェイのキャッシュとして次のように使用する) :
  + NVMe コントローラーを使用する SSD。
+ VM ネットワーク 1 に設定されたネットワークアダプタ 1:
  + VM ネットワーク 1 を使用し、取り込みに使用する VMXnet3 (10 Gbps) を追加する。
+ VM ネットワーク 2 に設定されたネットワークアダプタ 2:
  + VM ネットワーク 2 を使用し、 AWSへの接続に使用する VMXnet3 (10 Gbps) を追加する。

 **別の物理ディスクを使用したゲートウェイ仮想ディスクのバックアップ**  
ゲートウェイディスクをプロビジョニングする際は、ローカルストレージ用にローカルディスクをプロビジョニングする際、同じ基盤となる物理ストレージディスクを使用しないことを強く推奨します。たとえば、VMware ESXi の場合、基盤となる物理ストレージリソースはデータストアとして表されます。ゲートウェイ VM をデプロイする場合は、VM ファイルを保存するデータストアを選択します。仮想ディスクをプロビジョニングする場合は (アップロードバッファとして使用する場合など)、仮想ディスクを VM と同じデータストアか、別のデータストアに保存できます。  
複数のデータストアがある場合は、作成するローカルストレージのタイプごとに 1 つのデータストアを選択することを強く推奨します。基になる物理ディスクが 1 つのみのデータストアでは、パフォーマンスが低下することがあります。たとえば、そのようなディスクを使用して、ゲートウェイ設定のキャッシュストレージとアップロードバッファの両方がサポートされる場合です。同様に、RAID 1 のようなパフォーマンスの低い RAID 構成によってサポートされるデータストアでは、パフォーマンスが低下することがあります。

### アプリケーション環境へのリソースの追加
<a name="Optimizing-vtl-add-resources-app-common"></a>

**アプリケーションサーバーとゲートウェイの間の帯域幅の増大**  
ゲートウェイのパフォーマンスを最適化するには、アプリケーションとゲートウェイ間のネットワーク帯域幅が、アプリケーションのニーズを満たすようにしてください。ゲートウェイの `ReadBytes` および `WriteBytes` メトリクスを使用して、データの合計スループットを測定できます。  
アプリケーションでは、必要なスループットと測定されたスループットを比較します。測定されたスループットが必要なスループットを下回る場合、アプリケーションとゲートウェイの間の帯域幅を増やすと、ネットワークがボトルネックである場合にはパフォーマンスを向上させることができます。同様に、VM とローカルディスクの間の帯域幅を増やすことができます (直接接続されていない場合)。

**アプリケーション環境への CPU リソースの追加**  
アプリケーションが追加の CPU リソースを使用できる場合、CPU の追加はアプリケーションの I/O 負荷の調整に役立つことがあります。  
FSx ファイルゲートウェイでの一部のファイル操作 (トップレベルフォルダの名前変更や権限変更など) は、複数のファイル操作を引き起こし、FSx for Windows File Server ファイルシステムに高い I/O 負荷をもたらす可能性があります。ファイルシステムにワークロードに十分なパフォーマンスリソースがない場合、ファイルシステムは[シャドウコピー](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/shadow-copies-fsxW.html)の保持履歴よりも継続的な I/O の可用性を優先するため、シャドウコピーを削除する可能性があります。  
Amazon FSx コンソールで、「**モニタリングとパフォーマンス**」ページを見て、ファイルシステムがプロビジョニング不足かどうかを確認します。その場合は、SSD ストレージに切り替えるか、スループット容量を増やすか、または SSD IOPS を増やしてワークロードを処理することができます。