移行後の管理は、MySQL データベースをオンプレミス環境から Azure Database for MySQL に移動する際に重要です。 この記事では、移行後のデータベースの管理に関する重要なタスクとベスト プラクティスについて説明します。 監視、パフォーマンス チューニング、セキュリティ、メンテナンスに注目して、Azure 環境でデータベースが効率的かつ安全に動作することを確認できます。 このガイドでは、移行後のデータベースを効果的に管理し、可能性のある問題に対処し、Azure の高度な機能を使ってパフォーマンスと信頼性を最適化するために必要な、洞察と戦略について説明します。 目的がデータベースのパフォーマンスの向上、データのセキュリティの確保、メンテナンス タスクの効率化のいずれであっても、この記事を読めば、移行後の管理を成功させるための知識を得られます。
前提条件
オンプレミスの MySQL から Azure Database for MySQL への移行: MySQL Workbench を使用したデータ移行
監視とアラート
移行が正常に完了したら、次のフェーズで、新しいクラウドベースのデータ ワークロード リソースを管理します。 管理操作には、コントロール プレーンとデータ プレーンの両方のアクティビティが含まれます。 コントロール プレーン アクティビティは、Azure リソースに関連しています。それに対し、データ プレーンは Azure リソース (この場合、MySQL) 内にあります。
Azure Database for MySQL は、Azure Monitor、Log Analytics、Microsoft Sentinel などの Azure ベースのツールを使用して、これら両方の種類の操作アクティビティを監視する機能を備えています。 Azure ベースのツールに加え、これらのログを使用するようにセキュリティ情報イベント管理 (SIEM) システムを構成することもできます。
新しいクラウドベース ワークロードの監視にどちらのツールを使用する場合でも、疑わしいアクティビティについて Azure とデータベース管理者に警告するアラートを作成する必要があります。 特定のアラート イベントに明確に定義された修復パスがある場合、アラートによって自動化された Azure Runbook を起動し、そのイベントに対処できます。
完全に監視された環境を作成する最初の手順は、MySQL ログ データが Azure Monitor に流れるようにすることです。 詳細については、「Azure portal での Azure Database for MySQL の監査ログの構成とアクセス」を参照してください。
ログ データが流れるようになったら、Kusto Query language (KQL) クエリ言語を使用して、さまざまなログ情報に対するクエリを実行します。 KQL を使い慣れていない管理者は、こちらまたは「Azure Monitor でログ クエリの使用を開始する」ページで SQL から KQL へのチート シートを見つけることができます。
たとえば、Azure Database for MySQL のメモリ使用量を取得するには、次のようにします。
AzureMetrics
| where TimeGenerated \> ago(15m)
| limit 10
| where ResourceProvider == "MICROSOFT.DBFORMYSQL"
| where MetricName == "memory\_percent"
| project TimeGenerated, Total, Maximum, Minimum, TimeGrain, UnitName
| top 1 by TimeGenerated
CPU 使用率を取得する場合:
AzureMetrics
| where TimeGenerated \> ago(15m)
| limit 10
| where ResourceProvider == "MICROSOFT.DBFORMYSQL"
| where MetricName == "cpu\_percent"
| project TimeGenerated, Total, Maximum, Minimum, TimeGrain, UnitName
| top 1 by TimeGenerated
KQL クエリを作成したら、これらのクエリに基づいてログ アラートを作成します。
サーバー パラメーター
移行の一環として、高速エグレスをサポートするようにオンプレミスのサーバー パラメーターが変更されている可能性があります。 また、Azure Database for MySQL パラメーターにも、高速イングレスをサポートするように変更が行われています。 移行後は、Azure サーバー パラメーターを、オンプレミスのワークロード用に最適化された元の値に戻す必要があります。
ただし、必ず確認し、ワークロードと環境に適したサーバー パラメーターの変更を行ってください。 オンプレミス環境に最適な値の中には、クラウドベースの環境に最適でないものがあります。 さらに、現在のオンプレミスのパラメーターを Azure に移行しようとしている場合は、それらが実際に設定できることを確認してください。
一部のパラメーターは、Azure Database for MySQL で変更することが許可されません。
PowerShell モジュール
Azure Database for MySQL の管理には、Azure portal と Windows PowerShell を使用できます。 PowerShell の使用を開始するには、次の PowerShell コマンドを使用して、MySQL 用の Azure PowerShell コマンドレットをインストールします。
Install-Module -Name Az.MySql
モジュールをインストールしたら、次のようなチュートリアルを参照して、管理アクティビティのスクリプトを活用する方法を確認してください。
PowerShell を使用して Azure Database for MySQL サーバーをバックアップおよび復元する方法
PowerShell を使用して Azure Database for MySQL の読み取りレプリカを作成し、管理する方法
Azure Database for MySQL のアップグレード プロセス
Azure Database for MySQL は PaaS オファリングであるため、管理者がオペレーティング システムや MySQL ソフトウェアの更新を管理する必要はありません。 ただし、アップグレード プロセスはランダムである場合があること、およびデプロイ時に MySQL サーバーのワークロードが停止される可能性があることを知っておくことが重要です。 特定のインスタンスがメンテナンス モードになったときに読み取りレプリカにワークロードを経路変更するようにして、これらのダウンタイムに備えて計画してください。
Note
このスタイルのフェールオーバー アーキテクチャでは、この種のフェールオーバー シナリオをサポートするために、アプリケーション データ レイヤーに対する変更が必要になる場合があります。 読み取りレプリカが読み取りレプリカとして維持され、レベル上げされない場合、アプリケーションはデータの読み取りのみを行うことができ、何らかの操作でデータベースに情報を書き込もうとすると失敗することがあります。
計画メンテナンス通知機能により、更新プログラムまたは重要なセキュリティ パッチのインストールの最大 72 時間前に、リソース所有者に通知されます。 データベース管理者は、計画および計画外のメンテナンスについてアプリケーション ユーザーに通知することが必要になる場合があります。
Note
Azure Database for MySQL のメンテナンス通知は極めて重要です。 データベース メンテナンスにより、データベースおよび接続されているアプリケーションが一定期間停止される可能性があります。
WWI のシナリオ
WWI では、Azure アクティビティ ログを活用し、Log Analytics ワークスペースへのフローの MySQL ログ記録を有効にすることにしました。このワークスペースは、Microsoft Sentinel の一部として構成され、すべての脅威分析イベントを明らかにして、インシデントが作成されるようにします。
MySQL DBA は、Azure Database for MySQL の Azure PowerShell コマンドレットをインストールし、Azure portal に毎回ログオンしなくて済むように、MySQL サーバーの管理を自動化しました。
管理のチェックリスト
CPU やメモリなどの一般的な内容に関するリソース アラートを作成します。
移行後に、サーバー パラメーターがターゲット データのワークロード用に構成されていることを確認します。
一般的な管理タスクをスクリプト化します。
アップグレードやパッチなどのメンテナンス イベントの通知を設定します。 必要に応じてユーザーに通知します。