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

S3 ファイルゲートウェイスループットの最大化

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

S3 ファイルゲートウェイは、業界標準の NFS または SMB ファイルプロトコルを使用して Amazon S3 オブジェクトを保存および取得するためのファイルインターフェイスを提供し、ファイルとオブジェクトの間にネイティブな 1:1 のマッピングを備えています。S3 ファイルゲートウェイは、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 インスタンスの配置グループ」を参照してください。

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

IoWaitPercent CloudWatch メトリクスをモニタリングして、S3 ファイルゲートウェイの低速ストレージディスクが原因で発生するパフォーマンスのボトルネックを特定することを推奨します。ディスク関連のパフォーマンス問題を最適化する場合は、次の点を考慮してください。

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

  • IoWaitPercent が 5～10% を超えると、通常、パフォーマンスの低いディスクが原因でゲートウェイパフォーマンスのボトルネックが発生していることを示します。このメトリクスはできるだけ 0% に近い値 (つまり、ゲートウェイのディスク待機時間がない状態) にする必要があります。これにより、CPU リソースを最適化できます。

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

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

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

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

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

  • 割り当てる RAM 数を 32～64 GB に増やします。

    注記

    S3 ファイルゲートウェイは 64 GB を超える RAM を使用できません。

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

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

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

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

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

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

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

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

S3 ファイルゲートウェイを Amazon EC2 インスタンスとしてデプロイする場合は、次の点を考慮してください:

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

  • S3 ファイルゲートウェイに推奨される Amazon EC2 インスタンスタイプについては、Amazon EC2 インスタンスタイプの要件を参照してください。

  • アクティブな S3 ファイルゲートウェイをホストする Amazon EC2 インスタンスタイプを変更できます。これにより、Amazon EC2 ハードウェアの生成とリソースの割り当てを簡単に調整して、最適な費用対効果比を見つけることができます。インスタンスタイプを変更するには、Amazon EC2 コンソールで次の手順を使用します。

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

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

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

    注記

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

  • Amazon EC2 インスタンスの費用対効果比は、支払う料金に対してどれだけのコンピューティング能力を得られるかを示します。一般的に、より新しい世代の Amazon EC2 インスタンスのほうが、最高レベルの費用対効果比を実現できます。つまり、旧世代と比べて比較的低コストで、より新しいハードウェアを使用することで、パフォーマンスが向上します。インスタンスタイプ、リージョン、使用パターンなどの要因がこの比率に影響するため、コスト効率を最適化するには、そのワークロードに適したインスタンスを選択することが重要です。

SMB セキュリティレベルの調整

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

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 を参照してください。

  • 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 ファイルゲートウェイはメタデータを自動的に更新できます。これにより、ユーザーやアプリケーションがゲートウェイを通さずに直接 Amazon S3 バケットに書き込んだファイルセットの変更を反映させることが可能になります。詳細については、Amazon S3バケットオブジェクトキャッシュの更新」を参照してください。

ゲートウェイのスループットを最適化するために、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 ファイルゲートウェイのスループットが向上するかどうかを判断することを推奨します。詳細については、「ゲートウェイメトリクスについて」を参照してください。

注記

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

SMB タイムアウト設定の増大

S3 ファイルゲートウェイが大きなファイルを SMB ファイル共有にコピーする場合、長時間経過すると SMB クライアント接続がタイムアウトすることがあります。

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

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

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

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

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

ゲートウェイ容量パラメータは、ゲートウェイがローカルキャッシュにメタデータを保存するファイルの最大数を指定します。デフォルトでは、ゲートウェイ容量は 小 に設定されています。つまり、ゲートウェイは最大 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 ファイルゲートウェイのリソースは、パーティション化することなく、すべてのファイル共有で共有されます。

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

注記

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

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