View a markdown version of this page

クエリワークロードの調整 - AWS 規範ガイダンス
ワークロード内の問題のあるクエリの追跡と調整

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

クエリワークロードの調整

ワークロードを適切に調整すれば、急激な成長に対処するための安定したソリューションを手に入れるのに大いに役立ちますす。ワークロードを適切に調整していないと、使用する Amazon Aurora クラスターにどれほどの性能があっても、パフォーマンスを下げたりアプリケーションのユーザーエクスペリエンスに影響を与えたりするボトルネックが生じる可能性があります。ベストプラクティスは、システム内の問題のあるクエリを特定して調整するのに役立つプロセスを、最初から用意しておくことです。

ワークロード内の問題のあるクエリの追跡と調整

急激な成長に遭遇したときは、ワークロードを適切に調整すれば問題を解決したも同然になります。Aurora クラスターが直面している、ワークロードとパフォーマンスに関するリアルタイムの問題の性質を把握するには、チームでライターインスタンスとリーダーインスタンスの両方から問題のあるクエリを収集します。このような問題のあるクエリは、ワークロードが最適な状態で実行されるように調整する必要があります。Amazon Aurora MySQL 互換エディションには、そのための 2 つの方法が用意されています。

  • Performance Insights

  • スロークエリログ

Performance Insights の使用

Performance Insights は、平均アクティブセッション (AAS) に基づいて Aurora ライターインスタンスまたはリーダーインスタンスの負荷を追跡します。AAS の値は、サンプリングと、CPU がクエリのワークロードを取得し処理するのを待機しているアクティブなセッションの数とを使用して計算されます。Performance Insights のグラフィカルインターフェイスでは、アクティブなセッションを待機しているために最も高い負荷を引き起こしている SQL ステートメントを確認できます。

Peformance Insights のグラフと図表

上記のスクリーンショットでは、ストアドプロシージャ my_sqrt の呼び出しのため平均 13.03 のセッションが自らの負荷が処理されるのを待機しています。論理的な次のステップでこの手順を調整します。リーダーとライターで、それぞれのインスタンスに負荷をかけている SQL ステートメントを特定し、AAS 値が低下して Performance Insights の点線 Max vCPU を下回るまで、パフォーマンスが改善するように調整します。調整作業が上限に達したにもかかわらず、AAS が依然 Max vCPU の点線を上回っている場合は、より大きなインスタンスクラスを選択してワークロードに対処します。クエリのワークロードの調整を試みる前からより大きなインスタンスを選択することはしません。トラフィックが増えると、ワークロード内の質の悪いクエリによって生成された断層線が露出し始めるためです。

スロークエリログの使用と CloudWatch へのパブリッシュ

スロークエリログは、MySQL のネイティブな機能であり、Performance Insights を補完する機能です。そのベストプラクティスは、これらの方法を両方とも使用して、インスタンスに損害をもたらす可能性のある問題のあるクエリを未然に防ぐことです。スロークエリログには、動的変数 long_query_time よりも遅いクエリがすべて記録されます。この変数は、クラスターインスタンスを再起動することなく設定できます。

調整を柔軟に行い、その作業を隔離するため、ライターインスタンスとリーダーインスタンスには個別のパラメータグループを使用します。このことは、読み取り/書き込みの分割を使用する場合に特に重要になります。必要に応じてクラスターインスタンスの long_query_time に十分な上限を設定します。負荷を調整するときは、しきい値をミリ秒単位で設定できるため、long_query_time 変数に積極的な値を設定できます。同時実行性が高くワークロードが適切に調整されていれば、ほぼすべてのクエリは数ミリ秒で実行されるはずです。

Amazon Aurora MySQL 互換エディションを、スロークエリをファイルに記録するよう設定すると、Aurora MySQL 互換がスロークエリログを Aurora MySQL 互換ファイルシステムに書き込んでこれを 24 時間保持します。分析のためにスロークエリログを長期間保持するには、Amazon CloudWatch にパブリッシュします。また、CloudWatch ダッシュボードを作成してスロークエリをモニタリングすることもできます。詳細については、ブログ記事「Creating an Amazon CloudWatch dashboard to monitor Amazon RDS and Amazon Aurora MySQL」を参照してください。Amazon CloudWatch にあるスロークエリを分析するだけでなく、Percona Toolkit のツールである pt-query-digest を使用するとスロークエリログをプロファイリングできます。

さらに、クエリのダウンロードとプロファイリングのプロセスを自動化してチームの効率を高めることもできます。頻繁に実行されているクエリや長い間隔を空けて実行されているクエリをチェックして、調整の優先順位を決めるとよいでしょう。スロークエリログに記録されるクエリの数がほとんどない状態を目指すことで、long_query_time を減らし、ワークロードを把握して調整する間にさらに積極的な値を目指すことができます。