S3 File Gateway スループットの最大化 - AWS Storage Gateway
クライアントと同じ場所にゲートウェイをデプロイするディスクの速度低下によるボトルネックの軽減CPU、RAM、キャッシュディスクの仮想マシンリソース割り当てを調整するSMB セキュリティレベルを調整する複数のスレッドとクライアントを使用して書き込みオペレーションを並列化する自動キャッシュ更新をオフにするAmazon S3 アップローダースレッドの数を増やすSMB タイムアウト設定を増やす互換性のあるアプリケーションの日和見ロックを有効にする作業ファイルセットのサイズに応じてゲートウェイ容量を調整する複数のゲートウェイを大規模なワークロードにデプロイする

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

S3 File Gateway スループットの最大化

以下のセクションでは、NFS クライアントと SMB クライアント、S3 ファイルゲートウェイ、Amazon S3 間のスループットを最大化するためのベストプラクティスについて説明します。各セクションで提供されるガイダンスは、全体的なスループットの向上に段階的に貢献します。これらの推奨事項はいずれも必要ではなく、相互に依存しませんが、 サポート が S3 File Gateway 実装のテストとチューニングに使用する論理的な方法で選択および順序付けされています。これらの提案を実装してテストするときは、S3 File Gateway の各デプロイは一意であるため、結果が異なる場合があります。

S3 File Gateway は、業界標準の NFS または SMB ファイルプロトコルを使用して Amazon S3 オブジェクトを保存および取得するためのファイルインターフェイスを提供し、ファイルとオブジェクト間のネイティブ 1:1 マッピングを提供します。S3 File Gateway は、オンプレミスの VMware、Microsoft Hyper-V、Linux KVM 環境に仮想マシンとしてデプロイするか、Amazon EC2 インスタンスとして AWS クラウドにデプロイします。S3 File Gateway は、完全なエンタープライズ NAS 置換として機能するように設計されていません。S3 File Gateway はファイルシステムをエミュレートしますが、ファイルシステムではありません。Amazon S3 を耐久性のあるバックエンドストレージとして使用すると、I/O オペレーションごとに追加のオーバーヘッドが発生するため、既存の NAS またはファイルサーバーに対して S3 File Gateway のパフォーマンスを評価することは同等の比較ではありません。

クライアントと同じ場所にゲートウェイをデプロイする

S3 File Gateway 仮想アプライアンスは、S3 File Gateway 仮想アプライアンスと NFS または SMB クライアント間のネットワークレイテンシーをできるだけ小さくして、物理的な場所にデプロイすることをお勧めします。ゲートウェイの場所を選択するときは、次の点を考慮してください。

  • ゲートウェイへのネットワークレイテンシーを短くすると、NFS または SMB クライアントのパフォーマンスを向上させることができます。

  • S3 File Gateway は、ゲートウェイとクライアント間よりもゲートウェイと Amazon S3 間のネットワークレイテンシーが高くなるように設計されています。

  • Amazon EC2 にデプロイされた S3 File Gateway インスタンスの場合、ゲートウェイと NFS または SMB クライアントを同じプレイスメントグループに保持することをお勧めします。詳細については、Amazon EC2 インスタンスのプレイスメントグループ」を参照してください。

ディスクの速度低下によるボトルネックの軽減

IoWaitPercent CloudWatch メトリクスをモニタリングして、S3 File Gateway の低速ストレージディスクに起因するパフォーマンスのボトルネックを特定することをお勧めします。ディスク関連のパフォーマンス問題を最適化する場合は、次の点を考慮してください。

  • IoWaitPercent は、CPU がルートディスクまたはキャッシュディスクからの応答を待っている時間の割合を報告します。

  • IoWaitPercent が 5～10% を超えると、通常、パフォーマンスの低いディスクに起因するゲートウェイパフォーマンスのボトルネックを示します。このメトリクスはできるだけ 0% に近い値にする必要があります。つまり、ゲートウェイはディスクを待たないので、CPU リソースの最適化に役立ちます。

  • Storage Gateway コンソールのモニタリングタブIoWaitPercentで確認するか、メトリクスが特定のしきい値を超えた場合に自動的に通知するように推奨 CloudWatch アラームを設定できます。詳細については、「ゲートウェイの推奨 CloudWatch アラームの作成」を参照してください。

  • を最小限に抑えるには、ゲートウェイのルートディスクとキャッシュディスクに NVMe または SSD を使用することをお勧めしますIoWaitPercent。

CPU、RAM、キャッシュディスクの仮想マシンリソース割り当てを調整する

S3 File Gateway のスループットを最適化しようとするときは、CPU、RAM、キャッシュディスクなど、ゲートウェイ VM に十分なリソースを割り当てることが重要です。4 CPUs、16GB RAM、150GB キャッシュストレージの最小仮想リソース要件は、通常、小規模なワークロードにのみ適しています。大規模なワークロードに仮想リソースを割り当てる場合は、次のことをお勧めします。

  • S3 File Gateway によって生成される一般的な CPUs 使用率に応じて、割り当てられた CPU の数を 16～48 に増やします。UserCpuPercent メトリクスを使用して CPU 使用率をモニタリングできます。詳細については、「ゲートウェイメトリクスについて」を参照してください。

  • 割り当てられた RAM を 32～64 GB に増やします。

    注記

    S3 File Gateway は 64 GB を超える RAM を使用できません。

  • ルートディスクとキャッシュディスクに NVMe または SSD を使用し、ゲートウェイに書き込む予定のピーク作業データセットに合わせてキャッシュディスクのサイズを設定します。詳細については、公式の Amazon Web Services YouTube チャンネルのS3 File Gateway キャッシュサイジングのベストプラクティス」を参照してください。

  • 1 つの大きなディスクを使用するのではなく、少なくとも 4 つの仮想キャッシュディスクをゲートウェイに追加します。複数の仮想ディスクは、基盤となる同じ物理ディスクを共有していてもパフォーマンスを向上させることができますが、仮想ディスクが異なる基盤となる物理ディスクに配置されると、通常は改善点が大きくなります。

    たとえば、12TB のキャッシュをデプロイする場合は、次のいずれかの設定を使用できます。

    • 4 x 3 TB キャッシュディスク

    • 8 x 1.5 TB キャッシュディスク

    • 12 x 1 TB キャッシュディスク

    これにより、パフォーマンスに加えて、時間の経過とともに仮想マシンをより効率的に管理できます。ワークロードの変化に応じて、個々の仮想ディスクの元のサイズを維持しながら、キャッシュディスクの数と全体的なキャッシュ容量を段階的に増やして、ゲートウェイの整合性を維持できます。

    詳細については、「ローカルディスクストレージの量を決定する」を参照してください。

S3 File Gateway を Amazon EC2 インスタンスとしてデプロイする場合は、次の点を考慮してください。

  • 選択したインスタンスタイプは、ゲートウェイのパフォーマンスに大きな影響を与える可能性があります。Amazon EC2 は、S3 File Gateway インスタンスのリソース割り当てを柔軟に調整できます。

  • S3 File Gateway に推奨される Amazon EC2 インスタンスタイプについては、Amazon EC2 インスタンスタイプの要件」を参照してください。

  • アクティブな S3 File Gateway をホストする Amazon EC2 インスタンスタイプを変更できます。これにより、Amazon EC2 ハードウェアの生成とリソースの割り当てを簡単に調整して、理想的なprice-to-performanceの比率を見つけることができます。インスタンスタイプを変更するには、Amazon EC2 コンソールで次の手順を使用します。

    1. Amazon EC2 インスタンスを停止します。

    2. Amazon EC2 インスタンスタイプを変更します。

    3. Amazon EC2 インスタンスの電源を入れます。

    注記

    S3 File Gateway をホストするインスタンスを停止すると、ファイル共有アクセスが一時的に中断されます。必要に応じて、メンテナンスウィンドウを必ずスケジュールしてください。

  • Amazon EC2 インスタンスのprice-to-performance比は、支払う料金に対して得られるコンピューティング能力を示します。通常、新世代の Amazon EC2 インスタンスは、price-to-performance比を提供します。インスタンスタイプ、リージョン、使用パターンなどの要因がこの比率に影響するため、費用対効果を最適化するには、特定のワークロードに適したインスタンスを選択することが重要です。

SMB セキュリティレベルを調整する

SMBv3 プロトコルでは、SMB 署名と SMB 暗号化の両方が許可され、パフォーマンスとセキュリティにいくつかのトレードオフがあります。スループットを最適化するには、ゲートウェイの SMB セキュリティレベルを調整して、クライアント接続に適用されるこれらのセキュリティ機能を指定できます。詳細については、「ゲートウェイのセキュリティレベルを設定する」を参照してください。

SMB セキュリティレベルを調整するときは、次の点を考慮してください。

  • S3 File Gateway のデフォルトのセキュリティレベルは、Enforce 暗号化です。この設定では、ゲートウェイファイル共有への SMB クライアント接続の暗号化と署名の両方が適用されます。つまり、クライアントからゲートウェイへのすべてのトラフィックが暗号化されます。この設定は、ゲートウェイから へのトラフィックには影響せず AWS、常に暗号化されます。

    ゲートウェイは、暗号化された各クライアント接続を 1 つの vCPU に制限します。たとえば、暗号化されたクライアントが 1 つしかない場合、4 つ以上の vCPU がゲートウェイに割り当てられていても、そのクライアントは 1 つの vCPUs に制限されます。このため、単一のクライアントから S3 File Gateway への暗号化された接続のスループットは通常、40～60 MB/秒の間でボトルネックになります。

  • セキュリティ要件でより緩やかな体制が許可されている場合は、セキュリティレベルをクライアントネゴシエートに変更できます。これにより、SMB 暗号化が無効になり、SMB 署名のみが適用されます。この設定では、ゲートウェイへのクライアント接続で複数の vCPUsを利用できるため、通常、スループットパフォーマンスが向上します。

    注記

    S3 File Gateway の SMB セキュリティレベルを変更したら、ファイル共有ステータスが Storage Gateway コンソールの更新から使用可能に変わるのを待ってから、新しい設定を有効にするために SMB クライアントを切断して再接続する必要があります。

複数のスレッドとクライアントを使用して書き込みオペレーションを並列化する

単一のクライアントからのシーケンシャル書き込みはシングルスレッドオペレーションであるため、一度に 1 つの NFS または SMB クライアントのみを使用して 1 つのファイルを書き込む S3 File Gateway では、スループットパフォーマンスを最大化することは困難です。代わりに、各 NFS または SMB クライアントの複数のスレッドを使用して複数のファイルを並行して書き込み、複数の NFS または SMB クライアントを同時に S3 File Gateway に使用してゲートウェイのスループットを最大化することをお勧めします。

複数のスレッドを使用すると、パフォーマンスが大幅に向上します。ただし、より多くのスレッドを使用するには、より多くのシステムリソースが必要です。これは、ゲートウェイが増加した負荷を満たすようにサイズ設定されていない場合、パフォーマンスに悪影響を及ぼす可能性があります。一般的なデプロイでは、ゲートウェイの最大ハードウェアと帯域幅の制限に達するまで、スレッドとクライアントを追加すると、スループットのパフォーマンスが向上します。さまざまなスレッド数を試して、特定のハードウェアとネットワーク設定の速度とシステムリソースの使用状況の最適なバランスを見つけることをお勧めします。

スレッドとクライアント設定のテストに役立つ一般的なツールについては、次の情報を考慮してください。

  • マルチスレッド書き込みパフォーマンスをテストするには、robocopy などのツールを使用して、一連のファイルをゲートウェイ上のファイル共有にコピーします。デフォルトでは、robocopy はファイルのコピー時に 8 つのスレッドを使用しますが、最大 128 のスレッドを指定できます。

    robocopy で複数のスレッドを使用するには、 コマンドに /MT:nスイッチを追加します。ここで、 nは使用するスレッドの数です。例:

    robocopy C:\source D:\destination /MT:64

    このコマンドは、コピーオペレーションに 64 スレッドを使用します。

    注記

    最大スループットのテスト時に Windows Explorer を使用してファイルをドラッグアンドドロップすることはお勧めしません。この方法は 1 つのスレッドに制限され、ファイルを順番にコピーするためです。

    詳細については、Microsoft Learn ウェブサイトの「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 を使用してワークロードストレージのパフォーマンスをテストする」を参照してください。

  • 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 Linux の man ページを参照してください。

自動キャッシュ更新をオフにする

自動キャッシュ更新機能により、S3 File Gateway はメタデータを自動的に更新できます。これにより、ユーザーまたはアプリケーションがファイルセットに加えた変更を、ゲートウェイではなく Amazon S3 バケットに直接書き込むことでキャプチャできます。詳細については、Amazon S3バケットオブジェクトキャッシュの更新」を参照してください。

ゲートウェイのスループットを最適化するために、Amazon S3 バケットへのすべての読み取りと書き込みが S3 ファイルゲートウェイを介して実行されるデプロイでは、この機能をオフにすることをお勧めします。

自動キャッシュ更新を設定するときは、次の点を考慮してください。

  • デプロイ内のユーザーまたはアプリケーションが Amazon S3 に直接書き込むことがあるため、自動キャッシュ更新を使用する必要がある場合は、ビジネスニーズにとって依然として実用的な更新間隔をできるだけ長く設定することをお勧めします。キャッシュ更新間隔を長くすると、ディレクトリを参照したりファイルを変更したりするときにゲートウェイが実行する必要があるメタデータオペレーションの数を減らすことができます。

    例えば、ワークロードに許容できる場合は、自動キャッシュ更新を 5 分ではなく 24 時間に設定します。

  • 最小時間間隔は 5 分です。最大間隔は 30 日です。

  • 非常に短いキャッシュ更新間隔を設定する場合は、NFS および SMB クライアントのディレクトリブラウジングエクスペリエンスをテストすることをお勧めします。ゲートウェイキャッシュの更新にかかる時間は、Amazon S3 バケット内のファイルとサブディレクトリの数に応じて大幅に長くなる可能性があります。

Amazon S3 アップローダースレッドの数を増やす

デフォルトでは、S3 File Gateway は Amazon S3 データアップロード用に 8 つのスレッドを開き、ほとんどの一般的なデプロイに十分なアップロード容量を提供します。ただし、ゲートウェイが標準の 8 スレッド容量で Amazon S3 にアップロードできるよりも高いレートで NFS および SMB クライアントからデータを受信する可能性があります。これにより、ローカルキャッシュがストレージ制限に達する可能性があります。

特定の状況では、ゲートウェイの Amazon S3 アップロードスレッドプールの数を 8 から 40 に増やす サポート ことができます。これにより、より多くのデータを並行してアップロードできます。帯域幅やその他のデプロイに固有の要因によっては、アップロードパフォーマンスが大幅に向上し、ワークロードのサポートに必要なキャッシュストレージの量を減らすことができます。

CachePercentDirty CloudWatch メトリクスを使用して、Amazon S3 にまだアップロードされていないローカルゲートウェイキャッシュディスクに保存されているデータ量をモニタリングし、 サポート に連絡して、アップロードスレッドプール数を増やすことで S3 File Gateway のスループットが向上するかどうかを判断することをお勧めします。詳細については、「ゲートウェイメトリクスについて」を参照してください。

注記

この設定では、追加のゲートウェイ CPU リソースを消費します。ゲートウェイの CPU 使用率をモニタリングし、必要に応じて割り当てられた CPU リソースを増やすことをお勧めします。

SMB タイムアウト設定を増やす

S3 File Gateway が大きなファイルを SMB ファイル共有にコピーすると、SMB クライアント接続は長期間経過するとタイムアウトする可能性があります。

ファイルのサイズとゲートウェイの書き込み速度に応じて、SMB クライアントの SMB セッションタイムアウト設定を 20 分以上に拡張することをお勧めします。デフォルトは 300 秒、つまり 5 分です。詳細については、「ゲートウェイバックアップジョブが失敗するか、ゲートウェイへの書き込み時にエラーが発生します。」を参照してください。

互換性のあるアプリケーションの日和見ロックを有効にする

オポチュニスティックロック、つまり「oplocks」は、新しい S3 File Gateway ごとにデフォルトで有効になっています。互換性のあるアプリケーションでオプトロックを使用する場合、クライアントは複数の小さなオペレーションを大きなオペレーションにバッチ処理します。これは、クライアント、ゲートウェイ、ネットワークにとってより効率的です。Microsoft Office、Adobe Suite など、クライアント側のローカルキャッシュを活用するアプリケーションを使用する場合は、オポチュニスティックロックをオンにしておくことをお勧めします。これにより、パフォーマンスが大幅に向上する可能性があります。

オポチュニスティックロックをオフにすると、オプロックをサポートするアプリケーションは通常、大きなファイル (50 MB 以上) をよりゆっくりと開きます。この遅延は、ゲートウェイが 4 KB のパートでデータを送信するために発生します。これにより、I/O が高くなり、スループットが低くなります。

作業ファイルセットのサイズに応じてゲートウェイ容量を調整する

ゲートウェイ容量パラメータは、ゲートウェイがローカルキャッシュにメタデータを保存するファイルの最大数を指定します。デフォルトでは、ゲートウェイ容量は Small に設定されています。つまり、ゲートウェイは最大 500 万個のファイルのメタデータを保存します。デフォルト設定は、Amazon S3 に数億または数十億のオブジェクトがある場合でも、ほとんどのワークロードでうまく機能します。これは、通常のデプロイで特定の時間にアクティブにアクセスするファイルのサブセットがごくわずかであるためです。このファイルのグループは、「ワーキングセット」と呼ばれます。

ワークロードが 500 万を超えるファイルのワーキングセットに定期的にアクセスする場合、ゲートウェイは頻繁にキャッシュエビクションを実行する必要があります。これは、RAM に保存され、ルートディスクに保持される小さな I/O オペレーションです。ゲートウェイが Amazon S3 から新しいデータを取得すると、ゲートウェイのパフォーマンスに悪影響を及ぼす可能性があります。

IndexEvictions メトリクスをモニタリングして、メタデータがキャッシュから削除されたファイルの数を決定し、新しいエントリのスペースを確保できます。詳細については、「ゲートウェイメトリクスについて」を参照してください。

UpdateGatewayInformation API アクションを使用して、一般的なワーキングセット内のファイル数に対応するようにゲートウェイ容量を増やすことをお勧めします。詳細については、「UpdateGatewayInformation」を参照してください。

注記

ゲートウェイ容量を増やすには、追加の 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 ですが、ゲートウェイによって管理されるファイル共有の数はゲートウェイのパフォーマンスに影響を与える可能性があります。詳細については、「複数のファイル共有を持つゲートウェイのパフォーマンスガイダンス」を参照してください。

  • 各 S3 File Gateway のリソースは、パーティション化せずにすべてのファイル共有で共有されます。

  • 使用量の多い単一のファイル共有は、ゲートウェイ上の他のファイル共有のパフォーマンスに影響を与える可能性があります。

注記

少なくとも 1 つのゲートウェイが読み取り専用でない限り、複数のゲートウェイから同じ Amazon S3 の場所にマッピングされた複数のファイル共有を作成することはお勧めしません。

複数のゲートウェイから同じファイルへの同時書き込みは、マルチライターシナリオと見なされ、データ整合性の問題が発生する可能性があります。