SQL Server データベースバックアップ用の S3 ファイルゲートウェイの最適化 - AWS Storage Gateway
SQL Server と同じ場所へのゲートウェイのデプロイ低速ディスクによるボトルネックの軽減CPU、RAM、キャッシュディスクの S3 ファイルゲートウェイ仮想マシンリソース割り当ての調整S3 ファイルゲートウェイのセキュリティレベルを調整して SMB クライアントのスループットを向上SQL バックアップを複数のファイルに分割して SMB クライアントのスループットを向上SMB タイムアウト設定を増やして大きなファイルコピーの失敗を防止Amazon S3 アップローダースレッドの数の増大自動キャッシュ更新の無効化ワークロードをサポートするために複数のゲートウェイをデプロイするデータベースバックアップワークロードの追加リソース

新規のお客様への Amazon FSx ファイルゲートウェイの提供は終了しました。FSx ファイルゲートウェイの既存のお客様は、引き続き通常どおりサービスを使用できます。FSx ファイルゲートウェイに似た機能については、このブログ記事を参照してください。

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

SQL Server データベースバックアップ用の S3 ファイルゲートウェイの最適化

データベースのバックアップは、S3 ファイルゲートウェイの一般的で推奨されるユースケースです。S3 ファイルゲートウェイは、データベースのバックアップを Amazon S3 に保存することで、コスト効率の高い短期および長期の保持を提供し、必要に応じてライフサイクル管理により低コストのストレージ階層へ移行することができます。このソリューションを使用すると、SQL Server Management Studio や Oracle RMAN などの組み込みツールを使用して、エンタープライズバックアップアプリケーションの必要性を減らすことができます。

次のセクションでは、S3 ファイルゲートウェイのデプロイを最適化し、数百テラバイト規模の SQL データベースバックアップをコスト効率よくサポートするためのベストプラクティスについて説明します。各セクションで提供されるガイダンスは、全体的なスループットの段階的な向上に有用です。これらの推奨事項はいずれも必須ではなく、相互に依存するものでもありませんが、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 ファイルゲートウェイのパフォーマンスを比較して評価しても、同等の比較にはなりません。

SQL Server と同じ場所へのゲートウェイのデプロイ

S3 ファイルゲートウェイの仮想アプライアンスは、SQL Server との間のネットワークレイテンシーができるだけ小さい物理ロケーションにデプロイすることを推奨します。ゲートウェイの場所を選択するときは、次の点を考慮してください。

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

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

  • Amazon EC2 にデプロイされた S3 ファイルゲートウェイインスタンスの場合、ゲートウェイと SQL サーバーを同じプレイスメントグループに保持することをお勧めします。詳細については、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 ファイルゲートウェイ仮想マシンリソース割り当ての調整

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 インスタンスのほうが、最高レベルの費用対効果比を実現できます。つまり、旧世代と比べて比較的低コストで、より新しいハードウェアを使用することで、パフォーマンスが向上します。インスタンスタイプ、リージョン、使用パターンなどの要因がこの比率に影響するため、コスト効率を最適化するには、そのワークロードに適したインスタンスを選択することが重要です。

S3 ファイルゲートウェイのセキュリティレベルを調整して 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 クライアントを切断してから再接続すると、新しい設定が有効になります。

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 がバックアップ中に書き込むことができるファイルの数には厳密な制限はありませんが、ストレージアーキテクチャやネットワーク帯域幅などの実用的な検討事項が指針となるでしょう。

詳細については、以下を参照してください。

SMB タイムアウト設定を増やして大きなファイルコピーの失敗を防止

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

Amazon S3 アップローダースレッドの数の増大

デフォルトでは、S3 ファイルゲートウェイは Amazon S3 データアップロード用に 8 つのスレッドを使用し、ほとんどの一般的なデプロイに十分なアップロード容量を提供します。ただし、ゲートウェイが標準の 8 スレッド容量で Amazon S3 にアップロードできる速度を超えて SQL サーバーからデータを受信する場合があります。これにより、ローカルキャッシュがストレージの上限に達する可能性があります。

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

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

注記

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

自動キャッシュ更新の無効化

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

ゲートウェイのスループットを最適化するために、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 まで増やすことができます。

  • 概念実証テストを実施してパフォーマンスを測定し、デプロイ内のすべての変数を考慮することをお勧めします。SQL バックアップワークロードのピークスループットを決定したら、要件を満たすようにゲートウェイの数をスケールできます。

  • データベースの数とデータベースのサイズは時間の経過とともに増加する可能性があるため、成長を念頭に置いてソリューションを設計することをお勧めします。増加するワークロードを引き続きスケーリングしてサポートするために、必要に応じて追加のゲートウェイをデプロイできます。

データベースバックアップワークロードの追加リソース