翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# パフォーマンスと最適化
このセクションでは、ファイルゲートウェイのパフォーマンスを最適化するためのガイダンスとベストプラクティスについて説明します。
**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)」を参照してください。
# S3 ファイルゲートウェイスループットの最大化
次のセクションでは、NFS および SMB クライアント、S3 ファイルゲートウェイ、Amazon S3 間のスループットを最大化するためのベストプラクティスについて説明します。各セクションで提供されるガイダンスは、全体的なスループットの段階的な向上に有用です。これらの推奨事項は必須ではなく、相互に依存しませんが、 サポート が S3 File Gateway 実装のテストとチューニングに使用する論理的な方法で選択および順序付けされています。これらの提案を実装してテストするときは、S3 ファイルゲートウェイの各デプロイはそれぞれ固有であるため、結果は異なる場合があります。
S3 ファイルゲートウェイは、業界標準の NFS または SMB ファイルプロトコルを使用して Amazon S3 オブジェクトを保存および取得するためのファイルインターフェイスを提供し、ファイルとオブジェクトの間にネイティブな 1:1 のマッピングを備えています。S3 File Gateway は、VMware、Microsoft Hyper-V、Linux KVM 環境でオンプレミスの仮想マシンとしてデプロイするか、Amazon EC2 インスタンスとして AWS クラウドにデプロイします。S3 ファイルゲートウェイは、完全なエンタープライズ NAS の代役として動作するようには設計されていません。S3 ファイルゲートウェイはファイルシステムをエミュレートしますが、ファイルシステムそのものではありません。Amazon S3 を耐久性のあるバックエンドストレージとして使用すると、I/O オペレーションごとに追加のオーバーヘッドが発生します。そのため、既存の NAS やファイルサーバーと S3 ファイルゲートウェイのパフォーマンスを比較して評価しても、同等の比較にはなりません。
## クライアントと同じ場所へのゲートウェイのデプロイ
S3 ファイルゲートウェイの仮想アプライアンスは、NFS または SMB クライアントとの間のネットワークレイテンシーができるだけ小さい物理ロケーションにデプロイすることを推奨します。ゲートウェイの場所を選択するときは、次の点を考慮してください。
+ ゲートウェイへのネットワークレイテンシーを低くすると、NFS または SMB クライアントのパフォーマンスを向上させることができます。
+ S3 ファイルゲートウェイは、ゲートウェイとクライアント間よりもゲートウェイと Amazon S3 間のネットワークレイテンシーが高くなるように設計されています。
+ Amazon EC2 にデプロイされた S3 ファイルゲートウェイインスタンスの場合、ゲートウェイと NFS クライアントまたは SMB クライアントを同じプレイスメントグループに保持することをお勧めします。詳細については、Amazon Elastic Compute Cloud ユーザーガイドの「[Amazon EC2 インスタンスの配置グループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)」を参照してください。
## 低速ディスクによるボトルネックの軽減
`IoWaitPercent` CloudWatch メトリクスをモニタリングして、S3 ファイルゲートウェイの低速ストレージディスクが原因で発生するパフォーマンスのボトルネックを特定することを推奨します。ディスク関連のパフォーマンス問題を最適化する場合は、次の点を考慮してください。
+ `IoWaitPercent` は、CPU がルートディスクまたはキャッシュディスクからの応答を待っている時間の割合を報告します。
+ `IoWaitPercent` が 5～10% を超えると、通常、パフォーマンスの低いディスクが原因でゲートウェイパフォーマンスのボトルネックが発生していることを示します。このメトリクスはできるだけ 0% に近い値 (つまり、ゲートウェイのディスク待機時間がない状態) にする必要があります。これにより、CPU リソースを最適化できます。
+ Storage Gateway コンソールの**[モニタリング]** タブで `IoWaitPercent` を確認するか、あるいはメトリクスが特定のしきい値を超えた場合に自動的に通知するように推奨 CloudWatch アラームを設定できます。詳細については、[「ゲートウェイの推奨 CloudWatch アラームの作成](https://docs.aws.amazon.com/filegateway/latest/files3/cloudwatch-alarms-create-recommended.html)」を参照してください。
+ `IoWaitPercent` を最小限に抑えるには、ゲートウェイのルートディスクとキャッシュディスクに NVMe または SSD を使用することを推奨します。
## CPU、RAM、キャッシュディスクの仮想マシンリソースの割り当ての調整
S3 ファイルゲートウェイのスループットを最適化しようとするときは、CPU、RAM、キャッシュディスクなど、ゲートウェイ VM に十分なリソースを割り当てることが重要です。4 CPU、16GB RAM、150GB キャッシュストレージの最小仮想リソース要件は、通常、小規模なワークロードにのみ適しています。大規模なワークロードに仮想リソースを割り当てる場合は、次のことを推奨します。
+ S3 ファイルゲートウェイによって生成される一般的な CPU 使用率に応じて、割り当てられた CPU の数を 16～48 に増やします。`UserCpuPercent` メトリクスを使用して CPU 使用率をモニタリングできます。詳細については、「[ゲートウェイメトリクスについて](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics)」を参照してください。
+ 割り当てる RAM 数を 32～64 GB に増やします。
**注記**
S3 ファイルゲートウェイは 64 GB を超える RAM を使用できません。
+ ルートディスクとキャッシュディスクに NVMe または SSD を使用し、ゲートウェイに書き込む予定のピーク作業データセットに合わせてキャッシュディスクのサイズを設定します。詳細については、公式 Amazon Web Services YouTube チャンネルの「[S3 ファイルゲートウェイキャッシュサイジングのベストプラクティス](https://youtu.be/-ibL1eEcROI?si=dMAakj_dulZiG4Ln)」を参照してください。
+ 1 つの大きなディスクを使用するのではなく、少なくとも 4 つの仮想キャッシュディスクをゲートウェイに追加します。複数の仮想ディスクは、基盤となる同じ物理ディスクを共有していてもパフォーマンスを向上させることができますが、仮想ディスクが異なる基盤となる物理ディスクに配置されると、通常は改善点が大きくなります。
たとえば、12TB のキャッシュをデプロイする場合は、次のいずれかの設定を使用できます。
+ 4 x 3 TB キャッシュディスク
+ 8 x 1.5 TB キャッシュディスク
+ 12 x 1 TB キャッシュディスク
これにより、パフォーマンスに加えて、時間の経過とともに仮想マシンをより効率的に管理できます。ワークロードの変化に応じて、個々の仮想ディスクの元のサイズを維持しながら、キャッシュディスクの数と全体的なキャッシュ容量を段階的に増やして、ゲートウェイの整合性を維持できます。
詳細については、「[ローカルディスクストレージの量の決定](https://docs.aws.amazon.com/filegateway/latest/files3/decide-local-disks-and-sizes.html)」を参照してください。
S3 ファイルゲートウェイを Amazon EC2 インスタンスとしてデプロイする場合は、次の点を考慮してください:
+ 選択したインスタンスタイプは、ゲートウェイのパフォーマンスに大きな影響を与える可能性があります。Amazon EC2 は、S3 ファイルゲートウェイインスタンスのリソース割り当てを柔軟に調整できます。
+ S3 ファイルゲートウェイに推奨される Amazon EC2 インスタンスタイプについては、[Amazon EC2 インスタンスタイプの要件](https://docs.aws.amazon.com/filegateway/latest/files3/Requirements.html#requirements-hardware-ec2)を参照してください。
+ アクティブな S3 ファイルゲートウェイをホストする Amazon EC2 インスタンスタイプを変更できます。これにより、Amazon EC2 ハードウェアの生成とリソースの割り当てを簡単に調整して、最適な費用対効果比を見つけることができます。インスタンスタイプを変更するには、Amazon EC2 コンソールで次の手順を使用します。
1. Amazon EC2 インスタンスを停止します。
1. Amazon EC2 インスタンスタイプを変更します。
1. Amazon EC2 インスタンスの電源を入れます。
**注記**
S3 ファイルゲートウェイをホストするインスタンスを停止すると、ファイル共有アクセスが一時的に中断されます。必要に応じて、メンテナンスウィンドウの予定を必ず設定してください。
+ Amazon EC2 インスタンスの費用対効果比は、支払う料金に対してどれだけのコンピューティング能力を得られるかを示します。一般的に、より新しい世代の Amazon EC2 インスタンスのほうが、最高レベルの費用対効果比を実現できます。つまり、旧世代と比べて比較的低コストで、より新しいハードウェアを使用することで、パフォーマンスが向上します。インスタンスタイプ、リージョン、使用パターンなどの要因がこの比率に影響するため、コスト効率を最適化するには、そのワークロードに適したインスタンスを選択することが重要です。
## SMB セキュリティレベルの調整
SMBv3 プロトコルにより、SMB の署名と SMB の暗号化が可能になりますが、パフォーマンスとセキュリティはトレードオフの関係にあります。スループットを最適化するために、ゲートウェイの SMB セキュリティレベルを調整して、クライアント接続にどのセキュリティ機能を適用するかを指定できます。詳細については、「[ゲートウェイのセキュリティレベルを設定する](https://docs.aws.amazon.com/filegateway/latest/files3/security-strategy.html)」を参照してください。
SMB セキュリティレベルを調整するときは、次の点を考慮してください。
+ S3 ファイルゲートウェイのデフォルトのセキュリティレベルは **[暗号化の適用]** です。この設定では、ゲートウェイファイル共有への SMB クライアント接続の暗号化と署名の両方が適用されます。つまり、クライアントからゲートウェイへのすべてのトラフィックが暗号化されます。この設定は AWS、ゲートウェイから へのトラフィックには影響しません。このトラフィックは常に暗号化されます。
ゲートウェイは、暗号化された各クライアント接続を 1 つの vCPU に制限します。たとえば、暗号化されたクライアントが 1 つしかない場合、4 つ以上の vCPU がゲートウェイに割り当てられていても、そのクライアントは 1 つの vCPUs に制限されます。このため、単一のクライアントから S3 ファイルゲートウェイへの暗号化された接続のスループットは通常、40～60 MB/秒の間でボトルネックになります。
+ セキュリティ要件でより緩やかな体制が許されている場合には、セキュリティレベルを**クライアントネゴシエート**に変更できます。これにより、SMB 暗号化は無効になり、SMB 署名のみが適用されます。この設定では、ゲートウェイへのクライアント接続で複数の vCPU を利用できるため、通常、スループットパフォーマンスが向上します。
**注記**
S3 ファイルゲートウェイの SMB セキュリティレベルを変更します。その後、Storage Gateway コンソールでファイル共有ステータスが **[更新]** から **[使用可能]** に変わるまで待ちます。次に、SMB クライアントを切断してから再接続すると、新しい設定が有効になります。
## 複数のスレッドとクライアントを使用して、書き込みオペレーションを並列化
S3 ファイルゲートウェイで、1 つの NFS または SMB クライアントが 1 回に 1 ファイルずつ書き込む場合、単一クライアントからの連続書き込みはシングルスレッドの操作となるため、最大スループット性能を達成するのは困難です。代わりに、各 NFS または SMB クライアントで複数のスレッドを使用して複数のファイルを並列に書き込み、さらに複数の NFS または SMB クライアントを同時に S3 ファイルゲートウェイに接続して、ゲートウェイのスループットを最大化することを推奨します。
複数のスレッドを使うと、パフォーマンスを大幅に向上できます。ただし、より多くのスレッドを使うにはより多くのシステムリソースが必要であるため、負荷の増加に対応するようにゲートウェイのサイズを設定していない場合は、パフォーマンスに悪影響を及ぼす可能性があります。一般的なデプロイでは、ゲートウェイの最大ハードウェアと帯域幅の制限に達するまで、スレッドとクライアントを追加するとスループットのパフォーマンスが向上します。さまざまなスレッド数を試して、特定のハードウェアとネットワーク設定の速度とシステムリソースの使用状況の最適なバランスを見つけることをお勧めします。
スレッドとクライアント設定のテストに役立つ一般的なツールについては、次の情報を考慮してください。
+ マルチスレッド書き込みパフォーマンスをテストするには、Robocopy などのツールを使用して、一連のファイルをゲートウェイ上のファイル共有にコピーします。デフォルトでは Robocopy はファイルのコピーに 8 スレッドを使用しますが、最大 128 スレッドを指定できます。
Robocopy で複数のスレッドを使うには、 コマンドに `/MT:n` スイッチを追加します。ここで、`n` は使うスレッドの数です。例えば、次のようになります。
`robocopy C:\source D:\destination /MT:64`
このコマンドは、コピーの処理に 64 スレッドを使用します。
**注記**
最大スループットのテスト時に Windows Explorer を使ってファイルをドラッグアンドドロップすることはお勧めしません。この方法ではスレッドが 1 つに制限され、ファイルが順番にコピーされるからです。
詳細については、Microsoft Learn ウェブサイトの「[Robocopy](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy)」を参照してください。
+ DISKSPD や FIO などの一般的なストレージベンチマークツールを使用してテストを実行することもできます。これらのツールには、特定のワークロード要件に合わせてスレッド数、I/O 深度、およびその他のパラメータを調整するオプションがあります。
DiskSpd では、`-t`パラメータを使用してスレッドの数を制御できます。例えば、次のようになります。
`diskspd -c10G -d300 -r -w50 -t64 -o32 -b1M -h -L C:\testfile.dat`
このコマンド例では、次の操作を行います。
+ 10GB のテストファイルを作成します (`-c1G`)
+ 300 秒間実行 (`-d300`)
+ 読み取り 50%、書き込み 50% でランダム I/O テストを実行します (`-r -w50`)
+ 64 スレッドを使用 (`-t64`)
+ キューの深さをスレッドあたり 32 に設定します (`-o32`)
+ 1MB のブロックサイズを使用する (`-b1M`)
+ ハードウェアおよびソフトウェアのキャッシュを無効にします (`-h -L`)
詳細については、Microsoft Learn ウェブサイトの[「DISKSPD を使用してワークロードストレージのパフォーマンスをテストする](https://learn.microsoft.com/en-us/azure/azure-local/manage/diskspd-overview?view=azloc-24113)」を参照してください。
+ FIO は `numjobs` パラメータを使用して並列スレッドの数を制御します。例えば、次のようになります。
`fio --name=mixed_test --rw=randrw --rwmixread=70 --bs=1M -- iodepth=64 --size=10G --runtime=300 --numjobs=64 --ioengine=libaio --direct=1 --group_reporting`
このコマンド例では、次の操作を行います。
+ ランダム I/O テストを実行する (`--rw=randrw`)
+ 70% の読み取りと 30% の書き込みを実行する (`--rwmixread=70`)
+ 1MB のブロックサイズを使用する (`--bs=1M`)
+ I/O 深度を 64 に設定 (`--iodepth=64`)
+ 10 GB ファイルのテストをします (`--size=10G`)
+ 5 分間実行 (`--runtime=300`)
+ 64 の並列ジョブ (スレッド) を作成する (`--numjobs=64`)
+ 非同期 I/O エンジンを使用します (`--ioengine=libaio`)
+ 結果をグループ化して分析を容易にする (`--group_reporting`)
詳細については「[fio](https://linux.die.net/man/1/fio) Linux man」ページを参照してください。
## 自動キャッシュ更新の無効化
自動キャッシュ更新機能により、S3 ファイルゲートウェイはメタデータを自動的に更新できます。これにより、ユーザーやアプリケーションがゲートウェイを通さずに直接 Amazon S3 バケットに書き込んだファイルセットの変更を反映させることが可能になります。詳細については、[Amazon S3バケットオブジェクトキャッシュの更新](https://docs.aws.amazon.com/filegateway/latest/files3/refresh-cache.html)」を参照してください。
ゲートウェイのスループットを最適化するために、Amazon S3 バケットへのすべての読み取りと書き込みが S3 ファイルゲートウェイを介して実行されるデプロイでは、この機能をオフにすることをお勧めします。
自動キャッシュ更新を設定する際は、以下の点を考慮してください。
+ デプロイ内のユーザーまたはアプリケーションが Amazon S3 に直接書き込むことがあるため、自動キャッシュ更新を使用する必要がある場合は、更新間隔をできるだけ長く (業務ニーズに合理的な間隔で) 設定することを推奨します。キャッシュ更新間隔を長くすると、ディレクトリを参照したりファイルを変更したりするときにゲートウェイが実行する必要があるメタデータオペレーションの数を減らすことができます。
例えば、自動キャッシュ更新を 5 分ではなく 24 時間に設定します (ワークロードに許容できる範囲で)。
+ 最小更新間隔は 5 分です。最大間隔は 30 日間です。
+ 非常に短いキャッシュ更新間隔を設定する場合は、NFS および SMB クライアントのディレクトリブラウジングエクスペリエンスをテストすることをお勧めします。ゲートウェイキャッシュの更新にかかる時間は、Amazon S3 バケット内のファイル数とサブディレクトリ数によってかなり長くなる可能性があります。
## Amazon S3 アップローダースレッドの数の増大
デフォルトでは、S3 ファイルゲートウェイは Amazon S3 データアップロード用に 8 つのスレッドを使用し、ほとんどの一般的なデプロイに十分なアップロード容量を提供します。ただし、ゲートウェイが標準の 8 スレッド容量で Amazon S3 にアップロードできるよりも高いレートで NFS および SMB クライアントからデータを受信する可能性があります。これにより、ローカルキャッシュがストレージ制限に達する可能性があります。
特定の状況では、ゲートウェイの Amazon S3 アップロードスレッドプールの数を 8 から 40 に サポート 増やすことができます。これにより、より多くのデータを並行してアップロードできます。帯域幅やその他のデプロイに固有の要因によっては、アップロードパフォーマンスが大幅に向上し、ワークロードのサポートに必要なキャッシュストレージの量を減らすことができます。
`CachePercentDirty` CloudWatch メトリクスを使用して、Amazon S3 にまだアップロードされていないローカルゲートウェイキャッシュディスクに保存されているデータ量をモニタリングし、 サポート に連絡して、アップロードスレッドプール数を増やすことで S3 File Gateway のスループットが向上するかどうかを判断することをお勧めします。詳細については、「[ゲートウェイメトリクスについて](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics)」を参照してください。
**注記**
この設定では、追加のゲートウェイ CPU リソースを消費します。ゲートウェイの CPU 使用率をモニタリングし、必要に応じて割り当てられた CPU リソースを増やすことを推奨します。
## SMB タイムアウト設定の増大
S3 ファイルゲートウェイが大きなファイルを SMB ファイル共有にコピーする場合、長時間経過すると SMB クライアント接続がタイムアウトすることがあります。
ファイルのサイズとゲートウェイの書き込み速度に応じて、SMB クライアントの SMB セッションタイムアウト設定を 20 分以上に延長することを推奨します。デフォルトは 300 秒 (5 分) です。詳細については、「[ゲートウェイのバックアップジョブが失敗する、またはゲートウェイへの書き込み時にエラーが発生する](https://docs.aws.amazon.com/filegateway/latest/files3/troubleshooting-file-gateway-issues.html#backup-job-fails)」を参照してください。
## 互換性のあるアプリケーションの日和見ロックの有効化
日和見ロック (オプロック) は、新しい S3 ファイルゲートウェイごとにデフォルトで有効になっています。互換性のあるアプリケーションで日和見ロックを使用する場合、クライアントは複数の小さなオペレーションをまとめてより大きなオペレーションとしてバッチ処理します。これはクライアント、ゲートウェイ、ネットワークにとって効率的です。Microsoft Office、Adobe Suite など、クライアント側のローカルキャッシュを活用するアプリケーションを使用する場合は、日和見ロックを有効にしておくことを推奨します。これにより、パフォーマンスが大幅に向上する可能性があります。
日和見ロックを無効にすると、日和見ロックをサポートするアプリケーションは通常、大きなファイル (50 MB 以上) をよりゆっくりと開きます。この遅延は、ゲートウェイが 4 KB のパートでデータを送信するために発生します。これにより、I/O が高くなり、スループットが低くなります。
## 作業ファイルセットのサイズに応じたゲートウェイ容量の調整
ゲートウェイ容量パラメータは、ゲートウェイがローカルキャッシュにメタデータを保存するファイルの最大数を指定します。デフォルトでは、ゲートウェイ容量は **小** に設定されています。つまり、ゲートウェイは最大 500 万個のファイルのメタデータを保存できます。デフォルト設定は、Amazon S3 に数億または数十億のオブジェクトがある場合でも、ほとんどのワークロードでうまく機能します。これは、通常のデプロイで特定の時間にアクティブにアクセスされるファイルのサブセットがごくわずかであるためです。このファイルのグループは、「ワーキングセット」と呼ばれます。
ワークロードが 500 万を超えるファイルのワーキングセットに定期的にアクセスする場合、ゲートウェイは頻繁にキャッシュエビクションを実行する必要があります。これは、RAM に保存され、ルートディスクに保持される小さな I/O オペレーションです。これは、ゲートウェイが Amazon S3 から新しいデータを取得するときに、ゲートウェイのパフォーマンスに悪影響を及ぼす可能性があります。
`IndexEvictions` メトリクスをモニタリングして、メタデータがキャッシュから削除されたファイルの数を決定し、新しいエントリのスペースを確保できます。詳細については、「[ゲートウェイメトリクスについて](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics)」を参照してください。
`UpdateGatewayInformation` API アクションを使用して、一般的なワーキングセット内のファイル数に対応するようにゲートウェイ容量を増やすことをお勧めします。詳細については、「[UpdateGatewayInformation](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_UpdateGatewayInformation.html)」を参照してください。
**注記**
ゲートウェイ容量を増やすには、追加の RAM とルートディスク容量が必要です。
小 (500 万ファイル) には、少なくとも 16 GB RAM と 80 GB ルートディスクが必要です。
中 (1,000 万ファイル) には、少なくとも 32 GB RAM と 160 GB ルートディスクが必要です。
大 (2,000 万ファイル) の場合、64 GB RAM と 240 GB ルートディスクが必要です。
**重要**
ゲートウェイ容量を減らすことはできません。
## ワークロードの増大用の複数のゲートウェイのデプロイ
1 つの大きなゲートウェイに多数のファイル共有を統合するのではなく、可能であればワークロードを複数のゲートウェイに分割することをお勧めします。たとえば、頻繁に使用するファイル共有を 1 つのゲートウェイで分離し、使用頻度の低いファイル共有を別のゲートウェイでグループ化できます。
複数のゲートウェイとファイル共有を使用してデプロイを計画する場合は、次の点を考慮してください。
+ 1 つのゲートウェイでのファイル共有の最大数は 50 ですが、ゲートウェイによって管理されるファイル共有の数はゲートウェイのパフォーマンスに影響を与える可能性があります。詳細については、「[複数のファイル共有を持つゲートウェイのパフォーマンスガイダンス](https://docs.aws.amazon.com/filegateway/latest/files3/Performance.html#performance-multiple-file-shares)」を参照してください。
+ 各 S3 ファイルゲートウェイのリソースは、パーティション化することなく、すべてのファイル共有で共有されます。
+ 使用量が多い単一のファイル共有は、ゲートウェイ上の他のファイル共有のパフォーマンスに影響を与える可能性があります。
**注記**
少なくとも 1 つのゲートウェイを読み取り専用にしない限り、複数のゲートウェイから同じ Amazon S3 の場所にマッピングされた複数のファイル共有を作成することはお勧めしません。
複数のゲートウェイから同じファイルへの同時書き込みは、マルチライターシナリオと見なされ、データ整合性の問題が発生する可能性があります。
# SQL Server データベースバックアップ用の S3 ファイルゲートウェイの最適化
データベースのバックアップは、S3 ファイルゲートウェイの一般的で推奨されるユースケースです。S3 ファイルゲートウェイは、データベースのバックアップを Amazon S3 に保存することで、コスト効率の高い短期および長期の保持を提供し、必要に応じてライフサイクル管理により低コストのストレージ階層へ移行することができます。このソリューションを使用すると、SQL Server Management Studio や Oracle RMAN などの組み込みツールを使用して、エンタープライズバックアップアプリケーションの必要性を減らすことができます。
次のセクションでは、S3 ファイルゲートウェイのデプロイを最適化し、数百テラバイト規模の SQL データベースバックアップをコスト効率よくサポートするためのベストプラクティスについて説明します。各セクションで提供されるガイダンスは、全体的なスループットの段階的な向上に有用です。これらの推奨事項は必須ではなく、相互に依存しませんが、 サポート が S3 File Gateway 実装のテストとチューニングに使用する論理的な方法で選択および順序付けされています。これらの提案を実装してテストするときは、S3 ファイルゲートウェイの各デプロイはそれぞれ固有であるため、結果は異なる場合があります。
S3 ファイルゲートウェイは、業界標準の NFS または SMB ファイルプロトコルを使用して Amazon S3 オブジェクトを保存および取得するためのファイルインターフェイスを提供し、ファイルとオブジェクトの間にネイティブな 1:1 のマッピングを備えています。S3 File Gateway は、VMware、Microsoft Hyper-V、Linux KVM 環境でオンプレミスの仮想マシンとしてデプロイするか、Amazon EC2 インスタンスとして AWS クラウドにデプロイします。S3 ファイルゲートウェイは、完全なエンタープライズ NAS の代役として動作するようには設計されていません。S3 ファイルゲートウェイはファイルシステムをエミュレートしますが、ファイルシステムそのものではありません。Amazon S3 を耐久性のあるバックエンドストレージとして使用すると、I/O オペレーションごとに追加のオーバーヘッドが発生します。そのため、既存の NAS やファイルサーバーと S3 ファイルゲートウェイのパフォーマンスを比較して評価しても、同等の比較にはなりません。
## SQL Server と同じ場所へのゲートウェイのデプロイ
S3 ファイルゲートウェイの仮想アプライアンスは、SQL Server との間のネットワークレイテンシーができるだけ小さい物理ロケーションにデプロイすることを推奨します。ゲートウェイの場所を選択するときは、次の点を考慮してください。
+ ゲートウェイへのネットワークレイテンシーを低くすると、SQL サーバーなどの SMB クライアントのパフォーマンスを向上させることができます。
+ S3 ファイルゲートウェイは、ゲートウェイとクライアント間よりもゲートウェイと Amazon S3 間のネットワークレイテンシーが高くなるように設計されています。
+ Amazon EC2 にデプロイされた S3 ファイルゲートウェイインスタンスの場合、ゲートウェイと SQL サーバーを同じプレイスメントグループに保持することをお勧めします。詳細については、Amazon Elastic Compute Cloud ユーザーガイドの「[Amazon EC2 インスタンスの配置グループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)」を参照してください。
## 低速ディスクによるボトルネックの軽減
`IoWaitPercent` CloudWatch メトリクスをモニタリングして、S3 ファイルゲートウェイの低速ストレージディスクが原因で発生するパフォーマンスのボトルネックを特定することを推奨します。ディスク関連のパフォーマンス問題を最適化する場合は、次の点を考慮してください。
+ `IoWaitPercent` は、CPU がルートディスクまたはキャッシュディスクからの応答を待っている時間の割合を報告します。
+ `IoWaitPercent` が 5～10% を超えると、通常、パフォーマンスの低いディスクが原因でゲートウェイパフォーマンスのボトルネックが発生していることを示します。このメトリクスはできるだけ 0% に近い値 (つまり、ゲートウェイのディスク待機時間がない状態) にする必要があります。これにより、CPU リソースを最適化できます。
+ Storage Gateway コンソールの**[モニタリング]** タブで `IoWaitPercent` を確認するか、あるいはメトリクスが特定のしきい値を超えた場合に自動的に通知するように推奨 CloudWatch アラームを設定できます。詳細については、[「ゲートウェイの推奨 CloudWatch アラームの作成](https://docs.aws.amazon.com/filegateway/latest/files3/cloudwatch-alarms-create-recommended.html)」を参照してください。
+ `IoWaitPercent` を最小限に抑えるには、ゲートウェイのルートディスクとキャッシュディスクに NVMe または SSD を使用することを推奨します。
## CPU、RAM、キャッシュディスクの S3 ファイルゲートウェイ仮想マシンリソース割り当ての調整
S3 ファイルゲートウェイのスループットを最適化しようとするときは、CPU、RAM、キャッシュディスクなど、ゲートウェイ VM に十分なリソースを割り当てることが重要です。4 CPU、16GB RAM、150GB キャッシュストレージの最小仮想リソース要件は、通常、小規模なワークロードにのみ適しています。大規模なワークロードに仮想リソースを割り当てる場合は、次のことを推奨します。
+ S3 ファイルゲートウェイによって生成される一般的な CPU 使用率に応じて、割り当てられた CPU の数を 16～48 に増やします。`UserCpuPercent` メトリクスを使用して CPU 使用率をモニタリングできます。詳細については、「[ゲートウェイメトリクスについて](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics)」を参照してください。
+ 割り当てる RAM 数を 32～64 GB に増やします。
**注記**
S3 ファイルゲートウェイは 64 GB を超える RAM を使用できません。
+ ルートディスクとキャッシュディスクに NVMe または SSD を使用し、ゲートウェイに書き込む予定のピーク作業データセットに合わせてキャッシュディスクのサイズを設定します。詳細については、公式 Amazon Web Services YouTube チャンネルの「[S3 ファイルゲートウェイキャッシュサイジングのベストプラクティス](https://youtu.be/-ibL1eEcROI?si=dMAakj_dulZiG4Ln)」を参照してください。
+ 1 つの大きなディスクを使用するのではなく、少なくとも 4 つの仮想キャッシュディスクをゲートウェイに追加します。複数の仮想ディスクは、基盤となる同じ物理ディスクを共有していてもパフォーマンスを向上させることができますが、仮想ディスクが異なる基盤となる物理ディスクに配置されると、通常は改善点が大きくなります。
たとえば、12TB のキャッシュをデプロイする場合は、次のいずれかの設定を使用できます。
+ 4 x 3 TB キャッシュディスク
+ 8 x 1.5 TB キャッシュディスク
+ 12 x 1 TB キャッシュディスク
これにより、パフォーマンスに加えて、時間の経過とともに仮想マシンをより効率的に管理できます。ワークロードの変化に応じて、個々の仮想ディスクの元のサイズを維持しながら、キャッシュディスクの数と全体的なキャッシュ容量を段階的に増やして、ゲートウェイの整合性を維持できます。
詳細については、「[ローカルディスクストレージの量の決定](https://docs.aws.amazon.com/filegateway/latest/files3/decide-local-disks-and-sizes.html)」を参照してください。
S3 ファイルゲートウェイを Amazon EC2 インスタンスとしてデプロイする場合は、次の点を考慮してください:
+ 選択したインスタンスタイプは、ゲートウェイのパフォーマンスに大きな影響を与える可能性があります。Amazon EC2 は、S3 ファイルゲートウェイインスタンスのリソース割り当てを柔軟に調整できます。
+ S3 ファイルゲートウェイに推奨される Amazon EC2 インスタンスタイプについては、[Amazon EC2 インスタンスタイプの要件](https://docs.aws.amazon.com/filegateway/latest/files3/Requirements.html#requirements-hardware-ec2)を参照してください。
+ アクティブな S3 ファイルゲートウェイをホストする Amazon EC2 インスタンスタイプを変更できます。これにより、Amazon EC2 ハードウェアの生成とリソースの割り当てを簡単に調整して、最適な費用対効果比を見つけることができます。インスタンスタイプを変更するには、Amazon EC2 コンソールで次の手順を使用します。
1. Amazon EC2 インスタンスを停止します。
1. Amazon EC2 インスタンスタイプを変更します。
1. Amazon EC2 インスタンスの電源を入れます。
**注記**
S3 ファイルゲートウェイをホストするインスタンスを停止すると、ファイル共有アクセスが一時的に中断されます。必要に応じて、メンテナンスウィンドウの予定を必ず設定してください。
+ Amazon EC2 インスタンスの費用対効果比は、支払う料金に対してどれだけのコンピューティング能力を得られるかを示します。一般的に、より新しい世代の Amazon EC2 インスタンスのほうが、最高レベルの費用対効果比を実現できます。つまり、旧世代と比べて比較的低コストで、より新しいハードウェアを使用することで、パフォーマンスが向上します。インスタンスタイプ、リージョン、使用パターンなどの要因がこの比率に影響するため、コスト効率を最適化するには、そのワークロードに適したインスタンスを選択することが重要です。
## S3 ファイルゲートウェイのセキュリティレベルを調整して SMB クライアントのスループットを向上
SMBv3 プロトコルにより、SMB の署名と SMB の暗号化が可能になりますが、パフォーマンスとセキュリティはトレードオフの関係にあります。スループットを最適化するために、ゲートウェイの SMB セキュリティレベルを調整して、クライアント接続にどのセキュリティ機能を適用するかを指定できます。詳細については、「[ゲートウェイのセキュリティレベルを設定する](https://docs.aws.amazon.com/filegateway/latest/files3/security-strategy.html)」を参照してください。
SMB セキュリティレベルを調整するときは、次の点を考慮してください。
+ S3 ファイルゲートウェイのデフォルトのセキュリティレベルは **[暗号化の適用]** です。この設定では、ゲートウェイファイル共有への SMB クライアント接続の暗号化と署名の両方が適用されます。つまり、クライアントからゲートウェイへのすべてのトラフィックが暗号化されます。この設定は AWS、ゲートウェイから へのトラフィックには影響しません。このトラフィックは常に暗号化されます。
ゲートウェイは、暗号化された各クライアント接続を 1 つの vCPU に制限します。たとえば、暗号化されたクライアントが 1 つしかない場合、4 つ以上の vCPU がゲートウェイに割り当てられていても、そのクライアントは 1 つの vCPUs に制限されます。このため、単一のクライアントから S3 ファイルゲートウェイへの暗号化された接続のスループットは通常、40～60 MB/秒の間でボトルネックになります。
+ セキュリティ要件でより緩やかな体制が許されている場合には、セキュリティレベルを**クライアントネゴシエート**に変更できます。これにより、SMB 暗号化は無効になり、SMB 署名のみが適用されます。この設定では、ゲートウェイへのクライアント接続で複数の vCPU を利用できるため、通常、スループットパフォーマンスが向上します。
**注記**
S3 ファイルゲートウェイの SMB セキュリティレベルを変更します。その後、Storage Gateway コンソールでファイル共有ステータスが **[更新]** から **[使用可能]** に変わるまで待ちます。次に、SMB クライアントを切断してから再接続すると、新しい設定が有効になります。
## SQL バックアップを複数のファイルに分割して SMB クライアントのスループットを向上
+ 単一の SQL サーバーからのシーケンシャル書き込みはシングルスレッドの処理となるため、一度に 1 つの SQL サーバーのみを使用して 1 つのファイルを書き込む構成では、S3 ファイルゲートウェイのスループットを最大限に引き出すことは困難です。代わりに、各 SQL サーバーで複数のスレッドを使用して複数のファイルを並列に書き込み、さらに複数の SQL サーバーを同時に S3 ファイルゲートウェイに接続して、ゲートウェイのスループットを最大化することを推奨します。SQL バックアップでは、バックアップを複数のファイルに分割することで、各ファイルで個別のスレッドを使用できます。これにより、複数のファイルが同時に S3 ファイルゲートウェイファイル共有に書き込まれます。スレッドが多いほど、ゲートウェイの制限まで達成できるスループットが向上します。
+ SQL Server は、1 回のバックアップ処理中に複数のファイルへの書き込みを同時にサポートします。例えば、T-SQL コマンドまたは SQL Server Management Studio (SSMS) を使用して、複数のファイル送信先を指定できます。各ファイルは、個別のスレッドを使用して SQL Server からゲートウェイファイル共有にデータを送信します。この方法により、I/O スループットが向上し、バックアップの速度と効率を大幅に向上できます。
SQL Server バックアップを設定するときは、次の点を考慮してください。
+ バックアップを複数のファイルに分割することで、SQL Server 管理者はバックアップ時間を最適化し、大規模なデータベースバックアップをより効果的に管理できます。
+ 使用するファイル数は、サーバーのストレージ設定とパフォーマンス要件によって異なります。大規模なデータベースでは、バックアップをそれぞれ 10 GB から 20 GB までのいくつかの小さなファイルに分割することを推奨します。
+ SQL Server がバックアップ中に書き込むことができるファイルの数には厳密な制限はありませんが、ストレージアーキテクチャやネットワーク帯域幅などの実用的な検討事項が指針となるでしょう。
詳細については、以下を参照してください。
+ [複数のファイルに書き込むことで SQL Server を 43 ～ 67% 高速化](https://www.brentozar.com/archive/2020/08/back-up-sql-server-43-67-faster-by-writing-to-multiple-files/)
+ [ファイルゲートウェイを使用して SQL Server のバックアップを Amazon S3 に簡単に保存](https://aws.amazon.com/blogs/storage/easily-store-your-sql-server-backups-in-amazon-s3-using-file-gateway/)
## SMB タイムアウト設定を増やして大きなファイルコピーの失敗を防止
S3 ファイルゲートウェイが大きな SQL バックアップファイルを SMB ファイル共有にコピーすると、SMB クライアント接続は長期間経過するとタイムアウトする可能性があります。ファイルのサイズとゲートウェイの書き込み速度に応じて、SQL サーバー SMB クライアントの SMB セッションタイムアウト設定を 20 分以上に延長することを推奨します。デフォルトは 300 秒 (5 分) です。詳細については、「[ゲートウェイのバックアップジョブが失敗する、またはゲートウェイへの書き込み時にエラーが発生する](https://docs.aws.amazon.com/filegateway/latest/files3/troubleshooting-file-gateway-issues.html#backup-job-fails)」を参照してください。
## Amazon S3 アップローダースレッドの数の増大
デフォルトでは、S3 ファイルゲートウェイは Amazon S3 データアップロード用に 8 つのスレッドを使用し、ほとんどの一般的なデプロイに十分なアップロード容量を提供します。ただし、ゲートウェイが標準の 8 スレッド容量で Amazon S3 にアップロードできる速度を超えて SQL サーバーからデータを受信する場合があります。これにより、ローカルキャッシュがストレージの上限に達する可能性があります。
特定の状況では、ゲートウェイの Amazon S3 アップロードスレッドプールの数を 8 から 40 に サポート 増やすことができます。これにより、より多くのデータを並行してアップロードできます。帯域幅やその他のデプロイに固有の要因によっては、アップロードパフォーマンスが大幅に向上し、ワークロードのサポートに必要なキャッシュストレージの量を減らすことができます。
`CachePercentDirty` CloudWatch メトリクスを使用して、Amazon S3 にまだアップロードされていないローカルゲートウェイキャッシュディスクに保存されているデータ量をモニタリングし、 サポート に連絡して、アップロードスレッドプール数を増やすことで S3 File Gateway のスループットが向上するかどうかを判断することをお勧めします。詳細については、「[ゲートウェイメトリクスについて](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics)」を参照してください。
**注記**
この設定では、追加のゲートウェイ CPU リソースを消費します。ゲートウェイの CPU 使用率をモニタリングし、必要に応じて割り当てられた CPU リソースを増やすことを推奨します。
## 自動キャッシュ更新の無効化
自動キャッシュ更新機能により、S3 ファイルゲートウェイはメタデータを自動的に更新できます。これにより、ユーザーやアプリケーションがゲートウェイを通さずに直接 Amazon S3 バケットに書き込んだファイルセットの変更を反映させることが可能になります。詳細については、[Amazon S3バケットオブジェクトキャッシュの更新](https://docs.aws.amazon.com/filegateway/latest/files3/refresh-cache.html)」を参照してください。
ゲートウェイのスループットを最適化するために、Amazon S3 バケットへのすべての読み取りと書き込みが S3 ファイルゲートウェイを介して実行されるデプロイでは、この機能をオフにすることをお勧めします。
自動キャッシュ更新を設定する際は、以下の点を考慮してください。
+ デプロイ内のユーザーまたはアプリケーションが Amazon S3 に直接書き込むことがあるため、自動キャッシュ更新を使用する必要がある場合は、更新間隔をできるだけ長く (業務ニーズに合理的な間隔で) 設定することを推奨します。キャッシュ更新間隔を長くすると、ディレクトリを参照したりファイルを変更したりするときにゲートウェイが実行する必要があるメタデータオペレーションの数を減らすことができます。
例えば、自動キャッシュ更新を 5 分ではなく 24 時間に設定します (ワークロードに許容できる範囲で)。
+ 最小更新間隔は 5 分です。最大間隔は 30 日間です。
+ 非常に短いキャッシュ更新間隔を設定する場合は、SQL サーバーのディレクトリ閲覧エクスペリエンスをテストすることをお勧めします。ゲートウェイキャッシュの更新にかかる時間は、Amazon S3 バケット内のファイル数とサブディレクトリ数によってかなり長くなる可能性があります。
## ワークロードをサポートするために複数のゲートウェイをデプロイする
Storage Gateway は、ワークロードを複数のゲートウェイに分割することで、数百の SQL データベース、複数の SQL Server、数百テラバイトのバックアップデータを持つ大規模な環境の SQL バックアップをサポートできます。
複数のゲートウェイと SQL サーバーを使用してデプロイを計画する場合は、次の点を考慮してください。
+ 通常、1 つのゲートウェイで 1 日あたり最大 20 TB のハードウェアリソースと帯域幅をアップロードできます。Amazon S3 アップローダースレッドの数を増やすことで、[この制限を 1 日あたり 40 TB まで増やす](https://docs.aws.amazon.com/filegateway/latest/files3/SQL-Backup-Best-Practices.html#SQL-Backup-Uploader-Threads)ことができます。
+ 概念実証テストを実施してパフォーマンスを測定し、デプロイ内のすべての変数を考慮することをお勧めします。SQL バックアップワークロードのピークスループットを決定したら、要件を満たすようにゲートウェイの数をスケールできます。
+ データベースの数とデータベースのサイズは時間の経過とともに増加する可能性があるため、成長を念頭に置いてソリューションを設計することをお勧めします。増加するワークロードを引き続きスケーリングしてサポートするために、必要に応じて追加のゲートウェイをデプロイできます。
## データベースバックアップワークロードの追加リソース
+ [を使用して SQL Server バックアップを Amazon S3 に保存 AWS Storage Gateway](https://aws.amazon.com/blogs/database/storing-sql-server-backups-in-amazon-s3-using-aws-storage-gateway/)
+ [ファイルゲートウェイを使用して SQL Server のバックアップを Amazon S3 に簡単に保存できる](https://aws.amazon.com/blogs/storage/easily-store-your-sql-server-backups-in-amazon-s3-using-file-gateway/)
+ [AWS Storage Gateway を使用して Oracle データベースのバックアップを Amazon S3 に保存](https://aws.amazon.com/blogs/storage/using-aws-storage-gateway-to-store-oracle-database-backups-in-amazon-s3/)
+ [Oracle データベースを Amazon S3 に大規模にバックアップ](https://aws.amazon.com/blogs/storage/backing-up-oracle-databases-to-amazon-s3-at-scale/)
+ [を使用して SAP ASE データベースを Amazon S3 に統合する AWS Storage Gateway](https://aws.amazon.com/blogs/storage/integrate-an-sap-ase-database-to-amazon-s3-using-aws-storage-gateway/)
+ [1 人の AWS HERO がクラウド内バックアップ AWS Storage Gateway に を使用する方法](https://aws.amazon.com/blogs/storage/how-one-aws-hero-uses-aws-storage-gateway-for-in-cloud-backup/)
+ [S3 ファイルゲートウェイキャッシュサイジングのベストプラクティス](https://www.youtube.com/watch?v=-ibL1eEcROI)