Azure Well-Architected フレームワークのレビュー - Azure SQL Database
Azure SQL Database は、ユーザーの介入なしでほとんどのデータベース管理機能を処理するフル マネージドの PaaS (サービスとしてのプラットフォーム) データベース エンジンです。 管理関数には、アップグレード、パッチ、バックアップ、監視が含まれます。
単一データベースのリソースの種類では、Azure SQL Database 内にその独自のリソース セットでデータベースが作成され、論理サーバー経由で管理されます。 DTU ベースの購入モデルまたは仮想コアベースの購入モデルを選択できます。 エラスティック プールを使用して、1 つのリソース プールに複数のデータベースを作成できます。
次のセクションでは、Azure SQL Database のセキュリティに固有の設計チェックリストと推奨される設計オプションについて説明します。 このガイダンスは、アーキテクチャの卓越性の 5 つの柱に基づいています。
- 信頼性
- セキュリティ
- コストの最適化
- オペレーショナルエクセレンス
- パフォーマンス効率
前提条件
Well-Architected フレームワークの柱に関するガイダンスを理解すると、高品質で安定した効率的なクラウド アーキテクチャを作成するのに役立ちます。 Azure Well-Architected フレームワークの概要ページを参照し、アーキテクチャの卓越性の 5 つの柱を確認してください。
Azure SQL Database の中心的な概念に関するページと「Azure SQL Database の新機能」を参照してください。
Azure SQL Database と信頼性
Azure SQL Database は、ユーザーの介入なしでほとんどのデータベース管理機能を処理するフル マネージドの PaaS (サービスとしてのプラットフォーム) データベース エンジンです。 管理機能には以下が含まれます。
- アップグレード
- 修正プログラム
- バックアップ
- 監視
このサービスを使用すると、Azure アプリケーションとワークロードに対して可用性が高くハイ パフォーマンスのデータ ストレージ層を作成できます。 Azure SQL Database は常に、最新の安定したバージョンの SQL Server データベース エンジンおよびパッチが適用された OS 上で実行され、99.99%
の可用性を備えています。
Azure SQL Database を使用することで、信頼性を高め、中断時にビジネスを継続できるようにする方法の詳細については、「可用性に関する機能」を参照してください。
以降のセクションでは、Azure SQL Database と信頼性に特有の設計上の検討事項、構成チェックリスト、および推奨される構成オプションについて説明します。
設計上の考慮事項
Azure SQL Database では、次のような設計上の考慮事項があります。
geo レプリケーションで構成された Azure SQL Database Business Critical レベルでは、デプロイされた時間の
30
に対して100%
秒の回復時刻の目標 (RTO) が保証されます。"シャーディング" を使用して、同じ構造を持つ多数のデータベース間でデータとプロセスを分散します。 シャーディングは、コストと弾力性のための従来のスケールアップ アプローチの代替手段を提供します。 シャーディングを使用して、データベースを水平方向にパーティション分割することを検討してください。 シャーディングによって障害を分離できます。 詳細については、「Azure SQL Database によるスケール アウト」を参照してください。
ゾーン冗長デプロイ用に構成されていない Azure SQL Database Business Critical または Premium レベル、General Purpose、Standard、または Basic レベル、あるいは 2 つ以上のレプリカを持つ Hyperscale レベルは可用性が保証されています。 可用性の保証の詳細については、「Azure SQL Database の SLA」を参照してください。
すべての Azure リージョンに組み込みの高可用性とターンキーの geo レプリケーションが提供されます。 これには、次のような自動運転機能をサポートするインテリジェンスが含まれます。
- パフォーマンスのチューニング
- 脅威の監視
- 脆弱性の評価
- コード ベースの完全に自動化されたパッチおよび修正プログラムの適用
アプリケーションのパフォーマンスに関する SLA を定義し、アラートで監視します。 アプリケーションのパフォーマンスが不注意で許容レベル以下に低下した場合に素早く検知します。これは、高い回復性を維持するため重要です。 以前に定義した監視ソリューションを使用して、主要なクエリ パフォーマンス メトリックにアラートを設定し、パフォーマンスが SLA に違反したときに対策を講じることができるようにします。 詳細については、データベースの監視とアラート ツールに関するページを参照してください。
サービスの停止から復旧するには、geo リストアを使用します。 最新の geo レプリケートされたバックアップから、任意の Azure リージョンの任意の SQL Database サーバーにデータベースを復元するか、任意のマネージド インスタンスにインスタンス データベースを復元できます。 geo リストアでは、geo レプリケートされたバックアップをソースとして使用します。 データベースまたはデータセンターが停止したためにアクセスできない場合でも、geo リストアを要求できます。 geo リストアは geo 冗長バックアップからデータベースを復元します。 詳細については、データベースの自動バックアップを使用した Azure SQL データベースの復旧に関する記事を参照してください。
geo レプリケーションで構成された Business Critical レベルを使用します。このレベルでは、デプロイされた時間の
5
に対して100%
秒の回復ポイントの目標 (RPO) が保証されます。Azure SQL Database に組み込まれた PaaS 機能により、お客様のビジネスに不可欠なドメイン固有のデータベース管理および最適化のアクティビティに集中することができます。
人的ミスから復旧するには、ポイントインタイム リストアを使用します。 ポイントインタイム リストアを使用すると、データベースを以前の時点に戻し、誤って行われた変更からデータを回復することができます。 詳細については、ポイントインタイム リストア (PITR) に関するドキュメントを参照してください。
Business Critical または Premium レベルは、可用性を保証するゾーン冗長デプロイとして構成されます。 可用性の保証の詳細については、「Azure SQL Database の SLA」を参照してください。
チェック リスト
信頼性を考慮して Azure SQL Database を構成しましたか?
- アクティブ geo レプリケーションを使用して、異なるリージョンに読み取り可能なセカンダリを作成します。
- 通常は同じアプリケーションによって使用される、1 つ以上のデータベースを含めることができる自動フェールオーバー グループを使用します。
- ゾーン冗長データベースを使用します。
- Azure SQL Database を準リアルタイムで監視し、信頼性に影響するインシデントを検出します。
- 再試行ロジックを実装する。
- キーをバックアップします。
構成に関する推奨事項
次の推奨事項の表を参照して、信頼性を高めるためにお使いの Azure SQL Database 構成を最適化してください。
推奨 | 説明 |
---|---|
アクティブ geo レプリケーションを使用して、異なるリージョンに読み取り可能なセカンダリを作成します。 | プライマリ データベースが失敗した場合は、セカンダリ データベースへの手動フェールオーバーを実行します。 セカンダリ データベースは、フェールオーバーするまでは読み取り専用のままです。 データ センターの停止またはアプリケーションのアップグレードが発生した場合に、アクティブ geo レプリケーションを使って、読み取り可能レプリカを作成し、手動で任意のレプリカにフェールオーバーできます。 同じリージョン内または異なるリージョン内で最大 4 つのセカンダリがサポートされています。また、セカンダリを使用して読み取り専用アクセスのクエリを行うこともできます。 フェールオーバーはアプリケーションまたはユーザーによって手動で開始される必要があります。 フェールオーバー後、新しいプライマリには別の接続エンドポイントが設定されます。 |
通常は同じアプリケーションによって使用される、1 つ以上のデータベースを含めることができる自動フェールオーバー グループを使用します。 | 読み取り可能なセカンダリ データベースを使用して、読み取り専用クエリ ワークロードをオフロードできます。 自動フェールオーバー グループには複数のデータベースが含まれるため、これらのデータベースをプライマリ サーバーに構成する必要があります。 自動フェールオーバー グループでは、グループ内のすべてのデータベースを、別のリージョンの 1 つのセカンダリ サーバーまたはインスタンスのみにレプリケートすることがサポートされます。 自動フェールオーバー グループと DR 設計の詳細について確認してください。 |
ゾーン冗長データベースを使用します。 | 既定では、Premium 可用性モデル用のノードのクラスターは、同じデータ センター内に作成されます。 Azure Availability Zones の導入によって、SQL Database では同じリージョン内のさまざまな可用性ゾーンに対する Business Critical データベースのさまざまなレプリカを配置できます。 単一障害点をなくすため、制御リングも複数のゾーンで 3 つのゲートウェイ リング (GW) として複製できます。 特定のゲートウェイ リングへのルーティングは Azure Traffic Manager (ATM) によって制御されます。 Premium または Business Critical サービス レベルでのゾーン冗長構成では追加のデータベース冗長性が作成されないため、追加コストなしでこの構成を有効にできます。 ゾーン冗長データベースの詳細について確認してください。 |
Azure SQL Database を準リアルタイムで監視し、信頼性に影響するインシデントを検出します。 | 使用可能なソリューションのいずれかを使用して SQL DB を監視し、信頼性に影響する可能性のあるインシデントを早期に検出し、データベースの信頼性を高めます。 凖リアルタイムの監視ソリューションを選択して、インシデントに迅速に対応します。 詳細については、Azure SQL Analytics に関する記事を参照してください。 |
再試行ロジックを実装する。 | Azure SQL Database は、推移的なインフラストラクチャ障害に関しては回復性がありますが、これらの障害によって接続に影響が及ぼされる可能性があります。 SQL Database での作業中に一時的なエラーが発生した場合、コードで呼び出しを再試行できることを確認してください。 詳細については、再試行ロジックの実装方法に関する記事を参照してください。 |
キーをバックアップします。 | Azure Key Vault で暗号化キーを使用してデータを保護していない場合は、キーをバックアップします。 |
Azure SQL Database とセキュリティ
SQL Database は、アプリケーションがさまざまなセキュリティとコンプライアンスの要件を満たすために役立つ、幅広い組み込みのセキュリティとコンプライアンスの機能を備えています。
設計チェック リスト
セキュリティを念頭に置いてワークロードを設計し、Azure SQL Database を構成しましたか?
- 論理サーバーと、必要に応じて複数のデータベースのログインを管理する方法を理解します。
- Azure SQL を使用した Microsoft Entra 認証を有効にします。 Microsoft Entra 認証により、簡略化されたアクセス許可管理と一元的な ID 管理が可能になります。
- Azure SQL 論理サーバーには Microsoft Entra 管理者をプロビジョニングしておく必要があります。
- Azure サブスクリプションのサービス管理者と共同管理者の連絡先情報メール アドレスが社内の適切な関係者に到達することを確認します。 Azure からの重要なセキュリティ通知を見逃したり無視したりすることは望ましくありません。
- Azure SQL Database 接続アーキテクチャに関するページを参照してください。 必要に応じて、
Redirect
またはProxy
の接続ポリシーを選択します。 - Azure SQL Database のファイアウォール規則に関するページを参照してください。
- 仮想ネットワーク規則を使用して、仮想ネットワーク内の特定のサブネットからの通信を制御します。
- Azure Firewall を使用している場合は、SQL FQDN を使用して Azure Firewall アプリケーション規則を構成します。
推奨事項
推奨事項 | 特長 |
---|---|
TLS の最小バージョンに関するページを参照してください。 | 以前の TLS または暗号化されていない接続を必要とするレガシ アプリケーションがあるかどうかを確認します。 TLS のバージョンを適用した後で既定値に戻すことはできません。 Azure portal を介した SQL Database 接続の最小 TLS バージョンを確認して構成します。 ない場合は、最新の TLS バージョンを最小値に設定します。 |
元帳 | すべてのデータ変更の監査、改ざんの証拠、信頼性を確保するために、レジャーに基づいてデータベース テーブルを設計することを検討してください。 |
Always Encrypted | Always Encrypted を中心としたアプリケーション アクセスを設計し、データ アクセスを暗号化キーに委任することでアプリケーション内の機密データを保護することを検討してください。 |
プライベート エンドポイントとプライベート リンク | プライベート エンドポイント接続は、Azure SQL Database へのプライベート接続を有効にすることで、通信のセキュリティを強化します。 プライベート エンドポイントを使用して接続をセキュリティで保護し、既定でパブリック ネットワーク アクセスを拒否できます。 Azure Private Link for Azure SQL Database は、Azure SQL Database に推奨されるプライベート エンドポイントの一種です。 |
自動化された脆弱性評価 | 脆弱性評価スキャン結果と、データベースの脆弱性を修正する方法についての推奨事項を監視します。 |
Advanced Threat Protection | Advanced Threat Protection for Azure SQL Database を使用して、データベースへのアクセスや悪用を試みる、害を及ぼす可能性がある通常とは異なる異常なアクティビティを検出します。 Advanced Threat Protection では、アラートが Microsoft Defender for Cloud と統合されています。 |
監査 | Azure SQL Database の監査を使用してデータベース イベントを追跡します。 |
マネージド ID | ユーザー割り当てマネージド ID (UMI) の構成を検討します。 Azure リソース用マネージド ID を使用すると、コードで資格情報を管理する必要がなくなります。 |
Microsoft Entra 専用認証 | SQL ベースの認証を無効にして、Microsoft Entra 認証でのみ許可することを検討します。 |
ポリシーの定義
Azure SQL Database の Azure セキュリティ ベースラインと Azure Policy の組み込み定義に関するページを参照してください。
Azure SQL に関連するすべての組み込みのポリシー定義は、組み込みのポリシーに関するページに記載されています。
「チュートリアル: Azure SQL Database 内のデータベースをセキュリティで保護する」を参照してください。
Azure SQL Database とコストの最適化
Azure SQL Database は、ユーザーの介入なしでほとんどのデータベース管理機能を処理するフル マネージドの PaaS (サービスとしてのプラットフォーム) データベース エンジンです。 管理機能には以下が含まれます。
- アップグレード
- 修正プログラム
- バックアップ
- 監視
このサービスを使用すると、Azure アプリケーションとワークロードに対して可用性が高くハイ パフォーマンスのデータ ストレージ層を作成できます。 SQL Database には、自動パフォーマンス監視およびチューニングを通じてデータベースの実行と管理にかかるコストを大幅に削減するうえで役立つ組み込みのインテリジェンスが含まれています。
Azure SQL Database でコスト削減機能を提供する方法の詳細については、「Azure SQL Database のコストを計画および管理する」を参照してください。
以降のセクションでは、Azure SQL Database に固有の構成チェックリストと推奨構成オプション、およびコストの最適化について説明します。
チェック リスト
コストの最適化を念頭に、Azure SQL Database を構成していますか?
- クエリを最適化します。
- リソース使用状況を評価します。
- バックアップ ストレージの消費量を微調整します。
- Azure SQL Database サーバーレスを評価します。
- Azure SQL Database の予約容量を検討します。
- 複数のデータベースの管理とスケーリングのためのエラスティック プールを検討します。
構成に関する推奨事項
コスト削減に向けた Azure SQL Database 構成の最適化に関する推薦事項について、以下の表をご確認ください。
推奨 | 説明 |
---|---|
クエリを最適化します。 | リソースの消費量を減らし、適切な構成に到達できるように、Query Performance Insight とパフォーマンスに関する推奨事項を使用して、クエリ、テーブル、データベースを最適化します。 |
リソース使用状況を評価します。 | すべてのデータベースのリソース使用状況を評価し、サイズが正しくプロビジョニングされているかどうかを判断します。 非運用データベースの場合は、必要に応じてリソースをスケールダウンすることを検討します。 データベースの DTU または仮想コアは、ロード テストやユーザー受け入れテストの実行時などに、必要に応じてスケーリングできます。 |
バックアップ ストレージ消費量を微調整する | Azure SQL Database 仮想コア データベースの場合、各種バックアップ (完全、差分、ログ) によって使用されるストレージは、データベース監視ペイン上で別個のメトリックとして報告されます。 データベースの最大データ サイズまでのバックアップ ストレージの使用量については、課金されません。 超過のバックアップ ストレージ消費量は、個々のデータベースのワークロードと最大サイズに依存します。 詳細については、バックアップ ストレージ消費量に関する記事を参照してください。 |
Azure SQL Database サーバーレスを評価します。 | プロビジョニングされたコンピューティング レベルには Azure SQL Database サーバーレスの使用を検討します。 サーバーレスは、ワークロードの需要に基づいてコンピューティングが自動的にスケーリングされ、1 秒あたりに使用されるコンピューティングの量に対して課金される、単一データベースのコンピューティング層です。 また、サーバーレス コンピューティング層では、非アクティブな期間はデータベースが自動的に一時停止されます (この際はストレージに対してのみ課金が行われます)。 再びアクティブになると自動的にデータベースが再開されます Azure SQL Database サーバーレスは、すべてのシナリオに適しているわけではありません。 データベースの使用パターンが予測不能または急増し、使用量が少ないかアイドル状態の期間が散在する場合、サーバーレスは価格とパフォーマンスの最適化に役立つソリューションです。 |
Azure SQL Database の予約容量を検討します。 | 予約割引を使用することで、Azure SQL Database に関連するコンピューティング コストを削減できます。 リージョン内の Azure SQL データベースの合計コンピューティング容量とパフォーマンス レベルを決定したら、この情報を使用して容量を予約できます。 予約期間は 1 年または 3 年です。 詳細については、予約容量を使用したリソース コストの節約に関する記事を参照してください。 |
エラスティック プールを利用した Azure SQL Database 内の複数のデータベースの管理およびスケーリング | Azure SQL Database のエラスティック プールは、使用ニーズが多様で予測不可能な複数のデータベースを管理およびスケーリングするための、シンプルでコスト効率に優れたソリューションです。 エラスティック プール内のデータベースは、単一のサーバー上にあり、設定された数のリソースを設定価格で共有します。 詳細については、複数のデータベースを管理およびスケーリングするためのエラスティック プールに関するページを参照してください。 |
詳細については、「Azure SQL Database のコストを計画および管理する」を参照してください。
Azure SQL Database とオペレーショナル エクセレンス
Azure SQL Database は、ユーザーの介入なしでほとんどのデータベース管理機能を処理するフル マネージドの PaaS (サービスとしてのプラットフォーム) データベース エンジンです。 管理機能には以下が含まれます。
- アップグレード
- 修正プログラム
- バックアップ
- 監視
このサービスを使用すると、Azure アプリケーションとワークロードに対して可用性が高くハイ パフォーマンスのデータ ストレージ層を作成できます。 Azure SQL Database では、データベースやソリューションのパフォーマンスのトラブルシューティングと最大化に役立つ、人工知能によって支えられる高度な監視およびチューニング機能が提供されます。
Azure SQL Database によるオペレーショナル エクセレンスの促進と、中断している間も企業が業務を継続可能にする方法の詳細については、Azure SQL Database での監視とパフォーマンスの調整に関する記事を参照してください。
以降のセクションでは、Azure SQL Database とオペレーショナル エクセレンスに特有の設計上の考慮事項、構成チェックリスト、および推奨される構成オプションについて説明します。
設計上の考慮事項
Azure SQL Database では、次のような設計上の考慮事項があります。
geo レプリケーションで構成された Azure SQL Database Business Critical レベルでは、デプロイされた時間の
30
に対して100%
秒の回復時刻の目標 (RTO) が保証されます。"シャーディング" を使用して、同じ構造を持つ多数のデータベース間でデータとプロセスを分散します。 シャーディングは、コストと弾力性のための従来のスケールアップ アプローチの代替手段を提供します。 シャーディングを使用して、データベースを水平方向にパーティション分割することを検討してください。 シャーディングによって障害を分離できます。 詳細については、「Azure SQL Database によるスケール アウト」を参照してください。
ゾーン冗長デプロイ用に構成されていない Azure SQL Database Business Critical または Premium レベル、General Purpose、Standard、または Basic レベル、あるいは 2 つ以上のレプリカを持つ Hyperscale レベルは可用性が保証されています。 詳細については、「Azure SQL Database の SLA」を参照してください。
すべての Azure リージョンに組み込みの高可用性とターンキーの geo レプリケーションが提供されます。 これには、次のような自動運転機能をサポートするインテリジェンスが含まれます。
- パフォーマンスのチューニング
- 脅威の監視
- 脆弱性の評価
- コード ベースの完全に自動化されたパッチおよび修正プログラムの適用
アプリケーションのパフォーマンスに関する SLA を定義し、アラートで監視します。 アプリケーションのパフォーマンスが不注意で許容レベル以下に低下した場合に素早く検知します。これは、高い回復性を維持するため重要です。 以前に定義した監視ソリューションを使用して、主要なクエリ パフォーマンス メトリックにアラートを設定し、パフォーマンスが SLA に違反したときに対策を講じることができるようにします。 詳細については、データベースの監視に関する記事を参照してください。
サービスの停止から復旧するには、geo リストアを使用します。 最新の geo レプリケートされたバックアップから、任意の Azure リージョンの任意の SQL Database サーバーにデータベースを復元するか、任意のマネージド インスタンスにインスタンス データベースを復元できます。 geo リストアでは、geo レプリケートされたバックアップをソースとして使用します。 データベースまたはデータセンターが停止したためにアクセスできない場合でも、geo リストアを要求できます。 geo リストアは geo 冗長バックアップからデータベースを復元します。 詳細については、データベースの自動バックアップを使用した Azure SQL データベースの復旧に関する記事を参照してください。
geo レプリケーションで構成された Business Critical レベルを使用します。このレベルでは、デプロイされた時間の
5
に対して100%
秒の回復ポイントの目標 (RPO) が保証されます。Azure SQL Database に組み込まれた PaaS 機能により、お客様のビジネスに不可欠なドメイン固有のデータベース管理および最適化のアクティビティに集中することができます。
人的ミスから復旧するには、ポイントインタイム リストアを使用します。 ポイントインタイム リストアを使用すると、データベースを以前の時点に戻し、誤って行われた変更からデータを回復することができます。 詳細については、ポイントインタイム リストア (PITR) に関するドキュメントを参照してください。
Business Critical または Premium レベルは、ゾーン冗長デプロイとして構成されます。 可用性の保証の詳細については、「Azure SQL Database の SLA」を参照してください。
チェック リスト
オペレーショナル エクセレンスを念頭に Azure SQL Database を構成しましたか?
- アクティブ geo レプリケーションを使用して、異なるリージョンに読み取り可能なセカンダリを作成します。
- 通常は同じアプリケーションによって使用される、1 つ以上のデータベースを含めることができる自動フェールオーバー グループを使用します。
- ゾーン冗長データベースを使用します。
- Azure SQL Database を準リアルタイムで監視し、信頼性に影響するインシデントを検出します。
- 再試行ロジックを実装します。
- キーをバックアップします。
構成に関する推奨事項
次の表に記載されている推奨事項を参照して、オペレーショナル エクセレンスを実現するためにAzure SQL Database 構成を最適化します。
推奨 | 説明 |
---|---|
アクティブ geo レプリケーションを使用して、異なるリージョンに読み取り可能なセカンダリを作成します。 | プライマリ データベースが失敗した場合は、セカンダリ データベースへの手動フェールオーバーを実行します。 セカンダリ データベースは、フェールオーバーするまでは読み取り専用のままです。 データ センターの停止またはアプリケーションのアップグレードが発生した場合に、アクティブ geo レプリケーションを使って、読み取り可能レプリカを作成し、手動で任意のレプリカにフェールオーバーできます。 同じリージョン内または異なるリージョン内で最大 4 つのセカンダリがサポートされています。また、セカンダリを使用して読み取り専用アクセスのクエリを行うこともできます。 フェールオーバーはアプリケーションまたはユーザーによって手動で開始される必要があります。 フェールオーバー後、新しいプライマリには別の接続エンドポイントが設定されます。 |
通常は同じアプリケーションによって使用される、1 つ以上のデータベースを含めることができる自動フェールオーバー グループを使用します。 | 読み取り可能なセカンダリ データベースを使用して、読み取り専用クエリ ワークロードをオフロードできます。 自動フェールオーバー グループには複数のデータベースが含まれるため、これらのデータベースをプライマリ サーバーに構成する必要があります。 自動フェールオーバー グループでは、グループ内のすべてのデータベースを、別のリージョンの 1 つのセカンダリ サーバーまたはインスタンスのみにレプリケートすることがサポートされます。 自動フェールオーバーグループと DR 設計の詳細について確認してください。 |
ゾーン冗長データベースを使用します。 | 既定では、Premium 可用性モデル用のノードのクラスターは、同じデータ センター内に作成されます。 Azure Availability Zones の導入によって、SQL Database では同じリージョン内のさまざまな可用性ゾーンに対する Business Critical データベースのさまざまなレプリカを配置できます。 単一障害点をなくすため、制御リングも複数のゾーンで 3 つのゲートウェイ リング (GW) として複製できます。 特定のゲートウェイ リングへのルーティングは Azure Traffic Manager (ATM) によって制御されます。 Premium または Business Critical サービス レベルでのゾーン冗長構成では追加のデータベース冗長性が作成されないため、追加コストなしでこの構成を有効にできます。 ゾーン冗長データベースの詳細について確認してください。 |
Azure SQL Database を準リアルタイムで監視し、信頼性に影響するインシデントを検出します。 | 使用可能なソリューションのいずれかを使用して SQL DB を監視し、信頼性に影響する可能性のあるインシデントを早期に検出し、データベースの信頼性を高めます。 凖リアルタイムの監視ソリューションを選択して、インシデントに迅速に対応します。 詳細については、Azure SQL Analytics に関する記事を参照してください。 |
再試行ロジックを実装する。 | Azure SQL Database は、推移的なインフラストラクチャ障害に関しては回復性がありますが、これらの障害によって接続に影響が及ぼされる可能性があります。 SQL Database での作業中に一時的なエラーが発生した場合、コードで呼び出しを再試行できることを確認してください。 詳細については、再試行ロジックの実装方法に関するページと「SqlClient の構成可能な再試行ロジックの概要」を参照してください。 |
キーをバックアップします。 | Azure Key Vault で暗号化キーを使用してデータを保護していない場合は、キーをバックアップします。 |
Azure SQL Database とパフォーマンス効率
Azure SQL Database は、ユーザーの介入なしでほとんどのデータベース管理機能を処理するフル マネージドの PaaS (サービスとしてのプラットフォーム) データベース エンジンです。 管理機能には以下が含まれます。
- アップグレード
- 修正プログラム
- バックアップ
- 監視
次のセクションでは、Azure SQL Database のパフォーマンス効率に固有の設計チェックリストと推奨される設計オプションについて説明します。
設計チェック リスト
パフォーマンス効率を考慮してワークロードを設計し、Azure SQL Database を構成しましたか?
- リソース制限を確認します。 単一データベースの価格レベルごとの特定のリソース制限 (サービス目標とも呼ばれます) については、DTU ベースの単一データベース リソース制限または仮想コアベースの単一データベース リソース制限に関する記事を参照してください。 エラスティック プールのリソース制限については、DTU ベースのエラスティック プールのリソース制限または仮想コアベースのエラスティック プールのリソース制限に関する記事を参照してください。
- 実際のワークロード、仮想コア、または DTU に適したデプロイ モデルを選択します。 仮想コアと DTU ベースの購入モデルを比較します。
- Microsoft では、最新の仮想コア データベースの Standard シリーズまたは Premium シリーズのハードウェアを推奨しています。 以前の Gen4 ハードウェアは廃止されました。
- エラスティック プールを使用する場合は、リソース ガバナンスについてよく理解してください。
- 既定の並列処理の最大限度 (MAXDOP) に関するページを参照し、移行済みまたは予想されるワークロードに基づいて必要に応じて構成します。
- 重要なデータベースの読み取り専用レプリカを使用して、読み取り専用クエリ ワークロードをオフロードすることを検討します。
- 「SQL Server データベース エンジンと Azure SQL Database のパフォーマンス センター」を参照してください。
- Azure SQL Database に接続するアプリケーションは、最新の OLE DB ドライバーや ODBC ドライバーなどの最新の接続プロバイダーを使用する必要があります。
推奨事項
推奨事項 | 特長 |
---|---|
高い CPU 使用率を診断してトラブルシューティングします。 | Azure SQL Database には、高 CPU 使用率の原因を特定し、ワークロードのパフォーマンスを最適化するための組み込みツールが用意されています。 |
ブロックとデッドロックの問題を理解します。 | コンカレンシーによるブロックと、デッドロックによるセッションの終了は、原因と結果が異なります。 |
パフォーマンスのためにアプリケーションとデータベースを調整します。 | アプリケーションとデータベースを調整してパフォーマンスを向上させます。 ベスト プラクティスを確認します。 |
Azure portal の使用状況レポートを確認し、必要に応じてスケーリングします。 | デプロイ後は、Azure portal の組み込みのレポートを使用して、データベース使用率のピークと平均を定期的に確認し、適切なサイズに増減します。 データを損失せず、ダウンタイムを最小限に抑えながら単一データベースまたはエラスティック プールを簡単にスケーリングできます。 |
パフォーマンス レコメンデーションを確認してください。 | Azure portal のデータベース ページの [インテリジェント パフォーマンス] メニューで、パフォーマンスに関する推奨事項のいずれかに関するアクションを確認および検討し、インデックス、スキーマ、パラメーター化の問題を実装します。 |
Query Performance Insight を確認します。 | Query Performance Insight for Azure SQL Database レポートを確認して、最も多くのリソースを消費するクエリや実行時間の長いクエリなどを特定します。 |
自動チューニングを構成します。 | AI と機械学習に基づく継続的なパフォーマンス チューニングによって、最大限のパフォーマンスと安定したワークロードを実現します。 Azure Automation を使用して、自動チューニング用のメール通知を構成することを検討してください。 |
インメモリ データベース オブジェクトの潜在的な使用を評価します。 | インメモリ テクノロジにより、アプリケーションのパフォーマンスを向上させることができ、また、データベースのコストを削減できる可能性があります。 大容量の OLTP アプリケーションで一部のデータベース オブジェクトを設計することを検討します。 |
クエリ ストアを利用します。 | Azure SQL Database で既定で有効なクエリ ストアには、豊富なクエリ パフォーマンスとリソース消費のデータに加え、クエリ ストアのヒントや計画の自動修正などの高度なチューニング機能があります。 Azure SQL Database のクエリ ストアの既定値に関するページを参照してください。 |
一時的なエラーに対する再試行ロジックを実装します。 | 一般的な接続エラーを含め、一時的なエラーに対する自動トランザクション再試行ロジックをアプリケーションに含める必要があります。 指数関数的な再試行間隔ロジックを利用します。 |
その他のリソース
サポートされている機能の詳細については、機能と SQL Database への移行時の Transact-SQL の相違点の解決に関するページを参照してください。
Azure SQL Database に移行しますか? Azure データベース移行ガイドを参照してください。
Azure SQL のトピックなどを取り上げた Data Exused のエピソードをご覧ください。