チェックリスト: 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 シリーズ、M-Mv2- シリーズでは、OLTP ワークロードに必要な、最適なメモリと仮想コアの比率が提供されます。
  • M シリーズの VM は、メモリと仮想コアの比が Azure で最も高くなっています。 ミッション クリティカルなワークロードとデータ ウェアハウス ワークロードについては、これらの VM を検討してください。
  • パフォーマンスが最適になるように SQL Server の設定とストレージ オプションが構成されているため、Azure Marketplace イメージを活用して SQL Server 仮想マシンをデプロイしてください。
  • ターゲット ワークロードのパフォーマンス特性を収集し、それらを使用してお客様のビジネスに適した VM サイズを決定します。
  • Data Migration AssistantSKU レコメンデーション ツールを使用して、既存の SQL Server ワークロードに適した VM サイズを確認します。

詳細については、包括的な VM サイズのベスト プラクティスに関するページを参照してください。

ストレージ

Azure VM で SQL Server を実行する場合のストレージ構成に関するベスト プラクティスのクイック チェックリストは次のとおりです。

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

詳細については、包括的なストレージのベスト プラクティスに関するページを参照してください。

SQL Server 機能

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

機能とのマップ

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

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 (クラスター ノードあたり) と 1 つのサブネットを使用します。
  • 3 つ以上の奇数の投票を使用するように、クラスターのクォーラム投票を構成します。 投票は DR リージョンに割り当てないでください。
  • リソースの制約による予期しない再起動やフェールオーバーが発生しないように、リソース制限を慎重に監視します。
    • OS、ドライバー、SQL Server が最新のビルドになっていることを確認します。
    • Azure VM 上での SQL Server のパフォーマンスを最適化します。 詳細については、この記事の他のセクションを参照してください。
    • リソース制限に達しないように、ワークロードを削減または分散します。
    • 制約を回避するために、より制限の高い VM またはディスクに移行します。

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

  • 予期しないエラーが頻繁に発生する場合は、この記事の残りの部分で説明されているパフォーマンスのベスト プラクティスに従ってください。
  • SQL Server VM のパフォーマンスを最適化しても予期しないフェールオーバーが解決されない場合は、可用性グループまたフェールオーバー クラスター インスタンスの監視を緩和することを検討してください。 ただし、そうすることで問題の根底にある原因に対処できない場合があり、障害の可能性を減らすことで症状が表に現れない可能性があります。 その場合でも、根底にある根本原因を調査して対処しなければならない場合があります。 Windows Server 2012 以降の場合は、次の推奨値を使用します。
    • リース タイムアウト: こちらの式を使用して、リース タイムアウトの最大値を計算します。
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      40 秒から始めます。 先ほど推奨した緩和されている SameSubnetThresholdSameSubnetDelay の値を使用している場合は、リース タイムアウト値が 80 秒を超えないようにしてください。
    • 指定した期間の最大エラー数: この値は 6 に設定できます。
    • 正常性チェック タイムアウト: 最初は 60,000 に設定しておき、必要に応じて調整できます。
  • 仮想ネットワーク名 (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

詳細については、包括的な HADR のベスト プラクティスに関する記事を参照してください。

セキュリティ

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

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

  • Azure Security Center を使用して、データ環境のセキュリティ状態を改善するための評価と対策を実行します。 Azure Advanced Threat Protection (ATP) などの機能は、ハイブリッド ワークロード全体で活用できるため、セキュリティ評価を向上させ、リスクに対応できます。 SQL Server VM を SQL IaaS Agent 拡張機能に登録すると、Azure ポータルの SQL 仮想マシン リソース内で Azure Security Center の評価が表示されます。
  • Microsoft Defender for SQL を活用して、データベースの潜在的な脆弱性を検出および軽減し、SQL Server インスタンスおよびデータベース レイヤーへの脅威を示す可能性のある異常なアクティビティを検出します。
  • 脆弱性評価Microsoft Defender for SQL の一部であり、SQL Server 環境に対する潜在的なリスクを検出して修復するのに役立ちます。 セキュリティの状態を表示することができ、セキュリティの問題を解決するための実行可能な手順が含まれます。
  • Azure 機密 VM を使用して、使用中のデータと保存データの保護を強化し、ホスト オペレーターのアクセスから保護します。 Azure 機密 VM を使用すると、確実に機密データをクラウドに保存し、厳格なコンプライアンス要件を満たすことができます。
  • SQL Server 2022 を使っている場合、SQL Server のインスタンスに接続するには、Azure Active Directory 認証を使うことを検討してください。
  • 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 のポリシーとは異なります。

次のステップ

詳細については、このベスト プラクティス シリーズにある他の記事を参照してください。

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

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