最小限のダウンタイムでデータベース リソースを動的に拡張 - Azure SQL データベース と Azure SQL Managed Instance

  • [アーティクル]

適用対象:Azure SQL データベースAzure SQL Managed Instance

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

概要

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

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

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

Scale database performance

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

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

データベース、エラスティック プール、またはマネージド インスタンスのサービス レベル、コンピューティング レベル、およびリソースの制限は、いつでも変更できます。 たとえば、サーバーレス コンピューティング レベルを使用して 1 つのデータベースで最初のアプリを作成し、後でソリューションのニーズに合わせて、いつでもそのサービス レベルをプロビジョニングされたコンピューティング レベルに手動またはプログラムで変更できます。

注意

データベースのサービス レベルを変更できない主な例外は次のとおりです。

  • Business Critical と Premium のサービス レベルでのみ使用できる機能が使用されているデータベースは、General Purpose または Standard のサービス レベルを使用するように変更できません。 現在、このような機能はインメモリ OLTP のみです。
  • Hyperscale サービス レベルで最初に作成されたデータベースは、他のサービス レベルに移行できません。 Azure SQL Database 内の既存のデータベースを Hyperscale サービス レベルに移行する場合、元の Hyperscale への移行から 45 日以内であれば、General Purpose サービス レベルに逆移行することができます。 データベースを別のサービス レベル (Business Critical など) に移行する場合は、まず General Purpose サービス レベルに逆移行してから、さらに移行を行います。 詳細については、Hyperscale から逆移行する方法に関するページを参照してください。

ワークロードの需要に合わせてサービス目標 (スケーリング) を変更することによって、データベースに割り当てられたリソースを調整できます。 また、これにより、必要なときに必要な分のリソースに対してのみ料金を支払うことができます。 スケーリング操作がアプリケーションに与える可能性のある影響についての注意事項をご覧ください。

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

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

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

ヒント

動的スケーリングを使用すると、お客様はリソースの割り当てを手動またはプログラムで変更できます。 動的スケーリング機能は、すべての Azure SQL Database および Azure SQL Managed Instance リソースに使用できます。

動的スケーリングのサポートに加えて、Azure SQL Database のサーバーレス層では自動スケーリングがサポートされています。 サーバーレス層のデータベースが、ワークロードの需要に基づいて、お客様が指定した範囲内でリソースを自動的にスケーリングします。 データベースをスケーリングするためにお客様のアクションは必要ありません。

スケールアップまたはスケールダウンの操作の影響

前述のいずれかの種類でスケールアップまたはスケールダウンのアクションを開始すると、データベース エンジン プロセスが再起動され、必要に応じて別の仮想マシンに移動されます。 新しい仮想マシンへのデータベース エンジン プロセスの移動はオンライン プロセスです。その間は、既存の Azure SQL Database サービスの使用を継続できます。 ターゲット データベース エンジンでクエリを処理する準備が整うと、現在のデータベース エンジンへのオープン接続が終了され、コミットされていないトランザクションがロールバックされます。 ターゲット データベース エンジンへの新しい接続が行われます。

注意

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

注意

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

別のスケーリング方法

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

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

次のステップ