Amazon Web Services ブログ
File Gateway を使用して SQL Server バックアップを Amazon S3 に簡単に保存する
昨年公開したブログで、AWS Storage Gateway をセットアップして、File Gateway でクラウドベースの SMB 共有を使用して SQL Server バックアップを Amazon S3 に保存する方法を説明しました。 オンプレミスのバックアップコストが増加し、運用オーバーヘッドが増加しているお客様は、SQL Server バックアップを永続的かつ確実に AWS に保存するために、このソリューションを使っています。これにより、費用を節約し、オンプレミスのストレージインフラストラクチャを削減しながら、バックアップ操作を簡素化できます。
File Gateway は、ローカルキャッシュを使用して S3 バケットに保存されたデータへの SMB および NFS アクセスを提供し、データへ低レイテンシーでアクセスできるようにします。AWS は前回のブログ記事以来、 Storage Gateway の多くの機能をリリースし、耐障害性を高め、パフォーマンスを向上させ、機能を強化しました。このような機能には、VMware デプロイの高可用性、SMB 共有の監査ログ記録、パフォーマンスの向上、統合された CloudWatch アラーム、および S3 Intelligent-Tiering のサポートなどがあります。
この記事では、前回のブログを基に、File Gateway の設定、モニタリング、パフォーマンスに関するベストプラクティスについて説明します。また、さまざまな File Gateway 環境設定で実行した SQL Server バックアップテストの結果を示します。さらに、これらの結果から外挿して、独自の SQL Server 環境を計画する方法も示します。このブログを読むと、SQL Server バックアップワークロード用のスケーラブルで耐久性のあるソリューションをより適切に設計できるようになっていることでしょう。
File Gateway が書き込みを処理する方法
ベストプラクティスについて説明する前に、File Gateway がクライアントからの書き込みをどのように処理するかを理解しておくとよいでしょう。File Gateway をデプロイするときに、ローカルキャッシュに割り当てるディスク容量を指定します。このローカルキャッシュは、書き込みのバッファとして機能し、最近 Amazon S3 に書き込まれた、または Amazon S3 から読み取られたデータへの低レイテンシーアクセスを提供します。クライアントが File Gateway 経由でファイルにデータを書き込むと、そのデータは最初にゲートウェイ自体のローカルキャッシュディスクに書き込まれます。データがローカルキャッシュに安全に保持された後でのみ、File Gateway はクライアントへのライトバックを確認します。そこから、File Gateway はバックグラウンドで非同期にデータを S3 バケットに転送し、マルチパート並列アップロードを使用してデータ転送を最適化し、転送中のデータを HTTPS を使用して暗号化します。
これはバックアップソリューションにどのような意味があるのでしょうか?
まず、File Gateway に書き込まれたデータがすぐに Amazon S3 にコミットされるのではなく、キャッシュから S3 にデータをアップロードするのに時間がかかることを認識することが重要です。アップロードに必要な時間はさまざまで、ネットワーク速度とキャッシュディスク設定の両方に左右されます。アップロードにかかる時間を確認するためにどの Amazon CloudWatch メトリクスをモニタリングできるかを示します。
次に、キャッシュのサイズを適切に設定します。キャッシュのサイズ設定に関する詳細な説明はこの後行いますが、大まかな原則として、アクティブなデータセットに十分なキャッシュを割り当てることです。この場合、そのデータセットはバックアップウィンドウ内でバックアップされるデータの量になります。また、CloudWatch メトリクスを使用してキャッシュの使用状況をモニタリングし、追加のキャッシュを割り当てる必要があるかどうか、またいつ割り当てる必要があるかを判断する方法についても説明します。
3 番目に、バックアップする SQL Server データベースが多数ある場合は、複数の File Gateway をデプロイして、バックアップタイムフレームを満たすのに十分なローカルキャッシュを提供してパフォーマンスを発揮する必要がある場合があります。パフォーマンスに関するセクションで、File Gateway の数のサイジングについて詳しく説明します。
セットアップと設定
お客様は File Gateway を使用して、オンプレミスと AWS の両方で実行されている SQL Server データベースをバックアップしています。SQL Server がオンプレミスで実行されている場合は、File Gateway をオンプレミス環境の仮想マシンまたは物理マシンとしてデプロイできます。SQL サーバーが AWS の Amazon EC2 上で実行されている場合、Amazon EC2 インスタンスとして File Gateway をデプロイできます。デプロイする環境に関係なく、File Gateway を設定するときは、システム要件に関するガイダンスに従ってください。EC2 にデプロイされた File Gateway をオンプレミスシステムと一緒に使用したり、逆にオンプレミスで実行されている場合は EC2 インスタンスとしてデプロイしたりすることは避けてください。ネットワークレイテンシーが増加すると、バックアップワークロードのパフォーマンスが大幅に低下するためです。
Amazon EC2 にデプロイする際の考慮事項
EC2 で実行される SQL Server バックアップワークロードでは、m5.2xlarge または r5.2xlarge インスタンスタイプを使用することをお勧めします。この記事のパフォーマンスセクションで示したように、これらのインスタンスタイプは I/O パフォーマンスとコストのバランスが取れています。ゲートウェイを作成するときは、File Gateway を実行する EC2 インスタンスを SQL Server EC2 インスタンスと同じアベイラビリティーゾーンにデプロイして、、異なるアベイラビリティーゾーンにデプロイすることでネットワーク料金が発生するのを回避する必要があります。
一部のお客様は、File Gateway に i3en などの EC2 インスタンスタイプを使用しています。このインスタンスタイプは、キャッシュに高速のローカル NVMe ストレージを提供しているためです。けれども、インスタンスが停止または終了すると、ローカルインスタンスストレージ上のすべてのデータが失われます。これは、新しいインスタンスで使用できるようになる前にインスタンスストア内のすべてのストレージブロックがリセットされるためです。ゲートウェイキャッシュにインスタンスストレージを使用する場合は、バックアップワークフローがこのようなイベントに耐えられるかどうかを検討する必要があります。
File Gateway でより高いレベルの可用性が必要な場合は、オンプレミスまたは VMware Cloud on AWS で VMware vSphere クラスターにデプロイすることをご検討ください。そうすることで、vSphere HA 機能とともに File Gateway の統合を利用できます。vSphere HA を使用すると、File Gateway はほとんどのサービスの中断から 60 秒未満で自動的に回復し、データを失うことはありません。これにより、ハードウェア、ハイパーバイザー、ネットワーク障害、それに接続タイムアウトやファイル共有、ボリュームの使用不可などのソフトウェアエラーからストレージワークロードを保護できます。
キャッシュのサイズ変更
File Gateway のデプロイ方法を決定したら、割り当てるキャッシュディスクの量を検討する必要があります。SQL Server バックアップワークロードでは、バックアップウィンドウ中に生成するバックアップのボリュームを処理するのに十分なキャッシュをデプロイすることをお勧めします。キャッシュが小さいと、パフォーマンスが低下したり、Amazon S3 へのアップロードの保留中にローカルにデータを保存するための空きキャッシュスペースがない場合に書き込み操作が途中で失敗したり、S3 オブジェクトとして保存されるファイルが完全にはアップロードされなかったりする可能性があります。キャッシュが保持できるよりも多くのデータを書き込むと、ゲートウェイはキャッシュスペースを解放する方法として、ファイルの部分的なアップロードを Amazon S3 に書き込みます。この場合、S3 バケットでバージョン管理が設定されていると、ファイルは部分的にアップロードされてオブジェクトバージョンとして保存されることになります。
ゲートウェイには、いつでもキャッシュのディスク容量を追加できます (File Gateway のその時点のクォータを上限として)。ただし、いったんキャッシュ容量を追加すると、削除することはできません。これを念頭に置いて、アプリケーションのニーズを満たす最小のキャッシュ容量から始めて、必要に応じてキャッシュを拡張することをお勧めします。
Amazon S3 の設定
File Gateway はすべてのデータを Amazon S3 に保存するため、S3 バケットの設定は重要なステップです。重要な考慮事項の 1 つは、バケットのバージョン管理です。バケット内のデータの偶発的な上書きから保護するためにバージョン管理を有効にするか、S3 Object Lock またはバケットレプリケーションを使用する一環としてバージョン管理を有効にしてもよいでしょう。S3 バケットでバージョン管理が有効になっている場合、File Gateway は同じオブジェクトの複数のバージョンを短時間で作成することができます。これはさまざまな理由で発生しますが、主に、S3 オブジェクトがイミュータブルな性質を持っているのに対して、ファイルの操作はミュータブルであることが原因で発生します。バージョン管理を有効にして、オブジェクトごとに作成されるバージョンの数をモニタリングします。または有効期限ポリシーを作成して、一定期間後にオブジェクトの古いバージョンを削除することをご検討ください。
お客様のアプリケーションのアクセスパターンに基づいて、どの Amazon S3 ストレージクラスを使用するかもご検討ください。File Gateway は、S3 標準、S3 標準 – 低頻度アクセス (S3 標準 – IA)、S3 One Zone – 低頻度アクセス、および S3 Intelligent-Tiering のストレージクラスをサポートしています。使用するストレージクラスは、データにアクセスする頻度によって異なります。データに頻繁にアクセスする場合は、S3 標準を選択します。データへのアクセス頻度が低い場合は、クラスにより追加のアクセス料金がかかることを考慮して、アクセス頻度の低いストレージクラスのいずれかを使用してください。アクセスパターンがわからない場合は、S3 Intelligent-Tiering が最適です。S3 Intelligent-Tiering は、パフォーマンスへの影響や運用上のオーバーヘッドなしに、長期的に見たアクセス頻度に基づいて、データに適切なアクセス階層を自動的に選択します。SQL Server のバックアップワークロードの場合、バックアップファイルに頻繁にアクセスすることはあまりないため、S3 Standard-IA または S3 Intelligent-Tiering が適しています。
モニタリング
File Gateway には、システムをモニタリングするための方法がいくつもあります。CloudWatch Logs を使用してゲートウェイと関連リソースの正常性に関する情報を取得できます。また、CloudWatch メトリクスと CloudWatch アラームを使用してパフォーマンスとゲートウェイの状態をモニタリングできます。CloudWatch メトリクスとアラームの両方を Storage Gateway コンソールから直接モニタリングできます。個々のファイル共有のほかに、ゲートウェイのメトリクスもあります。以下、File Gateway が提供する主要なメトリクスのいくつかを確認しましょう。
CachePercentDirty: このメトリクスは、ゲートウェイとファイル共有の両方で使えます。これは、Amazon S3 にアップロードされていない「ダーティ」データを保持するために使用するキャッシュの割合を定義します。このメトリクスが 100% に達すると、ダーティデータがアップロードされてキャッシュが使用可能になるまでゲートウェイは新しいデータを受け入れず、クライアントは I/O エラーを受け取ります。CloudWatch アラームを 70% に設定し、誤警報を防ぐために 3 つのデータポイントの後にトリガーされるように設定することをお勧めします。アラームが定期的にトリガーされる場合は、ゲートウェイのキャッシュを増やす必要があることを示している可能性があります。
WriteBytes: このメトリクスは、NFS または SMB プロトコル経由でオンプレミスアプリケーションによって書き込まれているデータの量を示します。これを使用して SQL Server バックアップジョブのパフォーマンスをモニタリングし、目的の RPO/RTO ターゲットに到達していることを確認できます。
CloudBytesUploaded: このメトリクスは、キャッシュから Amazon S3 にアップロードされているデータの量を示します。このメトリクスを WriteBytes と併用して、アプリケーションがデータを取り込む速度と、データがクラウドにアップロードされる速度を比較できます。データがアップロードよりも速く書き込まれている場合、使用可能なキャッシュを使い果たし、I/O エラーが発生する可能性があります。これに対処するには、使用可能なキャッシュを増やすか、ゲートウェイで使用できるネットワーク帯域幅を増やす必要がある場合があります。
IoWaitPercent: このメトリクスは、ゲートウェイがローカルディスクからの応答を待機している時間の割合を報告します。4 つのデータポイントの後でトリガーされるアラームを 10% に設定することをお勧めします。このメトリクスが定期的に 10% を超える場合は、ローカルキャッシュディスクの速度によってゲートウェイがボトルネックになっている可能性があります。キャッシュにはローカルソリッドステートドライブ (SSD) ディスク、できれば NVM Express (NVMe) をお勧めします。そのようなディスクが利用できない場合は、パフォーマンスを向上させるために、個別の物理ディスクから複数のキャッシュディスクを使用してみてください。
CloudWatch メトリクスに加えて、File Gateway は SMB 共有の監査ログ記録もサポートしています。監査ログにより、ユーザーアクティビティをモニタリングし、不適切なアクティビティパターンが特定された場合にアクションを実行できます。File Gateway 監査ログは、モニタリング可能な属性をいくつも提供し、IT 管理者およびコンプライアンス管理者に、ファイルおよびフォルダへのユーザーアクセスについて必要な情報を提供します。SQL Server のバックアップワークロードでは、監査ログ記録を用いてコンプライアンスのニーズを満たし、バックアップファイルへのアクセスをモニタリングし、発生する可能性のあるアクセスエラーをトラブルシューティングできます。
お客様は古いバックアップを Amazon S3 Glacier または S3 Glacier Deep Archive に保存して、コンプライアンスの長期保存要件を満たしながらストレージコストを削減することがあります。File Gateway が Amazon S3 Glacier または S3 Glacier Deep Archive に移動したファイルを読み取ろうとすると、I/O エラーを返します。ただし、CloudWatch イベントを使用して、アーカイブされたバックアップファイルを自動的に取得して、データベースサーバーに復元できるようにすることができます。
パフォーマンス
いくつかの基本的なバックアップテストを実行して、オンプレミスとクラウドの両方のバックアップシナリオで、さまざまな File Gateway 設定でパフォーマンスはどのようになるかをご覧に入れました。すべてのテストで、SQL Server 2017 を使用して、1 つ以上の 20-GiB データベースの完全非圧縮バックアップを実行して、File Gateway 上の 1 つの SMB 共有を実現しました。すべてのケースで、バックアップ時間は 5 回実行して得られた時間を平均して計測しました。
その際、インスタンスストレージを備えた EC2 (i3en.2xlarge)、Amazon EBS ストレージを備えた EC2 (c5.2xlarge、m5.2xlarge、r5.2xlarge)、および SSD ストレージを備えたオンプレミス VMware の 3 種類のゲートウェイキャッシュ設定を使いました。EBS 設定の EC2 では、スループットを向上させるために複数のボリュームを用いて、キャッシュストレージのインスタンスごとに 3 つの 1 TiB gp2 ボリュームを使用しました。
最初のテストでは、さまざまな File Gateway 設定で 1 つの 20-GiB データベースをバックアップする時間を比較しました。
グラフから、i3en.2xlarge が最高のパフォーマンスを発揮したことがわかります (つまり、バックアップ時間が最短でした)。これは、インスタンスに直接アタッチされているローカル NVME ドライブがある場合に予想されます。ただし、m5.2xlarge と r5.2xlarge はどちらも gp2 EBS ボリュームで良好なパフォーマンスを発揮しました。
次に、1 つから 3 つのジョブにスケーリングして、複数のバックアップジョブを並行して実行することをテストしました。前回のテストでは近いパフォーマンスが得られた m5 と r5 のインスタンスタイプに焦点を当てました。報告されたのは、すべてのデータベースを同時にバックアップする時間でした。
グラフから、バックアップジョブの数が増えるにつれて、r5.2xlarge インスタンスの方が一般にパフォーマンスが向上することがわかります。r5 インスタンスタイプの 3 つのサーバー結果を見ると、60 GiB をバックアップするのに 123 秒かかりました。これは、499 MB/秒のスループットです。この結果を使用して、それぞれに 20-GiB データベースが 1 つある 10 台のサーバーに外挿すると、すべてのサーバーのフルバックアップに約 7 分かかることが予想されます。
結果は誤差が出る可能性があるため、お使いのワークロードと同じようなデータベースサイズでお客様の環境でテストを実行することをお勧めします。
大規模なデータベースのバックアップ
大規模なマルチ TiB SQL Server データベースをバックアップする必要がある場合は、Amazon S3 オブジェクトの最大サイズは 5 TiB であることを忘れないでください。File Gateway はすべてのファイルを直接 S3 に書き込むため、データベースバックアップファイルのサイズは 5 TiB を超えることができません。これに対処する方法の 1 つに、バックアップの圧縮を有効にする方法があります。他のオプションに、バックアップファイルを複数のサブファイルに分割することがあります。上記のマルチサーバーパフォーマンスグラフに示されているように、File Gateway は、より多くのファイルが並列に書き込まれるにつれてスループットをスケーリングするため、同じゲートウェイにサブファイルを書き込むことをお勧めします。パフォーマンスを最大化し、前述の問題のいくつかを回避するには、すべてのバックアップファイルが収まるように、File Gateway のキャッシュのサイズを設定してください。
複数の File Gateway のデプロイ
環境内の SQL Server の数、SQL データベースのサイズ、およびバックアップウィンドウによっては、複数の File Gateway をデプロイする必要がある場合があります。必要なゲートウェイの数は、ウィンドウ内でバックアップできるデータベースの数の要素です。メトリクスを使用してゲートウェイのパフォーマンスとキャッシュ使用率をモニタリングすることで、前述のパフォーマンスの数値から始めて、ニーズに応じて調整できます。
各 SQL データベースバックアップが一意のファイルで行われる限り、同じ S3 バケットを使用するように複数のゲートウェイを設定できます。
まとめ
このブログ記事では、オンプレミスまたは AWS で実行される SQL Server データベースバックアップに File Gateway を使用する際のベストプラクティスをご紹介しました。ローカルキャッシュにデータを書き込み、Amazon S3 に非同期にアップロードすることで、File Gateway が書き込みを処理する方法を詳しく説明しました。また、File Gateway のセットアップと設定、ゲートウェイをモニタリングする方法、および環境に必要なゲートウェイ数のサイジングに役立つパフォーマンスプロファイルについても見てきました。
SQL Server バックアップに File Gateway を使用すると、バックアップファイルを S3 に移動させ、Amazon S3 が提供する耐久性と信頼性を利用することで、バックアップ操作を簡素化し、ストレージコストを削減できます。
File Gateway の詳細については、次のリンクを参照してください。
お読みいただきありがとうございました。ご意見、ご感想をぜひ、以下のコメント欄にお寄せください。