Aurora MySQL データベースのワークロードに関する問題のトラブルシューティング - Amazon Aurora
インスタンスホストｘメトリクスデータベースメトリクス

Aurora MySQL データベースのワークロードに関する問題のトラブルシューティング

データベースワークロードは読み取りおよび書き込みとして見なすことができます。「通常の」データベースワークロードを理解していれば、需要の変化に合わせてクエリとデータベースサーバーを調整できます。パフォーマンスが変化する理由は多く存在するため、最初のステップは何が変わったのかを理解することです。

  • メジャーバージョンまたはマイナーバージョンのアップグレードは行われましたか?

    メジャーバージョンアップグレードには、エンジンコード、特にオプティマイザの変更が含まれ、それによってクエリ実行プランが変更される可能性があります。データベースバージョン、特にメジャーバージョンをアップグレードするときは、データベースのワークロードを分析し、それに応じて調整することが非常に重要です。調整には、テストの結果に応じて、クエリの最適化と書き換え、またはパラメータ設定の追加と更新が含まれる場合があります。何が影響を引き起こしているのかを理解することで、その特定の分野に集中できるようになります。

    詳細については、MySQL ドキュメントの「MySQL 8.0 の新機能」と「MySQL 8.0 で追加、廃止、または削除されたサーバー変数とステータス変数とオプション」、および「Aurora MySQL バージョン 2 と Aurora MySQL バージョン 3 の比較」を参照してください。

  • 処理中のデータ (行数) は増加しましたか?

  • 同時に実行されているクエリは他にもありますか?

  • スキーマやデータベースに変更はありますか?

  • コードに欠陥や修正はありましたか?

目次

インスタンスホストｘメトリクス

CPU、メモリ、ネットワークアクティビティなどのインスタンスホストのメトリクスをモニタリングして、ワークロードが変更されたかどうかを把握します。ワークロードの変化を理解するには、主に 2 つの概念があります。

  • 使用率 — CPU やディスクなどのデバイスの使用状況。時間ベースの場合とキャパシティベースの場合があります。

    • 時間ベース — 特定の観測期間にリソースがビジー状態である時間です。

    • キャパシティベース — システムまたはコンポーネントが提供できるスループットの量 (キャパシティに対する割合)。

  • 飽和度 — リソースで処理できる量よりも多くの作業が必要となる度合い。キャパシティベースの使用率が 100% に達すると、余分な作業は処理できなくなり、キューに入れる必要があります。

CPU の使用

次のツールを使用して、CPU の使用状況と飽和度を識別できます。

  • CloudWatch が CPUUtilization メトリクスを提供します。この値が 100% に達すると、インスタンスは飽和状態になります。ただし、CloudWatch メトリクスは 1 分間で平均化され、詳細さに欠けています。

    CloudWatch のメトリクスの詳細については、「Amazon Aurora のインスタンスレベルのメトリクス」を参照してください。

  • 拡張モニタリングは、オペレーティングシステム top コマンドによって返されるメトリクスを提供します。負荷平均と次の CPU 状態が 1 秒単位で表示されます。

    • Idle (%) = アイドル時間

    • IRQ (%) = ソフトウェア割り込み

    • Nice (%) = 優先順位が niced のプロセスの良好な時間。

    • Steal (%) = 他のテナントへのサービス提供に費やした時間 (仮想化関連)

    • System (%) = システム時刻

    • User (%) = ユーザー時間

    • Wait (%) = I/O 待機

    拡張モニタリングのメトリクスの詳細については、「Aurora の OS メトリクス」を参照してください。

メモリ使用量

システムがメモリ不足に陥っていて、リソース消費が飽和状態に達しつつある場合は、ページスキャン、ページング、スワップ、メモリ不足などのエラーが頻繁に発生しているはずです。

次のツールを使用して、メモリの使用状況と飽和度を識別できます。

CloudWatch は、一部の OS キャッシュと現在の空きメモリをフラッシュすることで再利用できるメモリを示す FreeableMemory メトリクスを提供します。

CloudWatch のメトリクスの詳細については、「Amazon Aurora のインスタンスレベルのメトリクス」を参照してください。

拡張モニタリングでは、メモリ使用量の問題を特定するのに役立つ以下のメトリクスが提供されます。

  • Buffers (KB) - ストレージデバイスへの書き込み前に I/O バッファリングリクエストに使用されたメモリの量 (キロバイト単位)。

  • Cached (KB) - ファイルシステムベースの I/O のキャッシュに使用されたメモリの量。

  • Free (KB) - 未割り当てのメモリの量 (キロバイト単位)。

  • Swap - キャッシュ、フリー、および合計。

例えば、DB インスタンスが Swap メモリを使用していることがわかった場合、ワークロードの合計メモリ量は、インスタンスで現在使用可能なメモリ量よりも多くなっています。DB インスタンスのサイズを増やすか、使用するメモリ量が少なくなるようにワークロードを調整することをお勧めします。

拡張モニタリングのメトリクスの詳細については、「Aurora の OS メトリクス」を参照してください。

パフォーマンススキーマと sys スキーマを使用して、どの接続やコンポーネントがメモリを使用しているかを見極める方法の詳細については、「Aurora MySQL データベースのメモリ使用量に関する問題のトラブルシューティング」を参照してください。

ネットワークスループット

CloudWatch は、ネットワークスループットの合計について、すべて 1 分間の平均値として次のメトリクスを提供します。

  • NetworkReceiveThroughput - Aurora DB クラスター内の各インスタンスが各クライアントから受信したネットワークスループットの量。

  • NetworkTransmitThroughput - Aurora DB クラスター内の各インスタンスが各クライアントに対して送信したネットワークスループットの量。

  • NetworkThroughput - Aurora DB クラスター内の各インスタンスが各クライアントで送受信したネットワークスループットの量。

  • StorageNetworkReceiveThroughput - DB クラスター内の各インスタンスが、Aurora のストレージサブシステムから受信した、ネットワークスループットの量。

  • StorageNetworkTransmitThroughput - Aurora DB クラスター内の各インスタンスが、Aurora のストレージサブシステムに送信した、ネットワークスループットの量。

  • StorageNetworkThroughput - Aurora DB クラスター内の各インスタンスが、Aurora のストレージサブシステムとの間で送受信した、ネットワークスループットの量。

CloudWatch のメトリクスの詳細については、「Amazon Aurora のインスタンスレベルのメトリクス」を参照してください。

拡張モニタリングでは、network が受信した (RX) および送信した (TX) グラフが最大 1 秒の精度で表示されます。

拡張モニタリングのメトリクスの詳細については、「Aurora の OS メトリクス」を参照してください。

データベースメトリクス

以下の CloudWatch メトリクスを調べて、ワークロードの変化を確認します。

  • BlockedTransactions - 1 秒あたりのブロックされたデータベース内のトランザクションの平均数。

  • BufferCacheHitRatio – バッファキャッシュから提供されたリクエストの割合 (パーセント)。

  • CommitThroughput - 1 秒あたりのコミット操作の平均回数。

  • DatabaseConnections - データベースインスタンスへのクライアントネットワーク接続の数。

  • Deadlocks - 1 秒あたりのデータベース内のデッドロックの平均回数。

  • DMLThroughput - 1 秒あたりの挿入、更新、削除の平均回数。

  • ResultSetCacheHitRatio - クエリキャッシュから提供されたリクエストの割合 (パーセント)。

  • RollbackSegmentHistoryListLength - コミットされたトランザクションが削除とマークされたレコードを記録する UNDO ログ。

  • RowLockTime - InnoDB テーブルのローロックの取得にかかった合計時間。

  • SelectThroughput - 1 秒あたりの選択クエリの平均回数。

CloudWatch のメトリクスの詳細については、「Amazon Aurora のインスタンスレベルのメトリクス」を参照してください。

ワークロードを調べる際には、以下の点を考慮してください。

  1. DB インスタンスクラスに最近変更があったか。例えば、インスタンスサイズを 8xlarge から 4xlarge に減らしたり、db.r5 から db.r6 に変更したりしたか？

  2. クローンを作成して問題を再現できますか? それとも 1 つのインスタンスでのみ発生していますか?

  3. サーバーリソースの消耗、CPU 使用率の上昇、またはメモリの消耗は発生していますか? 「はい」の場合は、ハードウェアの追加が必要な場合があります。

  4. 1 つまたは複数のクエリに時間がかかりますか?

  5. 変化の原因はアップグレード、特にメジャーバージョンアップグレードですか? 「はい」の場合は、アップグレード前とアップグレード後のメトリクスを比較してください。

  6. リーダー DB インスタンスの数に変更はありますか?

  7. 一般ロギング、監査ロギング、またはバイナリロギングを有効にしましたか? 詳細については、「Aurora MySQL データベースのログ記録」を参照してください。

  8. バイナリログ (binlog) レプリケーションの使用を有効化、無効化、または変更しましたか?

  9. 長時間実行されるトランザクションで、多数の行ロックが発生していませんか? InnoDB 履歴リストの長さ (HLL) を調べて、トランザクションが長時間実行されているかどうかを確認してください。

    詳細については、「InnoDB 履歴リストの長さが大幅に増加しました」および「Amazon Aurora MySQL DB クラスターで SELECT クエリの実行が遅いのはなぜですか?」というブログ記事を参照してください。

    1. 書き込みトランザクションが原因で HLL が大きくなっている場合は、UNDO ログが蓄積されている (定期的にクリーンアップされていない) ことを意味します。書き込みトランザクションが多いと、この蓄積が急速に増加する可能性があります。MySQL では、UNDO は SYSTEM テーブルスペースに保存されます。SYSTEM テーブルスペースは圧縮できません。UNDO ログにより、SYSTEM テーブルスペースが数 GB、さらには TB にまで増えることもあります。削除後、データの論理バックアップ (ダンプ) を作成して割り当てられたスペースを解放し、そのダンプを新しい DB インスタンスにインポートします。

    2. 読み取りトランザクション (実行時間の長いクエリ) が原因で HLL が大きくなっている場合は、クエリが大量の一時スペースを使用している可能性があります。再起動して一時スペースを解放します。Temp セクションで Performance Insights の DB メトリクスに変更 (created_tmp_tables など) がないかを調べます。詳細については、「Amazon Aurora での Performance Insights を使用したDB 負荷のモニタリング」を参照してください。

  10. 長時間実行されるトランザクションを、変更される行数が少ないより小さなトランザクションに分割できますか?

  11. ブロックされたトランザクションの変化やデッドロックの増加はありませんか? Locks セクションで Performance Insights の DB メトリクスにステータス変数の変更 (innodb_row_lock_time、 innodb_row_lock_waits、および innodb_dead_locks など) がないかを調べます。1 分または 5 分間隔を使用します。

  12. 増加した待機イベントがあるか？ Performance Insights の待機イベントと待機タイプを 1 分または 5 分間隔で調べます。上位の待機イベントを分析し、それらがワークロードの変化やデータベースの競合と相関関係があるかどうかを確認します。例えば、buf_pool mutex はバッファプールの競合を示しています。詳細については、「待機イベントを使用した Aurora MySQL のチューニング」を参照してください。