Azure Database for MySQL - フレキシブル サーバーのパフォーマンス機能
Azure Database for MySQL フレキシブル サーバーは、次の 3 つのサービス レベルのいずれかに基づいて作成できます: Burstable、General Purpose、Business Critical。 これらのサービス レベルが提供するコンピューティングとストレージのサイズ、サポートされる最大接続数と 1 秒あたりの I/O 操作数 (IOPS) は上になるほど増加します。 1 つの MySQL フレキシブル サーバーは複数のデータベースをホストできます。 CPU とメモリ使用率、I/O パフォーマンス、クエリ メトリックなどの MySQL フレキシブル サーバーのパフォーマンス メトリックを監視することで、情報に基づいた容量の決定を行うことができます。
コンピューティング サイズ:RAM とコア
3 つのサービス レベルが提供する根本の VM SKU はそれぞれ異なります。 Burstable レベルは B シリーズ VM を使用し、General Purpose レベルは D シリーズ VM を使用し、Business Critical レベルは E シリーズ VM を使用します。 使用される VM シリーズによって、サーバー上で利用できる仮想コアと RAM の数が決まります。
コンピューティング レベル、コンピューティング サイズ、ストレージ サイズは、サーバーの作成後に変更できます。 コンピューティング レベルやコンピューティング サイズの変更には再起動が必要であり、この実行には通常 1、2 分を要します。 ストレージ サイズの変更には再起動は必要ありません。
(開発、ステージング、テストなどの) 非運用環境ワークロードの場合は、バースト可能レベルに基づくサーバーの使用を検討してください。これは、CPU をフルで継続的には使用しないワークロードにとってコスト効率の高いソリューションを提供します。 使用率が低い期間中、B シリーズ VM を使用するサーバーは CPU クレジットを蓄積し、これは使用率が高い期間にベースラインを超えてパフォーマンスを "バースト" させるために使用できます。 ベースラインが高すぎる場合、または高使用率バーストが多すぎる場合は、パフォーマンスの低下を避けるために General Purpose または Business Critical レベルへのアップグレードを検討してください。
サービス レベルのコンピューティング サイズ
3 つのサービス レベルが提供するコンピューティング能力のレベルはそれぞれ異なります。 Burstable レベルは最大 20 個の仮想コアを、General Purpose レベルは最大 64 個の仮想コアをサポートできる一方、最大 96 個の仮想コアをサポートする Business Critical レベルは最高レベルのコンピューティング能力を提供します。 Business Critical レベルは、Ev4 シリーズ VM よりも最大で 30% 高い QPS と 50% 低い待機時間を持つ Ev5 シリーズ VM も提供しています。
IOPS:事前プロビジョニングと自動スケーリング
1 秒あたりに実行できる読み取りと書き込み操作の数は、ストレージ IOPS (1 秒あたりの I/O 操作数) と呼ばれます。 IOPS 設定が高いほど、ストレージ パフォーマンスは向上します。並列の読み取り/書き込み操作数が増えるほど、データ取得、データ永続化、インデックス更新が高速化され、データベース全体の効率性が向上します。 IOPS 設定が低すぎると、データベースで処理の遅延やパフォーマンスの低下が発生する可能性があります。 しかし、IOPS 設定が高すぎると、パフォーマンスの改善が実感できずにコストだけが増加する可能性があります。
Azure Database for MySQL - フレキシブル サーバーでは、IOPS を事前プロビジョニングするか、自動スケーリング IOPS 機能を使用します。
事前プロビジョニングされた IOPS では、一貫した予測可能なパフォーマンスを提供するために特定の数の IOPS を割り当てます。これは、負荷が I/O 操作が調整されるしきい値に近づかない場合に適しています。 ワークロード需要の増加に応じていつでも追加の IOPS を割り当てることができますが、これには手動の介入が必要です。
自動スケーリング IOPS 機能が有効になっていると、IOPS はワークロード アクティビティに基づいてオンデマンドでスケーリングされ、消費量に基づいた支払いを行うことになります。 ワークロードが増加するにつれ、サーバーは I/O パフォーマンスをシームレスにスケーリングし、トラフィックが少ない場合に未使用の容量に対して支払いを行うことなく、インスタンスがワークロードの急増に対処することが可能になります。
どちらの場合も、IOPS はサーバーの最大値を超えることはできません。 コンピューティング サイズ別の最大 IOPS の情報については、「コンピューティングとストレージのドキュメント」の記事を参照してください。
読み取りレプリカ
データベースのトラフィックが増加するにつれ、その容量を水平方向または "out" (コンピューティング ノードの数) に、あるいは垂直方向または "up" (コンピューティング ノードのサイズ) にスケーリングすることができます。 読み取りレプリカは水平方向のスケーリングを提供します。
読み取りレプリカは、MySQL のバイナリ ログ レプリケーション (binlog) を使用して同期状態に保たれたデータベースの読み取り専用コピーです。 アプリケーションが拡大するにつれて、コンピューティングおよびストレージ リソース (データベースなど) をスケーリングする必要があります。 アプリケーション コンポーネントのスケーリングは、Azure Kubernetes Service (AKS)、Virtual Machine Scale Sets、App Service を使用して新しい VM をプロビジョニングすることで簡素化されます。 これらのコンピューティング リソースのスケールと保存データが増加するにつれて、データベースの負担が増え、アプリケーションのアーキテクチャのボトルネックとなることがよくあります。
読み取りレプリカを使用すると、プライマリ サーバーが読み取り/書き込み操作をサポートできるように、読み取り専用操作をセカンダリ データベースに転送することができます。 Azure Database for MySQL は、マネージド読み取りレプリカを提供します。 ソース サーバーは、最大 10 個のレプリカにレプリケートできます。 これは、多くの場合に大量のデータのクエリを実行するレポートや分析などのユース ケースで役立ちます。
読み取りレプリカの使用は、何かの理由でクエリでインデックスを使用できない場合に特に役立ちます。 すべてのクエリ パターンのインデックスを追加することは、サーバーに余分な負荷 (処理、ディスク I/O、ストレージ、トランザクション時間など) を与えることになるため、実用的でなかったり問題を生じさせたりする可能性があります。 データ ウェアハウスが利用できない場合、または更新サイクルよりも新しいデータが必要な場合は、読み取りレプリカの使用は、重大な読み取り/書き込み操作を中断することなく "大きな" クエリを実行するのに最適な方法となります。
読み取りレプリカは、高可用性構成と同じ方法ですぐに同期されるわけではありません。 読み取りレプリカでは、HA ソリューションに関連するトランザクション待機時間は発生しませんが、データがプライマリ データベースからレプリカに届くために若干の遅延が発生する可能性があります。