スケーラビリティのためにデータベース タスクを自動化する

  • 7 分

SQL Server からの自動化を使用する場合、SQL Agent を使用して自動化の目的のためにジョブをスケジュールするのが一般的です。 Azure 仮想マシンで実行されている Azure SQL Managed Instance と SQL Server にもそのオプションはありますが、Azure SQL Database にはないため、同様の結果を得るには別の自動化方法を使用することが必要な場合があります。

Azure Automation

Azure Automation では、プロセスの自動化、構成管理、Azure プラットフォーム オプション (ロールベースのアクセス制御や Microsoft Entra ID など) との完全な統合に対応しており、Azure とオンプレミスのリソースを管理できます。

Azure Automation を使用すると、Azure とオンプレミスの両方の VM のリソースを簡単に制御できます。 たとえば、ハイブリッド Runbook を使用して、VM の起動、SQL Server のバックアップの実行、VM のシャットダウンなどのタスクを自動化して、費用対効果と効率性を高めることができます。

もう 1 つの一般的なシナリオは、古いデータの消去や、SQL データベースのインデックスの再作成など、定期的なメンテナンス操作に Azure Automation を使用することです。

コンポーネント

Azure Automation では、自動化と構成管理の両方のアクティビティがサポートされます。 ここでは自動化のコンポーネントに注目しますが、Azure Automation を使用してサーバーの更新プログラムと構成も管理できることに注意してください。

コンポーネント 説明
Runbook Runbook は、Azure Automation での実行単位です。 Runbook は、PowerShell に基づくグラフィカル Runbook、PowerShell スクリプト、または Python スクリプトの 3 種類のいずれかとして定義されます。 PowerShell Runbook は、Azure SQL リソースの管理に最もよく使用されます。
Module Azure Automation では、Runbook 内で実行している PowerShell または Python コードの実行コンテキストが定義されます。 コードを実行するには、サポート モジュールをインポートする必要があります。 たとえば、Get-AzSqlDatabase PowerShell コマンドレットを実行する必要がある場合は、Az.SQL PowerShell モジュールを Automation アカウントにインポートする必要があります。
資格情報 資格情報では、Runbook または構成で実行時に使用され可能性がある秘匿性の高い情報が格納されます。
[スケジュール] スケジュールは Runbook にリンクされ、特定の時間に Runbook をトリガーします。

Azure SQL Database および Azure SQL Managed Instance リソースの管理に使用できる Azure CLI と PowerShell のコマンドの詳細については、Azure SQL 用の PowerShell モジュールと Azure SQL 用の Azure CLI のリンクを参照してください。

エラスティック ジョブ

多くの DBA が Azure Automation をよく使うようになった理由の 1 つは、Azure SQL Database にはスケジュールされたジョブに関する機能がもともとなかったことです。

この制限により、DBA はこれらの重要なタスクを効率的に処理するための代替ソリューションを見つける必要がありました。 Azure Automation は、このシナリオにおいて、スケジュールされたジョブの作成と管理、データベース移行プロセスの自動化、定期的なメンテナンス タスクの実行のための手段を提供する貴重なツールとして登場しました。

Architecture

エラスティック ジョブ機能を使うと、サーバーまたはデータベースのコレクションに対して 1 回限りのジョブとして、または定義されたスケジュールを使用して、一連の T-SQL スクリプトを実行できます。 エラスティック ジョブは、SQL Server エージェントのジョブと同様に機能しますが、T-SQL の実行に限定される点が異なります。 ジョブは、Azure SQL Database のすべてのレベルで動作します。

Screenshot of the elastic job architecture diagram.

エラスティック ジョブを構成するには、ジョブの管理専用のジョブ エージェントとデータベースが必要です。 ジョブ データベースに推奨されるサービス レベルは S1 以上であり、最適なサービス レベルは、実行しているジョブの数と、それらのジョブの頻度によって決まります。

エラスティック ジョブのコンポーネントを確認してみましょう。

  • エラスティック ジョブ エージェント - ジョブを実行および管理するためのユーザーの Azure リソース。
  • ジョブ データベース - ジョブ管理専用のデータベース。
  • ターゲット グループ - ジョブが実行されるサーバー、エラスティック プール、単一データベースのコレクション。
  • ジョブ - ジョブ ステップを構成する 1 つ以上の T-SQL スクリプト。

サーバーまたはエラスティック プールがターゲットである場合は、ジョブ エージェントが内部のデータベースを列挙できるように、サーバーまたはプールの master データベース内に資格情報を作成する必要があります。 単一データベースの場合、必要なのはデータベース資格情報だけです。 資格情報には、ジョブ ステップの実行に最小限必要な権限だけを設定します。

Screenshot of the elastic job agent creation page.

エラスティック ジョブ エージェントは Azure portal で作成できます。 [エラスティック ジョブ エージェント] ページで、エージェントの名前を指定し、ジョブ データベース用の SQL データベースを指定します。

次の PowerShell スクリプトは、MyFirstElasticJob という名前のエラスティック ジョブを作成してジョブ ステップを追加し、テーブルがデータベースに存在しない場合は SQL コマンドを実行して作成します。

Write-Output "Creating a new job..."
$jobName = "MyFirstElasticJob"
$job = $jobAgent | New-AzSqlElasticJob -Name $jobName -RunOnce

Write-Output "Creating job steps for $($jobName) job..."
$sqlText1 = "IF NOT EXISTS (SELECT * FROM sys.tables WHERE object_id = object_id('MyTable')) CREATE TABLE [dbo].[MyTable]([Id] [int] NOT NULL);"

$job | Add-AzSqlElasticJobStep -Name "Step1" -TargetGroupName $serverGroup.TargetGroupName -CredentialName $jobCred.CredentialName -CommandText $sqlText1

最後に、MyFirstElasticJob エラスティック ジョブを実行します。

Write-Output "Start the job..."
$jobExecution = $job | Start-AzSqlElasticJob
$jobExecution

ユース ケース シナリオ

エラスティック ジョブは、次のシナリオで使用できます。

  • 特定のスケジュールで実行する管理タスクを自動化する。
  • スキーマの変更をデプロイする。
  • データ移動。
  • レポートまたは他の目的でデータを収集して集計する。
  • Azure Blob Storage からデータを読み込む。
  • データベース コレクションを対象として (ピーク外の時間などに) 定期的に実行するジョブを構成します。
  • テレメトリ収集など、多数のデータベースに対するデータ処理。 結果は 1 つの対象テーブルにまとめられて、分析に使用されます。

SQL Agent ジョブをエラスティック ジョブに移行する

SQL Agent ジョブをエラスティック ジョブに移行するための独自のスクリプトを作成することもできますが、より便利なオプションがあります。 既存の SQL Agent ジョブのエラスティック ジョブへのコピーを容易にするダウンロード可能なスクリプトが存在します。

スクリプトは、これらのジョブの変換プロセスを自動化するツールであり、新しい環境でそれらを手動で再作成するために時間と労力をかける必要がなくなります。

そのファイルは、スクリプトと関連ドキュメントを含む zip 形式のフォルダーです。 これを使用するには、ファイルをダウンロードし、手順に従います。

手順に示されるすべてのパラメーターを入力すると、ジョブ一覧が表示されます。 その後、スクリプトは、各ジョブを (まだ存在しないと想定して) 無効な状態で個別に作成します。 ジョブの作成後、同じ ID、コマンド テキスト、再試行回数、初期再試行間隔秒数を使用してステップが追加されます。 ジョブ ステップにリンクされているデータベースがターゲット グループになります。 ターゲット グループが存在しない場合は、自動的に作成されます。 スケジュール、アラート、通知はコピーに含まれません。

SQL Agent ジョブを Azure 上の SQL Agent に移行する

オンプレミスの SQL Server から仮想マシンで実行されている Azure SQL Managed Instance または SQL Server へのジョブの移行は、ほとんどの DBA にとってなじみのあるプロセスに従います。

このシナリオでは、オンプレミスの SQL Server を Azure SQL Managed Instance に移行したとします。 複数の SQL Agent ジョブを移行し、Azure 環境でシームレスに機能するように調整する必要があります。

  • 依存関係を評価する: 移行対象の SQL Agent ジョブを特定します。 ジョブが依存しているリンク サーバー、資格情報、データベースなどの依存関係を一覧表示します

  • SQL Agent ジョブをスクリプト化する: SQL Serverの SQL Agent ジョブを SQL スクリプトとしてスクリプト化します。 これを行うには、SQL Server Management Studio (SSMS) でジョブを右クリックし、[ジョブをスクリプト化] -> [CREATE] -> [新しいクエリ エディター ウィンドウ] を選択します。

  • ジョブの依存関係を修正する: SQL スクリプトを確認し、移行によって変わった可能性があるジョブの依存関係を修正します。 たとえば、ジョブがリンク サーバーを、またはローカル サーバー上のファイル パスを参照している場合は、新しい環境に合わせて更新します。

  • Azure SQL MI ジョブの作成: SSMS または Azure Data Studio を開き、Azure SQL Managed Instance に接続します。 先ほど生成したスクリプトを使用して、新しい SQL Agent ジョブを作成します。

  • Azure SQL MI への依存関係の作成: SQL Agent ジョブがリンク サーバーまたは資格情報に依存している場合は、Azure SQL MI 環境でそれらを作成します。 それらがオンプレミスの SQL Server の構成と一致していることを確認します。

  • ジョブをスケジュールする: SQL Server エージェントを使用して、Azure SQL MI でジョブ スケジュールを設定します。 新しいスケジュールを作成し、ジョブにリンクすることができます。

  • テストする:Azure SQL MI 環境で SQL Agent ジョブを十分にテストして、想定どおりに実行されていることを確認します。 オンプレミスの SQL Server と Azure SQL MI の違いによって発生する可能性があるエラーまたは問題の有無を確認します。

  • 監視とメンテナンス: ジョブのパフォーマンスを監視し、Azure SQL MI 環境で引き続き要件を満たしていることを確認します。 必要に応じて、構成またはスケジュールを調整します。