翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# パフォーマンスと最適化
このセクションでは、ファイルゲートウェイのパフォーマンスを最適化するためのガイダンスとベストプラクティスについて説明します。
**Topics**
+ [S3 ファイルゲートウェイの基本的なパフォーマンスガイダンス](#performance-fgw)
+ [複数のファイル共有を持つゲートウェイのパフォーマンスガイダンス](#performance-multiple-file-shares)
+ [S3 ファイルゲートウェイスループットの最大化](Performance-Throughput.md)
+ [SQL Server データベースバックアップ用の S3 ファイルゲートウェイの最適化](SQL-Backup-Best-Practices.md)
## S3 ファイルゲートウェイの基本的なパフォーマンスガイダンス
このセクションでは、S3 ファイルゲートウェイVM 用にハードウェアをプロビジョニングするためのガイダンスを説明します。表に示されているインスタンスのサイズとタイプは例ですので、参考までにご覧ください。
最高のパフォーマンスを得るには、キャッシュディスクのサイズをアクティブな作業セットのサイズ合わせる必要があります。キャッシュに複数のローカルディスクを使用すると、データへのアクセスを並列処理することで書き込みパフォーマンスが上がり、IOPS が向上します。
**注記**
エフェメラルストレージの使用はお勧めしません。エフェメラルストレージの使用については、「[EC2 ゲートウェイでのエフェメラルストレージの使用](ephemeral-disk-cache.md)」を参照してください。
Amazon EC2 インスタンスでは、S3 バケット内のオブジェクトが 500 万個を超え、汎用 SSD ボリュームを使用している場合、起動中のゲートウェイで許容できるパフォーマンスを得るには、最小 350 GiB のルート EBS ボリュームが必要です。ボリュームサイズを引き上げる方法については、「[Elastic Volumes を使用して EBS ボリュームを変更する (コンソール)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/requesting-ebs-volume-modifications.html#modify-ebs-volume)」を参照してください。
ファイルゲートウェイに接続するファイル共有内の個々のディレクトリの推奨サイズ制限は、ディレクトリあたり 10,000 ファイルです。ファイルゲートウェイは、ファイル数が 10,000 個を超えるディレクトリでも使用できますが、パフォーマンスに影響する可能性があります。
以下の表で、*キャッシュヒット*読み取りオペレーションは、キャッシュから提供されるファイル共有からの読み取りです。*キャッシュミス*読み取りオペレーションは、Amazon S3 から提供されるファイル共有からの読み取りです。
次の表は、S3 ファイルゲートウェイの構成の例を示しています。
### Linux クライアントでの S3 ファイルゲートウェイのパフォーマンス
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/filegateway/latest/files3/Performance.html)
### Windows クライアントでのファイルゲートウェイのパフォーマンス
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/filegateway/latest/files3/Performance.html)
**注記**
パフォーマンスは、ホストプラットフォーム設定とネットワーク帯域幅によって異なる場合があります。書き込みスループットのパフォーマンスはファイルサイズとともに低下し、小さなファイル (32MiB 未満) で達成可能なスループットは最大 1 秒あたり 16 ファイルです。
## 複数のファイル共有を持つゲートウェイのパフォーマンスガイダンス
Amazon S3 ファイルゲートウェイでは、1 つの Storage Gateway アプライアンスに最大 50 個のファイル共有をアタッチできます。ゲートウェイごとに複数のファイル共有を追加することで、管理するゲートウェイと仮想ハードウェアリソースを減らしても、ユーザーとワークロードの増大に対応できます。他の要因に加え、ゲートウェイで管理するファイル共有数が、ゲートウェイのパフォーマンスに影響を及ぼすことがあります。このセクションでは、アタッチされたファイル共有数に応じた、予想できるゲートウェイのパフォーマンスの変化について説明します。また、複数の共有を管理するゲートウェイのパフォーマンスを最適化するために推奨される仮想ハードウェアの構成を示します。
一般的に、単一の Storage Gateway が管理するファイル共有数を増やすと、次の結果が生じることがあります。
+ ゲートウェイの再起動により多くの時間がかかる。
+ vCPU や RAM などの仮想ハードウェアリソースの使用率が増える。
+ 仮想ハードウェアリソースが飽和状態になると、データおよびメタデータオペレーションのパフォーマンスが低下する。
次の表に、複数のファイル共有を管理するゲートウェイに推奨される仮想ハードウェア設定を示します。
| ゲートウェイあたりのファイル共有数 | 推奨されるゲートウェイ容量の設定 | 推奨される vCPU コア | 推奨 RAM | 推奨ルートディスクサイズ |
| --- | --- | --- | --- | --- |
| 1～10 | 小 | 4 (EC2 インスタンスタイプ **m4.xlarge** 以上) | 16 GiB | 80 GiB |
| 10～20 | 中 | 8 (EC2 インスタンスタイプ **m4.2xlarge** 以上) | 32 GiB | 160 GiB |
| 20 以上 | 大 | 16 (EC2 インスタンスタイプ **m4.4xlarge** 以上) | 64 GiB | 240 GiB |
上記の推奨される仮想ハードウェア構成に加えて、複数のファイル共有を管理する Storage Gateway アプライアンスを設定および保守するための以下のベストプラクティスを推奨します。
+ ファイル共有数とゲートウェイの仮想ハードウェアにかかる負荷との関係は必ずしも直線的ではないことに注意してください。一部のファイル共有は、他のファイル共有よりもスループットが高くなり、そのため他よりもハードウェアの負荷が高くなる可能性もあります。前の表の推奨事項は、最大ハードウェア容量とさまざまなファイル共有スループットレベルに基づいています。
+ 1 つのゲートウェイに複数のファイル共有を追加するとパフォーマンスが低下する場合は、最もアクティブなファイル共有を他のゲートウェイに移動することを検討してください。特に、非常に高いスループットを必要とするアプリケーションでファイル共有を使用する場合は、そのファイル共有専用に別のゲートウェイを作成することを検討してください。
+ 複数の高スループットアプリケーション用に 1 つのゲートウェイを設定したり、複数の低スループットアプリケーションを別のゲートウェイに設定する構成は推奨されません。別の方法として、ハードウェアの過負荷を防ぐため、高スループットと低スループットのファイル共有を複数のゲートウェイに均等に分散させることを検討してください。ファイル共有のスループットを測定するには、`ReadBytes` および `WriteBytes` メトリクスを使用します。詳細については、「[計測スループットについて](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#monitoring-file-gateway-resources)」を参照してください。