クラウドの新しい DBA – 移行後の Azure SQL Database の管理

[アーティクル]
08/23/2024

従来の自己管理型で自己制御型の環境から PaaS 環境への移行は、最初は少し面倒に思えるかもしれません。アプリの開発者や DBA であれば、常に、アプリケーションの高い可用性、パフォーマンス、セキュリティ、回復力を維持するのに役立つプラットフォームのコア機能を知りたいと思うでしょう。この記事の目的はまさにそれです。この記事では、リソースを簡潔に整理すると共に、アプリケーションの効率的な実行を管理および維持し、クラウドで最善の結果を得るために、単一データベースとプールされたデータベースで Azure SQL Database の主要な機能を最大限に活用する方法のガイダンスを示します。この記事は、主に以下のような読者を対象に書かれています。

Azure SQL Database へのアプリケーションの移行を評価している – アプリケーションの現代化。
アプリケーションの移行を行っている – 進行中の移行シナリオ。
Azure SQL Database への移行を最近完了した – クラウドの新しい DBA。

この記事では、単一データベースおよび Elastic Pool 内のプールされたデータベースで作業するときにすぐに使用できる、プラットフォームとしての Azure SQL データベースの主要な特性の一部について説明します。これらは次のとおりです。

Azure ポータルを使用したデータベースの監視
ビジネス継続性とディザスターリカバリー (BCDR)
セキュリティとコンプライアンス
インテリジェントなデータベースの監視とメンテナンス
データの移動

Note

Microsoft Entra ID の、旧称は Azure Active Directory（Azure AD）です。

Azure ポータルを使用したデータベースの監視

推奨されるアラートルールを含む、Azure Monitor のメトリックとアラートについては、「メトリックとアラートを使用して Azure SQL データベースを監視する」をご覧ください。サービスレベルの詳細については、DTU ベースの購入モデルと仮想コアベースの購入モデルに関する記事を参照してください。

パフォーマンスメトリックに対してアラートを構成できます。 [メトリック] ウィンドウの [アラートの追加] ボタンを選択します。ウィザードの指示に従ってアラートを構成します。メトリックが特定のしきい値を超えた場合、またはメトリックが特定のしきい値を下回った場合に警告するオプションがあります。

たとえば、データベースのワークロードが増加する見込みの場合、データベースのいずれかのパフォーマンスメトリックが 80% に達すると電子メールのアラートを送信するように構成できます。これは、次に大きいコンピューティングサイズにいつ切り替える必要があるかを見つけるための早期警告として使用できます。

下位のコンピューティングサイズにダウングレードできるかどうかを判断するために、パフォーマンスメトリックを利用することもできます。ただし、下位のコンピューティングサイズへの移行を決定する前に、急上昇や変動するワークロードに注意してください。

ビジネス継続性とディザスターリカバリー (BCDR)

ビジネス継続性とディザスターリカバリーの機能を使うと、障害が発生した場合でも、通常どおりビジネスを継続できます。この場合の障害は、データベースレベルのイベント (たとえば、ユーザーが誤って重要なテーブルを削除した) や、データセンターレベルのイベント (津波などの地域災害) です。

SQL Database でバックアップを作成し管理するにはどうすればよいですか

Azure SQL Database ではバックアップが必要ないため、作成しません。データベースのバックアップは SQL Database が自動的に行うため、バックアップのスケジュール、取得、管理について心配する必要はもうありません。プラットフォームは、完全バックアップを 1 週間ごと、差分バックアップを数時間ごと、ログバックアップを 5 分ごとに取得して、効率的なディザスターリカバリーと最小限のデータ損失を保証します。データベースを作成するとすぐに、最初の完全バックアップが行われます。これらのバックアップは "保持期間" と呼ばれる一定の期間だけ利用でき、この期間は選ばれているサービスレベルによって異なります。 SQL Database では、特定の時点への復旧 (PITR) を使って、この保有期間内の任意の時点に復元することができます。

さらに、長期保存 (LTR) 機能を使うと、はるかに長期 (最大 10 年) にわたりバックアップファイルを保持することができ、その期間内の任意の時点でこれらのバックアップからデータを復元できます。また、データベースバックアップは geo レプリケートされたストレージに保持されるので、リージョンレベルの災害からの回復力が保証されます。 Azure リージョン内のバックアップを保有期間の任意の時点に復元することもできます。詳細については、「事業継続の概要」をご覧ください。

データセンターレベルの障害または局所的大災害が発生した場合、ビジネス継続性を確保するにはどうすればよいですか

データベースバックアップは geo レプリケートされた記憶域に格納されるので、リージョンレベルの災害が発生した間でも、別の Azure リージョンにバックアップを復元することができます。これは geo リストアと呼ばれます。一般に、geo リストアの RPO (回復ポイントの目標) は < 1 時間以内、ERT (推定復旧時間) は数分から数時間です。

ミッションクリティカルなデータベースに対して、Azure SQL データベースはアクティブなアクティブ geo レプリケーションを提供し、地理的に複製された元のデータベースのセカンダリコピーを別の地域に作成します。たとえば、データベースが当初 Azure 米国西部リージョンでホストされていて、地域的な災害回復力を求める場合、米国西部から米国東部にデータベースのアクティブなジオ・レプリカを作成します。米国西部で災害が発生した場合は、米国東部リージョンにフェールオーバーできます。

アクティブなジオ・レプリケーションに加えて、フェイルオーバー・グループは、データベース・グループのレプリケーションとフェイルオーバーを管理する便利な方法を提供します。同じリージョンまたは異なるリージョンに複数のデータベースを含むフェールオーバーグループを作成できます。その後、フェールオーバーグループ内のすべてのデータベースのセカンダリリージョンへのフェールオーバーを開始できます。詳細については、フェールオーバーグループに関する記事を参照してください。

データセンターまたは可用性ゾーンの障害に対する回復性を実現するには、データベースまたはエラスティックプールに対してゾーンの冗長性が有効になっていることを確認します。

アプリケーションの障害を積極的に監視し、セカンダリへのフェールオーバーを開始します。このようなアクティブ geo レプリカは、異なる Azure リージョンに最大 4 個まで作成できます。回復力がさらに向上します。これらのセカンダリアクティブ geo レプリカには読み取り専用でアクセスすることもできます。これは、geo 分散アプリケーションシナリオの待機時間の削減に非常に便利です。

SQL Database でのディザスターリカバリーの外観

アクティブ geo レプリケーションまたはフェールオーバーグループを使用する場合、Azure SQL データベースでの数回のステップだけで、ディザスターリカバリーの構成と管理を行うことができます。引き続き、アプリケーションとそのデータベースで地域の障害を監視し、セカンダリリージョンにフェールオーバーしてビジネス継続性を復元する必要があります。

詳細については、Azure SQL データベースディザスターリカバリー 101

セキュリティとコンプライアンス

SQL Database ではセキュリティとプライバシーが非常に重視されています。 SQL Database 内のセキュリティはデータベースレベルとプラットフォームレベルで利用でき、最も理解しやすいのは複数のレイヤーに分類されているときです。各レイヤーで、アプリケーションを制御して最善のセキュリティを提供します。以下のレイヤーがあります。

ID と認証 (SQL 認証および、Microsoft Entra ID (旧称 Azure Active Directory) による認証)。
アクティビティの監視 (監査および脅威の検出)。
実際のデータの保護 (Transparent Data Encryption (TDE) および Always Encrypted (AE))。
機密データおよび特権データの制御 (行レベルセキュリティおよび動的データマスク)。

Microsoft Defender for Cloud は、Azure、オンプレミス、他のクラウドで実行されているワークロード全体でのセキュリティ管理を一元化します。監査や Transparent Data Encryption (TDE) などの SQL Database の主要な保護機能がすべてのリソースに対して構成されているかどうかを確認し、独自の要件に応じてポリシーを作成できます。

SQL Database ではどのようなユーザー認証方法が提供されますか

SQL Database では 2 種類の認証方法が提供されています。

Windows 認証はサポートされません。 Microsoft Entra ID は、一元化された ID およびアクセス管理サービスです。これを利用すると、組織の人間にシングルサインオン (SSO) アクセスを非常に便利な方法で提供できます。つまり、認証が簡単なように、資格情報は Azure サービスで共有されます。

Microsoft Entra ID は多要素認証をサポートしており、Windows Server Active Directory と簡単に統合できます。これを使用すると、SQL Database および Azure Synapse Analytics で、Microsoft Entra ドメイン内において Multi-Factor Authentication とゲストユーザーアカウントを提供できます。既に Active Directory をオンプレミスで使用している場合、Microsoft Entra ID とフェデレーションして Azure へ拡張できます。

SQL 認証では、特定のサーバー上の任意のデータベースに対してユーザーを認証するためのユーザー名とパスワードのみがサポートされます。

ユーザーの条件	SQL Database / Azure Synapse Analytics
オンプレミスの SQL Server で AD を使用している	AD を Microsoft Entra ID とフェデレーションし、Microsoft Entra 認証を使用します。フェデレーションを使用すると、シングルサインオンを使用できます。
多要素認証を適用する必要性	Microsoft 条件付きアクセスで多要素認証をポリシーとして必須にして、Microsoft Entra 多要素認証を使用します。
フェデレーションドメインから Microsoft Entra の資格情報を使用して Windows にログオンしている	Microsoft Entra 統合認証を使用します。
Azure にフェデレーションされていないドメインから資格情報を使用して Windows にログオンしている	Microsoft Entra 統合認証を使用します。
SQL Database または Azure Synapse Analytics への接続が必要な中間層サービスを使用している	Microsoft Entra 統合認証を使用します。
SQL 認証を使用するための技術的な要件があります	SQL 認証を使用します。

データベースへの接続アクセスを制限または制御する方法

複数の方法から適切なものを選んで、アプリケーションの最適な接続編成を実現できます。

ファイアウォールルール
VNet サービスエンドポイント
予約済み IP

ファイアウォール

ファイアウォールは、サーバーへのアクセスを特定のエンティティだけに許可することで、外部エンティティからサーバーへのアクセスを防ぎます。既定では、他の Azure サービスからの (オプションで 7 つの) 接続を除き、サーバー内のデータベースへの接続はすべて拒否されます。ファイアウォールルールを使用すると、ファイアウォールを通過できるコンピューターの IP アドレスを設定することで、特定のエンティティ (たとえば、開発者マシン) にのみサーバーへのアクセスを開くことができます。また、サーバーへのアクセスを許可する IP の範囲を指定することもできます。たとえば、ファイアウォール設定ページで範囲を指定することにより、組織内の開発者コンピューターの IP アドレスを一度に追加できます。

サーバーレベルまたはデータベースレベルで、ファイアウォールルールを作成できます。サーバーレベルの IP ファイアウォール規則は、Azure portal または SSMS で作成できます。サーバーレベルとデータベースレベルでファイアウォールルールを設定する方法について詳しくは、SQL Database での IP ファイアウォール規則の作成に関するページをご覧ください。

サービスエンドポイント

既定では、対象のデータベースは、"Azure サービスとリソースのサーバーへのアクセスを許可する" ように構成されます。つまり、Azure 内の任意の仮想マシンが対象のデータベースへの接続を試行する可能性があるということです。これらの試みも認証を受ける必要があります。ただし、Azure IP がデータベースにアクセスできるようにしたくない場合は、"サーバーへの Azure サービスとリソースのアクセス許可" を無効にすることができます。さらに、VNet サービスエンドポイントを構成できます。

サービスエンドポイント (SE) を使うと、Azure 内の自分のプライベート仮想ネットワークのみに、重要な Azure リソースを公開できます。これにより、基本的に、リソースへのパブリックアクセスが除去されます。仮想ネットワークと Azure の間のトラフィックは、Azure のバックボーンネットワーク上に留まります。 SE を使わない場合は、強制トンネリングパケットルーティングを使います。仮想ネットワークはインターネットトラフィックを強制的に組織に送り、Azure サービストラフィックは同じルートを経由します。サービスエンドポイントを使うと、パケットは仮想ネットワークから Azure バックボーンネットワーク上のサービスに直接流れるので、これを最適化できます。

予約済み IP

他の選択肢としては、VM に予約済み IP をプロビジョニングし、サーバーのファイアウォール設定でこれらの VM IP アドレスを追加します。予約済み IP アドレスを割り当てると、IP アドレスを変更した場合にファイアウォールの規則を更新する手間が省けます。

SQL Database への接続はどのポートで行われますか

ポート 1433 です。 SQL Database の通信はこのポートで行われます。企業ネットワーク内から接続するには、組織のファイアウォール設定に送信ルールを追加する必要があります。ガイドラインとして、Azure 境界の外部にはポート 1433 を公開しないでください。

サーバーおよび SQL Database のデータベースでのアクティビティを監視および規制するにはどうすればよいですか

SQL Database 監査

SQL Database では、監査を有効にしてデータベースイベントを追跡することができます。 SQL Database Auditing は、データベースイベントを記録して、Azure Storage アカウントの監査ログファイルに書き込みます。セキュリティとポリシーの違反の可能性について洞察を得たり、法令順守を維持したりするには、監査が特に有効です。監査が必要であると考えられる特定のイベントカテゴリを定義および構成し、それを基にして、あらかじめ構成されたレポートやダッシュボードを使ってデータベースで発生したイベントの概要を把握できます。これらの監査ポリシーは、データベースレベルまたはサーバーレベルで適用できます。サーバー/データベースの監査を有効にする方法については、SQL Database の監査を有効にする方法に関するトピックをご覧ください。

脅威の検出

脅威検出を使うと、監査によって発見されたセキュリティやポリシーの違反に、とても簡単に対処できます。セキュリティの専門家でなくても、システム内の潜在的な脅威や違反に対応できます。脅威検出には、SQL インジェクションの検出など、組み込み機能もいくつかあります。 SQL インジェクションとは、データを変更または侵害する試みであり、データベースアプリケーションを攻撃する非常に一般的な手段です。脅威検出機能では、潜在的な脆弱性と SQL インジェクション攻撃、および異常なデータベースアクセスパターン (通常とは異なる場所または未知のプリンシパルからのアクセスなど) を検出するアルゴリズムを複数セット実行します。データベースで脅威が検出された場合、セキュリティ責任者またはその他の指定された管理者に電子メール通知が送られます。各通知には、不審なアクティビティの詳細情報と、脅威に対して推奨されるさらなる調査方法や軽減策が記載されています。脅威検出を有効にする方法については、脅威検出の有効化に関するページを参照してください。

一般に SQL Database 上のデータを保護するにはどうすればよいですか

暗号化は、機微なデータをセキュリティで保護して侵入者から守るための強力なメカニズムを提供します。復号化キーがなくては、侵入者は暗号化されたデータを使用できません。したがって、暗号化は SQL Database に組み込まれている既存のセキュリティレイヤーの上に別の保護レイヤーを追加します。 SQL Database のデータの保護には 2 つの側面があります。

データファイルとログファイルに保存されているデータ
使用中のデータ

SQL Database では、既定により、記憶域サブシステムのデータファイルとログファイルに保存されているデータは、Transparent Data Encryption (TDE) によって常に完全に暗号化されます。バックアップも暗号化されます。 TDE を使う場合、このデータにアクセスするアプリケーション側を変更する必要はありません。名前のとおり、暗号化と復号化は透過的に行われます。使用中と保存中の機微なデータを保護するため、SQL Database には Always Encrypted (AE) という名前の機能が用意されています。 AE はクライアント側暗号化の 1 種であり、データベースの機密列を暗号化します (このため、これらの列は、データベース管理者および未承認ユーザーに対しては暗号化テキストになります)。サーバーは、最初に暗号化されたデータを受け取ります。 Always Encrypted のキーもクライアント側に格納されるため、機密列の暗号化を解除できるのは承認済みクライアントのみに限られます。暗号化キーはクライアントに格納されるため、サーバー管理者およびデータ管理者は機微なデータを確認することはできません。 AE は、未承認のクライアントから物理ディスクまで、テーブル内の機密列をエンドツーエンドで暗号化します。 AE では現在等値比較がサポートされているため、DBA では引き続き、SQL コマンドの一環として暗号化された列に対してクエリを行うことができます。 Always Encrypted は、Azure Key Vault、Windows 証明書ストア、ローカルハードウェアのセキュリティモジュールなどの多様なキーストアオプションと組み合わせて使用できます。

特性	常に暗号化	Transparent Data Encryption
暗号化の範囲	End-to-end	保存データ
サーバーは機微なデータにアクセスできる	いいえ	はい (暗号化は保存データに対するものであるため)
許可される T-SQL の操作	等価比較	T-SQL のすべての公開されている部分を使用できます
機能を使うために必要なアプリの変更	最小限	極めて最小限
暗号化の細分性	列レベル	データベースレベル

データベース内の機密データへのアクセスを制限するにはどうすればよいですか

どのようなアプリケーションでも、データベースには機微なデータがある程度の量存在し、無制限にアクセスされないように防ぐ必要があります。組織内の特定の担当者はこのデータを見る必要がありますが、他の人達はこのデータを見ることができないようにする必要があります。従業員の給与などはその一例です。管理者は自分の直属の部下の給与情報にアクセスする必要がありますが、個々のチームメンバーは同僚の給与情報にアクセスする必要はありません。もう 1 つのシナリオは、開発段階またはテストの間に機微なデータ (顧客の SSN など) を使用するデータ開発者です。この情報も、開発者に公開する必要はありません。このような場合、機微なデータはマスクするか、まったく公開しないようにする必要があります。 SQL Database には、機微なデータを未承認ユーザーが表示できないようにする 2 つのアプローチがあります。

動的データマスクはデータマスク機能であり、アプリケーションレイヤー上の権限のないユーザーに対して機微なデータをマスクすることでこれらのデータの公開を制限できます。マスクパターンを作成できるマスクルールを定義し (たとえば、XXX-XX-0000 のように、国民 ID である SSN の最後の 4 桁のみを表示しそれ以外の多くを X で隠す)、マスクルールから除外されるユーザーを識別します。マスクの適用は処理中に行われ、さまざまなデータカテゴリにさまざまなマスク関数を使用できます。動的データマスクを使うと、データベースの機微なデータを自動的に検出して、マスクを適用できます。

行レベルセキュリティを使うと、行レベルでアクセスを制御することができます。つまり、クエリを実行するユーザー (グループメンバーシップまたは実行コンテキスト) に基づいて、データベーステーブル内の特定の行が隠ぺいされます。このアクセス制限は、アプリのロジックを簡素化するため、アプリケーション層ではなくデータベース層で行われます。最初に公開されない行を排除するフィルター述語を作成し、次にこれらの行にアクセスできるユーザーを定義するセキュリティポリシーを作成します。最後に、エンドユーザーがクエリを実行すると、ユーザーの特権に応じて、制限された行が表示されるか、またはまったく表示されません。

暗号化キーはクラウドでどのように管理すればよいですか

Always Encrypted (クライアント側暗号化) および Transparent Data Encryption (保存時暗号化) ではともに、キー管理オプションが用意されています。暗号化キーを定期的にローテーションすることをお勧めします。ローテーションの頻度は、組織内部の規制とコンプライアンス要件の両方に合わせる必要があります。

Transparent Data Encryption (TDE)

TDE は 2 キー階層になっており、各ユーザーデータベースのデータは対称的でデータベース固有の AES-256 データベース暗号化キー (DEK) で暗号化され、さらにサーバー固有の非対称の RSA 2048 マスターキーで暗号化されます。マスターキーは次のどちらかで管理できます。

SQL Database プラットフォームで自動的。
キーストアとして Azure Key Vault を使用。

既定では、Transparent Data Encryption のマスターキーは利便性のために SQL Database サービスにより管理されます。組織でマスターキーを管理する必要がある場合、Azure Key Vault をキーストアとして使用できます。 Azure Key Vault を使用する場合、組織でキーのプロビジョニング、ローテーション、および権限管理を制御することになります。 TDE マスターキーは DEK を再暗号化しただけのものであるため、このキーのローテーションおよび種類の切り替えは短時間で行うことができます。セキュリティとデータ管理で役割が分けられている組織の場合、セキュリティ管理者が TDE マスターキーの主要な素材を Azure Key Vault にプロビジョニングし、サーバーでの保存時暗号化用に使用する Azure Key Vault キー ID をデータベース管理者に提供できます。 Key Vault は、マイクロソフトが暗号化キーを確認または抽出しないように作られています。また、組織のキーを一元的に管理できます。

Always Encrypted

Always Encrypted は 2 キー階層になっており、機密データの列は AES 256 列暗号化キー (CEK) で暗号化され、さらに列マスターキー (CMK) で暗号化されます。 Always Encrypted で提供されるクライアントドライバーには、CMK の長さに関する制限はありません。 CEK の暗号化値はデータベースに格納され、CMK は Windows 証明書ストア、Azure Key Vault、ハードウェアセキュリティモジュールなどの信頼できるキーストアに格納されます。

CEK と CMK はともにローテーションさせることができます。
CEK のローテーションはデータ操作のサイズであり、暗号化された列を含むテーブルのサイズによっては時間がかかる場合があります。そのため、CEK のローテーションを適切に計画することをお勧めします。
ただし、CMK のローテーションはデータベースのパフォーマンスに影響しないため、個別のロールを使用して行うことができます。

次の図に、Always Encrypted の列マスターキーのキーストアオプションを示します。

組織と SQL Database の間のトラフィックを最適化してセキュリティ保護するにはどうすればよいですか

組織と SQL Database の間のネットワークトラフィックは、一般に、パブリックネットワーク経由でルーティングされます。ただし、このパスを最適化してセキュリティを強化する場合は、Azure ExpressRoute を検討できます。 ExpressRoute を使うと、基本的に、プライベート接続経由で企業ネットワークを Azure プラットフォームに拡張できます。これにより、パブリックインターネットを使う必要がなくなります。また、パブリックインターネット経由の場合より、セキュリティと信頼性が強化され、ルーティングの最適化によりネットワーク待機時間が短縮されてはるかに高速になります。組織と Azure の間で大きなデータチャンクを転送することを計画している場合、ExpressRoute を使うとコストの点でメリットがあります。組織から Azure への接続は、3 つの異なる接続モデルから選ぶことができます。

また、ExpressRoute では、購入した帯域幅制限の最大 2 倍を追加料金なしで利用できます。また、ExpressRoute を使用してリージョン間接続を構成することもできます。 ExpressRoute 接続プロバイダーの一覧については、以下を参照してください: 「ExpressRoute パートナーとピアリングの場所」。次の記事では、ExpressRoute についてさらに詳しく説明されています。

SQL Database はすべての規制要件に準拠していますか。また、SQL Database は組織のコンプライアンスにどのように役立ちますか

SQL Database は、さまざまな規制に準拠しています。 SQL Database が準拠するコンプライアンスの最新の一覧を参照するには、Microsoft セキュリティセンターにアクセスしてご自分の組織に重要なコンプライアンスを細かく調査し、SQL Database が準拠する Azure サービスに含まれているかどうかを確認してください。 SQL Database はコンプライアンスに準拠しているサービスとして認証を受けていますが、これは組織のサービスのコンプライアンスを支援するものであり、自動的にコンプライアンスを保証するものではないことに留意することが重要です。

移行後のインテリジェントなデータベースの監視とメンテナンス

データベースを SQL Database に移行した後は、データベースを監視し (たとえば、リソースの使用状況の確認や DBCC のチェック)、定期的にメンテナンス (たとえば、インデックスの再構築や再構成、統計情報など) を行います。幸いにも、SQL Database はこの点でインテリジェントであり、履歴の傾向と記録されたメトリックや統計情報を使って、データベースの監視とメンテナンスを積極的に支援し、アプリケーションが常に最適な状態で稼働できるようにします。構成のセットアップによっては、Azure SQL Database はメンテナンスタスクを自動的に実行できる場合もあります。 SQL Database のデータベースの監視には、3 つの側面があります。

パフォーマンスの監視と最適化。
セキュリティの最適化。
コストの最適化。

パフォーマンスの監視と最適化

Query Performance Insight を使うと、データベースのワークロードに合わせて調整された推奨事項が得られ、アプリケーションは常に最適なレベルで実行できます。推奨事項を自動的に適用し、面倒なメンテナンスタスクを実行しなくてよいように設定することもできます。 SQL Database Advisor を使うと、ワークロードに基づくインデックスの推奨設定を自動的に実装できます。これは自動チューニングと呼ばれます。推奨事項はアプリケーションワークロードの変化に応じて進化し、最も重要な推奨事項が提供されます。また、手動でこれらの推奨事項を確認し、自分で判断して適用することもできます。

セキュリティの最適化

SQL Database では、データの保護に役立つ実践的なセキュリティの推奨事項と、データベースに対する潜在的な脅威になる不審なデータベースアクティビティを識別して調査する脅威検出が提供されます。脆弱性評価: データベーススキャンおよびレポートサービスであり、大規模なデータベースのセキュリティ状態を監視して、セキュリティ上のリスクおよびユーザーが定義したセキュリティベースラインからのずれを特定します。各スキャン後には、ユーザーに合わせた実行可能な手順の一覧と修復スクリプト、およびコンプライアンス要件に準拠するために使用可能な評価レポートが提供されます。

Microsoft Defender for Cloud では、全体的なセキュリティ推奨事項を確認し、それらをすばやく適用できます。

コストの最適化

Azure SQL プラットフォームにより、サーバーのデータベース全体の使用履歴が分析され、お客様に適したコストの最適化オプションが評価および推奨されます。この分析により実践的な推奨事項を分析して作成するには、通常数週間のアクティビティが必要です。

コストに関する推奨事項のバナー通知を Azure SQL Server で受信する場合があります。
Elastic Pool はそのようなオプションの 1 つです。詳細については、Elastic Pool を利用した Azure SQL データベース内の、複数のデータベースの管理およびスケーリングに関するページをご覧ください。
詳細については、「Azure SQL Database のコストを計画および管理する」を参照してください。

SQL Database のパフォーマンスとリソース使用率を監視するにはどうすればよいですか

SQL Database のパフォーマンスとリソース使用率は、次の方法で監視できます。

Database Watcher

Database Watcher は、データベースのパフォーマンス、構成、正常性の詳細ビューを提供するために、ワークロード監視データを詳細に収集します。 Azure portal のダッシュボードでは、Azure SQL 資産の単一ウィンドウビューと、各監視対象リソースの詳細ビューが提供されます。データは、Azure サブスクリプションの中央データストアに収集されます。収集したデータのクエリ、分析、エクスポート、視覚化を行い、ダウンストリームシステムと統合することができます。

Database Watcher の詳細については、以下の記事を参照してください。

Azure portal

Azure portal でデータベースを選択し [概要] ペインのグラフを選択すると、データベースの使用率が表示されます。このグラフは、CPU 使用率、DTU の割合、データ IO の割合、セッションの割合、データベースサイズの割合など、複数のメトリックを表示するように変更できます。

このグラフでは、リソース別のアラートを構成することもできます。これらのアラートを使用することで、リソースの状態に電子メールで対応したり、HTTPS/HTTP エンドポイントに書き込んだり、アクションを実行することができます。詳細については、アラートの作成に関するページをご覧ください。

動的管理ビュー

リソース使用率の統計について、sys.dm_db_resource_stats 動的管理ビューでクエリを実行すると過去 1 時間における履歴を確認でき、sys.resource_stats システムカタログビューでクエリを実行すると過去 14 日間の履歴を確認できます。

クエリパフォーマンスの分析情報

クエリパフォーマンスの分析情報では、指定したデータベースについて、リソース使用率が上位のクエリおよび実行時間が長いクエリの履歴を確認できます。リソース使用率、期間、および実行頻度で、上位のクエリをすばやく識別できます。クエリを追跡し、回帰を検出できます。この機能を使用するには、データベースでクエリストアを有効化しアクティブにする必要があります。

パフォーマンスに問題があります。SQL Database と SQL Server のトラブルシューティングの方法の違いはどのようなものですか

クエリおよびデータベースパフォーマンスの問題の診断に使用するトラブルシューティング手法の主要な部分は、変わりません。クラウドで利用されているデータベースエンジンは同じものです。ただし、Azure SQL Database プラットフォームには "インテリジェンス" が組み込まれています。それにより、パフォーマンスの問題のトラブルシューティングと診断が容易になります。ユーザーに代わって是正措置の一部を実行することもでき、場合によっては事前に問題を自動的に修復します。

パフォーマンスの問題のトラブルシューティングに向けたアプローチには、クエリパフォーマンスの分析情報 (QPI) や Database Advisor などのインテリジェントな機能を組み合わせて使うと大きなメリットがあり、方法においてはその点が異なります。問題のトラブルシューティングに役立つかもしれない重要な詳細を手作業で調べる必要はもうありません。難しい作業はプラットフォームがやってくれます。その 1 つの例は QPI です。 QPI では、クエリレベルまでドリルダウンし、過去の傾向を見て、クエリが回帰したときを正確に識別できます。 Database Advisor では、インデックスの欠落、インデックスの削除、クエリのパラメーター化など、全体的なパフォーマンスの向上に役立つ推奨事項が提供されます。

パフォーマンスのトラブルシューティングでは、アプリケーションだけの問題であるか、それともデータベースの問題がアプリケーションのパフォーマンスに影響しているのかを、識別することが重要です。多くの場合、パフォーマンスの問題はアプリケーション層にあります。アーキテクチャまたはデータアクセスパターンが原因である可能性があります。たとえば、ネットワーク待機時間の影響を受けやすい、頻繁に通信を行うアプリケーションについて考えます。この場合、アプリケーションとサーバーの間で多数の短い要求がやり取りされ、混雑したネットワークではこれらのラウンドトリップが急速に蓄積されるため、アプリケーションに悪影響があります。この場合にパフォーマンスを向上させるには、バッチクエリを使うことができます。バッチを使うと、要求が一括処理されるようになるので非常に有効です。ラウンドトリップ遅延時間を削減し、アプリケーションのパフォーマンスを向上させることができます。

さらに、データベースの全体的なパフォーマンスの低下が生じている場合は、sys.dm_db_resource_stats および sys.resource_stats の各動的管理ビューを監視して、CPU、IO、メモリ使用率を把握できます。パフォーマンスは、データベースのリソース不足のために影響を受けることがあります。ワークロードの需要の増減に応じて、コンピューティングサイズやサービスレベルの変更が必要になる場合があります。

パフォーマンスのチューニングに関する問題の包括的な推奨事項については、「データベースの調整」をご覧ください。

適切なサービスレベルとコンピューティングサイズを使用していることを確認するにはどうすればよいですか

SQL Database には、古い DTU モデルとより適応性の高い仮想コア購入モデルという 2 つの異なる購入モデルが用意されています。 2 つの違いについては、「Azure SQL データベースの仮想コアと DTU ベースの購入モデルを比較」を参照してください。

適切なコンピューティングサイズであることを確認するために、どちらの購入モデルでもクエリとデータベースリソースの消費量を監視できます。詳細については、監視とパフォーマンスチューニングに関するページをご覧ください。クエリまたはデータベースによる負荷が一貫して高い場合は、上位のコンピューティングサイズへのスケールアップを検討します。同様に、ピーク時間帯でもリソースがあまり使われていない場合は、現在のコンピューティングサイズからのスケールダウンを検討します。 Azure Automation を使用して、スケジュールに従って SQL Database をスケーリングすることを検討できます。

SaaS アプリパターンまたはデータベース統合シナリオがある場合は、エラスティックプールを使ってコストを最適化することを検討します。エラスティックプールは、データベースの統合とコストの最適化を実現する優れた方法です。 Elastic Pool を使った複数のデータベースの管理については、プールとデータベースの管理に関するページをご覧ください。

どのくらいの頻度でデータベースの整合性チェックを実行する必要がありますか

SQL Database では、特定のクラスのデータ破損にデータを失うことなく自動的に対処できるスマートな手法が使われています。これらの手法はサービスに組み込まれており、必要に応じてサービスで利用されます。サービス間のデータベースバックアップは、定期的に復元して DBCC CHECKDB を実行することでテストされます。問題がある場合、SQL Database は事前にそれらに対処します。ページの自動修復は、破損している、またはデータの整合性に問題があるページの修正に利用されます。データベースのページは常に、ページの整合性を検証する既定の CHECKSUM 設定で検証されます。 SQL Database は、データベースのデータの整合性を先行的に監視および確認し、問題が発生した場合は高い優先順位で対処します。これらに加えて、必要に応じて、独自の整合性チェックを実行することもできます。詳しくは、「Data Integrity in Azure SQL Database」(Azure SQL Database のデータ整合性) をご覧ください。

移行後のデータの移動

Azure portal を使用して、SQL Database のデータを BACPAC ファイルとしてエクスポートおよびインポートするにはどうすればよいですか

Export:Azure SQL Database は、Azure Portal で BACPAC ファイルとしてエクスポートできます

Import:Azure portal を使って、データを BACPAC ファイルとして Azure SQL Database のデータベースにインポートすることもできます。

SQL Database と SQL Server の間でデータを同期するにはどうすればよいですか

これを行うには、いくつかの方法があります。

データ同期 – この機能を使うと、複数の SQL Server データベースと SQL Database の間でデータを双方向に同期することができます。 SQL Server データベースと同期するには、ローカルコンピューターまたは仮想マシンに同期エージェントをインストールして構成し、発信 TCP ポート 1433 を開く必要があります。
トランザクションレプリケーション – トランザクションレプリケーションを使うと、SQL Server インスタンスをパブリッシャー、Azure SQL Database をサブスクライバーにして、SQL Server データベースから Azure SQL Database にデータを同期できます。現時点では、このセットアップのみがサポートされています。最小限のダウンタイムで SQL Server データベースから Azure SQL にデータを移行する方法の詳細については、「トランザクションレプリケーションの使用」を参照してください。

Azure SQL データベースと Azure SQL Managed Instance での監視とパフォーマンスチューニング

次の方法で共有