Azure のロックを解除する: 柔軟性の高い SQL データベース インフラストラクチャを構築する方法

近年、サービスとしてのインフラストラクチャとサービスとしてのプラットフォームが、その機能、特にリソース効率と柔軟性により、さまざまなプロジェクトでますます普及していることは秘密ではありません。その結果、Microsoft は SQL を使用できるユーザーフレンドリーな環境を構築するために多大な時間と労力を費やしました。

Social Discovery Group チームは、SQL を含むさまざまなデータベースを使用して製品を強化しています。世界中で出会い、つながるのに役立つ 40 以上のグローバル サービスのポートフォリオを備えた当社のユーザー ベースには、世界中の 2 億 5,000 万人以上の人々が含まれています。ユーザーに対する当社製品の信頼性を保証するために、当社は主要なインフラストラクチャの一部をクラウドに保管しています。これにより、復元力、セキュリティ、柔軟性が強化されます。

私たちは、Kubernetes クラスターを含むさまざまなプラットフォーム上でのサーバーおよびサービス データベースのデプロイに豊富な経験を持っています。しかし、私たちは、Azure クラウド内の関連する SQL データベース インフラストラクチャの一部を可能な限り柔軟、効率的、信頼性の高いものにする必要性に直面しました。 Microsoft Azure クラウドで SQL を使用するには、次の 3 つの方法があります。

• Azure SQLデータベース
• Azure SQL マネージド インスタンス
• Azure 仮想マシン上の SQL Server

調査の結果、Azure SQL データベースを使用することにしました。いわゆる Azure SQL データベースについて聞いたことがない人のために説明すると、これらは Microsoft Azure の一部として提供されるマネージド クラウド データベースです。

以下の利点を強調しました。

• アップデートやサポート終了について心配する必要はありません。
• 構成と展開が簡単。
• 導入 (したがって開発) の速度と拡張性。
• 高可用性。
• 耐障害性。
• バックアップが簡単。
• コストの最適化。
• 統合された Microsoft Azure 監視システム。

次に、ステップごとに説明し、データベースのデプロイと作成のプロセスを見てみましょう。これは Power Shell スクリプトまたは Azure CLI を使用して実行できますが、わかりやすくするために、ポータルのグラフィカル インターフェイスを使用してプロセスを確認します。これを行うには、Azure SQL に移動し、[作成] をクリックして、[SQL データベース] を選択します。

リソース グループを指定し、既存のサーバーがあるか新しいサーバーを作成するかを選択し (管理者の名前とデータを指定します)、データベースの名前を考えます。一般的なワークロードに対してコンピューティング リソースとストレージ リソースをバランスよく組み合わせた、DTU (データベース トランザクション ユニット) ベースのバンドル パッケージを選択することをお勧めします。

設定用のタブもいくつかあります: ネットワーク、セキュリティ、追加設定、タグ。最小の標準構成の場合、これらはデフォルトで変更しないままにすることができます。次に、データベースが作成されるのを待ちます。これで最低限のセットアップは完了し、ベースは完成です。

データベース リソースのサイズは、文字通りクリックするだけで非常に簡単に変更でき、リソースが不十分な場合は、サイズとパフォーマンスの点で必要なパラメータを設定できます。

その後、IP アドレスやサブネットを追加したり、このデータベースがホストされているサーバーのファイアウォールですべての接続を許可したりすることを忘れずに、外部から任意の方法でデータベースに接続できます。

SQL Server Management Studio (SSMS) を介して接続してさらに管理するのが便利ですが、他のツールや Azure portal 自体を介して接続することも可能です。

パブリック接続ポイントに加えて、必要なサブネットにサーバーを追加し、プライベート DNS ゾーンを構成することで、プライベート接続ポイントを作成することもできます。

フォールト トレランスについて言えば、ここでは、さまざまなリージョンに基づいてサーバーを保護するグループであるフェイルオーバーの非常に便利で直感的な実装が見られます。

Azure では、フェールオーバー グループ、強制フェールオーバー、および自動フェールオーバー モード内のサーバー上のデータベースを追加および削除できます。

以下のスクリーンショットでこれを確認できます。フェイルオーバー グループの名前を考えて、サーバーをフェイルオーバーさせましょう。指定したデータベースの同期が自動的に開始されます。 2 番目のサーバーは読み取り専用モードになります。障害が発生した場合、トラフィックは自動的に 2 番目のリージョンに切り替えられ、プライマリ サーバーとセカンダリ サーバーが自動的に切り替わります。

ただし、データベース自体にデータレベルの問題がある場合、フェイルオーバーは役に立ちません。この場合、必ずバックアップを作成する必要があります。バックアップは、ポータル内と、サードパーティ ツールや Azure DevOps などの両方を使用して構成できます (パイプラインでは、SqlAzureDacpacDeployment + AzureFileCopy タスクを使用できます)。ポータル内のバックアップは [バックアップ] タブで構成され、必要なストレージ ポリシーが設定されます。

サードパーティのバックアップ ツールを使用したい場合は、Azure DevOps または SQL パッケージ ツールを検討することをお勧めします。

私の意見では、ポータル自体の回復プロセスはあまり便利ではありません。最初に気づくのは、単純なテスト データベースの回復時間が長いことです。たとえば、昨日のバックアップから 30MB の基本サイズのデータベースを復元するのに 30 分以上かかりました。 Microsoft Azure サポートに連絡したところ、PowerShell スクリプトを使用して回復するようアドバイスされ、回復プロセスではデータベース サイズが少なくとも S3 である必要があり、後でサイズを減らすことができると通知されました。以下に、このテーマに関する私のスクリプトと開発の一部を紹介します。これらは改善され強化される可能性がありますが、多くの人にとって役立つと確信しています。

ステップごとに説明します。

1. Windows に PowerShell ISE がインストールされていない場合は、ここからダウンロードしてください。 https://github.com/PowerShell/Pohell/releases/download/v7.3.0/PowerShell-7.3.0-win-x64.msi
   https://github.com/PowerShell/PowerShell/releases/download/v7.3.0/PowerShell-7.3.0-win-x86.msi
2. 次に、Azure モジュールをインストールする必要があります: Install-Module Az
3. AZ モジュールをインストールした後、AZ モジュールをインポートします: Import-Module Az
4. インポートしたら、Azure アカウント Connect-AzAccount に接続できます。 Azure アカウントにログインするためのポップアップが表示され、接続されます。
5. PowerShell スクリプト自体を実行します。

 “ #Variables in use $Database = Get-AzSqlDatabase -ResourceGroupName "Test" -ServerName "test-serv1" -DatabaseName "dbforscript" $TargetDB = "dbforscript_new" $PITRtimedate = "2022-12-02 10:00:00Z" ##вам нужно увидеть действительную дату и время на портале $PITRSLO = "S3" $PITRNEWSLO = "S0" $PITRedition = "Standard" $failoverGroupRG = "Test" $failoverGroupS = "test-serv1" $failoverGroupDB = "dbforscript" $removedbfromfgRG = "Test" $removedbfromfgS = "test-serv1" $removedbfromfgDB = "XXXXX" $dropreplicaRG = "Test" $dropreplicaS = "test-serv2" $dropreplicaDB = "dbforscript" $sourcedbRG = "Test" $sourcedbS = "test-serv1" $sourcedbDBname = "dbforscript" $sourcedbDBNEWname = "dbforscript_old" $TargetDBNEWname = "dbforscript" “

1 - このコードは、別の名前でデータベースの復元を開始します。復元されるデータベースの元の名前が「dbforscript」の場合、復元されるデータベースの名前は dbforscript_new になります。復元されたデータベースは SLO バージョン S3 以降になります。これは、このアクションを実行するための推奨方法です。この変数は $PITRSLO = "S3" であり、S3 以降を使用できます。この後、SLO レベルを元のレベルにリセットします。これは回復のみを目的としています。

 “Restore-AzSqlDatabase -FromPointInTimeBackup -PointInTime $PITRtimedate -ResourceGroupName $Database.ResourceGroupName -ServerName $Database.ServerName -TargetDatabaseName $TargetDB -ResourceId $Database.ResourceID -Edition $PITRedition -ServiceObjectiveName $PITRSLO”

2 - このコードは、フェイルオーバー グループからソース データベースを削除します: ソース データベース: dbforscript。

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $failoverGroupdb | Remove-AzSqlDatabaseFromFailoverGroup -ResourceGroupName $removedbfromfgRG -ServerName $removedbfromfgS -FailoverGroupName $removedbfromfgDB”

3 - このコードは、レプリカ データベースが存在するサーバー (test-serv2 サーバー上の dbforscript) からレプリカ データベースを削除します。

 “Remove-AzSqlDatabase -ResourceGroupName $dropreplicaRG -ServerName $dropreplicaS -DatabaseName $dropreplicaDB”

4 - このコードは、元のデータベースの名前を別の名前に変更します。名前変更後、dbforscript は dbforscript_old になります。

 “Set-AzSqlDatabase -ResourceGroupName $sourcedbRG -DatabaseName $sourcedbDBname -ServerName $sourcedbS -NewName $sourcedbDBNEWname”

5 - このコードは、復元されたデータベースの名前を元のデータベース名に変更し、dbforscript_new の名前を dbforscript に変更します。

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDB -ServerName $Database.ServerName -NewName $TargetDBNEWname”

6 - このコードは、データベースの SLO レベルを以前の (元の) S0 値に戻します。データベースがベーシックの場合は、ポータルで後で S0 からベーシックにアップグレードできます。

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDBNEWname -ServerName $Database.ServerName -Edition $PITRedition -RequestedServiceObjectiveName $PITRNEWSLO -MaxSizeBytes 10737418240”

7 - 最後のコードは、復元されたデータベースをフェイルオーバー グループに追加します。このグループには既に元の名前が付いています (前のコードで変更したため)。

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $TargetDBNEWname | Add-AzSqlDatabaseToFailoverGroup -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -FailoverGroupName $removedbfromfgDB”

コマンドの後に -ErrorAction Stop パラメーターを追加することを検討できます。これにより、エラーが発生した場合に次のコマンドが実行されなくなり、雪だるま式に発生することはなくなります。

また、スクリプトの最初と最後に Get-Date を追加して、実行時間を計算することもできます。私の場合、このようなスクリプトにより約 3.3 GB のデータベースが 6 分以内に復元されました。

必要に応じて、スクリプトを最適化したり、Azure DevOps 経由で追加したり、変数の数を減らしたり、何かをハードコードしたりすることもできますが、私はできるだけ詳細に、誰もが理解できる方法で説明するよう努めました。

Azure 上のデータベース監視と、Datadog などのさまざまなシステムと統合する機能は、特に注目に値します。監視は非常に便利ですが、ニュアンスがないわけではありません (たとえば、この記事の執筆時点では、読み取り専用ユーザーは 1 つのデータベースの監視のみを参照でき、一度にすべてを監視することはできませんでした...まあ、ここに色合いがあります)。

結論として、私たちのチームは、アップデートやサポートの終了に関する懸念にも対処しながら、経費の最適化に成功しました。パフォーマンス、復元力、開発速度、柔軟性の向上を実現しました。さらに、スクリプトの実装により、必要なときに迅速に回復する能力が著しく強化されました。

執筆者は、Social Discovery Group のリード DevOps エンジニアである Pavel Shapurau です。