Table of Contents
目次
- はじめに
- 主なポイント
- MySQL パフォーマンスについて
- MySQL の概要
- データベースのパフォーマンスに影響する MySQL の機能
- MySQL パフォーマンスの監視を行う理由
- MySQL データベースの主なパフォーマンスのメトリクス
- MySQLデータベースパフォーマンスの測定
- MySQL パフォーマンスメトリクスの検索
- 監視するパフォーマンスメトリクスの選択
- MySQL パフォーマンスメトリクスの収集と監視
- サーバステータス変数
- パフォーマンススキーマ
- Sys スキーマ
- フル機能の監視ツール
- まとめ
はじめに
Stack Overflow Developer Survey 2022 の結果によると、回答者の約半数である46%が MySQL を使っていると回答しており、現在デベロッパーの間で最も広く採用されているデータベース技術となっています。この人気の大きな理由は、小規模なソフトウェア プロジェクトからビジネスに欠かせないシステムまで、最新のアプリケーションのニーズに簡単に対応できる MySQL の独自の機能にあります。
ユースケースがますます複雑になり、消費するデータ量が増えるにつれて、MySQL データベースを管理する上で、パフォーマンスの監視はより重要な役割を果たします。そしてパフォーマンスを常に監視することで、MySQL が提供する高度な柔軟性、スケーラビリティ、可用性、信頼性、およびセキュリティをアプリケーションで最大限に活用できるようになります。
そこで本記事では、MySQL パフォーマンス監視の詳しいご紹介とガイドを提供し、MySQL データベースの監視に関する主な概念、追跡すべき重要なパフォーマンスのメトリクス、効果的な監視戦略に含めるべき手順やツールについて見ていきます。
MetricFire のようなツールで、MySQL のパフォーマンス監視はよりシンプルで効率的になります。MetricFire は、MySQL データベースのパフォーマンスを追跡するのに理想的な、フル機能の監視および観測プラットフォームであり、MetricFire を使うと、時系列メトリクスを自分で管理や保存をする必要がなくなります。その代わりに、MetricFire がホストされたタイムスケールデータベースにパフォーマンスデータを取り込んで、それを使ってカスタマイズ可能なレポートやダッシュボードを生成してくれます。
こちらの簡単なデモをご覧になるか、こちらから無料トライアルにサインアップして、MetricFire が MySQL 監視プロセスをどのように改善するのかぜひご覧ください。
主なポイント
- MySQL は、その最新のアプリケーションのニーズを満たす独自の機能により、デベロッパーの間で最も広く採用されているデータベース技術であり、回答者の46% が MySQL を使用している。
- MySQL は、その速度、信頼性、および ANSI SQL 標準との互換性で知られており、さまざまなアプリケーション、特に分散操作と迅速なスケーラビリティが必要なアプリケーションに最適。
- MySQL には、リソースグループ、パーティショニング、高い同時実行最適化、サーバサイドスレッドプールなどの機能があり、高速で信頼性の高いデータベースパフォーマンスに貢献している。
- MySQL のパフォーマンス監視は、アプリケーションのパフォーマンスの確保やデータベース運用の最適化、セキュリティの脆弱性、成長機会、改善領域の特定に非常に重要。
- 効果的な MySQL 監視戦略には、特定の要件を満たし、効率的なデータベースパフォーマンスを確保するのに、適切な監視ツールの選択が含まれるべき
MySQL パフォーマンスについて
MySQL は、今日の多くの Web、モバイル、デスクトップ、クラウドアプリケーションのバックボーンとして機能しており、当初から速度と信頼性に重点を置いて構築されました。なので、MySQLのセールスポイントの1つとして、高性能なデータベースシステムが挙げられます。
MySQL の概要
公式の MySQL リファレンスマニュアルでは、MySQL は高速で安定したマルチユーザ、マルチスレッドのオープンソース RDBMS(リレーショナルデータベース管理システム)と説明されています。1995年にリリースされ、現在は無料で利用できる MySQL Community Server と商用版の MySQL Enterprise Edition の2つのエディションがあります。
また、MySQLは、柔軟なアーキテクチャ(オープンソース、マルチスレッド、プラグイン可能なストレージエンジン)、ANSI SQL 標準との互換性、高可用性およびレプリケーション(ビルトインレプリケーションエンジン、グローバルトランザクション ID、シャーディングなど)、OLTP およびトランザクション(ACID 準拠、参照整合性、行レベルロックなど)、データベースセキュリティ、高性能などの重要な機能に対応しています。
このような機能により、MySQL は、分散処理に依存するアプリケーション、Web サイト、速やかな出荷が必要な Web アプリケーション、オンデマンドで迅速なスケーリングが必要なシステムにとって理想的なデータベースバックエンドとなっています。
データベースのパフォーマンスに影響する MySQL の機能
PostgreSQL のようなフル機能のリレーショナルデータベースと比べて、MySQL には比較的軽量な機能セットが備わっているので、より優れた速度と信頼性を実現できます。
MySQL の技術仕様には、データベースのパフォーマンスを左右する以下の項目が含まれています:
- リソースグループ(スレッドの割り当てとリソースの割り当てに使用)
- パーティショニング
- 高い同時実行性に最適化
- 読み取り専用に最適化
- SSDに最適化
- 複数のインデックスタイプ(Bツリー、Rツリー、ハッシュ、フルテキストなど)
- サーバー側スレッドプール
- 接続スレッドキャッシング
- 診断とSQLトレース
- パフォーマンススキーマとシステムスキーマ
このようなパフォーマンス重視の機能が内蔵されているため、MySQL は、他の RDBMS オプションが新しいベンチマークテストで MySQL のパフォーマンスに匹敵し始めた現在でも、速くて信頼性の高いデータベースソリューションとして高い評価を得ています。
MySQL パフォーマンスの監視を行う理由
データベースは、アプリケーションスタックの重要なレイヤーを形成し、そのレイヤーの上に構築されるアプリや Web サイトは、どれもデータベースの性能に左右されます。
データベースのパフォーマンスを監視することで、アプリケーションで起こりうる問題がエンドユーザーに影響を及ぼす前に、先手を打って対処することができますが、データモニタリングで問題の予防と修正ができるだけでなく、以下のようなこともできます:
- データベース最適化の機会の特定(最適でないクエリの書き換えなど)
- 変更の影響の判断(データ移行、スキーマ定義の変更、構成の変更、新機能の出荷など)。
- 実際の要件に応じたサーバーとコンピュートリソースのプロビジョニング(水平スケーリング)
- 潜在的なセキュリティの脆弱性の特定と、適切なセキュリティ対策の適用。
- UX(ユーザーエクスペリエンス)の成長と改善のための領域の発見
つまり、MySQL のパフォーマンス監視は、データベースそのものだけでなく、アプリや Web サイトのすべての重要なレベルが対象になります。
MySQL データベースの主なパフォーマンスのメトリクス
MySQL のさまざまなパフォーマンスのメトリクスを追跡する前に、まずデータベースのパフォーマンスを測るとはどういうことかにについて見てみましょう。結局のところ、メトリクスを監視する際に、特定のアクティビティの測定とその測定値の記録を本質的には行います。
MySQL データベースパフォーマンスの測定
一般に、データベースのパフォーマンス メトリクスは、主に「ワークロード 」と「リソース」の2つのメトリクスのタイプに大別されます。ワークロードメトリクスは、特定の期間にデータベースが生成できる作業量または出力量を測って、データベースの全体的なパフォーマンスを測定します。一方、リソースメトリクスは、データベースが機能するのに消費するハードウェア、ソフトウェア、およびネットワークのリソースの量を測定します。
また、ワークロードとリソースのメトリクスは、さらにさまざまなパフォーマンス サブカテゴリで構成され、大抵のユース ケースで最も重要なカテゴリとしては以下が挙げられます:
- スループット:特定の時間間隔でデータベースが実行する作業量を測定するワークロード メトリクス(クエリ、トランザクション、読み取り、書き込みの数など)
- レイテンシ(実行時間):データベースが特定の作業単位を実行するのにかかる時間を測定するワークロードメトリクス(クエリの実行時間など)
- 接続(同時実行):同時に実行され、時間内に完了できないクエリの数を示すリソース メトリクス(接続されたスレッドの数、実行中のスレッドの数、中止された接続の数など)
- バッファ(使用率):バッファ(キャッシュ)の使用率を測定するリソース メトリクス(例:バッファプールの使用率)
また後ほど、各カテゴリで監視する重要な統計をいくつか見ていきます。
MySQL パフォーマンスメトリクスの検索
MySQL パフォーマンス監視メトリクスは、サーバーステータス変数、sys スキーマ、パフォーマンススキーマの3つの異なる場所からクエリできます。
- サーバー ステータス変数:MySQL が操作に関する情報を提供するのに維持する内部「カウンター」であり、その変数には、Questions、Slow_queries、Threads_running、Com_select などがある(サーバー ステータス変数の完全なリストについては、こちらを参照)。
- パフォーマンス スキーマ:MySQL Server イベントとクエリ実行の監視のための MySQL 機能であり、パフォーマンス メトリックは、events_statements_summary_by_digest テーブルなどの performance_schema データベース内の1つ以上のテーブルをクエリすることによって取得される。
- Sys スキーマ:MySQL sys スキーマで、パフォーマンス スキーマが使いやすくなる(パフォーマンス スキーマは、テーブルが数十個あるため、操作が面倒になることがある)。また、スキーマには、パフォーマンス スキーマによって集められたデータを分析しやすくするビュー、関数、およびプロシージャが含まれる。
この3つの機能の使用例については、また後ほど見ていきます。
監視するパフォーマンスメトリクスの選択
MySQL データベースで監視できるパフォーマンス メトクスは数百もある可能性がありますが、どの統計に注目すべきでしょうか。ユースケースによって異なる場合がありますが、主なデータベースパフォーマンスカテゴリごとに追跡すべき重要なメトリクスとしては以下の4つが挙げられます:
- スループット:- 質問:サーバーによって実行されるクライアント開始ステートメントの数
- クエリ:サーバーによって実行されたステートメントの数(クライアントが送ったステートメントとストアドプロシージャで実行されたステートメントの両方を含む)
- Com_select:実行された SELECT文 の数をカウントし、読み取り専用アクティビティのレベルを示す。
- Com_insert、Com_update、Com_delete:書き込み操作のレベルを示し、通常は1つの変数にまとめられる。
- レイテンシ:
- Slow_Queries:実行に long_query_time 秒を超えるクエリの数
- クエリ実行時間:クエリの実行にかかった時間に関する統計。パフォーマンス スキーマで利用可能
- 同時実行性:
- Aborted_connects:MySQL サーバーへの接続に失敗した回数をカウントする
- Threads_connected:現在開いている接続の数
- Threads_running:スリープしていないスレッドの数をカウントする
- バッファ:
- SHOW ENGINE INNODB STATUS ステートメントの実行から得られる統計
注:特に明記されていない限り、上記のメトリックは組み込みのビルトインのサーバーステータス変数をクエリすることで取得でき、説明も MySQL の公式ドキュメントから引用されています。
MySQL パフォーマンスメトリクスの収集と監視
前のセクションでは、MySQL データベースで監視するパフォーマンス メトリクスの種類について見てきましたが、ここでは、必要なデータを集めるためのさまざまな方法とツールについて見ていきます。
サーバステータス変数
MySQL は、サーバーステータス変数という「カウンター」を追跡していることがわかりました。サーバー ステータス変数で、MySQL の操作に関する情報を得られ、サーバー ステータス変数の合計数は、使っている MySQL サーバーのバージョンによって異なります。
この変数には、SHOW [GLOBAL | SESSION] STATUS のステートメントを使ってアクセスできます。また、GLOBAL では、ステートメントは接続すべてにわたって集計された値を返しますが、SESSION では値が現在の接続のみに制限されます。
たとえば、以下のステートメントは、全接続にわたる全サーバーステータス変数とその値を表示します:
mysql> SHOW GLOBAL STATUS;
+-------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name | Value |
+-------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Aborted_clients | 0 |
| Aborted_connects | 3 |
| Acl_cache_items_count | 0 |
| Binlog_cache_disk_use | 11 |
| Binlog_cache_use | 60 |
| Binlog_stmt_cache_disk_use | 0 |
| Binlog_stmt_cache_use | 8 |
| Bytes_received | 3843055 |
| Bytes_sent | 214977 |
...
| Threads_cached | 1 |
| Threads_connected | 3 |
| Threads_created | 4 |
| Threads_running | 2 |
| Uptime | 6086 |
| Uptime_since_flush_status | 6086 |
+-------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
463 rows in set (0.0047 sec)
以下の方法で単一のサーバーステータス変数を表示することもできます:
mysql> SHOW STATUS LIKE '%Com_select%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Com_select | 10 |
+---------------+-------+
1 row in set (0.0130 sec)
前のセクションでは、Questions、Queries、Com_insert、Com_update などの重要なサーバーステータス変数について説明しましたが、利用できる変数の完全なリストについては、MySQL Server のバージョンのドキュメントでご確認ください。
パフォーマンススキーマ
MySQL のパフォーマンス スキーマは、個々のクエリレベルでサーバーの実行を監視し、パフォーマンス スキーマに対応している MySQL サーバーでは、通常の SELECT ステートメントでクエリできるテーブルを含む performance_schema というデータベースとして使用できます。そしてパフォーマンス スキーマのクエリを開始する前に、まずパフォーマンス スキーマが適切にインストールされて有効になっていることを確認する必要があります。
performance_schema データベースは、現在のイベント、イベント履歴と概要、オブジェクト インスタンス、セットアップ(設定)情報など、格納されている情報の種類に基づいてテーブルをグループ化します。そして performance_schema で利用できるテーブルをすべて表示するには、以下のステートメントを実行します:
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'performance_schema';
+------------------------------------------------------+
| TABLE_NAME |
+------------------------------------------------------+
| accounts |
| cond_instances |
| data_lock_waits |
| data_locks |
| events_errors_summary_by_account_by_error |
| events_errors_summary_by_host_by_error |
| events_errors_summary_by_thread_by_error |
...
| table_handles |
| table_io_waits_summary_by_index_usage |
| table_io_waits_summary_by_table |
| table_lock_waits_summary_by_table |
| threads |
| user_defined_functions |
| user_variables_by_thread |
| users |
| variables_by_thread |
| variables_info |
+------------------------------------------------------+
103 rows in set (0.1040 sec)
先ほど、主なパフォーマンス統計は、performance_schema データベース内のいくつかのテーブル、具体的には events_statements_summary_by_digest テーブルをクエリすることで見つかるということについてお話しました。
以下のステートメントは、実行時間が最も長いクエリを返します。
mysql> SELECT digest_text, avg_timer_wait
FROM performance_schema.events_statements_summary_by_digest
ORDER BY avg_timer_wait DESC
LIMIT 1;
+-----------------------------------------------+----------------+
| digest_text | avg_timer_wait |
+-----------------------------------------------+----------------+
| INSERT INTO `rental` VALUES (...) /* , ... */ | 407201600000 |
+-----------------------------------------------+----------------+
1 row in set (0.0052 sec)
注:USE performance_schema を使って performance_schema を現在のデータベースとして設定することで、上記のステートメントで performance_schema スキーマ名を使わないようにできます。
Sys スキーマ
上記の非常に単純な例でも、より複雑なユースケースではパフォーマンス スキーマのクエリが面倒になるのは容易に想像できます。なので、MySQL ではバージョン 5.7.7 から sys スキーマが機能として導入されました。
sys スキーマには、performance_schema データベーステーブルに含まれる情報に簡単にアクセスできるようにするビュー、ストアド プロシージャ、およびストアド関数が備わっています。
公式の sys schema ドキュメントの例を使って、ホストごとにグループ化されたファイル I/O を要約し、レイテンシのより読みやすい値を表示する host_summary_by_file_io ビューでこれが実際にどのように機能するかを確認します:
mysql> SELECT * FROM sys.host_summary_by_file_io;
+------------+-------+------------+
| host | ios | io_latency |
+------------+-------+------------+
| background | 12167 | 1.48 s |
| localhost | 1694 | 427.99 ms |
+------------+-------+------------+
2 rows in set (0.0049 sec)
MySQL Workbench
MySQL でも対応しているデータベース パフォーマンスを探索および調査するためのより便利な方法として、Workbench GUI の使用があり、MySQL Workbench で、MySQL データベースを視覚的に設計、管理、および監視する方法を得られます。
MySQL Workbench では、高レベルの統計情報を表示するビルトインのダッシュボードに加えて、sys スキーマに含まれるパフォーマンス メトクスをサッとドリルダウンすることもできます。
フル機能の監視ツール
MySQL が標準で提供する監視機能は、簡単な1回限りのチェックには適していますが、運用データベースを継続的にリアルタイムで監視する必要がある場合、これらのビルトイン機能と基本機能だけでは不十分です。
ここでは、フル機能のデータベース監視ツールを使う必要があります。こういったプラットフォームは MySQL と統合されており、パフォーマンス メトリクスの収集、保存、取得を管理するので、以下のことができるようになります。
- データベースリソースがアプリケーションの処理のみに集中できるように、パフォーマンスデータの監視と保存のタスクを外部サービスにオフロードする。
- さまざまな粒度レベルでデータベースのパフォーマンスを分析および視覚化する。
- さまざまなイベントやトリガーに対してアラートと通知を設定する。
- 大量生産環境でもパフォーマンスを継続的に追跡する。
MetricFire は、データベースのパフォーマンスをリアルタイムで継続的に追跡することができる、強固でフル機能の監視プラットフォームの一例であり、外部ツールとしてセットアップが簡単で、MySQL サーバーと統合できます。また、プラグインすると、MetricFire が時系列データの収集と保存の作業を実行することから、カスタム視覚化/レポート、プロアクティブなアラート、および完全に管理されたサポートを得られます。
MySQL の監視をシンプルにする MetricFire の重要な機能の1つに、Hosted Graphite Agent(HG-Agent)のすぐに使えるサポートがあります。Hosted Graphite Agent は、Diamond メトリック収集ツールと Supervisor プロセス マネージャー上に構築された監視アプリケーションであり、起動して実行するには簡単なインストールプロセスしか必要でなく、追加の構成やセットアップなしで、実行中のサーバーを自動的に監視します。そして HG-Agent はインストールされると、 システム メトリクスを集めて Hosted Graphite に公開し、そこで時系列データが保存、処理、視覚化されます。また、MetricFire の Hosted Graphite Agent クライアントを使うと、HG-Agent のインストールとセットアップがさらに早くなります。
こちらからデモを予約するか、MetricFire の無料トライアルでぜひご体験ください。
まとめ
本記事では、MySQL データベースを効果的に監視するために押さえておく必要のある重要な事項について見てきました。そして、MySQL を速くて信頼性の高い RDBMS にする機能、MySQL でデータベース パフォーマンスを測定する方法、追跡するパフォーマンス メトリック、パフォーマンスを監視するためのさまざまな機能とツールの使用方法がわかりました。
これらの概念を念頭に置けば、堅実な監視戦略をまとめる準備はバッチリです。そして自身の計画には、要件を満たす適切な監視ツールの選択が含まれるべきですが、ホストされた Graphite と Grafana をフル機能の監視プラットフォームに組み合わせることで、MetricFire は MySQL 監視のニーズにピッタリなツールになります。こちらからデモを予約して詳細を確認するか、こちらから無料トライアルにサインアップして早速 MetricFire を始めてみましょう。