AWS RDSの突然のパフォーマンス低下に対処するための5つのステップ

AWS RDS のパフォーマンスが急激に低下した場合のトラブルシューティングのための5つのステップ

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

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

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

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

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

低下が発生する直前および発生中の期間に焦点を当て、相関するスパイクを探しながら、以下のメトリックを分析します。

CPU 使用率: 100%に近づく突然のスパイクは、通常、過剰なワークロード、不適切なクエリオプティマイザの計画、または大規模なバックグラウンドタスクを示します。
読み取り/書き込み IOPS およびレイテンシ: 最大の IOPS と高いレイテンシの組み合わせは、データベースがストレージ待ちでボトルネックになっていることを示します。これは、ワークロードがプロビジョニングされた IOPS (PIOPS) を超えた場合や、汎用 SSD (gp2/gp3) インスタンスのバースト残高が枯渇した場合によく発生します。
データベース接続数: アクティブな接続数の急増は、メモリを使い果たしたり、max_connections の制限に達したりして、接続エラーやリソースの競合を引き起こす可能性があります。
空き可能メモリ (Freeable Memory): 急速な減少や一貫して低い空き可能メモリは、非効率的なクエリキャッシングや、過剰なメモリを使用するプロセスを示している可能性があり、スワッピング（I/O集約的で遅い）につながります。

Performance Insights の活用

ほとんどの最新の RDS エンジン (PostgreSQL、MySQL、MariaDB、Oracle、SQL Server) にとって、Performance Insights (PI) は最も重要なツールです。PI はデータベース負荷 (DB Load) を視覚化し、スパイクの直接的な原因を即座に確認できるようにします。

PI は、DB Load を待機状態（例：CPU、I/O 待機、ロック待機）とトップ SQL に分解し、ボトルネックの発生源を即座に可視化します。

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

ステップ2：アクティブセッションと待機イベントの確認

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

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

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

MySQL/MariaDB

実行中のクエリを確認するには SHOW PROCESSLIST を使用します。実行時間の長いトランザクション (Time 値が高いもの) や、Sending data または Locked 状態にスタックしているコマンドを探します。

SHOW FULL PROCESSLIST;

PostgreSQL

pg_stat_activity ビューをクエリして、アクティブなクエリとその待機イベントを見つけます。非 NULL の wait_event_type と高い 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) を使用して、データベースがそのクエリをどのように実行しているかを理解します。

フルテーブルスキャンの特定: 頻繁なパフォーマンス低下の原因となります。インデックスを使用せずに巨大なテーブルをスキャンしている場合、パフォーマンスは急落します。
インデックス使用状況の確認: WHERE 句、JOIN 条件、ORDER BY 句に対して、データベースが最適なインデックスを使用していることを確認します。

クエリ計画の確認例

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

計画が不十分なインデックス使用状況を示している場合、即時の解決策は、ターゲットを絞った新しいインデックスを作成することであることがよくあります。クリティカルで実行時間の長いクエリの場合は、JOIN の単純化または複雑な操作の分割を検討してください。

ベストプラクティス: クエリの最適化は、最も頻繁な長期的な解決策です。最も高い I/O または CPU 負荷の原因となっているクエリの最適化を優先してください。

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

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

インスタンスサイジングとタイプ

Tシリーズのクレジット確認: バースト可能なインスタンス (Tシリーズ) を使用している場合は、CloudWatch で CPU クレジット残高を確認します。残高がゼロに達すると、インスタンスはスロットリングされ、壊滅的なパフォーマンス低下につながります。継続的なロードが必要な場合は、固定パフォーマンスクラス (M、R、または C) へのアップグレードを検討してください。
リソース制限: インスタンスクラスが現在のワークロードプロファイルに対して十分な 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アーカイブ)

高トランザクション環境では、レプリケーションまたはポイントインタイムリカバリに必要な過剰なバイナリロギング（PostgreSQL の場合は WAL アーカイブ）が I/O に負担をかける可能性があります。I/O レイテンシがボトルネックとして確認されている場合は、ワークロードに合わせてバイナリロギングの保持期間とファイルサイズ設定パラメーターが最適化されていることを確認してください。

結論

RDS のパフォーマンスが突然低下した場合のトラブルシューティングには、一般的なメトリック（ステップ1）から具体的なコード分析（ステップ3）、そして最終的な設定制限の確認（ステップ4および5）へと体系的に進む、規律あるアプローチが必要です。AWS Performance Insights および標準的なデータベース診断コマンドを活用することで、チームは平均修復時間 (MTTR) を大幅に短縮し、最適なデータベース機能を復元できます。DB Load、I/O レイテンシ、および主要なシステムパラメーターの継続的な監視は、予期せぬ将来の低下に対する最良の防御策です。