適用対象:Azure SQL データベース
この記事では、Azure SQL Databaseのサーバーレス計算層におけるオートスケーリングの仕組みについて説明します。 サーバーレス計算層において、 最小vCore と 最大vCore パラメータは重要です。 これらのパラメータはデータベースのパフォーマンス体験と計算コストを形作ります。
スケーリング応答性
サーバーレス データベースは、最大仮想コア構成によって設定された制限内で要求されたコンピューティング量を中断することなく、リソースの需要を満たすのに十分な容量を備えたインフラストラクチャ上で実行されます。 一般に、構成された最大仮想コアへの CPU スケールアップはほぼ瞬時であり、接続が中断されることなく発生します。 場合によっては、マシン リソースを再調整する必要がある場合、スケールアップに時間がかかる場合があります。この場合、最大で数分かかる場合があります。 データベースは、再調整中もオンラインのままです。ただし、接続が一時的に切断された場合は、操作の終了時を除きます。 この種の再調整はまれです。 いずれの場合も、CPU のスケールアップはメモリのスケールアップに依存しません。
メモリ管理
汎用サービス層とハイパースケールサービス層の両方で、システムはプロビジョニング済みの計算データベースよりもサーバーレスデータベースのメモリを回収する頻度が高いです。 この挙動はサーバーレス環境でのコスト管理に役立ち、パフォーマンスに影響を与えることがあります。
キャッシュの再利用
プロビジョニング型コンピュートデータベースとは異なり、サーバーレスデータベースはCPUやアクティブキャッシュの利用率が低いときにSQLキャッシュからメモリを回収します。
- アクティブキャッシュ利用率は、直近使用されたキャッシュエントリの総サイズが一定期間閾値以下にとどまると低くなります。
- キャッシュ回収がトリガーされると、システムはターゲットキャッシュサイズを前回のサイズの一部に段階的に減らし、使用率が低い場合にのみ回収を続けます。
- キャッシュの回収が発生している場合、削除するキャッシュ エントリの選択ポリシーは、メモリ負荷が高いときのプロビジョニングされたコンピューティング データベースの選択ポリシーと同じです。
- システムは、最小vCoreで定義された最小メモリ制限以下にキャッシュサイズを削減することはありません。
サーバーレスおよびプロビジョニング済みのコンピュートデータベースの両方で、利用可能なメモリがすべて使用されていれば、システムはキャッシュエントリを追放できます。
CPU 使用率が低い場合、使用パターンによってはアクティブなキャッシュの使用率が高いままになり、メモリの再利用が妨げられる可能性があります。 また、ユーザーの活動が停止した後、メモリ回収が行われる前に、定期的なバックグラウンドプロセスが前のユーザーの活動に応答することで、他の遅延が発生することもあります。 例えば、削除操作やクエリ ストアのクリーンアップタスクは、削除対象としてマークされたゴーストレコードを生成しますが、ゴーストクリーンアッププロセスが実行されるまで物理的に削除されません。 ゴースト クリーンアップでは、キャッシュへのデータ ページの読み取りが行われる場合があります。
キャッシュハイドレーション
SQLメモリキャッシュは、システムがディスクからデータを取得するにつれて成長し、プロビジョニングされたデータベースと同じ速度で動作します。 データベースが忙しい時は、メモリが利用可能であればキャッシュは制約なく成長できます。
ディスク キャッシュ管理
サーバーレスおよびプロビジョ化された計算層の両方のHyperscaleサービス層では、各計算レプリカはResilient Buffer Pool Extension(RBPEX)キャッシュを使用します。 このキャッシュはIO性能を向上させるためにローカルSSDにデータページを保存します。 ただし、Hyperscale のサーバーレス コンピューティング レベルでは、ワークロードの需要の増減に応じて、各コンピューティング レプリカの RBPEX キャッシュが自動的に拡大縮小します。 RBPEX キャッシュが拡大できる最大サイズは、データベース用に構成された最大メモリの 3 倍です。 サーバーレスにおける最大メモリおよびRBPEXの自動スケーリング制限の詳細については、 サーバーレス・ハイパースケールリソースリミットを参照してください。