Amazon EBS を使って Microsoft SQL Server のパフォーマンスを最大化する

AWS のお客様は 10 年以上にわたり、SQL Server などのミッションクリティカルな Windows を実行しています。この投稿では、Amazon EBS ストレージを使用して SQL Server のパフォーマンスを最大化する方法について説明します。

永続ブロックストレージはリレーショナルデータベース管理システム (RDBMS) の重要なコンポーネントであり、重要なデータの速度、セキュリティ、耐久性の最終的な責任を担います。AWS は SQL Server のニーズに合わせて、EBS を通じて、高性能で使いやすいブロックストレージを提供しています。

この投稿は、SQL Server データベースアーキテクト、管理者、および開発者に関連した内容です。AWS プラットフォームでの最適なストレージ構成の概要を説明しています。現在 AWS を使用している、またはオンプレミスのワークロードをクラウドに移行しようとしているのであれば、EBS についてのより詳しい情報と基本的な理解を得ることができます。

Amazon EBS の概要

EBS はすべての AWS リージョンで利用可能な、高性能のブロックストレージサービスです。EBS を使用すると、わずか数回のクリックで SQL Server インスタンスにボリュームを作成し接続が可能です。ホストバスアダプター (HBA)、スイッチ、ネットワーク帯域幅、ディスクキャッシュ、コントローラー、ストレージエリアネットワークなどを構成する必要がなくなります。

EBS ボリュームは専用ストレージネットワークを使用してインスタンスに接続し、高速で信頼性の高いボリュームを柔軟にプロビジョニングするため、SQL Server の重要なワークロードにも対応できます。

EBS ボリュームは伸縮自在です。ワークロードを中断することなく、次のような変更を実行できます。

• ボリュームサイズを最大 16 TiB まで増やす。
• 最大 64,000 IOPS までボリュームパフォーマンスを改善する。
• SSD ボリュームと HDD ボリュームを切り替える。

EBS ボリュームは独立して存続しているため、同じアベイラビリティーゾーン内の異なるインスタンスに接続と接続解除が可能です。1 つのインスタンスには多くのボリュームを接続できますが、ボリュームは一度に 1 つのインスタンスにしか接続できません。

EBS が SQL Server に選ばれる理由を他にも挙げてみましょう。

• ほぼ 100％ の可用性
• クラッシュ整合性のあるポイントインタイムスナップショットをサポート
• 暗号化をサポート

SQL Server と gp2

単一のプロビジョンド IOPS (io1) ボリュームを使用して IOPS とスループットの要件を満たすことができる一方、汎用 SSD (gp2) ボリュームは適切に設定すれば SQL Server ワークロード用にハイレベルにバランスの取れた料金とパフォーマンスを実現します。

Gp2 ボリュームは、1 桁のミリ秒単位のレイテンシーと 3,000 IOPS に長期間バーストする機能があります。このプロパティは SQL Server に適しています。SQL Server などのリレーショナルデータベースが生成する IOPS の負荷により、スパイクを引き起こすことがよくあります。たとえば、テーブルスキャン操作にはスループットのバーストが必要ですが、他のトランザクション操作には安定した低いレイテンシーが必要です。

Gp2 ボリュームは、費用対効果の高い方法で前述の要件を満たします。蓄積された IOPS のバーストを使い果たすことはほとんどないため、EBS はさまざまなアプリケーションワークロードを分析し、gp2 を慎重に設計してこのスパイクを活用しています。

バーストクレジットは設定した GB/秒あたり 3 回の頻度で累積していき、1 回の読み込みまたは 1 回の書き込みに対して支払いが発生します。各ボリュームは最大 540 万クレジットから始まり、ボリュームごとに 1 秒あたり最大 3,000 クレジットを使用できます。

たとえば 200-GiB の gp2 ボリュームがある場合、540 万クレジットを使い切るまで、600 IOPS のベースラインと最大 3,000 IOPS のバーストを取得します。200-GiB ボリュームは 37.5 分間バーストします (バーストレートから累積レートを差し引いたもの)。

Amazon CloudWatch で利用可能な EBS BurstBalance メトリクスを使うと、gp2 ボリュームのバーストバケットレベルをモニタリングできます。サイズの異なる gp2 ボリュームは、ボリュームのサイズに応じて異なるレートで使い切ったり、補充したりします。ボリュームが大きいほどベースラインパフォーマンスが高くなり、クレジットバランスの補充が速くなります。IOPS の測定方法の詳細については、「I/O の特性とモニタリング」をご参照ください。

CloudWatch では、BurstBalance 値が特定のレベルに低下したときに通知するアラームを設定することもできます。

SQL Server のベンチマークでは、単一の 1,000-GiB gp2 ボリュームをプロビジョニングする代わりに、5 つの 200-GiB ボリュームを作成し、Windows で RAID 0 ディスクストライピングを使用して、必要な追加のパフォーマンスを提供しています。

**I/O サイズあたり 16 KiB に基づく

まれではありますが、gp2 ボリュームがすべての I/O クレジットバランスを使用する場合には、ボリュームの最大 IOPS パフォーマンスはベースライン IOPS パフォーマンスレベル (ボリュームがクレジットを獲得するレート) のままとなります。最大スループットボリュームは、ベースライン IOPS に最大 I/O サイズを掛けた値に縮小します。この場合、クレジットバランスがない 200-GiB gp2 ボリュームのベースラインパフォーマンスは 600 IOPS で、150 MiB/秒のスループット制限 (1 秒あたり 600 I/O オペレーション* I/O オペレーションあたり 256 KiB = 150 MiB/秒) となります。

ボリュームパフォーマンスベースラインレベルに頻繁にヒットする (I/O クレジットバランスが空であることによる) 場合、ベースラインパフォーマンスレベルがさらに高い、より大きな gp2 ボリュームの使用を検討できます。または、io1 ボリュームに切り替えると、GB- 月あたりのコストが高まりますが、持続的な IOPS パフォーマンスを得ることができます。

SQL Server 設定のベストプラクティス

SQL Server インスタンスを設定する際に考慮すべきいくつかのベストプラクティスがあります。

適切なボリュームを選択する

ワークロードに適したボリュームを選択するには、パフォーマンス、レイテンシー、コストの要件を詳しく調べる必要があります。よく分からない場合は、gp2 ボリュームから始めてください。これだと、ほとんどのワークロードにおいて価格とパフォーマンス適切なバランスとバースト機能を得ることができます。EBS ボリュームタイプを決定するときは、次のフローチャートを参照してください。

EBS に最適化したインスタンスタイプの使用

EBS に最適化したインスタンスは最適化済み設定スタックを使用して、EBS I/O に専用容量を追加します。この最適化は、EBS I/O とインスタンスからの他のトラフィックとの間の競合を最小限に抑えることで、EBS ボリュームが最高のパフォーマンスを実現できるようにします。すべての現行世代のインスタンスタイプでは、この最適化がデフォルト設定となっています。

正しいインスタンスサイズの選択

インスタンスに最適なファミリーを選択したら、インスタンスのサイズが EBS ボリュームに必要なストレージ帯域幅をサポートしていることを確認してください。

インスタンスに、EBS ボリュームの接続に必要なスループットがあることを確認してください。EBS ボリュームタイプおよび EBS 最適化インスタンスで指定している、公開済み EBS 最大スループット/インスタンスと最大スループット/ボリュームには特に注意してください。正しいバランスを得るために重要です。

たとえば、単一の 20,000-IOPS ボリュームを r5.4xlarge インスタンスに接続すると、20,000 IOPS のボリューム制限に達する前に 18,750 IOPS のインスタンス制限に達します。

EBS ボリュームのストライピング

EBS ボリュームをストライプして、パフォーマンスを最適化し、単一ボリュームのパフォーマンスの制限が上回ります。

EBS データは既に 99.999％ の可用性でレプリケートしており、0.1％〜0.2％ の年間故障率 (AFR) に対応するよう設計されているため、RAID 冗長レベルを実装する必要はありません。たとえば RAID1 を実装すると、EBS の帯域幅と容量の両方において不要である 50％ が削減されます。

Tempdb にローカル接続された NVMe ストレージを使用する

新しい Nitro インスタンスタイプの多くは、ホストに物理的に接続したローカル NVMe SSD を含んでいます。これらの超低遅延ディスクは、tempdb を使用するクエリに最適です。ただし、ローカル SSD データはインスタンスの存続期間中のみ持続します。

スループット最適化 HDD (st1) の使用

接続された EBS ボリュームへのバックアップは、試行済みで信頼できる方法を引き続きお勧めします。st1 ボリュームの高スループットパフォーマンスにより、SSD ストレージの半分のコストで、高速のローカルバックアップと復元が可能になります。

EBS スナップショットを撮る

バックアップボリュームの Amazon S3 へのスナップショットは、長期的なバックアップとして効果的です。Amazon Data Lifecycle Manager (Amazon DLM) を使用すれば、スナップショットを自動的に作成および削除 (オプション) できます。EBS は、完全マネージド型のバックアップサービスである AWS Backup とも統合できます。

Amazon EC2 Systems Manager の Run Command を使うと、Microsoft ボリュームシャドウコピーサービス (VSS) 対応のスナップショットを取得できます。

EBSで革新を起こす

EBS では、ワークロードに合わせてスケーリングするストレージソリューションを柔軟に選択できます。EBS は世界で最も重要な SQL Server のワークロードの基盤であり、要件に合わせるために進化していきます。EBS が進化していくに伴い、パフォーマンス、信頼性、セキュリティを通じてお客様は直接、これらの利点を享受できるのです。長年にわたる重要な立ち上げのタイムラインを簡単に示しています。

2006 年: Amazon EC2 をインスタンスストレージとして開始。

2008 年: 磁気ストレージで EBS を開始。

2012 年: AWS がプロビジョンド IOPS と EBS 最適化インスタンスを導入。

2014 年: SSD 基盤の汎用ストレージで EBS を強化。

2014 年: サードパーティのセキュリティツールに代わって EBS データボリュームの暗号化。

2014 年: Gp2 と io1 ボリュームのパフォーマンスが 2 倍に向上。

2015 年: Encrypted EBS Boot Volumes の開始。

2016 年: EBS がスループット最適化 HDD (st1) と Cold HDD (sc1) ボリュームタイプを追加。

2017 年:Amazon EBS Elastic Volumes でライブボリュームの変更を有効化。

2017年: IOPS SSD (io1) のパフォーマンスが 60％ 向上。

2017 年: EC2 が Microsoft VSS で アプリケーション整合性のあるスナップショットを提供。

2018 年: 汎用SSD (gp2) のパフォーマンスが 60％ 向上。

2018 年: IOPS SSD (io1) のパフォーマンスが 2 倍に向上。

2019 年: EBS が AWS Backup と統合。

2019 年: 新しくなった EBS ボリュームで暗号化がデフォルト設定に。

2019 年: EBS が複数の EBS ボリュームにわたって、ポイントインタイムのクラッシュ整合性のあるスナップショットを取得する機能を追加。

まとめ

EBS などのサービスや Windows のエンジニアリングチームによるイノベーションのおかげで、SQL Server の実行なら AWS はこれからも最適です。詳細については、EBS ページまたは SQL Server ページをご参照ください。