デプロイ オプションの説明
Azure SQL Database は、サービスとしてのプラットフォーム (PaaS) であり、高いスケーラビリティと最小限のメンテナンスを実現する、特定のワークロードに最適のソリューションです。 新しいアプリケーションの開発に適しており、開発者が新しいサービスを構築する際に高い柔軟性を発揮することができ、詳細なデプロイ オプションが大規模に用意されています。 このメンテナンスが容易なソリューションは、さまざまなワークロードに最適であり、効率的かつ効果的なアプリケーション開発を実現します。
デプロイ モデルについて
Azure SQL Database をデプロイする場合、2 つの主要なデプロイ モデル ( 単一データベース と エラスティック プール) があります。 エラスティック プール モデルでは、同じプール内の複数のデータベース間でリソースが共有されますが、単一データベース モデルでは、リソースがデータベースごとに独立して管理されます。
仮想マシンと同様に、SQL Database は PowerShell、Azure CLI、Azure portal などのさまざまな方法を使用してデプロイできます。
単一データベース
単一データベース デプロイ モデルは、Azure SQL Database を使用する最も簡単な方法です。 このモデルでは、規模とデータ サイズの観点から各データベースを個別に管理します。 複数のデータベースが同じ論理サーバーにデプロイされている場合でも、各データベースには独自の専用リソースがあります。
Azure portal を通じて各データベースのリソース使用率を監視できます。 この機能を使用すると、データベースのパフォーマンスを簡単に追跡および評価できます。
エラスティック プール
エラスティック プールを使用すると、ストレージとコンピューティング リソースをデータベースのグループに割り当てることができるため、各データベースを個別に処理する場合と比べて管理が簡略化されます。 エラスティック プールに対する変更では、含まれるすべてのデータベースのリソースが自動的に調整されるため、単一データベースよりも簡単にスケーリングできます。
このモデルは、リソースがすべてのデータベース間で共有されるため、サービスとしてのソフトウェア アプリケーションにとってコスト効率が高くなります。 DTU ベースまたは仮想コアベースの購入モデルを使用してリソースを構成できます。
リソースを継続的に監視して、プール内の他のデータベースに影響を与える可能性のあるパフォーマンスのスパイクを特定することが重要です。 割り当て戦略を定期的に見直すことで、すべてのデータベースに十分なリソースが確保されます。
エラスティック プールは、各テナントに独自のデータベース コピーがある、平均使用率が低いマルチテナント アーキテクチャに最適です。
購入モデルについて
SQL データベースに適切なデプロイ モデルを選択したら、次の手順は、ワークロードと予算の要件に最適な購入モデルを選択することです。 Azure SQL Database には、 仮想コア モデルと DTU ベースのモデルの 2 つの購入モデルが用意されています。 各モデルには独自の利点があるため、どのモデルがワークロード要件とコストの考慮事項に最も適しているかを理解することが重要です。
仮想コアベース
これは推奨される購入モデルであり、コンピューティング リソースとストレージ リソースが分離されています。 つまり、ストレージ リソースとコンピューティング リソースを互いに独立してスケーリングできます。 この柔軟性により、他のコンポーネントに影響を与えることなく、特定のニーズに応じてリソースを調整できます。
仮想コアベースの購入モデルでは、コストはサービス レベル、ハードウェア構成、仮想コアの数とメモリ量、予約済みデータベース ストレージ、実際のバックアップ ストレージなどのいくつかの要因によって異なります。
注
価格の詳細については、Azure SQL Database の価格ページ
サービス レベルは、パフォーマンス、ストレージの種類、高可用性、ディザスター リカバリー オプション、データベースの特定の機能の可用性を決定する事前定義された構成です。
仮想コア購入モデルには、次の 3 つのサービス レベル オプションが用意されています。
| サービス レベル | 機能 |
|---|---|
| 汎用 | このサービス レベルは、それほど負荷のかからない運用向けに設計されており、コンピューティングおよびストレージ オプションのコスト効率の高いバランスを提供します。 これにはプロビジョニング済みコンピューティング レベルと サーバーレス コンピューティング レベルの両方が含まれており、予算を最適化しながら、さまざまなワークロードの需要に柔軟に対応できます。 |
| ビジネスクリティカル | このレベルは、低待機時間でハイ パフォーマンスのストレージを必要とするアプリケーションに最適です。 In-Memory OLTP をサポートし、組み込みの読み取り専用レプリカが含まれています。 さらに、コアあたりのメモリが多く、ローカル SSD ストレージを使用するため、パフォーマンス重視のワークロードに最適です。 |
| ハイパースケール | このレベルは、大規模なデータベースと高スループット要件を持つアプリケーション向けに調整されています。 Hyperscale には高度な水平スケーリング機能が導入されており、データ サイズの増加に応じてコンピューティング ノードを追加できます。 これは 1 つの SQL データベースでのみサポートされており、General Purpose および Business Critical サービス レベルの制限を超えてストレージとコンピューティング リソースを大幅にスケーリングできます。 |
DTU ベース
DTU モデルには、次の 3 つのサービス レベルがあります。Basic、Standard、Premium。 コンピューティングおよびストレージ リソースは DTU レベルに依存し、固定ストレージ制限、バックアップ保持、コストで幅広いパフォーマンス機能を提供します。
たとえば、データベースが最大ストレージ制限に達した場合は、コンピューティング使用率が低い場合でも、DTU 容量を増やす必要があります。 また、Azure SQL Database でのスケーリング操作により、プロセスの最後に接続が短時間中断される可能性があります。 これは、主に次の 2 つのシナリオで発生する可能性があります。
- 内部フェールオーバーを必要とするスケーリング操作の開始。
- エラスティック プールへのデータベースの追加または削除。
注
接続エラーを処理するには、アプリケーションに適切な 再試行ロジック を実装します。
パフォーマンスとコスト効率を最適化するには、デプロイ モデルと購入モデルの間の相互作用を理解することが重要です。 適切な組み合わせを慎重に選択することにより、予算の範囲内で、Azure SQL Database のデプロイがアプリケーションの要件を確実に満たすようにすることができます。
たとえば、単一データベース デプロイ モデルを選択する場合、コンピューティングおよびストレージ リソースを個別にスケーリングできる柔軟性から、仮想コア購入モデルが適している場合があります。 一方、エラスティック プール デプロイ モデルを選択した場合は、DTU ベースの購入モデルの方が、プール内の複数のデータベース間でリソースを共有できるため、コスト効率が高くなる可能性があります。
バックアップと復元を実行する
Azure では、SQL Database のシームレスなバックアップと復元機能が用意されています。 主な機能をいくつか示します。
継続的バックアップ
Azure SQL Database では定期的なバックアップが確保され、継続的に読み取りアクセス geo 冗長ストレージ (RA-GRS) にコピーされます。 完全バックアップは毎週、差分バックアップは 12 から 24 時間ごと、トランザクション ログのバックアップは 5 から 10 分ごとに行われます。
geo リストア
geo 冗長バックアップを既定で使用すると、データベースを異なるリージョンに簡単に復元できます。これは、それほど厳密でないディザスター リカバリー シナリオに役立ちます。 バックアップ ストレージは別途課金されますが、選択したデータ レベルの最大サイズで追加コストなしで作成されます。 geo リストアの所要時間は、データベースのサイズ、トランザクション ログ、同時復元要求によって異なります。
注
geo リストアは、バックアップ ストレージ冗長プロパティが geo 冗長バックアップ ストレージに設定されている場合に使用できます。
ポイントインタイム リストア (PITR)
データベースごとに、1 から 35 日の範囲 (既定値は 7 日) で特定の時点のアイテム保持ポリシーを構成できます。 Azure portal、PowerShell、CLI、または REST API を使用して、同じサーバー内の特定の時点にデータベースを復元することもできます。
長期保有 (LTR)
長期保有は、Azure によって提供されるポリシーを超えて保持ポリシーを設定する必要があるシナリオで有用です。 保持ポリシーは最大 10 年間まで設定できます。このオプションは既定で無効になっています。
自動バックアップの詳細については、「 自動バックアップ - Azure SQL Database と Azure SQL Managed Instance」を参照してください。
自動チューニングの有効化
自動チューニングは、機械学習を適用してクエリのパフォーマンスを最適化する、強力な組み込み機能です。 チューニングの機会を自動的に特定し、それを実施してデータベースの効率を高めます。
現在、自動チューニングには次の機能が含まれています。
- コストの高いクエリの識別
- 最後の良好な実行プランの実施
- インデックスの追加
- インデックスの削除
Azure サービスでは、高度なアルゴリズムを使用して、クエリ パターンに最適なインデックスを決定します。 これらのインデックスは、ライブ環境に適用される前にデータベースのコピーで最初にテストされ、中断が最小限に抑えられます。
すべてのデータベースは親サーバーから構成を継承します。この機能は、必要に応じて簡単に無効にできます。 この柔軟性により、開発者は自動化されたパフォーマンス強化の恩恵を受けながら制御を維持できます。
エラスティック クエリを使用する
エラスティック クエリを使用すると、SQL Database 内の複数のデータベースにわたって T-SQL クエリを実行できます。 この機能は、変更できない 3 部構成および 4 部構成の名前を使用するアプリケーションに役立ち、移行を容易にすることで移植性を高めます。
エラスティック クエリでは、次のパーティション分割シナリオがサポートされます。
| サービス レベル | 機能 |
|---|---|
| 垂直パーティション分割 | データベース間クエリとも呼ばれます。 データは、異なるスキーマを持つ複数のデータベース間で列方向にパーティション分割されます。 たとえば、顧客データ用に 1 つのデータベースがあり、支払い情報用に別のものがあるとします。 列分割により、これらのデータベースにわたってデータベース間クエリを実行できます。 |
| 水平パーティション分割 | シャーディングとも呼ばれます。 データは行方向にパーティション分割され、すべて同じスキーマを共有する複数のスケールアウトされたデータベースに行を分散します。 このトポロジでは、シングルテナント モデルとマルチテナント モデルの両方がサポートされます。 |
この柔軟性により、エラスティック クエリは、複数のデータベースにわたるデータの管理とクエリを実行するための強力なツールになります。
エラスティック ジョブを構成する
エラスティック ジョブ機能は、オンプレミスの SQL Server インスタンスのマルチサーバー管理機能と同様に、Azure SQL Database の SQL Server エージェントの代替機能として機能します。
エラスティック ジョブを使用すると、SQL Database、SQL Database エラスティック プール、シャード マップ内の SQL Database など、さまざまなターゲット デプロイにわたって T-SQL コマンドを実行できます。 これらのデータベース リソースは、さまざまな Azure サブスクリプションおよびリージョンにまたがることができます。 並列実行機能は、データベースのメンテナンス タスクを自動化し、デプロイ全体での効率と整合性を確保するのに役立ちます。
SQL データ同期を使用してデータを移動する
SQL データ同期 を使用すると、SQL Database またはオンプレミスの SQL Server で実行されているかどうかにかかわらず、複数のデータベース間でデータを増分同期できます。 この機能は、分析や計画外の操作のために集中型の運用ワークロードを別のデータベースにオフロードする場合に役立ちます。
データ同期は、同期グループ内の 1 つのデータベースがハブとして指定されるハブ トポロジで動作します。 同期グループには複数のメンバー データベースを含めることができ、同期はハブと個々のメンバー データベースの間で行われます。 変更は、ユーザー データベース上に作成された履歴テーブルの insert、update、delete トリガーを使用して追跡されます。
同期グループを作成するときは、同期グループのメタデータを保存するデータベースを指定する必要があります。 このメタデータ データベースは、同期グループと同じリージョンに存在する限り、新規でも既存でも構いません。
SQL データ同期を構成する方法の詳細については、「 チュートリアル: Azure SQL Database と SQL Server のデータベース間で SQL データ同期を設定する」を参照してください。