Table of Contents
Great systems are not just built. They are monitored.
MetricFire runs Graphite and Grafana as a fully managed service for growing engineering teams, taking care of storage, scaling, and version updates so your team doesn't have to. Plans start at $19/month, billed per metric namespace rather than per host, and include engineer-staffed support. Integrations work natively with Heroku, AWS, Azure, and GCP, and data is stored with 3× redundancy in SOC2- and ISO:27001-certified data centres.
目次
- はじめに
- 主なポイント
- 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のセールスポイントの１つとして、高性能なデータベースシステムが挙げられます。
MySQL の概要
公式の MySQL リファレンスマニュアルでは、MySQL は高速で安定したマルチユーザ、マルチスレッドのオープンソース RDBMS（リレーショナルデータベース管理システム）と説明されています。1995年にリリースされ、現在は無料で利用できる MySQL Community Server と商用版の MySQL Enterprise Edition の２つのエディションがあります。
また、MySQLは、柔軟なアーキテクチャ（オープンソース、マルチスレッド、プラグイン可能なストレージエンジン）、ANSI SQL 標準との互換性、高可用性およびレプリケーション（ビルトインレプリケーションエンジン、グローバルトランザクション ID、シャーディングなど）、OLTP およびトランザクション（ACID 準拠、参照整合性、行レベルロックなど）、データベースセキュリティ、高性能などの重要な機能に対応しています。
このような機能により、MySQL は、分散処理に依存するアプリケーション、Web サイト、速やかな出荷が必要な Web アプリケーション、オンデマンドで迅速なスケーリングが必要なシステムにとって理想的なデータベースバックエンドとなっています。企業向けアプリケーションでデータアクセスが必要な場合、DreamFactory のような自己ホスト型 API プラットフォームを使用すると、MySQL や他のデータソースへのセキュアな REST API インターフェースを通じた統制されたデータアクセスを実現できます。
データベースのパフォーマンスに影響する MySQL の機能
PostgreSQL のようなフル機能のリレーショナルデータベースと比べて、MySQL には比較的軽量な機能セットが備わっているので、より優れた速度と信頼性を実現できます。
MySQL の技術仕様には、データベースのパフォーマンスを左右する以下の項目が含まれています：
- リソースグループ（スレッドの割り当てとリソースの割り当てに使用）
- パーティショニング
- 高い同時実行性に最適化
- 読み取り専用に最適化
- SSDに最適化
- 複数のインデックスタイプ（Bツリー、Rツリー、ハッシュ、フルテキストなど）
- サーバー側スレッドプール
- 接続スレッドキャッシング
- 診断とSQLトレース
- パフォーマンススキーマとシステムスキーマ
このようなパフォーマンス重視の機能が内蔵されているため、MySQL は、他の RDBMS オプションが新しいベンチマークテストで MySQL のパフォーマンスに匹敵し始めた現在でも、速くて信頼性の高いデータベースソリューションとして高い評価を得ています。
MySQL パフォーマンスの監視を行う理由
データベースは、アプリケーションスタックの重要なレイヤーを形成し、そのレイヤーの上に構築されるアプリや Web サイトは、どれもデータベースの性能に左右されます。
データベースのパフォーマンスを監視することで、アプリケーションで起こりうる問題がエンドユーザーに影響を及ぼす前に、先手を打って対処することができますが、データモニタリングで問題の予防と修正ができるだけでなく、以下のようなこともできます：
- データベース最適化の機会の特定（最適でないクエリの書き換えなど）
- 変更の影響の判断（データ移行、スキーマ定義の変更、構成の変更、新機能の出荷など）。
- 実際の要件に応じたサーバーとコンピュートリソースのプロビジョニング（水平スケーリング）
- 潜在的なセキュリティの脆弱性の特定と、適切なセキュリティ対策の適用。
- UX（ユーザーエクスペリエンス）の成長と改善のための領域の発見
つまり、MySQL のパフォーマンス監視は、データベースそのものだけでなく、アプリや Web サイトのすべての重要なレベルが対象になります。
MySQL データベースの主なパフォーマンスのメトリクス
MySQL のさまざまなパフォーマンスのメトリクスを追跡する前に、まずデータベースのパフォーマンスを測るとはどういうことかにについて見てみましょう。結局のところ、メトリクスを監視する際に、特定のアクティビティの測定とその測定値の記録を本質的には行います。
MySQL データベースパフォーマンスの測定
一般に、データベースのパフォーマンス メトリクスは、主に「ワークロード 」と「リソース」の２つのメトリクスのタイプに大別されます。ワークロードメトリクスは、特定の期間にデータベースが生成できる作業量または出力量を測って、データベースの全体的なパフォーマンスを測定します。一方、リソースメトリクスは、データベースが機能するのに消費するハードウェア、ソフトウェア、およびネットワークのリソースの量を測定します。
また、ワークロードとリソースのメトリクスは、さらにさまざまなパフォーマンス サブカテゴリで構成され、大抵のユース ケースで最も重要なカテゴリとしては以下が挙げられます：
- スループット：特定の時間間隔でデータベースが実行する作業量を測定するワークロード メトリクス（クエリ、トランザクション、読み取り、書き込みの数など）
- レイテンシ（実行時間）：データベースが特定の作業単位を実行するのにかかる時間を測定するワークロードメトリクス（クエリの実行時間など）
- 接続（同時実行）：同時に実行され、時間内に完了できないクエリの数を示すリソース メトリクス（接続されたスレッドの数、実行中のスレッドの数、中止された接続の数など）
- バッファ（使用率）：バッファ（キャッシュ）の使用率を測定するリソース メトリクス（例：バッファプールの使用率）
また後ほど、各カテゴリで監視する重要な統計をいくつか見ていきます。
MySQL パフォーマンスメトリクスの検索
MySQL パフォーマンス監視メトリクスは、サーバーステータス変数、sys スキーマ、パフォーマンススキーマの３つの異なる場所からクエリできます。
- サーバー ステータス変数：MySQL が操作に関する情報を提供するのに維持する内部「カウンター」であり、その変数には、Questions、Slow_queries、Threads_running、Com_select などがある（サーバー ステータス変数の完全なリストについては、こちらを参照）。
- パフォーマンス スキーマ：MySQL Server イベントとクエリ実行の監視のための MySQL 機能であり、パフォーマンス メトリックは、events_statements_summary_by_digest テーブルなどの performance_schema データベース内の１つ以上のテーブルをクエリすることによって取得される。
- Sys スキーマ：MySQL sys スキーマで、パフォーマンス スキーマが使いやすくなる（パフォーマンス スキーマは、テーブルが数十個あるため、操作が面倒になることがある）。また、スキーマには、パフォーマンス スキーマによって集められたデータを分析しやすくするビュー、関数、およびプロシージャが含まれる。
この３つの機能の使用例については、また後ほど見ていきます。
監視するパフォーマンスメトリクスの選択
MySQL データベースで監視できるパフォーマンス メトクスは数百もある可能性がありますが、どの統計に注目すべきでしょうか。ユースケースによって異なる場合がありますが、主なデータベースパフォーマンスカテゴリごとに追跡すべき重要なメトリクスとしては以下の４つが挙げられます：
- スループット：- 質問：サーバーによって実行されるクライアント開始ステートメントの数
- クエリ：サーバーによって実行されたステートメントの数（クライアントが送ったステートメントとストアドプロシージャで実行されたステートメントの両方を含む）
- Com_select：実行された SELECT文 の数をカウントし、読み取り専用アクティビティのレベルを示す。
- Com_insert、Com_update、Com_delete：書き込み操作のレベルを示し、通常は１つの変数にまとめられる。
- レイテンシ：
- 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
