Freigeben über

新しい Azure SQL Database サービス レベルのパフォーマンス

  • Artikel

このポストは、5 月 19 日に投稿した Performance in the new Azure SQL Database Service Tiers の翻訳です。

4 月 24 日に、SQL Database の新しいサービス レベルのプレビューとして Basic (基本) および Standard (標準) を導入し、またビジネス継続性に関する新たな機能を導入しました。今回の記事では、SQL Database のパフォーマンスに対する新しいアプローチについて詳しく見ていきます。

まず、今回の変更に至った経緯について説明します。新しいサービス レベルにおいて、パフォーマンス、特に予測可能な形でのパフォーマンスを重視したのは、Web Edition と Business Edition での SQL Database のパフォーマンスに対するお客様からの強い要望にお応えするためです。これまで Web Edition と Business Edition のパフォーマンスは予測ができず不安定で、ビジネスクリティカルなアプリケーションを運用するお客様にとっては問題の種になっていました。もちろん予測可能なパフォーマンスがきわめて重要であることは私たちも承知しており、長期的なパフォーマンスに信頼が置けないプラットフォーム上では安定稼動するシステムを構築するのは容易ではないというご意見もいただいていました。

そうした声に応えるべく、2013 年 7 月よりプレビュー提供していた Premium (プレミアム) に加えて、Basic (基本) および Standard (標準) のレベルを新たに設定しました。Premium (プレミアム) は、とりわけ予測可能なパフォーマンスの提供に重点を置いており、そのパフォーマンスについてはお客様から非常に良好な反応をいただいています。Basic (基本) および Standard (標準) レベルはそうしたメリットを新たな価格設定で提供します。お客様がパフォーマンスをレバーでコントロールできるようになり、これは、クラウド コンピューティング業界の情勢とも一致します。こうした選択肢をお客様に提供すること。それが Web Edition や Business Edition の “価格/ストレージ” サービス モデルを捨てて “価格/パフォーマンス + 機能” という新たなモデルを採用した一番の理由です。

新しいサービス レベルでアプリケーションをテストする際は、現在はパフォーマンスの細かい調整を重ねていくプレビュー段階であることに留意してください。このプレビュー期間に寄せられたお客様のご意見によく耳を傾け、新しいサービス レベルの洗練に活用させていただきます。パフォーマンス テストを実行する場合は、新しいサービス レベルが提供するさまざまなパフォーマンス レベルをきちんと把握できるように、定期的にテストを繰り返してください。マイクロソフトでは、プレビュー期間を通じて進展があるたびに、パフォーマンスに関するブログ記事を随時投稿していきます。

実は、既にお客様からのフィードバックを基に、Basic (基本) と Standard (標準) レベルのスループットを以下のとおり改善しています。提供開始は 5 月 19 日 (月) の週です。

  • Basic:1 DTU –> 5 DTU
  • S1:5 DTU –> 15 DTU
  • S2:25 DTU –> 50 DTU

パフォーマンスについて

データベースのパフォーマンスは複雑で、その状態を説明するために多くの指標が使用されます。アプリケーションの観点からユーザーが注目するのは、以下の点です。

  • 応答時間
  • 特定のクエリ実行の開始から終了までの経過時間。
  • スループット
  • システムが特定の時点に実行可能な総仕事量または実行速度。スループットが適正であると見なされるのは、通常、個々の実行が指定の応答時間内で終了する場合に限られます。

応答時間やスループットにはさまざまな要素が影響しますが、それらは主に、アプリケーションの設計とハードウェア リソースの 2 つに分けることができます。以下に、データベース アプリケーションのパフォーマンスに関するトラブルシューティングについてよくある質問の例をいくつか紹介します。

  • アプリケーションの設計
  • クエリを実行するのに最適なプラットフォームを正しく評価できる指標は存在するか。
  • 適切なトランザクション分離レベルを使用しているか。システムはロックされたリソースに対して不要な待機を行っていないか。
  • ラウンドトリップが、マルチステートメント バッチやストアド プロシージャの使用などによって最小限に抑えられているか。
  • ハードウェア リソース
  • ワークロードを実行するのに十分なリソースがあるか。
  • 今後発生するさまざまなタイプのワークロードに対してどのくらいのリソースが必要か。

パフォーマンスに関しては、SQL Database の新たなサービス レベルの導入により、ハードウェア リソースがより充実したパフォーマンス レベルにアップグレードできるようになったので、ハードウェア リソースに関する問題は解消されます。スケールアウト設計パターン (シャーディング) を採用している場合は、新たなパフォーマンス レベルを利用して、ワークロードの配分に応じてシャード毎にリソースを調節することができます (例: きわめて活発な利用者がいるシャードには高パフォーマンス レベルを割り当てる、など)。シャーディングに関する詳しいガイダンスを鋭意準備中ですので、今しばらくお待ちください。

また、クラウドの設計のベスト プラクティスは、アプリケーションの設計を継続的に最適化していくことです。その結果、高いパフォーマンス レベルを使用する必要が減り、データベース ワークロードの実行コストを削減できます。

ハードウェアの仕様

データベース ワークロードの実行に必要なリソースは、各種ハードウェア、すなわち CPU、ディスク IO 処理 (読み取り/書き込み)、およびメモリなどです。これらリソースの諸元はそれぞれさまざまであり、たとえば、コアの種類によってクロック サイクルやキャッシュ サイズが異なり、IO はデータベース システムが実行している処理に応じてさまざまなサイズで実行されます。アプリケーションが実際にこれらの各リソースをどのくらい必要とするかを見積もったり、使用率の遷移を比較したりするのは容易ではなく、時間もかかります。オンプレミスの世界では、データベースが稼動するハードウェアを制御することの代償として受け入れられていますが、クラウドへの移行、特に SQL Database を使用することのメリットは、ハードウェアの管理や修正プログラムの管理、データベース ソフトウェアの保守を行う必要がなく、アプリケーションの開発に専念できるという点です。面倒な作業は要らない、必要なときにスループットを確保したい、というお客様の声を受け、マイクロソフトは、パフォーマンスに新たに注力しています。

新たに提供するサービス レベルでは、予測可能なパフォーマンスを確保するため、新しい設計原則を採用しました。各パフォーマンス レベル (Basic/S1/S2/P1/P2/P3) はリソース (CPU、メモリ、IO など) の割り当てに対応しており、レベルごとにデータベースが利用可能なリソースの最大量が定義されています。この設計原則では、データベースは、指定パフォーマンス レベルのリソースを積んだ専用コンピューター上で実行する場合とほぼ同等のパフォーマンスを達成します。この設計原則は、予測可能なパフォーマンスを提供するための土台となるものです。

各レベルのリソースがどのように異なるかを簡単に把握できるように、DTU (Database Throughput Unit: データベース スループット ユニット) という概念を導入しています。この DTU は、パフォーマンス レベルごとに割り当てられたリソースの指標です。たとえば、P1 の DTU は 100、S1 は 15 で、S1 のリソースは P1 の 1/7 以下ということになります。上記の設計原則では、S1 で稼動しているデータベースのパフォーマンスは、P1 の 1/7 以下の速度の CPU、1/7 以下の量のメモリ、1/7 以下の IO 容量を搭載した専用コンピューターで実行した場合と同じレベルになります。

ユーザーやトラブルシューティングに関しては、マイクロソフトでは現在のパフォーマンス レベルに対してデータベース ワークロードが消費している各リソースの割合を公開しており、各種 IO やディスク キューの長さなどを理解していなくとも、現在のパフォーマンス レベルに対するリソース消費量を簡単に把握していただけます。

CPU 使用率、読み取り、書き込みの利用統計情報をマスター データベースの sys.resource_stats ビューで確認することができ、メモリについてもプレビュー期間中に追加される予定です。各リソースについて 5 分あたりの平均値 (総消費/5 分) を確認できるので、リソースに対する要求の遷移を追うのに便利です。この利用統計情報はポータルでも確認できます。sys.resource_stats のクエリや、使用された DTU の評価の詳細については、新しいサービス レベルに関するこちらの MSDN 記事を参照してください。

パフォーマンスのトラブルシューティングには説得力のある利用統計情報が重要になります。これについてもプレビュー期間中にさらに機能を強化していくつもりです。

データベース ワークロードのライフサイクル

“データベースの使用” にはさまざまな作業が伴います。当たり前のように聞こえますが、このことは、データベースに最適なパフォーマンス レベルを見積もり、そこからデータベース ワークロードを実行するために最適なコストを計算するうえで重要です。“Standard ( 標準) S2 で月額 200 ドル” (一般提供の価格を使用) というように簡単に数字を弾き出せるとは限りません。クラウド、特に SQL Database がもたらす大きなメリットの 1 つは、柔軟なスケーラビリティです。たとえば、“Basic ( 基本) を使用して月曜日から木曜日、土曜日、日曜日はわずかなクエリを実行、金曜日は S2 を使用して特定の時間帯に大規模なバッチ ジョブの実行を管理、月に 1 日は P1 を使用して大規模な ETL 処理を高速実行する” というケースでは、次のようになります。

  • (Basic 価格 / 30 * 25) = 4.16 ドル
  • (S2 価格 / 30 * 4) = 26.7 ドル
  • (P1 価格 / 30 * 1) = 31 ドル
    月額 61.86 ドル

上の例のように、通常、データベースのワークロードのライフサイクルには、要件がさまざまに異なるサブワークロードが含まれます。これにはたとえば次のようなものがあります。

  • データベースの初期ロード (例: SQL Database への移行時)
  • 通常の使用 (例: 通常営業日の単一の部署のユーザーによるアプリの使用)
  • ピーク時の使用 (例: 月に一度の社内の全従業員のレポートの一括処理)
  • 大規模な ETL (抽出、変換、読み込み) またはインポート/エクスポート処理
  • 物理的なデータベースの保守作業 (インデックスの作成など)

ワークロードを要件別に分類すれば、たとえばピーク時の負荷に合わせたパフォーマンス レベルを常に維持する必要がないことがわかり、コストを大幅に削減できる場合があります。

また、アプリケーションのコードから必要に応じてパフォーマンス レベルを変更することが可能です。シンプルな Update Database API (英語) コールを使用し、新たなサービス目標を指定します。変更は非同期で行われ、Get Database API を使用して変更の状態を監視できます。変更処理全体を通じてデータベースは利用可能な状態を維持します。

Web Edition および Business Edition と、Basic (基本)、Standard (標準)、Premium (プレミアム) の比較

新しいサービス レベルのパフォーマンスは、Web Edition および Business Edition と比べてどうなのかという質問をよく受けます。これは即答するのが難しい質問です。Web Edition および Business Edition と新しいサービス レベルは根本的に異なるからです。Web Edition と Business Edition のサービス モデルはストレージの使用量のみがベースで、その他のハードウェア リソースは考慮していません。システムはストレージの可用性を保証するよう最適化されており、データベース ワークロードを実行するために使用されるその他のリソースはそれに含まれません。これには根本的な欠陥があります。Web Edition と Business Edition のパフォーマンス レベルやリソースの可用性は、同じマシンを利用する他のお客様のワークロードや、使用率の上昇に対するシステムの防止機能など、さまざまな要因に左右されます。これらのリソースを利用できるかどうかはギャンブルのようなもので、今回新たに導入したサービス レベルで対応しなければ、問題がますます顕著になるところでした。

冒頭で述べたとおり、予測できない不安定なパフォーマンスについては否定的なご意見をいただいており、新しいサービス レベルの Basic (基本)、Standard (標準)、Premium (プレミアム) では、高水準の予測可能性をさまざまな価格帯で提供することに重点を置いています。それにより、ストレージに限らず、データベース ワークロード実行に必要なその他のハードウェア リソースの可用性を維持するようシステムを最適化しています。

このように、新しいサービス レベルは設計原則が根本的に異なるため、比較するにはりんごとオレンジを比べるようなことになってしまいます。

Web Edition と Business Edition のリソース消費を把握できるように、sys.resource_stats (前述) でリソース使用率を提供しています。Web Edition と Business Edition のリソース使用率の計算に関する利用統計情報の基準値は、Web/Business データベースに対応する一般的な価格帯である Standard (標準) S2 の 2 分の 1 に設定されています。これは利用統計情報の基準値に過ぎず、Web Edition と Business Edition で利用可能なリソースの量 (前述のとおり、定義されていません) を表しているものではないことに注意してください。データベースが必要とするパフォーマンス レベルを正確に把握するには、新しいサービス レベルのいずれかにアップグレードしてワークロードを実行し、sys.resource_stats をモニタリングする必要があります。現在、Basic (基本) および Standard (標準) サービス レベルは新しい論理サーバーでのみ利用可能ですが、この制限はプレビュー期間内に解除される予定で、その後は新しいサービス レベルをテストするために Web Edition や Business Edition のデータベースをインポートする必要がなくなります。

最後に

今回の記事で新しいサービス レベルのパフォーマンスについて少しでも理解を深めていただけたなら幸いです。冒頭で述べたとおり、プレビュー期間を通じてフィードバックおよびパフォーマンス目標の評価を行っています。皆様からお寄せいただいたフィードバックを基に、パフォーマンス レベルの調整を加えていくつもりです。

最後に参考資料をいくつかご紹介します。

SQL Database をご利用いただき、またプレビュー版をご試用いただきありがとうございます!

/Tobias および SQL Database チーム一同