最小限のダウンタイムでデータベースのリソースを動的にスケーリングする

適用対象: Azure SQL Database Azure SQL Managed Instance

Azure SQL Database と SQL Managed Instance では、最小限のダウンタイムでデータベースにリソースを動的に追加できます。ただし、データベースへの接続が短時間失われる切り替え期間があります。これは、再試行ロジックを使用することで軽減できます。

概要

少数のデバイスや顧客から始まったアプリの需要が何百万という数にまで膨れ上がると、Azure SQL Database と SQL Managed Instance は、最小限のダウンタイムですばやくスケーリングされます。 スケーラビリティは、必要なときにサービスにリソースを動的に追加することができる、サービスとしてのプラットフォーム (PaaS) の最も重要な特性の 1 つです。 Azure SQL Database では、データベースに割り当てられたリソース (CPU パワー、メモリ、IO スループット、ストレージ) を簡単に変更することができます。

インデックス付けやクエリ書き換えの方法では修正できない、アプリケーション使用量増加によるパフォーマンスの問題を軽減することができます。 リソースを追加すると、データベースが現在のリソース制限に達し、受信ワークロードの処理にいっそうのパワーが必要なときに、迅速に対応できます。 Azure SQL Database では、必要のないリソースをスケールダウンしてコストを抑えることもできます。

ハードウェアの購入や、基になるインフラストラクチャの変更について、心配する必要はありません。 データベースのスケーリングは、Azure portal でスライダーを使って簡単に実行できます。

データベースのパフォーマンスをスケーリングする

Azure SQL Database には、DTU ベースの購入モデル仮想コアベースの購入モデルが用意されていますが、Azure SQL Managed Instance には仮想コアベースの購入モデルのみが用意されています。

  • DTU ベースの購入モデルには、データベースの軽量ワークロードから重量ワークロードまでをサポートする、計算リソース、メモリ リソース、および I/O リソースの組み合わせがそれぞれ異なる、Basic、Standard、Premium の 3 つのサービス レベルがあります。 各レベルにおけるパフォーマンス レベルでは、これらのリソースのさまざまな組み合わせが提供され、ストレージ リソースを追加することができます。
  • 仮想コアベースの購入モデルでは、仮想コアの数、メモリの量、およびストレージの容量と速度を選択できます。 この購入モデルは 3 つのサービス レベルを提供します:General Purpose、Business Critical、および Hyperscale。

最初に Basic、Standard、または General Purpose サービス レベルで月額の安い小さな単一データベースにアプリをビルドし、後でいつでもソリューションのニーズに合わせて手動またはプログラムでサービス レベルを Premium または Business Critical サービス レベルに変更できます。 アプリにも顧客にもダウンタイムを発生させずにパフォーマンスを調整することができます。 動的なスケーラビリティにより、データベースは変化の激しいリソース要件に透過的に対処することができ、必要なときに必要な分のリソースにのみ課金されます。

注意

動的スケーラビリティは自動スケールとは異なります。 自動スケールは、基準に基づいてサービスが自動的にスケールされるのに対し、動的スケーラビリティでは、最小限のダウンタイムで手動スケールすることができます。

Azure SQL Database の単一データベースは、手動の動的スケーラビリティをサポートしていますが、自動スケーリングはサポートしていません。 自動 操作を増やすには、エラスティック プールの使用を検討してください。エラスティック プールを使用すると、データベースが個々のデータベースのニーズに基づいてプール内のリソースを共有できます。 ただし、Azure SQL Database の単一データベースのスケーラビリティを自動化できるスクリプトがあります。 例については、「PowerShell を使用して単一の SQL データベースを監視およびスケーリングする」を参照してください。

DTU サービス層または仮想コアの特性はいつでも変更することが可能で、アプリケーションのダウンタイムも最小限に留められます (通常、平均で 4 秒未満)。 特に使用パターンが比較的予測可能である場合、多くのビジネスとアプリについては、データベースを作成し、要求に応じてパフォーマンスを調整する能力は十分です。 しかし、使用パターンが予測できない場合、コストおよびビジネス モデルを管理するのが難しくなる可能性があります。 このシナリオでは、プール内の複数のデータベース間で共有される特定の数の DTU でエラスティック プールを使用します。

SQL Database の概要:階層とレベル別の 1 つのデータベースの DTU

Azure SQL Database には、データベースを動的にスケーリングする機能が用意されています。

Azure SQL Managed Instance を使用すると、次のようにスケーリングすることもできます。

  • SQL Managed Instance では仮想コア モードが使用され、インスタンスに割り当てられる最大 CPU コア数と最大ストレージ量を定義できます。 マネージド インスタンス内のすべてのデータベースによって、インスタンスに割り当てられたリソースが共有されます。

いずれかの種類でスケールアップまたはスケールダウンのアクションを開始すると、データベース エンジン プロセスが再起動され、必要に応じて別の仮想マシンに移動されます。 新しい仮想マシンへのデータベース エンジン プロセスの移動は、プロセスの実行中に既存の Azure SQL Database サービスの使用を継続できる オンライン プロセス です。 ターゲット データベース エンジンが完全に初期化され、クエリを処理する準備が整うと、接続はソースからターゲット データベース エンジンに切り替えられます

注意

データのインポート、データ処理ジョブ、インデックスの再構築など、実行時間の長いトランザクションが実行されている場合、またはインスタンスにアクティブな接続がある場合は、マネージ インスタンスをスケーリングしないことをお勧めします。 スケーリングの完了にかかる時間が通常よりも長くならないようにするには、実行時間の長いすべての操作の完了時にインスタンスをスケーリングする必要があります。

注意

スケールアップ/スケールダウン処理が完了するとき、短時間の接続の中断が予想されます。 標準の一時的なエラーのための再試行ロジックを実装している場合、フェールオーバーを意識することはありません。

別のスケーリング方法

リソースのスケーリングは、データベースまたはアプリケーション コードを変更することなく、データベースのパフォーマンスを向上させることができる、最も簡単で効果的な方法です。 場合によっては、最高のサービス レベル、コンピューティング サイズ、パフォーマンス最適化であっても、コスト効果の高い方法でワークロードを正常に処理できないことがあります。 そのような場合は、次の追加オプションでデータベースの規模を変更できます。

  • 読み取りスケールアウトは、データの 1 つの読み取り専用レプリカを取得している場合に利用できる機能であり、レポートなどの負荷が高い読み取り専用クエリを実行できます。 読み取り専用レプリカでは、プライマリ データベースのリソース使用量に影響を与えることなく、読み取り専用ワークロードが処理されます。
  • データベース シャーディングは、データを複数のデータベースに分割してそれらを個別にスケーリングできる一連のテクニックです。

次のステップ