Amazon Web Services ブログ
Performance Insights を使用した Amazon RDS データベースの負荷分析
AWSは Amazon Aurora with PostgreSQL compatibility の一般リリースを先日発表しました。このリリースには Performance Insights と呼ばれる Amazon Relational Database Service (Amazon RDS) に有用な機能の最初のリリースも含まれます。データベースの負荷（どのSQL文が負荷を発生させており、それはなぜなのか）を可視化するダッシュボードを使用して、エキスパートな方とエキスパートではない方の両方が、Performance Insights でパフォーマンス問題を容易に検出できます。
軽量な方法でパフォーマンスデータを収集するため、Performance Insights はアプリケーションのパフォーマンスに影響を与えません。また、設定やメンテナンスも不要で、現在は Amazon Aurora PostgreSQL 用の無料プレビューを利用できます。AWS Management Console で作成したインスタンスでは Performance Insights はデフォルトで有効になっています。コンソールで「インスタンスの操作」メニューから「変更」を選択することで、その他のインスタンスでも有効にすることができます。または、APIメソッドのCreateDbInstanceまたはModifyDbInstanceのEnablePerformanceInsightsパラメーターを使用できます。
始めるのは簡単です。Amazon RDS コンソールにサインインし、ワンクリックで Performance Insights ダッシュボードにアクセスするだけでパフォーマンス監視を始めることができます。
Performance Insights へのアクセス
RDSコンソールから2つの方法で Performance Insights にアクセスできます。
- ダッシュボードを開くために、左側のナビゲーションパネルから Performance Insights を選び、Performance Insights が有効になったDBインスタンスのリストを表示します。
- 特定DBインスタンスの Performance Insights を開くために、DBインスタンスの「現在のアクティビティ」の下のバーを選択します。Performance Insights が有効なインスタンスでは、「セッション」として現在のアクティビティが計測されます。
Performance Insights がセッションによってデータベースの負荷を測定するのはなぜですか？
この場合のセッションとは「平均アクティブセッション」の省略であり、「AAS」と略されることもあります。アクティブセッションとは、データベースにに要求を発行したものの応答を受信していないデータベース接続のことです。同時実行されているアクティブセッションの平均数を継続的に測定すると、データベースの負荷を明確に把握できます。
DBインスタンスのリストでは、「現在のアクティビティ」列のバーに Performance Insights が有効になっている各インスタンスのデータベース負荷が表示されます。青い枠線の空の四角はアイドル状態のインスタンスを意味します。データベースの負荷が増えると、バーは青で塗りつぶされます。負荷がホストの許容量を超えると、バーは赤に変わります。
つまり、バーに赤が表示されていると、DBインスタンスが飽和していることを意味し、Performance Insights ダッシュボードを参照して原因を理解する必要があります。次の例では、Auroraインスタンスの「現在のアクティビティ」バーに赤が表示されています。これはDBインスタンスに負荷が掛かっていることを示します。「現在のアクティビティ」が「セッション」で計測されるため、このインスタンスでは Performance Insights が有効であることが分かります。バーを選択すると Performance Insights ダッシュボードが開きます。
Performance Insights のダッシュボード
ダッシュボードは2つに分けられます。
- 上部の負荷グラフは、平均アクティブセッション (AAS) 単位でのデータベース負荷の最近の履歴を表示します。
- 下部のアクティビティ表は、時間によって区切られた負荷グラフによって、データベース負荷に何が影響しているかを表示します。
デフォルトでは、負荷グラフは待機タイプごとに色分けされます。待機タイプ別にデータベース負荷を分割することで、負荷に主な影響を与えているデータベースメカニズムの種類を理解するのに役立ちます。トップアクティビティはデフォルトではSQL文を表示します。負荷に主な影響を与えているSQLを理解することは、アプリケーションのどの部分がボトルネックになっているのかを理解することに役立ちます。
アイドル状態のデータベース
完全にアイドル状態のデータベースにはアクティブなセッションがないため、負荷が掛かりません。当たり前のように聞こえるでしょうが、データベースがアイドル状態であることを知ることは問題の診断に役立ちます。たとえば、データベースがアイドル状態のときに発生するパフォーマンス上のすべての問題は、データベースが原因ではないでしょう。Performance Insights のダッシュボードによって、パフォーマンス問題がデータベース内なのか、データベース外（アプリケーション層など）なのかを簡単に判別できます。
以下はアイドル状態のデータベースの例です。
データベース負荷のボトルネックのチューニング
セッションとは、アプリケーションが利用するデータベース接続を意味するデータベース用語です。データベースに要求中の待機しているセッションは、データベース負荷に影響を与えています。セッションは多くの理由で応答を待ちます。一般的な理由の一つは、リクエストが実行中で、完了のためにCPUを使用しているからです。ただし、I/Oの完了、ロック、ストレージへの書き込み、バッファの空き領域、その他の多くの理由によっても要求は待機する可能性があります。これらの様々な待機状態は、積み上げられた色の領域として負荷グラフに表れます。これらの色は、右側の凡例に示される待機状態に対応します。負荷グラフで最も顕著な色がデータベース負荷の最大の原因です。
負荷グラフでの重要な視覚的手がかりは「最大CPU」ラインです。このラインはホスト上のvCPUの数を表します。vCPUよりも多くのアクティブセッションがCPU待機している場合、CPUの許容量を超えてインスタンスが実行されていることを意味します。負荷全体が「最大CPU」のラインを超えると、ボトルネックが発生する可能性があります。ボトルネックはCPUの飽和が原因かもしれませんし、データベース内でセッションが待機するその他の多くの理由によって引き起こされているかもしれません。
CPUボトルネック
上記の例ではvCPUが2つのため、キューで待たずに同時に実行できるセッションは2つだけです。3つのセッションがCPUで同時に実行される場合、いずれの時点でも、少なくとも1つのセッションがランキュー内で待機しているため、処理が完了しません。
次の例ではデータベース負荷が「最大CPU」ラインを大きく超えています。このときの質問は「このボトルネックの原因は何ですか？」です。関心のある領域を選択するためにクリック & ドラッグ（以下のグラフの薄い青い部分）すると、ボトルネックにズームインできます。
以下が、選択した領域にズームインした例です。
今回のケースでのボトルネックはCPUです。緑 (CPU) がアクティブセッション内で最大の色です。CPUの需要は、最大CPUで示されている使用可能なCPUを上回ります。この問題に対処するには2つの選択肢があります。より多くのCPUを載せたより大きなインスタンスへのスケールアップ、または現行のインスタンス上での負荷を減らすことです。より大きなインスタンスタイプへのスケールアップは選択肢の一つですが、一般的に議論とスケジュール設定が必要となり、コストが増加するでしょう。より直接的な解決方法は、現在のシステム上のワークロードをチューニングすることです。
先ほどの例のシステムをチューニングするということは、「何をチューニングするのか」という質問になります。負荷グラフの下のトップアクティビティ表はその回答に役立ちます。SQLタブを選択すると（デフォルト）、どの文が負荷に最も影響を与えているかがこの表に表示されるため、チューニングの候補になります。今回のケースでは、1つのSQLが負荷に主な影響を与えており、CPU待機にも主な影響を与えています。このデータベースのCPU負荷の原因がminute_rollup()ファンクションであることは明らかです。このストアドファンクションのCPU使用率を減らすことに労力を割く価値はありそうです。
待機ボトルネックのチューニング
上記の例では、同一データベース上で少しの時間が空いた後に薄いオレンジ色のスパイクとして新しいボトルネックが表れていることが分かります。
CPUではなく、このスパイクは主にIO:XactSync待機イベントで構成されています。この待機について詳細を調べるために凡例の項目にカーソルを置くと、その待機イベントに関する情報が表示されます。この情報から、セッションがストレージへの書き込みを待っているときにIO:XactSyncが発生することが分かります。トップSQLを見ると、この待機状態に最も影響を与えているのはINSERT文であることが分かります。
PostgreSQLのデフォルトでは、単一行のINSERTは各行ごとに自動コミットします。これは、データベースが各行ごとに永続化（ストレージへの書き込み）を待たなければならないことを意味します。パフォーマンスを向上させるため、PostgreSQLの複数行INSERTを有効にし、自動コミットを無効にします。
データベースホストのサイジングに Performance Insights を使用する
Performance Insights はデータベース用のインスタンスタイプのサイジングに役立ちます。次の例では、データベースの負荷が「最大CPU」の下にあります。これが典型的な状況の場合、データベースは必要以上のインスタンスタイプで実行されている可能性があり、縮小できるかもしれません。
一方で、データベースの負荷が定期的に「最大CPU」を超え、ワークロードをチューニングできる余地がない場合は、インスタンスタイプが小さすぎるかもしれません。次の例ではデータベースの負荷が「最大CPU」を超えています。
その他の切り口からの調査
ダッシュボードの負荷グラフとトップアクティビティの両方で、デフォルトで表示されている切り口（待機とSQL）以外のものを表示させることができます。
負荷グラフの凡例には、グラフの切り口を選ぶセレクターがあります。Aurora PostgreSQL の場合、Performance Insights は、待機、SQL、ホスト、ユーザーによるスライスを現在サポートしています。
トップアクティビティでは、リスト上部に切り口が一覧されています。Aurora PostgreSQL の場合、Performance Insights は、トップSQL、待機、ホスト、ユーザーによる一覧を現在サポートしています。
上の画像では、トップアクティビティがホスト別にグループ化されています。これはSQLが実行された各クライアントマシンからの負荷を示しています。この場合では、CPU負荷を発生させているホストは1つだけです。これはデプロイメントの問題を示しているかもしれません。これらのホストはアプリケーションサーバーで、同じコードを実行し、似たような負荷プロファイルになるべきです。
これらのホストでのSQLワークロードがどのように異なるのかを知るには、負荷グラフの凡例で「スライス基準」を選び、SQLを選択します。
ホスト負荷が待機ではなくSQLでグループ化されると、172.31.31.154だけが With cte as (SELECT … を実行しているホストであることが分かります。ホストの負荷が待機でグループ化された先ほどの例で、CPU負荷が偏っていたホストとこれは同じです。
172.31.18.90が INSERT INTO authors … を実行している唯一のホストであることも分かります。さらにこれが実行されている唯一のSQLのように見えます。ワークロードとデータベース負荷が複数のアプリケーションサーバーにどのように偏って分散しているかを理解することは、エンドユーザーのパフォーマンス問題を診断にするのに役立ちます。
デフォルトでは、ダッシュボードには待機による負荷とSQLによるトップアクティビティが表示されます。これは一般的用途では最も有用な組み合わせです。
まとめ
Performance Insights は Amazon RDS DBインスタンスのパフォーマンスボトルネックを迅速かつ簡単に特定し、そのボトルネックに対処するための個所を示します。Performance Insights はコンソールで作成したデータベースではデフォルトで有効で、データベースインスタンスを変更することで有効にすることもできます。完全に自動化されており、オーバーヘッドは1つのvCPUの1%程度です。データの格納、処理、集約のすべては自動的に管理され、データベースホスト外で実行されるので、監視対象のデータベースに影響を与えません。
Amazon RDS Performance Insights は Amazon Aurora PostgreSQL で現在利用可能で、まもなくすべての Amazon RDS データベースエンジンで展開されます。
著者について
Kyle Hailey は Amazon Web Services の Performance Insights のプロダクトマネジャーです。
翻訳はソリューションアーキテクトの柴田（シバタツ）が行いました。原文は Analyzing Amazon RDS Database Workloads with Performance Insights です。