DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

AWS RDSにおける突然のパフォーマンス低下をトラブルシューティングする5つのステップ

AWS RDSデータベースで突然発生するパフォーマンス低下を迅速に診断・解決するための5つの重要なステップを学びます。このガイドでは、CloudWatchとPerformance Insightsを使用した即時メトリクス分析から始まる体系的な方法論を提供します。リソースのボトルネック（CPU、I/O、接続）の特定、実行計画を用いた低速クエリの特定、Tシリーズクレジット残高やパラメータグループ設定などの重要なインスタンス設定の検証を行い、最適なデータベースパフォーマンスを効率的に復元する方法を解説します。

AWS RDSにおける突然のパフォーマンス低下をトラブルシューティングする5つのステップ

本番データベースにおける突然のパフォーマンス低下は、運用チームが直面する最も重大な問題の一つです。Amazon Relational Database Service（RDS）はデータベース管理を簡素化しますが、高レイテンシ、トランザクションタイムアウト、アプリケーションエラーとして現れる予期せぬパフォーマンス低下のトラブルシューティングには、体系的かつ焦点を絞ったアプローチが必要です。

このガイドでは、AWS RDSインスタンスのパフォーマンス低下の根本原因を迅速に特定するための、実践的で実行可能な5つのステップを概説します。特に、AWSの組み込みモニタリングツールと標準的なデータベース診断技術の活用に焦点を当てています。この順次的な方法論に従うことで、症状の分析から解決までを効率的に進めることができます。

ステップ1: CloudWatchとPerformance Insightsによる即時メトリクス分析

パフォーマンス調査の最初のステップは、ボトルネックを定量化することです。AWS CloudWatchは、問題がコンピュートバウンド、I/Oバウンド、または接続バウンドのいずれであるかを診断するために必要な高レベルメトリクスを提供します。

調査すべき主要メトリクス

以下のメトリクスを分析します。特に、パフォーマンス低下の直前および低下中の時間帯に注目し、相関するスパイクを探します。

  1. CPU使用率: 100%近くへの突然のスパイクは、通常、過剰なワークロード、不適切なクエリプラン、または大規模なバックグラウンドタスクを示します。
  2. 読み取り/書き込みIOPSとレイテンシ: 高いレイテンシとIOPSの最大使用が組み合わさっている場合、データベースがストレージ待ちでボトルネックになっていることを示します。これは、ワークロードがプロビジョニングされたIOPSまたはスループットを超えた場合、またはバースト動作を使用するストレージ構成でバースト容量が枯渇した場合に発生します。
  3. データベース接続: アクティブな接続の急激な増加は、メモリを枯渇させたり、max_connections制限に達したりして、接続障害やリソース競合を引き起こす可能性があります。
  4. Freeable Memory: 利用可能メモリの急激な低下または一貫した低さは、非効率なクエリキャッシュや過剰なメモリを使用するプロセスを示している可能性があり、スワッピング（I/O集中型で低速）につながります。

Performance Insightsの使用

サポートされているRDSエンジンの場合、Performance Insights (PI) はこのステップで最も高速なツールであることがよくあります。PIはデータベース負荷（DB Load）を視覚的に表現し、スパイクの原因を特定するのに役立ちます。

  • PIはDB負荷を待機状態（例：CPU、I/O待機、ロック待機）とTop SQLで分類し、ボトルネックの原因を即座に可視化します。

ヒント: DB負荷がスパイクしても、待機の大部分がCPUとして分類される場合、問題は複雑なクエリ処理です。待機が主にI/Oの場合、問題はストレージからのデータの読み取りまたは書き込みです。

ステップ2: アクティブセッションと待機イベントの調査

メトリクスによってボトルネックの場所（例：高いCPU）が確認されたら、次のステップは、現在負荷を引き起こしている誰または何かを特定することです。

Performance Insightsを使用して、パフォーマンス低下期間中に最も多くのDB負荷を消費しているTop SQLを特定します。PIが有効になっていない場合は、データベースインスタンスに直接接続する必要があります。

データベース固有のセッションコマンド

MySQL/MariaDB

SHOW PROCESSLISTを使用して、現在実行中のクエリを表示します。長時間実行されているトランザクション（Time値が高い）や、Sending dataまたはLocked状態でスタックしているコマンドを探します。

SHOW FULL PROCESSLIST;

PostgreSQL

pg_stat_activityビューをクエリして、アクティブなクエリとその待機イベントを見つけます。wait_event_typeがNULLでなく、query_start時間が長いクエリを探します。

SELECT pid, datname, usename, client_addr, application_name, backend_start,
       state, wait_event_type, wait_event, query_start, query
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY query_start ASC;

待機イベント（例：lock待機イベント）に焦点を当てることで、システム全体を停止させる可能性のある同時実行性の問題やスキーマロックの競合が即座に明らかになります。

ステップ3: 低速クエリの診断と最適化

多くの場合、突然のパフォーマンス低下は、最近デプロイされた変更（新しいクエリ、古いクエリプラン、欠落したインデックス）によって引き起こされます。スロークエリログ（MySQL/MariaDB）またはpg_stat_statements（PostgreSQL）をPerformance Insightsデータと組み合わせて使用し、最も影響の大きいクエリを特定します。

実行計画の分析

候補となるクエリが特定されたら、データベースの実行計画ツール（EXPLAINまたはEXPLAIN ANALYZE）を使用して、データベースがクエリをどのように実行しているかを理解します。

  1. フルテーブルスキャンの特定: パフォーマンスを低下させる一般的な原因です。クエリがインデックスを使用せずに巨大なテーブルをスキャンする場合、パフォーマンスは急落します。
  2. インデックス使用状況の確認: WHERE句、JOIN条件、ORDER BY句に対して最適なインデックスが使用されていることを確認します。

例: クエリプランの確認

EXPLAIN ANALYZE 
SELECT * FROM large_table WHERE column_a = 'value' AND column_b > 100;

計画が不適切なインデックス使用を示している場合、即座の解決策は、多くの場合、新しいターゲットインデックスを作成することです。重要で長時間実行されるクエリについては、結合を簡素化するか、複雑な操作を分割することを検討します。

ベストプラクティス: クエリの最適化は、最も頻繁に行われる長期的な解決策です。最も高いI/OまたはCPU負荷を引き起こしているクエリの最適化を優先します。

ステップ4: インスタンスとパラメータグループの設定を確認

負荷が正常に見えるにもかかわらず、リソース（メモリや接続など）が最大に達している場合、問題はインスタンスのサイズ不足または最適でない設定パラメータである可能性があります。

インスタンスサイズとタイプ

  1. Tシリーズクレジット確認: バースト可能インスタンス（Tシリーズ）を使用している場合は、CloudWatchでCPUクレジット残高を確認します。残高がゼロになると、インスタンスがスロットリングされ、深刻なパフォーマンス低下を引き起こす可能性があります。データベースに持続的な負荷がある場合は、固定パフォーマンスクラスに移行します。
  2. リソース制限: インスタンスクラスが現在のワークロードプロファイルに十分なRAMとIOPSを提供しているか確認します。データベースが頻繁にスワップしたり、PIOPS制限に達したりする場合は、アップグレード（垂直スケーリング）が必要です。

パラメータグループの確認

重要なパラメータを確認します。これらは通常、インスタンスサイズに基づいて自動的にスケーリングされますが、上書きされたり、低く設定されたりしている可能性があります。

  • max_connections: このパラメータ（インスタンスメモリから派生）がピーク負荷に十分であることを確認します。
  • innodb_buffer_pool_size（MySQL）またはshared_buffers（PostgreSQL）: このメモリ領域はデータのキャッシュに重要です。小さすぎると、データベースは低速なディスクI/Oに大きく依存します。

ステップ5: システムメンテナンスと二次的な操作の確認

パフォーマンス低下は、自動化されたシステムタスクやバックグラウンドのレプリケーションプロセスによって一時的に発生することがあります。

自動バックアップとメンテナンスウィンドウ

RDSコンソールでメンテナンスウィンドウとバックアップウィンドウの設定を確認します。自動スナップショットは、特にワークロードがすでに高い場合に、一時的なI/Oレイテンシを引き起こす可能性があります。パフォーマンス低下がバックアップウィンドウと正確に相関している場合は、ウィンドウを重要でない時間に移動するか、バックアップ中の負荷を処理するために十分なPIOPSが割り当てられていることを確認します。

レプリケーションラグ

アプリケーションがリードレプリカに依存している場合、プライマリインスタンスでの突然のパフォーマンス低下により、深刻なレプリケーションラグが発生する可能性があります。レプリケーションラグが大きい場合は、プライマリインスタンスが変更を十分な速さで処理できないことを示しており、多くの場合、ステップ3（低速クエリ）またはステップ4（リソース不足）で見つかった問題に戻ります。

CloudWatchのReplicaLagメトリクスを監視します。ラグが大きい場合は、プライマリインスタンスのトランザクションレートと最適化にトラブルシューティングの焦点を戻します。

バイナリログとWALアクティビティ

高トランザクション環境では、MySQLのバイナリログまたはPostgreSQLの先行書き込みログは、特にレプリケーションやポイントインタイムリカバリが有効な場合に、意味のあるI/Oプレッシャーを追加する可能性があります。I/Oレイテンシがボトルネックである場合は、トランザクション量、レプリカの健全性、チェックポイント動作、および最近開始されたジョブが通常よりもはるかに多くのデータを書き込んでいないかを確認します。

インシデント対応を絞り込む

インシデント中は、プレッシャーを取り除く最小限の変更を行います。暴走ジョブを停止する、不良なデプロイをロールバックする、ワーカーの同時実行性を減らす、安全なインデックスを追加する、またはワークロードが明らかにインスタンスの能力を超えている場合はインスタンスをスケーリングします。その後、最初の不良メトリクス、トップの待機イベント、トップのSQLまたは操作、および修正内容を記録します。その記録こそが、次回のRDSパフォーマンス低下をより短い調査時間に変えるものです。