パフォーマンスと効率を最大化するには、オンプレミス環境から Azure Database for MySQL に移行した後、MySQL データベースを最適化することが不可欠です。 この記事では、Azure 環境でデータベースを最適化するための主要戦略とベスト プラクティスについて説明します。 データベースの潜在能力を最大限に引き出すには、クエリのパフォーマンス、インデックス作成、リソース割り当て、構成のチューニングに重点を置きます。 このガイドでは、パフォーマンスのボトルネックを特定して対処し、Azure の高度な機能を使用して、最適なデータベース パフォーマンスを実現するうえで必要な分析情報と手法を提供します。 目的が応答時間の短縮、スケーラビリティの改善、運用コストの削減のいずれであっても、この記事を読めば、Azure 上で MySQL データベースを最適化するための知識を得られます。
前提条件
オンプレミスの MySQL から Azure Database for MySQL への移行: 移行後の管理
ハードウェアとクエリのパフォーマンスを監視する
サーバーのパフォーマンス監視には、監査ログとアクティビティ ログに加えて、Azure メトリックスを使用することもできます。Azure メトリックスは 1 分に 1 回の頻度で提供され、それに基づいたアラートを構成できます。 監視できるメトリックの種類の詳細については、「Azure Database for MySQL での監視」を参照してください。
前述のとおり、cpu_percent や memory_percent などのメトリックを監視することは、データベース レベルのアップグレードを決定する際に重要になる可能性があります。 値が一貫して高い場合、レベルのアップグレードが必要であることを示している可能性があります。
また、CPU とメモリが問題ではないと思われる場合、管理者は、パフォーマンスの低いクエリについてインデックス作成やクエリの変更などのデータベースベースのオプションを調べることができます。
パフォーマンスの低いクエリを検出するには、次を実行します。
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DBFORMYSQL"
| where Category == 'MySqlSlowLogs'
| project TimeGenerated, LogicalServerName\_s,
event\_class\_s, start\_time\_t , q uery\_time\_d,
sql\_text\_s| top 5 by query\_time\_d desc
Query Performance Insight
Azure には、サーバー監視の基本的な側面に加えて、アプリケーションのクエリ パフォーマンスを監視するためのツールが用意されています。 クエリを修正または改善すると、クエリのスループットが大幅に向上する可能性があります。 Query Performance Insight ツールを使用して、実行時間の最も長いクエリを分析し、これらの項目をキャッシュできるかどうか (設定された期間内に確定される場合)、またはクエリを変更してパフォーマンスを向上できるかどうかを決定します。
slow\_query\_log を、MySQL ログ ファイルの低速なクエリを表示するように設定できます (既定ではオフ)。 long\_query\_time サーバー パラメーターを使用すると、クエリ時間が長い (既定値は 10 秒) ことをユーザーに警告できます。
レベルをアップグレードする
Azure portal は、General Purpose と Memory Optimized の間のスケーリングに使用できます。 Basic レベルを選択した場合、後でレベルを General Purpose またはMemory Optimized にアップグレードするオプションはありません。 ただし、別の手法を使用して、新しい Azure Database for MySQL インスタンスへの移行またはアップグレードを実行することはできます。
Basic から別のサーバー レベルに移行するスクリプトの例については、「Azure Database for MySQL で Basic から General Purpose または Memory Optimized レベルへのアップグレード」を参照してください。
サーバーのスケーリング
レベル内で、そのレベルで許容される最小および最大の限度までコアおよびメモリをスケーリングすることができます。 監視によって、CPU またはメモリが継続的に限界に達していることが判明した場合、手順に従ってスケールアップし、需要に対応します。
リージョンを移動する
別の Azure リージョンへのデータベースの移動は、アプローチとアーキテクチャによって異なります。 アプローチによっては、システムのダウンタイムが発生する可能性があります。
推奨されるプロセスは、メンテナンス フェールオーバーに読み取りレプリカを使用する場合と同じです。 ただし、前述の計画メンテナンス方法と比較すると、フェールオーバー レイヤーがアプリケーションに実装されている場合に、フェールオーバーの速度が速くなります。 アプリケーションは、読み取りレプリカのフェールオーバー プロセス中、少しの間ダウンするだけです。 詳細については、「事業継続とディザスター リカバリー」のセクションを参照してください。
WWI のシナリオ
WWI ビジネスおよびアプリケーション ユーザーは、データベースをオンデマンドでスケーリングする機能に非常に興奮していました。 また、Query Performance Insight を使用して、実行時間の長いクエリのパフォーマンスに対処する必要があるかどうかを判断することにも関心を示しました。
彼らは、潜在的なフェールオーバーや読み取り専用が必要になるあらゆるシナリオに対して、読み取りレプリカ サーバーを利用することを選択しました。
移行チームは、Azure エンジニアと協力して、MySQL サーバーのパフォーマンスに関する潜在的な問題を監視するために KQL クエリを設定しました。 KQY クエリは、データベースおよび会議チームにイベントの問題を電子メールで送信するアラートを使用して設定されました。
彼らは、現時点では潜在的な問題を監視し、運用効率を向上させるために必要に応じて後で Azure Automation Runbook を実装することを選択しました。
最適化チェック リスト
速度の遅いクエリを監視します。
Performance Insight ダッシュボードを定期的に確認します。
監視を利用して、レベルのアップグレードとスケールの決定を行います。
ユーザーまたはアプリケーションのニーズが変化した場合にリージョンの移動を検討します。