Azure Database for MySQL サーバーのスケーリング ニーズを決定する

  • 8 分

コンピューティング リソースのサイズ設定については、既存の使用量と予測される使用量が容量内に収まるかどうかを検討します。 CPU や RAM の使用率などの基本的なパフォーマンス メトリックを監視すると、必要な情報を取得できます。 低速クエリ ログを使用すると、パフォーマンスの低いクエリを識別して最適化し、コンピューティング サイズをスケーリングせずにパフォーマンスの問題を解決できる場合があります。 また、I/O パフォーマンスを監視して、データベースの読み取りと書き込みがパフォーマンスのボトルネックになっていないことを確認する必要があります。 主要データベース上の使用可能な容量を効果的に増やすもう 1 つのオプションは、読み取りレプリカをプロビジョニングしてクエリ負荷をシフトすることです。

データベースのパフォーマンス メトリックを監視する

Azure portal では、データベースのパフォーマンスを監視するために使用できる さまざまなメトリックにアクセスできます。 たとえば、フレキシブル サーバーで使用されている CPU 使用率を視覚化できます。

CPU 使用率を示すメトリックのスクリーンショット。

CPU 使用率が 100% に近付くと、データベースのパフォーマンスが大幅に低下します。 そのため、フレキシブル サーバーの CPU 使用率が一貫して 50% を超える場合は、コンピューティング サイズを増やすことを検討してください。

パフォーマンス メトリックは、監視概要ブックで表示することができます。 概要ブックにアクセスするには、次の手順を行います。

  1. Azure portal の左側のペインで、[Azure Database for MySQL フレキシブル サーバー インスタンスの監視] の下にある [ブック] を選択します。

    ブックの一覧が表示されている監視セクションのスクリーンショット。

  2. [概要] ブックを選択します。 次のスクリーンショットのように、接続、CPU とメモリの使用量、その他のメトリックを示すグラフが表示されます。

    監視概要ブックのスクリーンショット。

これらのメトリックの分析に加えて、フレキシブル サーバーの [ログ] パネルでサーバー診断を表示して、パフォーマンスに関する分析情報を得ることができます。

クエリ セレクターが表示されている [ログ] パネルのスクリーンショット。

これらのメトリックとログに加えて、低速クエリ ログを監視して、長時間実行されるクエリに関する詳細をキャプチャすることもできます。 この情報により、最適化に向けて、既存の低速クエリを明らかにすることができます。また、将来のクエリ パフォーマンスの低下を軽減するために、アラートを設定して、低下を即座に検出できるようにすることもできます。

低速クエリ ログ機能を有効にするには、お使いのフレキシブル サーバーに関連付けられているページで、[サーバー ログ] を選択し、[有効] と [低速クエリ ログ] のチェック ボックスをオンにします。

低速クエリ サーバー ログを有効にするための Azure portal ページのスクリーンショット。

低速クエリ ログを有効にすると、ログ分析や視覚化ブックを使用してクエリ パフォーマンスに関する分析情報を表示できます。 クエリ パフォーマンス分析情報にアクセスするには、上記と同じ手順に従います。ただし、[概要] ではなく [クエリ パフォーマンス分析情報] を選択します。

次のスクリーンショットに示すように、最も長い上位 5 つのクエリや低速クエリの概要など、さまざまな視覚化が表示されます。

最も長い上位 5 つのクエリと低速クエリの概要のスクリーンショット。

サーバーのパフォーマンス パラメーターを調整する

監視に基づいてパフォーマンスを最適化するように MySQL サーバーのパラメーターを構成できます。 たとえば、innodb_buffer_pool_size の値を増加すると、より多くのテーブル データをメモリ内に保持し、ディスク読み取り回数を節約できます。 innodb_log_file_size を増加すると、バッファ プールのチェックポイント フラッシュ アクティビティを削減できますが、クラッシュ回復は遅くなります。

アプリケーション接続がキューに登録されており、サーバーの負荷が許容できる場合は、最大接続数を増加して並列処理を増やすことができます。

サーバーのパラメーターを変更するには、MySQL フレキシブル サーバーの Azure portal にアクセスし、[サーバー パラメーター] セクションに移動します。 検索バーにパラメーター名を入力するか、[上位] または [すべて] のサポートされているサーバー パラメーターを参照します。

自動スケーリング IOPS 機能を調べて有効にする

Azure Database for MySQL には、ディスク IO 容量を割り当てるために、事前プロビジョニングされた IOPS と "自動スケーリング" IOPS (1 秒あたりの I/O 操作数) の 2 つの方法が用意されています。

事前プロビジョニングされた IOPS は、データベースの読み込みが予測可能であり、スパイクが発生しない場合に適している可能性があります。 サーバーは、プロビジョニングされた基本数の IOPS を取得します。必要に応じて、[コンピューティングとストレージ] に移動し、追加の IOPS (最大コンピューティング サイズまで) を割り当てることができます。

事前プロビジョニングされた IOPS を追加するための設定パネルのスクリーンショット。

スパイクが発生した場合、I/O 操作が割り当てられている値を超えると、サーバーのパフォーマンスは一時的に低下する可能性があります。 ただし、容量とコストは予測可能です。

自動スケーリング IOPS 機能は、予測できない、スパイクが多い、または増大するデータベース トラフィック向けに構築されています。 この機能を有効にすると、IOPS は動的にスケーリングされるため、ワークフローの変動に応じてコストまたはパフォーマンスを最適化するために手動で調整する必要はありません。 その結果、自動スケーリング IOPS 機能を使用すると、予期していないワークロードのスパイクが透過的に処理され、消費された操作に対してのみ料金を支払い、未使用の容量に対しては料金が発生しません。

既存の MySQL フレキシブル サーバーについては、Azure portal で [コンピューティングとストレージ] を選択して、自動スケーリング IOPS 機能を有効にすることができます。

IOPS を自動スケーリングするための作成オプションのスクリーンショット。

Note

また、サーバーの作成時に自動スケーリング IOPS 機能を有効にすることもできます。

IOPS を監視する

IOPS を監視すると、インスタンスが、事前にプロビジョニングされた IOPS を使用している場合は最大 IOPS に、または Autoscale IOPS 機能を使用している場合はコンピューティング サイズの最大値に、どの程度近いかを判断できます。

IOPS パフォーマンスを監視するには、[監視] セクションの [メトリック] ブレードに移動します。また、IOPS パフォーマンスを他の一般的なメトリックと共に表示するには、[概要] ブレードに移動します。

[概要] ブレードの [監視] のスクリーンショット。

WingTip Toys では、マーケティング キャンペーンのロールアウト時に予期しない時間にトラフィックが大幅に増加することが予想されるため、受注に対応できなくなるリスクを回避したいと考えています。 また、実際に必要ない場合は、最大容量に対する支払いを回避したいとも考えています。 必要に応じて IOPS を手動で追加する必要がある事前プロビジョニングされた IOPS ではなく、自動スケーリング IOPS 機能を使用することを選択します。 このアプローチは、費用対効果とスケーラビリティのバランスをオンデマンドで調整します。

読み取りレプリカをプロビジョニングする

読み取りレプリカをプロビジョニングして、読み取り専用クエリを別のデータベースにオフロードし、主要アプリケーション データベースの負荷を軽減します。

読み取りレプリカをプロビジョニングするには、Azure portal のフレキシブル サーバーに関連付けられたページで、[レプリケーション]、[レプリカの追加] の順に選択します。

[レプリカの追加] ボタンのスクリーンショット。

読み取りレプリカを作成したら、レプリカ サーバー名とそのコンピューティングおよびストレージ設定を構成できます。 認証などの一部の設定はプライマリ サーバーから継承されるため、変更できません。

レプリカの追加のスクリーンショット。

Wingtip Toys では、データ サイエンス チームとレポート ツールが読み取りレプリカ サーバーに対してクエリを実行できるようになり、主要アプリケーション データベースの負荷が軽減され、分析を抑制したり、クエリを営業時間外に制限したりする必要がなくなりました。