チェックリスト: Azure VM 上の SQL Server のベスト プラクティス

  • [アーティクル]

適用対象: Azure VM 上の SQL Server

この記事では、Azure 仮想マシン (VM) 上の SQL Server のパフォーマンスを最適化するための一連のベスト プラクティスおよびガイドラインとして、クイック チェックリストを提供します。

包括的な詳細については、このシリーズの他の記事 (VM サイズ、ストレージ、セキュリティ、HADR の構成、ベースラインの収集) を参照してください。

Azure VM 上の SQL Server 用の SQL Assessment を有効にすると、お使いの SQL Server が既知のベスト プラクティスに照らして評価され、その結果が Azure portal の SQL VM 管理ページに表示されます。

SQL Server VM のパフォーマンスを最適化し、管理を自動化するための最新の機能に関するビデオについては、次の Data Exposed ビデオをご覧ください。

概要

Azure Virtual Machines で SQL Server を実行するときは、オンプレミスのサーバー環境内の SQL Server に適用できるデータベース パフォーマンス チューニング オプションと同じものを引き続き使用します。 ただし、パブリック クラウド内のリレーショナル データベースのパフォーマンスは、仮想マシンのサイズやデータ ディスクの構成などのさまざまな要素に左右されます。

通常、コストの最適化とパフォーマンスの最適化はトレードオフの関係になっています。 このパフォーマンスに関するベスト プラクティス シリーズでは、Azure Virtual Machines の SQL Server の "最善の" パフォーマンスを得ることに重点を置いています。 ワークロードの要求が厳しくない場合は、推奨される最適化がすべて必要になるわけではありません。 各推奨事項を評価するときに、パフォーマンスのニーズ、コスト、およびワークロードのパターンを考慮してください。

VM サイズ

このセクションのチェックリストの対象は、Azure VM 上の SQL Server の VM サイズに関するベスト プラクティスです。

  • Ebdsv5 シリーズは、Azure で最も高い I/O スループットと仮想コアの比率を提供し、メモリと仮想コアの比率は 8 です。 このシリーズのオファーでは、Azure VM 上の SQL Server ワークロードに対して最適な価格パフォーマンス比が提供されます。 ほとんどの SQL Server ワークロードで、このシリーズを最初に検討してください。
  • 4 つ以上の vCPU を持つ VM サイズ (E4ds_v5 以上など) を使用します。
  • SQL Server ワークロードの最適なパフォーマンスを得るために、メモリ最適化済み仮想マシン サイズを使用します。
  • Edsv5 シリーズと Ebdsv5 シリーズ、Msv3 および Mdsv3 シリーズは、OLTP ワークロードに必要な最適なメモリ対仮想コア比を提供します。
  • M シリーズ VM は、Azure で最高のメモリ対仮想コア比を提供します。 ミッション クリティカルな OLTP ワークロードとデータ ウェアハウス ワークロードには、これらの VM を検討してください。
  • パフォーマンスが最適になるように SQL Server の設定とストレージ オプションが構成されるため、Azure Marketplace イメージを使って SQL Server 仮想マシンをデプロイします。
  • ターゲット ワークロードのパフォーマンス特性を収集し、それらを使用してお客様のビジネスに適した VM サイズを決定します。
  • Data Migration Assistant と SKU 推奨ツールを使って、既存の SQL Server ワークロードに適した VM サイズを確認します。
  • Azure Data Studio を使って Azure に移行します。

警告

現在、NUMA ノードあたり 64 コアを超えるシステムへの SQL Server のインストールはサポートされていません。 現在、この制限は Msv3 および Mdsv3 ミディアム メモリ シリーズ内の Standard_M176s_3_v3 および Standard_M176s_4_v3 Azure 仮想マシン サイズに適用されます。

Storage

このセクションのチェックリストの対象は、Azure VM 上の SQL Server のストレージに関するベスト プラクティスです。

  • ディスクの種類を選択する前に、アプリケーションを監視し、SQL Server のデータ、ログ、および tempdb の各ファイルのストレージ帯域幅と待機時間の要件を判断します。
  • 使用可能な場合は、D: ローカル SSD ボリュームで tempdb データとログ ファイルを構成します。 SQL IaaS Agent 拡張機能は、再プロビジョニング時に必要なフォルダーとアクセス許可を処理します。
  • ストレージのパフォーマンスを最適化するには、キャッシュ不使用時の使用可能な最大の IOPS を計画し、データ読み取りのパフォーマンス機能としてデータ キャッシュを使用する一方で、仮想マシンとディスクの上限を回避します。
  • Ebdsv5 または Ebsv5 シリーズの SQL Server VM を使用する場合は、最適な価格パフォーマンスをプレミアム SSD v2 を使用します。 AZURE portal (現在プレビュー段階) を使用して、プレミアム SSD v2 を使用して SQL Server VM を配置できます。
  • 別々のドライブにデータ、ログ、および tempdb の各ファイルを配置します。
    • データ ドライブには、Premium P30 と P40 あるいはそれより小さいディスクを使用して、キャッシュ サポートの可用性を確保します。 Ebdsv5 VM シリーズを使用する場合は、高い IOPS と I/O スループットを必要とするワークロードの価格パフォーマンスを向上させる Premium SSD v2 を使用します。
    • ログ ドライブについては、Premium SSD v2 または Premium SSD P30 - P80 ディスクのどちらかを評価しながら、容量を計画し、コスト パフォーマンスをテストします
      • ミリ秒未満のストレージ待機時間が求められる場合は、トランザクション ログに Premium SSD v2 または Azure Ultra Disks を使用します。
      • M シリーズの仮想マシンを展開するには、Azure Ultra ディスクを使用するよりも、書き込みアクセラレータを検討してください。
    • 最適な VM サイズを選択した後、フェールオーバー クラスター インスタンス (FCI) の一部ではないほとんどの SQL Server ワークロード用の一時ディスク (一時ディスクはエフェメラルで、既定では D:\) に tempdb を配置します。
    • フェールオーバー クラスター インスタンス (FCI) の場合は、tempdb共有ストレージ上に配置されます。
      • FCI ワークロードが tempdb ディスクのパフォーマンスに大きく依存する場合、高度な構成として、FCI ストレージに属さないローカル エフェメラル SSD (既定は D:\) ドライブに tempdb を配置します。 ローカル エフェメラル SSD (既定は D:\) ドライブで障害が発生しても、FCI からアクションはトリガーされないため、この構成では、このドライブを常時確実に使用できるようにするためのカスタムの監視とアクションが必要になります。
  • 記憶域スペースを使用して複数の Azure データ ディスクをストライピングし、ターゲット仮想マシンの IOPS およびスループットの上限まで I/O 帯域幅を増やします。
  • データ ファイル ディスクの場合は、[ホスト キャッシュ] を [読み取り専用] に設定します。
  • ログ ファイル ディスクの場合は、[ホスト キャッシュ] を [なし] に設定します。
    • SQL Server のデータまたはログ ファイルが含まれているディスクでは、読み取り/書き込みキャッシュを有効にしないでください。
    • ディスクのキャッシュ設定を変更する前に、必ず SQL Server サービスを停止してください。
  • 複数の異なるワークロードをクラウドに移行する場合、 Azure Elastic SAN はコスト効率の高い統合ストレージ ソリューションになります。 ただし、Azure Elastic SAN を使用する場合、SQL Server ワークロードで必要な IOPS/スループットを実現するには、多くの場合、容量のオーバープロビジョニングが必要になります。 通常、単一の SQL Server ワークロードには適していませんが、低パフォーマンスのワークロードと SQL Server を組み合わせると、コスト効率の高いソリューションを実現できます。
  • 開発とテストのワークロード、および長期的なバックアップのアーカイブでは、Standard Storageの使用を検討してください。 運用環境のワークロードには Standard HDD または SSD を使わないことをお勧めします。
  • クレジットベースのディスク バースト (P1 から P20) は、小規模な開発またはテストのワークロードおよび部門別システムでのみ検討してください。
  • ストレージのパフォーマンスを最適化するには、使用可能な最大の未キャッシュ IOPS を計画し、データの読み取りのパフォーマンス機能としてデータ キャッシュを使用しながら、仮想マシンとディスクの上限や調整を回避します。
  • ドライブに配置されるすべてのデータ ファイルに 64 KB アロケーション ユニット サイズを使用するように、データ ディスクをフォーマットします。ただし、一時 D:\ ドライブ (既定値は 4 KB) 以外が対象です。 Azure Marketplace を通じてデプロイされた SQL Server VM には、アロケーション ユニット サイズでフォーマットされたデータ ディスクが付属しており、64 KB に設定された記憶域プールに対してインターリーブします。
  • ストレージ アカウントは、SQL Server VM と同じリージョンに構成します。
  • ストレージ アカウントで Azure geo 冗長ストレージ (geo レプリケーション) を無効にし、LRS (ローカル冗長ストレージ) を使用します。
  • SQL ベスト プラクティス評価を有効にして、考えられるパフォーマンスの問題を特定し、ベスト プラクティスに従って SQL Server VM が構成されていることを評価します。
  • ストレージ IO 使用率メトリックを使用して、ディスクと VM の制限を確認および監視します。
  • ウイルス対策ソフトウェアのスキャンから、データ ファイル、ログ ファイル、バックアップ ファイル などの SQL Server ファイルを除外します。

セキュリティ

このセクションのチェックリストでは、Azure VM 上の SQL Server のセキュリティのベスト プラクティスについて説明します。

SQL Server の機能は、データベース レベルでデータを確実に保護する方法を提供します。この機能はインフラストラクチャ レベルのセキュリティ機能と組み合わせることができます。 機能を組み合わせることで、クラウドベースやハイブリッド ソリューションのインフラストラクチャ レベルで多層防御が提供されます。 さらに、Azure のセキュリティ対策により、機密データの暗号化、ウイルスやマルウェアからの仮想マシンの保護、ネットワーク トラフィックのセキュリティ保護、脅威の特定と検出、コンプライアンス要件の遵守、およびハイブリッド クラウドでのセキュリティ ニーズに対する単一の管理方法とレポート作成が可能になります。

  • Microsoft Defender for Cloud を使用して、データ環境のセキュリティ体制を改善するための評価と対策を実行してください。 Azure Advanced Threat Protection (ATP) などの機能は、ハイブリッド ワークロード全体で使用できるため、セキュリティ評価を改善させると共にリスク対応能力を付与します。 SQL Server VM を SQL IaaS Agent 拡張機能に登録すると、Azure portal の SQL 仮想マシン リソース内で Microsoft Defender for Cloud の評価が表示されます。
  • Microsoft Defender for SQL を使用して、データベースの潜在的な脆弱性を検出および軽減し、SQL Server インスタンスおよびデータベース レイヤーへの脅威を示す可能性のある異常なアクティビティを検出します。
  • 脆弱性評価は Microsoft Defender for SQL の一部であり、SQL Server 環境に対する潜在的なリスクを検出して修復するのに役立ちます。 セキュリティの状態を表示することができ、セキュリティの問題を解決するための実行可能な手順が含まれます。
  • Azure 機密 VM を使用して、使用中のデータと保存データの保護を強化し、ホスト オペレーターのアクセスから保護します。 Azure 機密 VM を使用すると、確実に機密データをクラウドに保存し、厳格なコンプライアンス要件を満たすことができます。
  • SQL Server 2022 を使用している場合は、Microsoft Entra 認証を使用して SQL Server のインスタンスに接続することを検討してください。
  • Azure Advisor は、リソースの構成と使用状況のテレメトリを分析し、Azure リソースの費用対効果、パフォーマンス、高可用性、およびセキュリティを向上させるのに役立つソリューションを推奨します。 仮想マシン、リソース グループ、またはサブスクリプション レベルで Azure Advisor を使用してベストプラクティスを特定し、Azure のデプロイを最適化します。
  • コンプライアンスとセキュリティのニーズで、エフェメラル (ローカルに接続された一時) ディスクの暗号化など、暗号化キーを使用してエンド ツー エンドでデータを暗号化する必要がある場合は、Azure Disk Encryption を使用します。
  • マネージド ディスクの暗号化は既定で、Azure Storage Service Encryption を使用して行われます。暗号化キーは、Microsoft が Azure で管理するキーです。
  • マネージド ディスク暗号化オプションの比較については、マネージド ディスク暗号化の比較表を確認してください。
  • 仮想マシンで管理ポートを閉じる必要があります - オープンなリモート管理ポートは、インターネットベースの攻撃による高いレベルのリスクに VM をさらしています。 これらの攻撃では、資格情報に対するブルート フォース攻撃を行ってマシンへの管理者アクセス権の取得を試みます。
  • Azure 仮想 マシンの Just-In-Time (JIT) アクセスを有効にする
  • リモート デスクトップ プロトコル (RDP) で Azure Bastion を使用します。
  • ポートをロックダウンし、元の IP アドレスに基づいてサーバーへのアクセスを許可/拒否を管理するサービスとしてのファイアウォール (Faas) である Azure Firewall を使用して必要なアプリケーショント ラフィックのみを許可します。
  • ネットワーク セキュリティ グループ (NSG) を使用して、Azure 仮想ネットワーク上の Azure リソースとの間のネットワーク トラフィックをフィルター処理する
  • アプリケーション セキュリティ グループを使用して、Web サーバーやデータベース サーバーなどの同様の機能を備えた同様のポート フィルタリング要件でサーバーをグループ化します。
  • Web サーバーとアプリケーション サーバーの場合、Azure 分散型サービス拒否 (DDoS) 保護を使用します。 DDoS 攻撃は、ネットワーク リソースを過剰に消費してアプリの速度を低下させたり、応答しなくなったりするように設計されています。 DDoS 攻撃では、ユーザー インターフェイスを標的にするのが一般的です。 Azure DDoS 保護は、サービスの可用性に影響を与える前に、不要なネットワーク トラフィックをサニタイズします
  • VM 拡張機能を使用すると、マルウェア対策、望ましい状態、脅威の検出、防止、修復に対処でき、オペレーティング システム、マシン、ネットワーク レベルでの脅威に対処できます。
  • Azure Policy を使用して、環境に適用できるビジネス ルールを作成します。 Azure ポリシーは、これらのリソースのプロパティを JSON 形式で定義されたルールと比較することにより、Azure リソースを評価します。
  • Azure Blueprints によってクラウド アーキテクトや中央の情報技術グループは、組織の標準、パターン、要件を実装および順守した反復可能な一連の Azure リソースを定義できます。 Azure Blueprints は Azure のポリシーとは異なります。
  • Windows Server 2019 または Windows Server 2022 を使用して、Azure VM 上の SQL Server を FIPS に準拠させます。

SQL Server 機能

次に示すのは、実稼働環境の Azure 仮想マシンで SQL Server インスタンスを実行する場合の、SQL Server 構成設定のベスト プラクティスの簡単なチェックリストです。

機能とのマップ

以下は、Azure VM で SQL Server を実行する場合の Azure 固有のガイダンスに関するベスト プラクティスのクイック チェックリストです。

HADR の構成

このセクションのチェックリストの対象は、Azure VM 上の SQL Server の HADR に関するベスト プラクティスです。

高可用性とディザスター リカバリー (HADR) 機能 (Always On 可用性グループやフェールオーバー クラスター インスタンスなど) は、基盤となる Windows Server フェールオーバー クラスター テクノロジに依存しています。 クラウド環境への対応を強化するように HADR 設定を変更するためのベスト プラクティスを確認してください。

Windows クラスターの場合は、次のベスト プラクティスについて検討します。

  • Azure Load Balancer または分散ネットワーク名 (DNN) に依存しなくても HADR ソリューションにトラフィックをルーティングできるよう、可能な限り SQL Server VM を複数のサブネットにデプロイします。
  • 一時的なネットワーク障害や Azure プラットフォーム メンテナンスによって予期しない停止が起こらないよう、クラスターを変更してパラメーターを緩和します。 詳細については、ハートビートとしきい値の設定に関する記事を参照してください。 Windows Server 2012 以降の場合は、次の推奨値を使用します。
    • SameSubnetDelay: 1 秒
    • SameSubnetThreshold: 40 ハートビート
    • CrossSubnetDelay: 1 秒
    • CrossSubnetThreshold: 40 ハートビート
  • VM は可用性セットまたは別の可用性ゾーンに配置します。 詳細については、「VM の可用性の設定」を参照してください。
  • クラスター ノードごとに 1 つの NIC を使用します。
  • 3 つ以上の奇数の投票を使用するように、クラスターのクォーラム投票を構成します。 投票は DR リージョンに割り当てないでください。
  • リソースの制約による予期しない再起動やフェールオーバーが発生しないように、リソース制限を慎重に監視します。
    • OS、ドライバー、SQL Server が最新のビルドになっていることを確認します。
    • Azure VM 上での SQL Server のパフォーマンスを最適化します。 詳細については、この記事の他のセクションを参照してください。
    • リソース制限に達しないように、ワークロードを削減または分散します。
    • 制約を回避するために、より制限の高い VM またはディスクに移行します。

SQL Server の可用性グループまたはフェールオーバー クラスター インスタンスの場合は、こちらのベスト プラクティスを検討してください。

  • 予期しないエラーが頻繁に発生する場合は、この記事の残りの部分で説明されているパフォーマンスのベスト プラクティスに従ってください。
  • SQL Server VM のパフォーマンスを最適化しても予期しないフェールオーバーが解決されない場合は、可用性グループまたフェールオーバー クラスター インスタンスの監視を緩和することを検討してください。 ただし、そうすることで問題の根底にある原因に対処できない場合があり、障害の可能性を減らすことで症状が表に現れない可能性があります。 その場合でも、根底にある根本原因を調査して対処しなければならない場合があります。 Windows Server 2012 以降の場合は、次の推奨値を使用します。
    • リース タイムアウト: こちらの式を使用して、リース タイムアウトの最大値を計算します。
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      40 秒から始めます。 先ほど推奨した緩和されている SameSubnetThreshold と SameSubnetDelay の値を使用している場合は、リース タイムアウト値が 80 秒を超えないようにしてください。
    • 指定した期間の最大エラー数: この値は 6 に設定します。
  • 仮想ネットワーク名 (VNN) と Azure Load Balancer を使用して HADR ソリューションに接続する場合は、お使いのクラスターが 1 つのサブネットにしかまたがっていない場合でも、接続文字列に MultiSubnetFailover = true を指定します。
    • クライアントで MultiSubnetFailover = True がサポートされていない場合は、RegisterAllProvidersIP = 0 および HostRecordTTL = 300 を設定して、クライアント資格情報をより短期間だけキャッシュすることが必要になる可能性があります。 ただし、そうすることで、DNS サーバーに対して追加のクエリが発生する場合があります。
  • 分散ネットワーク名 (DNN) を使用して HADR ソリューションに接続する場合は、以下の注意点があります。
    • MultiSubnetFailover = True をサポートするクライアント ドライバーを使用する必要があります。このパラメーターは接続文字列に含める必要があります。
    • 可用性グループの DNN リスナーに接続するときに、接続文字列内の一意の DNN ポートを使用します。
  • 基本の可用性グループのデータベース ミラーリング接続文字列を使用して、ロード バランサーまたは DNN の必要性をなくします。
  • 高可用性ソリューションをデプロイする前に VHD のセクター サイズを検証して、I/O の不整合を回避します。 詳細については、KB3009974 を参照してください。
  • SQL Server データベース エンジン、Always On 可用性グループ リスナー、またはフェールオーバー クラスター インスタンスの正常性プローブが 49,152 から65,536 の間のポート (TCP/IP の既定の動的ポート範囲) を使うように構成されている場合は、各ポートの除外を追加します。 このようにすると、他のシステムが同じポートを動的に割り当てるのを防ぐことができます。 次の例では、ポート 59999 の除外を作成します。
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

パフォーマンスのトラブルシューティング

SQL Server のパフォーマンスに関する問題のトラブルシューティングに役立つリソースの一覧を次に示します。

関連するコンテンツ

Azure vm での SQL Server の SQL Assessment を有効にすることを検討してください。

SQL Server Virtual Machines に関する他の記事については、Azure Virtual Machines 上の SQL Server の概要に関するページをご覧ください。 SQL Server の仮想マシンに関するご質問については、よくあるご質問に関するページをご覧ください。