次の方法で共有

Azure Database for MySQL を使用してアプリケーションを構築するためのベスト プラクティス

  • [アーティクル]

適用対象: Azure Database for MySQL - 単一サーバー Azure Database for MySQL - フレキシブル サーバー

重要

Azure Database for MySQL シングル サーバーは廃止パスにあります。 Azure Database for MySQL フレキシブル サーバーにアップグレードすることを強くお勧めします。 Azure Database for MySQL フレキシブル サーバーへの移行の詳細については、Azure Database for MySQL シングル サーバーの現状に関するページを参照してください

ここでは、Azure Database for MySQL を使用したクラウド対応アプリケーションを構築する際に役立つベスト プラクティスをいくつか紹介します。 これらのベスト プラクティスにより、アプリの開発時間を短縮できます。

アプリケーションとデータベースのリソースの構成

同一リージョン内にアプリケーションとデータベースを維持する

アプリケーションを Azure にデプロイするときに、すべての依存関係が同一のリージョン内にあることを確認します。 リージョン間または可用性ゾーン間にインスタンスを分散すると、ネットワーク待機時間が発生し、アプリケーションの全体的なパフォーマンスに影響を及ぼす可能性があります。

MySQL サーバーの安全を維持する

MySQL サーバーを、セキュリティで保護してパブリック アクセスできないように構成します。 サーバーをセキュリティで保護するには、次のいずれかのオプションを使用します。

セキュリティ確保のために、必ず、MySQL サーバーを SSL 経由で接続し、TLS1.2 を使用するように MySQL サーバーとアプリケーションを構成する必要があります。 SSL/TLS の構成方法に関する記事を参照してください。

AKS による高度なネットワークを使用する

VM で高速ネットワークが有効になると、待ち時間が少なくなり、ジッターが減り、VM の CPU 使用率が下がります。 詳細については、「Azure Kubernetes Service と Azure Database for MySQL を接続する」を参照してください。

サーバー パラメーターを調整する

読み取り負荷の高いワークロードのチューニングのサーバー パラメーターについては、tmp_table_size と max_heap_table_size を使用することでパフォーマンスを向上させることができます。 これらの変数に必要な値を計算するには、接続ごとの合計とベース メモリの値を調べます。 tmp_table_size を除く接続ごとのメモリ パラメーターの合計とベース メモリを組み合わせたものが、サーバーの合計メモリに相当します。

tmp_table_size と max_heap_table_size の考えられる最大サイズを計算するには、次の数式を使用します。

(total memory - (base memory + (sum of per-connection memory * # of connections)) / # of connections

Note

合計メモリは、プロビジョニングされた仮想コア全体でサーバーによって使用されるメモリの総量を示します。 たとえば、General Purpose 2 仮想コア Azure Database for MySQL サーバーでは、合計メモリは、5 GB * 2 になります。 各レベルのメモリの詳細については、価格レベルのドキュメントを参照してください。

ベース メモリは、サーバーの起動時に MySQL によって初期化され、割り当てられるメモリ変数 (query_cache_size や innodb_buffer_pool_size など) を示します。 接続ごとのメモリ (sort_buffer_size や join_buffer_size など) は、クエリで必要な場合にのみ割り当てられるメモリです。

管理者以外のユーザーを作成する

各データベースの管理者以外のユーザーを作成します。 通常、ユーザー名は、データベース名として識別されます。

パスワードをリセットする

Azure portal を使用して、MySQL サーバーのパスワードをリセットすることができます。

運用データベースのサーバー パスワードをリセットすると、アプリケーションが停止する可能性があります。 アプリケーションのユーザーに対する影響を最小限に抑えるために、ピーク時以外に運用ワークロードのパスワードをリセットすることをお勧めします。

パフォーマンスと回復性

アプリケーションのパフォーマンス問題をデバッグするために役立ついくつかのツールと手法を次に示します。

パフォーマンス問題を特定する低速クエリ ログを有効にする

サーバーで低速クエリ ログと監査ログを有効にできます。 低速クエリ ログを分析すると、トラブルシューティングの目的でパフォーマンスのボトルネックを特定するのに役立ちます。

監査ログは、Azure Monitor ログ、Azure Event Hubs、ストレージ アカウントでの Azure Diagnostics ログを通じて入手することもできます。 クエリのパフォーマンス問題をトラブルシューティングする方法に関する記事を参照してください。

接続プールの使用

データベース接続の管理が、全体としてアプリケーションのパフォーマンスに大きな影響を与える場合があります。 パフォーマンスを最適化するには、接続を確立する回数を削減し、キー コード パスで接続を確立する時間を短縮する必要があります。 回復性とパフォーマンスを向上するには、接続プールを使用して Azure Database for MySQL に接続します。

ProxySQL 接続プーラーを使用して、接続を効率的に管理できます。 接続プーラーを使用すると、アイドル状態の接続を削減でき、既存の接続を再利用することで問題を回避できます。 詳細については、ProxySQL のセットアップ方法に関する記事を参照してください。

一時的エラーを処理する再試行ロジック

アプリケーションで、データベースへの接続が断続的に切断されるか、または失われる一時的エラーが発生する可能性があります。 このような状況では、5 から 10 秒で 1、2 回再試行した後、サーバーは起動して稼働します。

最初に再試行する前に、5 秒間待つことをお勧めします。 その後、待機時間を 60 秒まで段階的に増やして、各再試行を行います。 再試行の最大回数を制限します。その時点で、アプリケーションによって操作が失敗したと見なされ、さらに調査できるようになります。 詳細については、接続エラーをトラブルシューティングする方法に関する記事を参照してください。

フェールオーバーを軽減するために読み取りレプリケーションを有効にする

フェールオーバー シナリオには、データイン レプリケーションを使用できます。 読み取りレプリカを使用している場合、ソースとレプリカのサーバー間で自動フェールオーバーは発生しません。

レプリケーションは非同期であるため、ソースとレプリカの間にラグがあります。 ネットワーク ラグは、ソース サーバーで実行されているワークロードのサイズやデータセンター間の待機時間など、さまざまな要因によって影響を受ける可能性があります。 ほとんどの場合、レプリカの遅延は数秒から数分の範囲になります。

データベースのデプロイ

CI/CD デプロイ パイプラインで MySQL タスク用に Azure データベースを構成する

場合によっては、変更をデータベースにデプロイする必要があります。 このような場合、Azure Pipelines を使用して、継続的インテグレーション (CI) および継続的デリバリー (CD) を使用でき、MySQL サーバーのタスクを使用して、データベースに対してカスタム スクリプトを実行すると、これを更新することができます。

データベースの手動デプロイに効果的なプロセスを使用する

手動でデータベースをデプロイする場合、ダウンタイムを最小限に抑えるか、デプロイが失敗するリスクを低減するために、次の手順に従ってください。

  1. mysqldump または MySQL Workbench を使用して、新しいデータベースに運用データベースのコピーを作成します。
  2. データベースに必要な新しいスキーマの変更または更新で新しいデータベースを更新します。
  3. 運用データベースを読み取り専用状態にします。 デプロイが完了するまで、運用データベースに対して書き込み操作を行わないことをお勧めします。
  4. 手順 1 で新しく更新したデータベースを使用してアプリケーションをテストします。
  5. アプリケーションの変更をデプロイし、アプリケーションが最新の更新を含む新しいデータベースを使用するようになったことを確認します。
  6. 変更をロールバックするために、古い運用データベースを保持します。 その後、古い運用データベースを削除するか、必要に応じて Azure Storage にエクスポートするかを評価できます。

Note

アプリケーションが e コマース アプリのようなもので、読み取り専用状態にできない場合、バックアップを作成した後、変更を運用データベースに直接デプロイします。 一部のユーザーで要求の失敗が発生する可能性があるので、影響を最小限に抑えるために、これらの変更は、アプリへのトラフィックが少ないピーク時以外に行う必要があります。

アプリケーション コードで、失敗した要求も処理されることを確認してください。

MySQL ネイティブ メトリックを使用して、ワークロードがメモリ内の一時テーブルのサイズを超えているかどうかを確認する

読み取り負荷の高いワークロードの場合、MySQL サーバーに対するクエリは、メモリ内の一時テーブルのサイズを超える可能性があります。 読み取り負荷の高いワークロードにより、サーバーが、一時テーブルをディスクに書き込むように切り替えられ、アプリケーションのパフォーマンスに影響を与える可能性があります。 一時テーブルのサイズを超えた結果としてサーバーがディスクに書き込んでいるかどうかを判断するには、次のメトリックを調べます。

show global status like 'created_tmp_disk_tables';
show global status like 'created_tmp_tables';

created_tmp_disk_tables メトリックは、ディスク上に作成されたテーブルの数を示します。 ワークロードが与えられたときに、created_tmp_table メトリックは、メモリ内に形成する必要がある一時テーブルの数を示します。 特定のクエリで一時テーブルを使用するかどうかを判断するには、クエリで EXPLAIN ステートメントを実行します。 一時テーブルを使用してクエリが実行される場合、extra 列の詳細には、Using temporary が示されます。

クエリがディスクへの書き込みを行うワークロードの割合を計算するには、次の数式でメトリック値を使用します。

(created_tmp_disk_tables / (created_tmp_disk_tables + created_tmp_tables)) * 100

理想的には、この割合は 25% 未満である必要があります。 割合が 25% 以上の場合、tmp_table_size と max_heap_table_size の 2 つのサーバー パラメーターを変更することをお勧めします。

データベース スキーマとクエリ

データベース スキーマとクエリを構築するときに覚えておくべきいくつかのヒントを示します。

テーブル列に適したデータ型を使用する

格納するデータの種類に基づいて適切なデータ型を使用すると、ストレージを最適化し、不正なデータ型が原因のエラーを削減することができます。

インデックスを使用する

クエリの速度の低下を回避するには、インデックスを使用します。 インデックスを使用すると、特定の列を含む行をすばやく見つけることができます。 MySQL でのインデックスの使用方法に関する記事を参照してください。

SELECT クエリに EXPLAIN を使用する

クエリを実行するための MySQL の実行内容について分析情報を取得するには、EXPLAIN ステートメントを使用します。 これは、クエリのボトルネックまたは問題を検出するのに役立ちます。 EXPLAIN を使用してクエリのパフォーマンスをプロファイリングする方法に関する記事を参照してください。