【レポート】Amazon RDS におけるパフォーマンス最適化とパフォーマンス管理 #AWSSummit

こんにちは、崔です。
AWS Summit Tokyo 2019 3日目のB3-04のセッションである「Amazon RDS におけるパフォーマンス最適化とパフォーマンス管理」のレポートをお届けします。

DBのパフォーマンスを最適化する上でDBのパフォーマンスメトリクスを収集し定期的に分析することが重要になります。Amazon RDSでは、Performance Insightsを利用することでメトリクスの収集、蓄積を自動化し、パフォーマンス問題発生時点の問題解析を迅速に行うことができるようになります。パフォーマンス問題の解析のためにPerformance Insightsが取得するメトリクス”Database Load”の意味を理解するとともに、Performance Insightsを使ったパフォーマンス分析のケーススタディを説明します。また、クエリーパフォーマンスの管理という観点からAurora PostgreSQLに備わるクエリ実行計画管理なども合わせて解説します。

スピーカー

アマゾン ウェブ サービス ジャパン株式会社
技術統括本部
ソリューションアーキテクト 新久保 浩二 様

はじめに

DBのパフォーマンスを管理する流れの理解と、その中でRDS Performance Insightsの役割や、クエリーのパフォーマンス管理を行うAurora PostgreSQLの新機能Query Plan Managementの利用ケースを理解していただきます

RDSの振り返りと重要なデータベース管理タスクの変化

RDS概要

• フルマネージドなRDB
• シンプルかつ迅速にスケール
• 高速、安定したパフォーマンス
• 低コスト、従量課金

自動化されるデータベースの管理タスク

データベース管理者が、データベース構築、バックアップ、リカバリ、高可用性の担保、パッチ適用など定型で時間のかかるタスクから解放

重要になるパフォーマンス最適化の管理タスク

• スキーマデザイン
• クエリの作成
• パフォーマンスの最適化

パフォーマンスの最適化に注力し、ビジネスに直結するアプリケーションの改善を行うことが可能
パフォーマンスの最適化がより重要になり、次のステップとしてのパフォーマンス管理

データベースパフォーマンス管理

データベースのパフォーマンス管理サイクル

• モニタリング(監視)
  • 各レイヤーでデータベースのパフォーマンスKPI、分析に必要な詳細なデータを収集
• ディスカバリ(発見)
  • データベースでパフォーマンス問題が発生しているのか否か、またその度合を検知
• アナリシス(分析)
  • 検知した問題についてモニタリングで取得した詳細データを使って原因を分析すると共にチューニング計画を立てる
  • 掛けたコストに見合うのか、青天井なのか　計画することが重要
• レゾリューション(解決)
  • チューニング計画におけるゴールの定義に基づいて

RDSのパフォーマンス管理（課題）

• モニタリング(監視)
  • CloudWatch
  • CloudWatch Logs
  • 拡張モニタリング
  • 自作プログラム
• ディスカバリ(発見)
  • OSレイヤーやDBの特定の統計情報で問題を発見
  • 広範なパフォーマンス問題を発見するのは困難
• アナリシス(分析)
  • どの程度リソースが不足、余剰なのかの見積もりが困難
• レゾリューション(解決)
  • ボトルネックが曖昧なため、SQLやデータベースのチューニングが困難

RDSのパフォーマンス管理（改善）

• モニタリング(監視)
  • Amazon RDS Performance Insights
• ディスカバリ(発見)
  • OSに加えて、データベースレイヤーのKPIを見ることで問題の有無を診断可能
• アナリシス(分析)
  • 待機イベントベースのKPIによりボトルネックが明確、またチューニング目標を設定しやすい
• レゾリューション(解決)
  • ボトルネックとチューニング目標を明確にし、目的に向かって効率的なチューニングを実施

Performance Insights

• 対応エンジン
  • 全てのエンジンに対応している
• 主要な機能
  • データベースロード
  • カウンターメトリクス
  • Top N ディメンショ
    • 分析軸：待機、SQL、ホスト、ユーザ
  • 7日間のデータ保持期間（デフォルト）
    • 2年間の長期保持も選択可能
  • CloudWatchアラーム
  • API/SDK

DBに負荷をかけると即座にリアルタイムに確認可能
5秒毎に描画される

パフォーマンス管理のためのKPI

• データベースロード
  • アクティブなセッション数
    • データベースのセッションはアクティブとアイドルのステータスがある
    • さらにアクティブセッションはCPU使用中なのか他の処理を待機中なのか
  • データベースロード
    • 1秒おきにアクティブなセッションの詳細な情報をサンプリング

データベースロード

• 1秒おきにアクティブなセッションを取得し、時系列棒グラフにプロットしていく
• 待機している状態もプロットしていく
• アクティブなセッションの裏で、待機しているセッションも可視化
• さらに待機イベントでブレークダウン

データベースロードで問題の発見

• データベースロード (AverageActiveSessions) とvCPUsを比較する
• データベースロード (AAS) ~= 0
  • 基本的にデータベースが使用されていない
• データベースロード (AAS) > # of vCPUs
  • パフォーマンス問題の可能性がある
• データベースロード (AAS) >> # of vCPUs
  • 問題である
• パフォーマンス問題の有無は、データベースロードがインスタンスの最大vCPUを超えているかどうかが基準

データベースのパフォーマンス問題の例

ケース１

CPU使用率が100%になっているケース
CPU使用率100%でも問題かどうかはわからない。効率的に使っているだけかも
閾値（vCPU）の8を大きく越えたデータベースロード（約32）を示す時間帯が大きな問題だと判断できる

ケース２

CPU使用率が100%の時間帯と、CPU使用率が低い時間帯があるケース
OSリソースから問題ない状況に見えても、データベースロードからは問題だと明確に判断できる CPUを使っていないときが問題と分かる

パフォーマンス問題の分析

• ボトルネック分析
  • 待機イベントは？
  • SQL文は？
  • 接続元ホストは？
  • 接続ユーザは？
• 優先度の決定
  • チューニングの優先度
  • 待機時間の多いイベント？
  • 最も遅いSQL？
  • システム全体の中で問題の比率の高いアプリケーション？
  • ビジネス要件？
  • チューニングの目標
  • 2倍、4倍、100倍のパフォーマンスが必要？
  • そもそもデータベースとしてチューニングの限界はどこなのか？

問題例ケース１の場合

• ボトルネック分析
  • カウンターメトリクスからCPU使用率が100%とわかる
    • CPUリソースが飽和している
  • データベースロードから
    • データベースが使用したリソースの全てがCPUリソース
    • データベースとして、I/O、ロック、ラッチ等の待機ではなく純粋にCPUリソース不足とわかる
  • 待機SQL文からCPU負荷をかけたSQLも確認可能

どうすればよいのか？

• チューニング目標の定義
  • ４倍のCPUリソースを用意することで、処理時間が1/4になることが予測される
  • パフォーマンス要件と合わせて検討し、増強するCPUリソースを決定する必要がある

問題例ケース２の場合

• ボトルネック分析
  • データベースロードから
    • １の時間帯は、リソース使用効率は優れている
    • ２の時間帯は、全ての処理が待機していることを示している
    • 待機イベントからLock:relationだと分かる
    • アプリケーションのロジックの問題で、テーブルのロック待ちにより処理がブロックされていることがわかる

どうすればよいのか？

• チューニング目標の定義
  • ２のトランザクションロック待ち
  • このボトルネックが完全に除去できた形が理想

DBのパフォーマンス最適化

• システムチューニング
  • データベースのパフォーマンス管理
• クエリチューニング
  • クエリのパフォーマンス管理
  • Performance InsightsでSQLやSQLの実行プランに起因する問題だと特定したあとの話

クエリのパフォーマンス管理

クエリのパフォーマンスを管理する方法

• SQLヒント
  • オプティマイザのヒント句を利用して実行プランを制御
    • SQL文（アプリケーション）の修正を伴う
    • より効率の良い実行プランが存在しても選択されない
• SQL Plan Stablility
  • SQLヒントで利用可能なヒント句の集合をSQL文に外部から関連させることで実行プランを制御
    • アプリケーションの修正を伴わない
    • より効率の良い実行プランが存在しても選択されない
• SQL Plan管理
  • データの偏りなど統計情報により変化する実行プランを蓄積しながら管理者もしくはDBが最適な実行プランを承認して固定化
    • 実行プランのバージョンを管理しどのバージョンを承認するか管理が可能
    • 統計情報に効率の良い実行プランが生成された場合も確認が可能
    • SQL文を直接書き換える必要もないため、アプリケーションの修正も必要ない
    • 個別に実行プランの修正が必要な場合は、ヒント句でプランを修正した後にプランの承認が可能
    • SQL Plan Managementが可能だDBエンジンが限られる

Query Plan Managementの概要

• 機能概要
  • 手動／自動でプランのキャプチャー
  • プランの測定／比較
  • プランの承認／拒否
  • ベースライン内のプランを使用
  • pg_hint_planを使ったプランの修正
  • プランの解除
  • プランのエクスポート／インポート
• サポートバージョン／制御
  • Aurora PostgreSQL 2.1.0以上（PostgreSQL 10.5互換）
  • PL/pgSQLは未サポート

Query Plan Managementのユースケース

• パフォーマンス低下を防止する事前予防
  • 手動／自動でプランをキャプチャー
  • ベースラインのプランを強制
  • キャプチャーされたプランの効率性を分析
• パフォーマンス低下を検出した際の事後対応
  • プランをベースラインで固定
  • パフォーマンス低下を監視、分析
  • 既存のベースラインのプランを拒否し、適切な別のプランを使用
  • pg_hint_plan拡張でプランを修正

まとめ

• マネージドサービスの利用により重要なデータベース管理タスクが変化
  • インフラレイヤーの管理タスクより、ビジネスに直結するアプリケーションのパフォーマンスの最適化や管理の重要性
  • 事前のオーバープロビジョニングよりも、データベースのパフォーマンスを把握し、柔軟な運用が求められる
• データベースのパフォーマンス管理
  • データベース全体のパフォーマンスを把握し、問題の発見・分析が可能
• クエリのパフォーマンス管理
  • クエリ実行プランの管理が重要
  • 最適なものをオプティマイザに選択させることで、パフォーマンスの安定性の向上
  • Aurora PostgreSQLでQuery Plan Managementの拡張機能が利用可能

感想

Aurora PostgreSQLのQuery Plan Managementを利用して、パフォーマンスチューニングをやってみます！