エクスポート (0) 印刷
すべて展開

Azure SQL データベースの Basic、Standard、および Premium プレビュー

更新日: 2014年5月

執筆者: Conor Cunningham、Kun Cheng、Jan Engelsberg

技術校閲者: Morgan Oslake、Joanne Marone、Keith Elmore、José Batista-Neto、Rohit Nayak

Premium に加えて、Azure SQL データベースは Basic と Standard という 2 つの新しいサービス階層でご利用いただけます。Premium サービス階層では、Azure SQL データベース とそのセカンダリ レプリカのリソース量を厳しく管理することで、クラウド アプリケーションのパフォーマンスをより高い精度で予測できます。Azure SQL データベース ではこの概念が新しい Standard サービス階層にも拡大され、Premium サービス階層よりパフォーマンス要件が低いデータベースでも高い精度でパフォーマンスを予測できます。Basic サービス階層は、低コストのデータベースのパフォーマンス要件を満たすように設計されています。

この文書では、このプレビューを通じて利用できるサービス階層のうち、どれがアプリケーションに適切かを判断するために役立つガイダンスを提供し、Azure SQL データベースを最大限に活用できるようにアプリケーションをチューニングするための推奨事項を示します。この文書のセクションは次のとおりです。

Azure SQL データベースの背景

新しいサービス階層での変更点

新しいサービス階層を使用する理由

リソースの使用について

アプリケーションの調整

結論

Azure SQL データベースの背景

Basic、Standard、Premium の各サービス階層が既存の Azure SQL データベース サービスを強化するしくみを理解するには、Azure SQL データベースの全体像を把握することが役立ちます。現在、お客様はさまざまな理由で Azure SQL データベースを選択しています。理由の 1 つは、ハードウェアを購入してインストールするまでの長いサイクルを避けたいということです。Azure SQL データベースでは即座にデータベースを作成および削除できるので、購買発注の承認、コンピューターの到着、電源や冷却装置のアップグレード、インストールの完了などを待つ必要がありません。マイクロソフトはこれらの課題に対処し、各データ センターで集計された需要に基づいてハードウェアを事前プロビジョニングすることによって、アイデアからソリューションまでに必要な時間を大幅に短縮します。お客様の事業において、ハードウェアの購入と展開を手動で行う場合より、数週間から数か月の時間を節約できます。

Azure SQL データベースには、自動 HA、負荷分散、組み込み管理など、多くの自動管理機能が含まれています。

  • 自動高可用性 (HA)

    Azure SQL データベースは、各ユーザー データベースに対して少なくとも 3 つのレプリカを保持し、各変更を同期的にレプリカのクォーラムへ自動的にコミットするためのロジックを持っています。こうすることで、単一のコンピューターのエラーによってデータの損失が発生しないことが保証されます。さらに、電源やネットワーク スイッチの喪失がデータベースに影響しないように、各レプリカは異なるハードウェア ラックに配置されます。最後に、コンピューターが使用できなくなった場合に、自動的にレプリカを再構築するロジックがあります。そのため、コンピューターが異常な状態になっても、システムは必要な正常性を自動的に維持します。これらのメカニズムによって、今日の高可用性ソリューションのインストールや構成に必要な、時間のかかる処理を回避できます。データのためにあらかじめ構成された HA ソリューションを利用することで、従来の技法を使用してミッション クリティカルなデータベース ソリューションを構築するというもう 1 つの難題も解決できます。

  • 負荷分散

    従来の仮想マシンとは異なり、Azure SQL データベースには、複数のコンピューター間で自動的に負荷を分散するメカニズムもあります。ロード バランサーは、クラスターのリソースの使用状況を動的に監視し、クラスター内のコンピューターにデータベース レプリカを移動して、多くのユーザーからの負荷を公平に分担できるようにします。そのため、データベースのキャパシティ オン デマンド機能が強化され、ユーザーは各データベースの容量の要件を個別に考慮できます。ロード バランサーは、負荷の高いデータベースを互いに離れた場所へ移行できるためです。多くのデータベースにまたがるソリューションを作成すると、このロジックでは抽象化レイヤーが用意されます。これによって、利用者は仮想マシンの特定のサイズ制限ではなく、各データベースの容量のニーズに集中できます。

  • 組み込み管理

    Azure SQL データベースはサービスとして実行されます。つまり、各データベースに定義済みのアップタイム ターゲットがあり、長いメンテナンス ダウンタイム ウィンドウが回避されます。マイクロソフトではサービス用に単一ベンダー ソリューションを提供しているため、問題が発生した場合でも 1 つの会社に連絡するだけで済みます。また、常にサービスの更新、機能や容量の追加を行い、更新ごとに操作性が向上するように努めています。更新は透過的にダウンタイム ウィンドウなしで行われるので、通常の HA フェールオーバーのメカニズムに統合されています。そのため、利用者は次回のダウンタイム ウィンドウ中にサーバーがアップグレードされるまで待たなくても、使用可能というアナウンスがあればすぐに新しい機能を活用できます。

これらのすべての機能がすべてのサービス階層で提供されます。エントリ価格は月に数ドルと低く設定されています。独自のサーバーを購入して稼働させるよりもはるかに安いので、ごく小規模なプロジェクトでも多額の費用を費やさずに Azure を利用できます。

新しいサービス階層での変更点

マイクロソフトは、Azure SQL データベースを初めて導入する多くのお客様と密接に協力することで、お客様がどのようにサービスを使用するかを学び、その教訓を将来の機能の計画に活かすようにエンジニアリング チームに伝えてきました。こうした努力を通じて、一部のお客様はニーズによく合った機能セットを実際に見つけていることがわかりました。たとえば、新しいクラウド サービスの開発を始めると、キャパシティ オン デマンドと管理オーバーヘッドの削減の組み合わせによって業務が簡素化され、主要業務に集中できるようになることがよくあります。他のお客様の場合は、厳しいパフォーマンス要件に関連する面で、困難な点がありました。たとえば、現時点での Azure SQL データベース サービスでは対応できないような大規模な多層データベース ソリューションの一元的な API によるサービスなどです。結論は、一部のお客様は非常に低い料金で済ませるためにはパフォーマンスの変動が大きくなることを進んで受け入れるものの、他のお客様はデータベース上により高いレベルの価値をより容易に構築できるようにするために、一定のパフォーマンスの保証の方に強い関心を持っているということでした。

お客様のあらゆる要望に応えるために、マイクロソフトは、現在のところパブリック プレビューですが、サービス階層として Basic、Standard、Premium を導入しました。それぞれのサービス階層には 1 つまたは複数のパフォーマンス レベルがあり、予測可能な状態でデータベースを実行できる性能が提供されます。この性能はデータベース スループット ユニット (DTU) で表現されます。次の表はサービス階層、パフォーマンス レベル、DTU をまとめたものです。

 

サービス クラス

パフォーマンス レベル

DTU

Basic

5

Standard

S1

15

Standard

S2

50

プレミアム

P1

100

プレミアム

P2

200

プレミアム

P3

800

Basic サービス階層は、各データベースのパフォーマンスを時間単位で適切に予測できるよう設計されています。Basic データベースの DTU は、複数の同時要求のない小規模のデータベースが問題なく動作するのに十分なリソースを提供する設計になっています。

ワークグループや Web アプリケーションなど、複数の同時要求に対応するデータベースのパフォーマンスの予測可能性を向上させて高い基準を設定するために、マイクロソフトは Standard サービス階層を導入しました。Standard サービス階層を利用すると、お客様は、分単位で予測可能なパフォーマンスに基づいて、データベース アプリケーションのサイズを変更できます。Standard サービス階層にはレベル S1 とレベル S2 という 2 つのパフォーマンス レベルがあるので、ニーズに基づいて選択できます。

Premium サービス階層のパフォーマンスに関する最上級の機能は、Premium データベースごとに秒単位で予測可能なパフォーマンスです。Premium サービス階層を利用すると、お客様はデータベース アプリケーションのサイズをそのデータベースのピーク時の負荷に基づいて調整でき、遅延が問題になる操作で、パフォーマンスの変動によって小さいクエリに予想以上に長い時間がかかることもなくなります。このモデルでは、ピークのリソース ニーズ、パフォーマンス変動、またはクエリの遅延が重大な問題となるアプリケーションに必要な開発および製品検証のサイクルを大幅に簡略化できます。また、一部のオンプレミス アプリケーションは、大きな変更をせずに移行できるようになります。これは、それらのアプリケーションが最初に構築されたときに想定していた従来の分離された環境と近い環境になっているためです。

Standard と同様に、Premium サービス階層では、お客様の希望する分離性に基づいて、異なるパフォーマンス レベルを選択できます。

Standard と Premium のパフォーマンス レベル設定によって、お客様は必要な容量の分だけを支払い、ワークロードの変化に応じて容量を調整できます。たとえば、データベースのワークロードが新学期のための買い物シーズン中に高くなる場合は、その期間だけデータベースのパフォーマンス レベルを上げ、ピーク期間が終了したらそれを下げることができます。そうすることで、お客様はクラウド環境をビジネスの季節性に対して最適化し、支払い額を最小限に抑えることができます。このモデルは、ソフトウェア製品のリリース サイクルにも適しています。テスト チームは、テストの実行中は容量を割り当て、テストが完了したらその容量を解放できます。これらの容量要求は、必要な分の容量に対してだけ料金を支払い、あまり使用しない専用リソースへの支出は避けるモデルによく適しています。こうすることで、パフォーマンスの状態は、多くのマイクロソフトのお客様が SQL Server で使用してきた従来の専用ハードウェア モデルにかなり近づきます。これで、より多くの種類のアプリケーションを Azure SQL データベースでより簡単に実行できます。

新しいサービス階層を使用する理由

各ワークロードは異なっても、新しいサービス階層の目的は、さまざまなパフォーマンス レベルで、パフォーマンスの高度な予測可能性を提供することです。これにより、データベースに大規模なリソースを必要とするお客様が、より専用度の高いコンピューティング環境で作業できるようになります。

Basic サービス階層の機能に適した一般的な事例には、次のようなものがあります。

  • Azure SQL データベースの使い始め – 開発中のアプリケーションは、多くの場合、高いレベルのパフォーマンスを必要としません。Basic データベースは、低価格でデータベース開発の理想的な環境を提供します。

  • ユーザーが 1 人のデータベース – 1 人のユーザーをデータベースに関連付けるアプリケーションでは、通常、同時性とパフォーマンスの要件は高くありません。そのような要件のアプリケーションに Basic サービス階層は適しています。

Standard サービス階層の機能に適した一般的な事例には、次のようなものがあります。

複数の同時要求に対応するデータベース - トラフィックが中程度の Web サイトのような一度に複数のユーザーにサービスを提供するアプリケーションや、より多くのリソースを必要とする部門別アプリケーションなどに Standard サービス階層は適しています。

Premium サービス階層の機能に適した一般的な事例には、次のようなものがあります。

  • 高いピーク時負荷 – 操作を完了するために多くの CPU、メモリ、IO を必要とするアプリケーション。たとえば、データベース操作で複数の CPU コアを長時間使用することがわかっている場合は、Premium データベースを使用する候補になります。

  • 多くの同時要求 – 一部のデータベース アプリケーションは、多くの同時要求を処理します。たとえば、トラフィック量の多い Web サイトにサービスを提供するアプリケーションです。Basic と Standard サービス階層では、同時要求の数が制限されています。より多くの接続を必要とするアプリケーションは、必要な要求の最大数を処理できる、適切な予約サイズを選択する必要があります。

  • 低遅延 – 一部のアプリケーションは、最短時間でのデータベースからの応答を保証する必要があります。特定のストアド プロシージャがお客様のより広い操作の一部として呼び出される場合、ほぼ確実に 20 ミリ秒未満でその呼び出しから戻るという要件があることがあります。このような種類のアプリケーションは、Premium データベースを使用することで、コンピューティング能力を確実に利用できるという利点が得られます。

Azure SQL データベースを使用した場合にパフォーマンスの問題が発生する可能性がある一般的なシナリオの詳細については、「Azure SQL データベースと SQL Server のパフォーマンスとスケーラビリティの比較」を参照してください。

必要となる的確なレベルは、リソースの各要素のピーク負荷要件によって異なります。一部のアプリケーションでは、1 つのリソースの使用量はわずかであっても、別のリソースは大量に必要である場合があります。

新しいサービス階層の構成は次のようになります。

 

サービス階層/パフォーマンス レベル DTU 最大 DB サイズ 最大 ワーカー スレッド 最大 セッション 予測可能性

Basic

1

2 GB

20

100

良い

Standard/S1

5

250 GB

50

200

Standard/S2

25

250 GB

100

500

Premium/P1

100

500 GB

200

2,000

最高

Premium/P2

200

500 GB

400

4,000

最高

Premium/P3

800

500 GB

1,600

16,000

最高

リソースの使用について

次のグラフは、1 週間の各時間における、P2 パフォーマンス レベルの Premium データベースの CPU リソース使用状況を示しています。月曜日に始まり、5 営業日と、アプリケーションの利用が大幅に低下する週末が示されています。

SQL_DB

このデータからは、このデータベースには現在のところ、P2 パフォーマンス レベルと比較して CPU 使用率が 50% をわずかに超えるピーク CPU 負荷があることがわかります (火曜日の正午)。CPU がアプリケーションのリソース プロファイルで主要な要素である場合、ワークロードに常に対応できるためには、P2 が正しいパフォーマンス レベルであることをお客様は判断できます。アプリケーションが今後拡張されていく予定である場合は、アプリケーションが上限に達してしまうことがないように、リソースにいくらかの余裕を持たせておくことが有益です。そうすることで、特に遅延が問題になる環境 (データベースの呼び出しの結果に基づいて Web ページを描画するアプリケーションをサポートしているデータベースなど) で、要求を効果的に処理するための性能が不足しているデータベースによって、お客様が認識できるエラーが発生するのを避けることができます。

他のアプリケーションの種類では、同じグラフの解釈が異なる場合があることに注意してください。たとえば、給与データを毎日処理するアプリケーションが同じグラフになった場合、この種類の "バッチ ジョブ" モデルは、P1 のパフォーマンス レベルでも問題ない場合があります。P1 パフォーマンス レベルは 100 DTU で、P2 パフォーマンス レベルは 200 DTU です。つまり、P1 パフォーマンス レベルは P2 パフォーマンス レベルの半分のパフォーマンスを提供します。P2 における 50% の CPU 利用率は P1 における 100% の CPU 利用率に相当します。アプリケーションがタイムアウトにならない限り、大きなジョブの完了までに 2 時間または 2.5 時間かかったとしても、今日中に完了すれば問題ありません。このカテゴリのアプリケーションは、多くの場合、P1 パフォーマンス レベルを使用できます。そのようなお客様は、一日のうちでリソースの使用率が低くなる時間帯があるという事実を利用できます。つまり、"大きな山" の部分であふれた分は、その日の後の谷の部分で処理されるということです。このようなアプリケーションでは、ジョブが毎日予定どおりに完了できれば、P1 パフォーマンス レベルで十分です (コストも節約できます)。

Azure SQL データベースでは、各アクティブ データベースで使用されたリソースの情報を、各サーバーのマスター データベースの sys.resource_stats ビューで公開しています。テーブルのデータは、5 分間隔で集計されます。Basic、Standard、Premium の各サービス階層のプレビュー期間中は、データがテーブルに表示されるまでに 5 分以上かかる場合があります。つまり、このデータは、ほぼリアルタイムの分析よりも履歴の分析に適しているということです。sys.resource_stats ビューに対してクエリを実行すると、データベースの最近の履歴が表示されるので、選択した予約によって必要なときに期待どおりのパフォーマンスが得られているかどうかを検証できます。次の例は、このビューでデータがどのように公開されるかを示しています。

SELECT TOP 10 * 
FROM sys.resource_stats 
WHERE database_name = 'resource1' 
ORDER BY start_time DESC

SQL_DB

注: テーブルのいくつかの列は、スペースのために省略されています。出力のすべての説明については、トピック「sys.resource_stats」を参照してください。

リソースの使用状況を監視する方法

ここでは、Azure SQL データベースのリソース使用状況を監視する方法と、現在のリソース使用状況とさまざまなパフォーマンス レベルを比較する方法について説明します。

  1. 現在のプレビューでは、sys.resource_stats カタログ ビューは、データベース レベルでのリソース使用状況の履歴情報がより充実しています。たとえば、データベース "userdb1" の過去の週のリソース使用状況を表示するには、次のクエリを実行します。

    SELECT * 
    FROM sys.resource_stats 
    WHERE database_name = 'userdb1' AND 
          start_time > DATEADD(day, -7, GETDATE())
    ORDER BY start_time DESC;
    
    
  2. ワークロードがパフォーマンス レベルにどの程度適しているかを評価するには、リソース メトリックのさまざまな側面 (CPU、読み取り、書き込み、ワーカー数、セッション数など) を詳細に確認する必要があります。次に示すのは、sys.resource_stats を使用してこれらのリソース メトリックの平均値と最大値をレポートする、変更したクエリです。

    SELECT 
        avg(avg_cpu_percent) AS 'Average CPU Utilization In Percent',
        max(avg_cpu_percent) AS 'Maximum CPU Utilization In Percent',
        avg(avg_physical_data_read_percent) AS 'Average Physical Data Read Utilization In Percent',
        max(avg_physical_data_read_percent) AS 'Maximum Physical Data Read Utilization In Percent',
        avg(avg_log_write_percent) AS 'Average Log Write Utilization In Percent',
        max(avg_log_write_percent) AS 'Maximum Log Write Utilization In Percent',
        avg(active_session_count) AS 'Average # of Sessions',
        max(active_session_count) AS 'Maximum # of Sessions',
        avg(active_worker_count) AS 'Average # of Workers',
        max(active_worker_count) AS 'Maximum # of Workers'
    FROM sys.resource_stats 
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    
  3. 上記の各リソース メトリックの平均値と最大値の情報を利用し、選択したパフォーマンス レベルにワークロードがどの程度適しているのかを評価できます。ほとんどの場合、sys.resource_stats での平均値が、該当サイズに対して使用する適切なベースラインになります。これが、主要なものさしです。たとえば、S2 パフォーマンス レベルの Standard サービス階層を使用しているとき、CPU、読み取り、書き込みの平均利用率が 20% 以下、ワーカーの平均数が 50 以下、セッションの平均数が 200 以下であれば、ワークロードは S1 パフォーマンス レベルに適しているかもしれません。データベースがワーカーとセッションの上限に収まっているかどうかは簡単にわかります。CPU、読み取り、書き込みに関して、データベースが下位のパフォーマンス レベルに適しているかどうかを確認するには、下位のパフォーマンス レベルの DTU 数を現在のパフォーマンス レベルの DTU レベルで除算し、その計算結果に 100 を乗算します。



    S1 DTU / S2 DTU * 100 = 5 / 25 * 100 = 20



    計算結果は、2 つのパフォーマンス レベルの間の相対的パフォーマンス差異 (%) になります。利用率がこの割合を超えない場合、ワークロードは下位のパフォーマンス レベルに適しているかもしれません。ただし、リソース使用量の値のすべての範囲も調べ、割合の観点から、どのくらいの頻度でデータベース ワークロードが下位のパフォーマンス レベルに収まるかを判断する必要があります。次のクエリでは、上記で計算された 20% のしきい値に基づき、リソースの要素別の適正割合が出力されます。

    SELECT 
        (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU Fit Percent'
        ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log Write Fit Percent'
        ,(COUNT(database_name) - SUM(CASE WHEN avg_physical_data_read_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical Data Read Fit Percent'
    FROM sys.resource_stats
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    
    データベースのサービス レベル目標 (SLO) に基づき、ワークロードが下位のパフォーマンス レベルに適しているかどうかを決定できます。データベース ワークロード SLO が 99.9% で、上記のクエリで 3 つすべてのリソース要素に対して 99.9 を超える値が返される場合、ワークロードが下位のパフォーマンス レベルに適している可能性が高いです。

    適正割合を見れば、SLO を達成するために、1 つ上位のパフォーマンス レベルに移行するべきかどうかもわかります。たとえば、"userdb1" の前の週の使用状況が次のようになっているとします。

     

    平均 CPU 割合

    最大 CPU 割合

    24.5

    100.00

    平均 CPU はパフォーマンス レベルの上限の約 4 分の 1 であり、データベースのパフォーマンス レベルに適しています。ただし、最大値はデータベースがパフォーマンス レベルの上限に到達することを示しています。1 つ上位のパフォーマンス レベルに移る必要があるでしょうか。改めて、ワークロードが 100% に到達する回数を調べ、それをデータベース ワークロード SLO と比較する必要があります。

    SELECT 
    (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU Fit Percent'
    ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log Write Fit Percent’
    ,(COUNT(database_name) - SUM(CASE WHEN avg_physical_data_read_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical Data Read Fit Percent'
    FROM sys.resource_stats
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    上記のクエリにより、3 つのリソース要素のいずれかに対して、99.9 未満の値が返される場合は、1 つ上位のパフォーマンス レベルに移るか、アプリケーションのチューニング手法を利用し、Azure SQL データベースの負荷を減らすことを検討してください。

  4. 上記の例では、将来に予測されているワークロードの増加も考慮に入れる必要があります。

アプリケーションの調整

従来のオンプレミス SQL Server では、初期のキャパシティ プランニングのプロセスは、多くの場合、実稼働アプリケーションを実行するプロセスとは分離されています。つまり、ハードウェアの購入と、SQL Server を実行するための関連ライセンスは事前に処理されますが、パフォーマンス チューニングは後で行われます。Azure SQL データベースを使用する場合に、一般的にお勧めするのは、アプリケーションの実行プロセスとチューニング プロセスを交互に行うことです (お客様は月ごとに課金されるので、そうすることが望ましいでしょう)。キャパシティ オン デマンドでの支払いモデルによって、お客様は必要な最小限のリソースを使用するようにアプリケーションを即座にチューニングできます。アプリケーションの将来的な成長プランの予測に基づいてハードウェアを大幅に余分にプロビジョニングする必要がありません (遠い将来の予測をしなければならないため、こうした見通しは誤りがちです)。一部のお客様は、アプリケーションをチューニングせずに、ハードウェア リソースを余分にプロビジョニングすることを選択します。この方法は、お客様がアプリケーションのビジー期間中も主要アプリケーションを変更したくない場合は、効果があることもあります。アプリケーションをチューニングすると、Azure SQL データベースの新しいサービス階層を使用するときに、必要なリソースを最小限に抑え、毎月の請求額を下げることができます。

アプリケーションの特性

新しいサービス階層はアプリケーションのパフォーマンスの安定性と予測可能性を向上させるように設計されていますが、機能をより活用できるようにアプリケーションをチューニングするためのいくつかの推奨事項があります。多くのアプリケーションは上位のパフォーマンス レベルまたはサービス階層に切り替えるだけでパフォーマンスが大幅に向上しますが、追加のチューニングも行わないと同様の効果が得られないアプリケーションもあります。次のような特徴があるアプリケーションでは、Azure SQL データベースの使用時にパフォーマンスをさらに向上させるために、追加のアプリケーション チューニングも検討する必要があります。

  • "話し好き" な動作によってパフォーマンスが低下するアプリケーション

    これには、ネットワーク待機時間の影響を受けやすいデータ アクセス操作を過剰に行うアプリケーションが含まれます。そのようなアプリケーションでは、Azure SQL データベースに対するデータ アクセス操作の回数を減らすための変更が必要になることがあります。たとえば、アプリケーションは、アドホック クエリのバッチ化やストアド プロシージャへのクエリの移動などの技法を使用することで改善される場合があります。詳細については、後の「クエリのバッチ化」のセクションを参照してください。

  • 1 台のコンピューター全体でサポートしきれない大量のワークロードを持つデータベース

    最高の Premium パフォーマンス レベルを超えるリソースを必要とするデータベースは、適切な候補ではありません。これらのデータベースは、ワークロードをスケールアウトすると効果がある場合があります。詳細については、後の「複数データベース間での分割」と「機能的なパーティション分割」のセクションを参照してください。

  • 最適化されていないクエリを含むアプリケーション

    クエリのチューニングが不十分なアプリケーションは、特にデータ アクセス層にある場合、上位のパフォーマンス レベルを選択することの利点を期待ほどには得られない場合があります。たとえば、WHERE 句がないクエリ、欠落したインデックスがあるクエリ、古い統計があるクエリなどです。これらのアプリケーションは、標準的なクエリ パフォーマンス チューニング手法が効果的です。詳細については、後の「欠落したインデックス」と「クエリのチューニング/ヒント設定」のセクションを参照してください。

  • データ アクセス デザインが最適化されていないアプリケーション

    本質的なデータ アクセスの同時実行に関する問題 (デッドロックなど) があるアプリケーションは、上位のパフォーマンス レベルを選択することの利点を得られない場合があります。アプリケーション開発者は、Azure Caching サービスなどのキャッシュ テクノロジを使用してクライアント側にデータをキャッシュすることによって、Azure SQL データベースに対するやり取りを減らすことを検討する必要があります。後の「アプリケーション層キャッシュ」のセクションを参照してください。

チューニング テクニック

ここでは、Azure SQL データベースをチューニングすることで、アプリケーションのパフォーマンスを最大限に高め、できるだけ小さいパフォーマンス レベルで実行できるようにするために使用できる、いくつかのテクニックについて説明します。多くのテクニックは従来の SQL Server でのチューニングのベスト プラクティスと同等ですが、一部のテクニックはAzure SQL データベース に固有です。場合によっては、データベースのために使用されたリソースを調べて、さらにチューニングする必要がある領域を見つけることで、従来の SQL Server のテクニックを Azure SQL データベースでも機能するように拡張できます。

欠落したインデックス

OLTP データベースのパフォーマンスの一般的な問題は、データベースの物理デザインに関連しています。多くの場合、データベース スキーマは実際の規模 (および負荷やデータ量) でのテストなしでデザインおよび出荷されます。残念ながら、クエリ プランのパフォーマンスは、小規模では許容できても、実稼働レベルのデータ量を扱うと大幅に低下する場合があります。この問題の最も一般的な原因は、クエリのフィルターやその他の制限の条件を満たす、適切なインデックスの欠落です。それは、多くの場合、インデックスのシークで十分なときにテーブル スキャンが行われることで明らかになります。

次の例では、シークで十分なときに、選択されたクエリ プランにスキャンが含まれるケースを作成します。

DROP TABLE dbo.missingindex;
CREATE TABLE dbo.missingindex (col1 INT IDENTITY PRIMARY KEY, col2 INT);
DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
WHILE @a < 20000
BEGIN
    INSERT INTO dbo.missingindex(col2) VALUES (@a);
    SET @a += 1;
END
COMMIT TRANSACTION;
GO
SELECT m1.col1 
FROM dbo.missingindex m1 INNER JOIN dbo.missingindex m2 ON(m1.col1=m2.col1) 
WHERE m1.col2 = 4;


SQL_DB

Azure SQL データベースには、一般的なインデックスの欠落の条件を見つけて修正する方法に関するヒントをデータベース管理者に与える機能が含まれています。Azure SQL データベースに組み込まれている動的管理ビュー (DMV) では、クエリを実行するための推定コストがインデックスによって大きく削減されるクエリのコンパイルが調べられます。クエリの実行中には、各クエリ プランが実行される頻度や、実行中のクエリ プランと、インデックスが存在する場合を想定したクエリ プランとの推定ギャップを追跡します。これによって、データベース管理者は、どの物理的なデータベース デザインの変更が特定のデータベースの全体的なワークロードを向上させるかと、その実際のワークロードをすばやく判断できます。

次のクエリを使用すると、潜在的な欠落したインデックスを評価できます。

SELECT CONVERT (varchar, getdate(), 126) AS runtime, 
    mig.index_group_handle, mid.index_handle, 
    CONVERT (decimal (28,1), migs.avg_total_user_cost * migs.avg_user_impact * 
            (migs.user_seeks + migs.user_scans)) AS improvement_measure, 
    'CREATE INDEX missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + 
              CONVERT (varchar, mid.index_handle) + ' ON ' + mid.statement + ' 
              (' + ISNULL (mid.equality_columns,'') 
              + CASE WHEN mid.equality_columns IS NOT NULL 
                          AND mid.inequality_columns IS NOT NULL 
                     THEN ',' ELSE '' END + ISNULL (mid.inequality_columns, '')
              + ')' 
              + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement, 
    migs.*, 
    mid.database_id, 
    mid.[object_id]
FROM sys.dm_db_missing_index_groups AS mig
INNER JOIN sys.dm_db_missing_index_group_stats AS migs 
    ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details AS mid 
    ON mig.index_handle = mid.index_handle
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

この例では、次のインデックスが提示されます。

CREATE INDEX missing_index_5006_5005 ON [dbo].[missingindex] ([col2])

これを作成すると、同じ SELECT ステートメントがスキャンでなくシークを使用する別のプランを選択するようになり、次のクエリ プランに示すように、より効率的に実行できます。

SQL_DB

重要なのは、共有されている汎用的なシステムの IO 能力は、一般的に、専用のサーバー コンピューターよりも制限が厳しいということです。そのため、不要な IO を最小化して、Azure SQL データベースの新しいサービス階層の各パフォーマンス レベルの DTU 内でシステムの利点を最大限に活用することにはメリットがあります。適切な物理データベース デザインを選択すると、個々のクエリの待機時間や、スケール単位あたりの処理可能な同時要求のスループットを大幅に向上させ、クエリの条件を満たすために必要なコストを最小限に抑えることができます。欠落したインデックスの DMV に関する詳細については、「sys.dm_db_missing_index_details」を参照してください。

クエリのチューニング/ヒント設定

Azure SQL データベース内のクエリ オプティマイザーは、従来の SQL Server のクエリ オプティマイザーによく似ています。クエリのチューニングと、クエリ オプティマイザーに対する推論モデルの制限の理解に関するベスト プラクティスの多くは、Azure SQL データベースにも当てはまります。Azure SQL データベースでクエリをチューニングすると、総合的なリソース需要を削減することによる付加的な利益が得られます。また、アプリケーションは下位のパフォーマンス レベルで実行できるために、チューニングしていない場合よりも低コストで実行できるようになります。

Azure SQL データベースにも適用できる、SQL Server での一般的な例の 1 つは、より最適なプランを作成しようとしてコンパイル中にパラメーターを "見つけ出す" 方法に関連しています。パラメーターを見つけ出す機能は、クエリ オプティマイザーがより最適なクエリ プランを生成しようとしてクエリをコンパイルするときにパラメーターの現在の値を考慮するためのプロセスです。多くの場合、この方法では、パラメーター値に関する知識なしでコンパイルされるプランよりも大幅に速いクエリ プランが得られますが、現在の SQL Server/Azure SQL データベースの動作は不完全です。パラメーターが調べられない場合があったり、調べられても生成されるプランがワークロードのパラメーター値の完全なセットに対して最適でなかったりします。クエリ ヒント (ディレクティブ) を含めて、お客様が意図をより明確に指定し、パラメーターを見つけ出す機能の既定の動作を上書きできるようにしています。多くの場合、ヒントを使用すると、既定の SQL Server/Azure SQL データベースの動作が特定のお客様のワークロードに対して不完全であるケースを修正できます。

次の例は、クエリ プロセッサがどのようにパフォーマンスとリソース要件の両面で最適でないプランを生成するかと、クエリ ヒントの使用によってどのように Azure SQL データベースのクエリ実行時間とリソース要件を削減できるかを示しています。

セットアップ例:

DROP TABLE psptest1;
CREATE TABLE psptest1(col1 int primary key identity, col2 int, col3 binary(200));

DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
WHILE @a < 20000
BEGIN
    INSERT INTO psptest1(col2) values (1);
    INSERT INTO psptest1(col2) values (@a);
    SET @a += 1;
END
COMMIT TRANSACTION
CREATE INDEX i1 on psptest1(col2);
GO

CREATE PROCEDURE psp1 (@param1 int)
AS
BEGIN
    INSERT INTO t1 SELECT * FROM psptest1 
    WHERE col2 = @param1
    ORDER BY col2;
END
GO

CREATE PROCEDURE psp2 (@param2 int)
AS
BEGIN
    INSERT INTO t1 SELECT * FROM psptest1 WHERE col2 = @param2
    ORDER BY col2
    OPTION (OPTIMIZE FOR (@param2 UNKNOWN))
END
GO

CREATE TABLE t1 (col1 int primary key, col2 int, col3 binary(200));
GO

このセットアップ コードは、データ分布に偏りがあるテーブルを作成します。最適なクエリ プランは、選択されているパラメーターに応じて異なります。残念ながら、プラン キャッシュの動作では、最も一般的なパラメーター値に基づいてクエリが常に再コンパイルされるわけではありません。つまり、別のプランの方がより良い平均的なプラン候補であっても、準最適なプランがキャッシュされ、多くの値に対して使用される可能性があります。次に、2 つのほぼ同じストアド プロシージャが作成されます。違うのは、一方に特別なクエリ ヒントが含まれていることだけです (根拠は以下で説明されています)。

例 (パート 1):

-- Prime Procedure Cache with scan plan
EXEC psp1 @param1=1;
TRUNCATE TABLE t1;

-- Iterate multiple times to show the performance difference
DECLARE @i int = 0;
WHILE @i < 1000
BEGIN
    EXEC psp1 @param1=2;
    TRUNCATE TABLE t1;
    SET @i += 1;
END

例 (パート 2 – 結果の遠隔測定データが明らかに異なるように、このパートを試す前に 10 分間待ってください):

EXEC psp2 @param2=1;
TRUNCATE TABLE t1;

DECLARE @i int = 0;
WHILE @i < 1000
BEGIN
    EXEC psp2 @param2=2;
    TRUNCATE TABLE t1;
    SET @i += 1;
END


この例の各パートは、パラメーター化された挿入ステートメントを 1,000 回実行しようとします (テスト データ セットで関心を持たれるための十分な負荷を生成するため)。ストアド プロシージャを実行するときに、クエリ プロセッサは最初のコンパイル時にプロシージャに渡されたパラメーター値を調べます (パラメーターを "見つけ出す" と言われます)。生成されたプランはキャッシュされ、以降の呼び出しで、パラメーター値が異なる場合でも使用されます。その結果、最適なプランはどの場合にも使用されないことがあります。場合によっては、クエリが最初にコンパイルされたときの特定のケースではなく、平均的なケースにより適したプランを選択するように、お客様がオプティマイザーに指定する必要があります。この例では、最初のプランによって "スキャン" プランが生成され、パラメーターに一致する各値を見つけるためにすべての行が読み取られます。

SQL_DB

プロシージャを値 1 で実行したので、生成されたプランは 1 に対して最適でしたが、テーブルの他のすべての値に対しては準最適でした。その結果の動作は、お客様が各プランをランダムに選択する場合、プランの実行はより遅くなり、より多くのリソースを使用するので、望ましい動作にはならないでしょう。

テストを "SET STATISTICS IO ON" で実行すると、この例で内部的に行われる論理スキャン作業が表示されます。それによると、プランによって 1,148 の読み取りが行われたことがわかります (平均的なケースで返される行が 1 行だけの場合、これは非効率的です)。

SQL_DB

例の 2 つ目のパートは、クエリ ヒントを使用して、オプティマイザーに対してコンパイル処理中に特定の値を使用するように指示します。この場合、パラメーターとして渡された値を無視し、"UNKNOWN" と見なすようにクエリ プロセッサに強制します。つまり、テーブル内で平均的な頻度である値になります (偏りが無視されます)。生成されるプランはシーク ベースのプランであり、通常は例のパート 1 によるプランよりも高速で、使用リソースが少なくなります。

SQL_DB

この効果は、sys.resource_stats テーブルを調べるとわかります (注: テストを実行した時間とテーブルにデータが設定される時間との間に遅延があります)。この例では、パート 1 が 22:25:00 の時間枠中に実行され、パート 2 は 22:35:00 で実行されました。早い方の時間枠が、遅い方の時間枠よりも、その時間枠内でより多くのリソースを使用したことに注意してください (プランの効率性が向上したため)。

SELECT TOP 1000 * 
FROM sys.resource_stats 
WHERE database_name = 'resource1' 
ORDER BY start_time DESC

SQL_DB
Important重要
ここで使用されている例は意図的に小規模にしてありますが、準最適なパラメーターの影響は、特に大規模なデータベースでは、かなり大きくなる場合があります。極端な場合は、速いケースと遅いケースで数秒と数時間の差になることがあります。

お客様は sys.resource_stats を調べて、特定のテストで使用されるリソースがもう 1 つのテストと比べて多いか少ないかを判断できます。データを比較するときは、各テスト間に十分な時間をおいて、sys.resource_stats ビューで両方が同じ 5 分の時間枠内に一緒にグループ化されないようにしてください。さらに、この作業の目的は使用されるリソースの総量を最小限に抑えることであり、リソースのピーク自体を最小化することではない点に注意してください。通常は、待機時間のためにコードの一部を最適化すると、リソースの消費量も減少します。クエリ ヒントを使用するときは、アプリケーションに対して検討されている変更が実際に必要であり、アプリケーションを使用するどのユーザーの操作性にも悪い影響を与えないことを確認するようにしてください。

繰り返し実行されるクエリのセットがワークロードに含まれている場合は、通常、キャプチャしてこれらのプランの選択の最適性を検証してみると有益です。このようなクエリのセットによって、データベースをホストするために必要な最小限のリソース サイズのユニットが使用される可能性が高いためです。検証後は、たまにそれらのプランを再検査すると、プランの最適性が低下していないことを確認できます。クエリ ヒントの詳細については、「クエリ ヒント (Transact-SQL)」を参照してください。

複数データベース間での分割

Azure SQL データベースは汎用的なハードウェアで実行されるので、通常は従来のオンプレミス SQL Server インストールの場合よりも 1 つのデータベースに対する容量の上限が低くなります。そのため、多くのお客様がシャーディング (分割) 技法を使用しています。この技法では、データベース操作が Azure SQL データベースの 1 つのデータベースに対する制限内に収まらない場合に、データベース操作を複数のデータベースに分散させます。現在、Azure SQL データベースでシャーディング技法を使用しているほとんどのお客様は、1 つのディメンションのデータを複数のデータベースに分散させています。このアプローチでは、OLTP アプリケーションが多くの場合はスキーマ内の 1 行または数行のグループだけに適用されるトランザクションを行うことを理解しておく必要があります。たとえば、データベースに顧客、注文、および注文明細が含まれている場合 (SQL Server に付属している、従来のサンプル Northwind データベースなど)、関連する注文および注文明細の情報と共に顧客をグループ化し、それが 1 つのデータベース内にあることを保証することで、このデータを複数のデータベースに分割できます。アプリケーションが顧客を複数のデータベースに分割し、負荷が効率的に複数のデータベースに分散されるようにします。こうすることで、お客様はデータベース サイズの上限を回避できるだけでなく、Azure SQL データベースも個別の各データベースが DTU に収まる限り、さまざまなパフォーマンス レベルの上限よりも大幅に大きいワークロードを処理できるようになります。

データベース シャーディングはソリューションのリソース容量の総量を削減しませんが、この技法は複数のデータベースに分散された非常に大規模なソリューションをサポートするために非常に効果的であり、リソース要件が厳しく、非常に大きい "効果的な" データベースをサポートするために、各データベースを異なるパフォーマンス レベルで実行することができます。

機能的なパーティション分割

SQL Server ユーザーは、多数の機能を 1 つのデータベース内で組み合わせることがよくあります。たとえば、アプリケーションに店舗の在庫を管理するためのロジックが含まれている場合、そのデータベースには在庫、購買発注の追跡、月末レポートを管理したストアド プロシージャとインデックス付き/具体化されたビュー、およびその他の機能と関連するロジックが含まれている場合があります。この手法には BACKUP などの操作でデータベースを簡単に管理できる利点がありますが、アプリケーションのすべての機能にわたってピーク時の負荷を処理するためにお客様がハードウェアのサイズを調整することも必要になります。

Azure SQL データベースで使用されるスケールアウト アーキテクチャ内では、多くの場合、アプリケーションの機能を別々のデータベースに分割すると便利です。そうすれば、各データベースで個別にスケーリングを行うことができます。アプリケーションがよりビジーになると (そしてデータベースに対する負荷が増えると)、管理者はアプリケーションの機能ごとに個別のパフォーマンス レベルを選択できます。制限内で、このアーキテクチャでは複数のコンピューター間で負荷を分散することによって、単一の汎用コンピューターで処理できるサイズよりもアプリケーションを大きくできます。

クエリのバッチ化

負荷と頻度が高いアドホック クエリによってデータにアクセスするアプリケーションの場合、応答時間の大部分はアプリケーション層と Azure SQL データベース層間のネットワーク通信に費やされます。アプリケーションと Azure SQL データベースが同じデータ センター内に存在する場合でも、両者の間のネットワーク遅延は多数のデータ アクセス操作によって増す場合があります。このようなデータ アクセス操作のためのネットワーク ラウンド トリップを削減するために、アプリケーション開発者はアドホック クエリをバッチ処理するか、それらをコンパイルしてストアド プロシージャにするオプションを考慮する必要があります。アドホック クエリをバッチ処理すると、複数のクエリを 1 つの大きなまとまりとして、Azure SQL データベースへの 1 回のトリップで送信できます。アドホック クエリをストアド プロシージャにコンパイルすると、バッチ処理と同じ結果を得ることができます。ストアド プロシージャを使用すると、同じストアド プロシージャを後でまた実行するときのためにクエリ プランを Azure SQL データベースにキャッシュできる可能性が高くなるという利点もあります。

一部のアプリケーションでは、集中的に書き込みが行われます。場合によっては、書き込みを 1 つにまとめる方法を検討することで、データベースに対する合計 IO 負荷を削減できます。そのためには、通常、単にストアド プロシージャおよびアドホック バッチ内で自動コミット トランザクションの代わりに明示的なトランザクションを使用します。使用可能な別の手法の評価については、「Azure での SQL データベース アプリケーションのバッチ処理手法」で参照できます。独自のワークロードで実験して、バッチ処理用の適切なモデルを見つけてください。モデルごとにトランザクションの一貫性の保証が多少異なる場合があることを理解しておく必要があります。最終的には、リソース使用を最小限に抑える適切なワークロードを見つけるには、一貫性とパフォーマンスのトレードオフの適切な組み合わせを見つける必要があります。

アプリケーション層キャッシュ

一部のデータベース アプリケーションには、読み取りが集中的に行われるワークロードが含まれます。キャッシュ層を使用して、データベースの負荷を削減し、場合によっては、Azure SQL データベースを使用しているデータベースのサポートに必要なパフォーマンス レベルを下げることができます。Azure Caching (キャッシュ) を使用すると、読み取りが集中的に行われるワークロードを持つお客様は、データを一度 (構成方法によっては、アプリケーション層コンピューターごとに 1 回ずつ) 読み取って、そのデータを Azure SQL データベースの外部に格納できます。そうすることで、データベースの負荷 (CPU および読み取り IO) を削減できますが、キャッシュから読み取られるデータはデータベースのデータより古い場合があるので、トランザクションの一貫性に影響があります。不整合の量が許容されるアプリケーションも多数ありますが、すべてのワークロードでもそうであるとは限りません。アプリケーション層のキャッシュ方法を採用する前に、アプリケーションの要件について十分に理解しておいてください。

結論

Azure SQL データベースの新しいサービス階層の導入により、お客様はクラウド内で構築するアプリケーションの種類の水準を引き上げることができます。アプリケーションのチューニングに手間をかければ、アプリケーションのパフォーマンスが強化され、予測可能になります。このドキュメントでは、新しいパフォーマンス レベルの 1 つに適合するようにデータベースのリソース利用を最適化する推奨手法について説明します。チューニングはクラウド モデルでの継続的な作業であり、新しいサービス階層とそのパフォーマンス レベルを使用すると管理者は Microsoft Azure プラットフォームでのコストを最小限に抑え、パフォーマンスを最大にすることができます。

参照

コミュニティの追加

追加
表示:
© 2014 Microsoft