Aurora MySQLのエラーレート悪化の原因がPerformance Schemaだった事例
CyberAgentのSRGチームは、Aurora MySQLで負荷増加なしにエラーレートが悪化した事象を調査し、Kubernetesの短命PodがPerformance Schemaのメモリ消費を増大させたことを特定した。
キーポイント
負荷メトリクスの異常なし
CPU、AAS、クエリ数、接続数は安定していたが、FreeableMemoryの減少とSwapUsageの上昇でメモリ逼迫が発生し、エラーレートが悪化した。
Performance Schemaの過剰消費
Performance Schemaのメモリ使用量が約5.2GBに達しており、host/accountサマリテーブルに約16,000件のエントリが蓄積されていた。
根本原因の特定
アプリケーションリリースで追加されたKubernetes CronJobによる毎分の短命Pod実行が、Performance Schemaに多数の接続元記録を残した。
外部事例との照合
ANDPAD Tech Blogで報告されたAurora MySQLバージョンアップに伴うPerformance Schemaのデフォルト挙動変化と類似する事象として対応した。
Performance Schemaの肥大化がOOM回避とクエリKillを引き起こした
短命PodのIP変更によりPerformance Schemaが無限に累積しメモリを消費、Freeable Memory減少とSwap使用でAuroraのOOM回避動作（クエリKill）を誘発した。
パラメータ制限による解決と再起動の必要性
`performance_schema`を手動管理に変更し関連パラメータに上限値を設定することでメモリ問題を解消したが、変更適用にはRDSインスタンスの再起動が必要。
設定制限のデメリットと代替案
上限設定はPerformance Insightsのホスト別集計情報が欠落するリスクがある。接続元HOSTを安定させるためRDS Proxyの導入も検討できる。
影響分析・編集コメントを表示
影響分析
本記事は、クラウドデータベースの運用において「負荷メトリクスが正常でもメモリ逼迫でエラーが発生する」という隠れたリスクを可視化した。SREやDBAは、Performance Schemaのメモリ消費を監視指標に組み込むことで、予期せぬOOM回避動作によるサービス障害を未然に防げる。特にKubernetesなどの動的環境では、接続元の頻繁な変化が内部テーブルに蓄積する点を運用ガイドラインに反映させるべきである。
編集コメント
負荷メトリクスが正常でもメモリ逼迫で障害が発生する「見えないボトルネック」の特定事例として、SREチームの調査手法は参考になる。Performance Schemaのような内部監視ツールのメモリ消費を運用指標に組み込むことが、クラウドDBの安定稼働には不可欠である。
HOME / 技術記事 / Aurora MySQLの負荷は高騰していないのにエラーレートが悪化した原因がPerformance Schemaだった話 Aurora MySQLの負荷は高騰していないのにエラーレートが悪化した原因がPerformance Schemaだった話 2026/4/2 8:35 2026/4/2 8:38 メディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。
#SRG （Service Reliability Group）は、主に弊社メディアサービスのインフラを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事では、ある日起きたAurora MySQLの障害対応事例を紹介します。
ある日突然アプリケーションのエラーレート悪化アラートが発報 初動調査 一件のブログ記事を見つける Performance Schemaを調査 根本原因 一次対応 おわりに ある日突然アプリケーションのエラーレート悪化アラートが発報 ある日突然、アプリケーションのエラーレートが悪化したためアラートが発報されました。
初動調査 該当時間のAurora MySQLのRDSインスタンスのエラーログを確認すると、以下のようなログが残っていました。
Aurora MySQLがメモリ不足によるOOM（Out Of Memory）の発生を回避するために、コネクションを切断したりクエリを拒否したりしていたようです。
メトリクスを確認してみると、ある日を境にFreeableMemory（利用可能メモリ）が右肩下がりになっていることがわかりました。
時間差でSwapUsage（スワップ使用量）も上昇しています。
他にDB負荷に関連するメトリクスに変化がないか確認してみます。CPU使用率は1ヶ月のスパンで見ても大きな変化はなさそうです。
Database Insight（データベースインサイト）で直近1週間の平均アクティブセッション（AAS）を見ても、悪化はなさそうです。スロークエリログも発生していませんでした。
クエリー数の傾向にも変化はなさそうです。
コネクション数の傾向にも変化はありません。
FreeableMemoryが右肩下がりを始めた日にアプリケーションの新機能リリースがあり、それが関係していそうだということはわかりました。
しかし、メモリ逼迫以外のメトリクスが上昇しておらず、どうしたものかと思案していました。
一件のブログ記事を見つける アンドパッドさんのこちらの記事で、Performance Schema（パフォーマンススキーマ）が原因でFreeableMemoryが低下するという事象が紹介されていました。
Aurora MySQLにおけるPerformance Schemaの手動管理と自動管理の違い - ANDPAD Tech Blog こんにちは。アンドパッドでDBRE（Database Reliability Engineer）を務めている久保と申します。
こちらは ANDPAD Advent Calendar 2025 の24日目の記事です。
今日はAurora MySQLにおけるPerformance Schemaの手動管理と自動管理の違いについてお話しします。
背景 現在DBREではAurora MyS… https://tech.andpad.co.jp/entry/2025/12/24/100000 記事内の事例では、Aurora MySQL 3.04(MySQL8.0.28)から3.10(MySQL8.0.42)へのアップグレードによって、特定インスタンスのデフォルト挙動が変わったことが原因でした。
今回私が見ていた環境はAurora MySQL 3.04でしたので、この記事とまったく同じ事象ではないのですが、要因としてPerformance Schemaが怪しいということで調査を進めました。
Performance Schemaを調査 Performance Schemaの全体のメモリ使用量を確認したところ、約5.2GB消費していることがわかりました。
Currentの値と最大使用量の値が一致しており、消費が伸び続けていることがわかります。
消費メモリの内訳の上位を確認してみると、host/account別サマリーが支配的であることがわかりました。
host/accountの件数をカウントしてみると、約16000件ずつあることがわかりました。
accountsの中を見てみると、ユニークな接続元HOSTが大量に並んでおり、異なるIPアドレスで記録されていることがわかりました。
根本原因 Freeable Memoryが下がり始めた日のアプリケーションリリースで、Kubernetes CronJobによる毎分実行のバッチ処理が追加されていたことが判明しました。
これによって、短命のPodが毎回新しいPod IPでDBへ接続され、host/accountのエントリが累積で増え続け、それぞれのサマリーも増殖し、Performance Schemaのメモリ消費が肥大化していました。
その結果、Freeable Memoryが減り続け、Swap Usageも増加し、最終的にAurora側のOOM回避挙動が発動したため、クエリのKillが発生しアプリケーションのレイテンシ悪化につながりました。
一次対応 Aurora MySQLのパラメータグループの以下のパラメータを変更しました。
パラメータ名 デフォルト値 変更後の値
performance_schema 0 (自動管理) 1 (手動管理)
performance_schema_accounts_size -1 (無制限) 100
performance_schema_hosts_size -1 (無制限) 100
Performance Schema関連のパラメータを変更するため、performance_schemaを手動管理に変更して、performance_schema_accounts_sizeとperformance_schema_hosts_sizeそれぞれに上限値を設定しました。
この2つはデフォルトでは無制限のため、今回のようにエントリが累積し続けることになってしまいました。
なお、これらのパラメータの変更の適用にはRDSインスタンスの再起動が必要な点には注意が必要です。
この対応によって、FreeableMemoryの右肩下がりの状況と、SwapUsageの発生を解消することができました。
performance_schema_accounts_sizeとperformance_schema_hosts_sizeの2つに上限を設定した場合のデメリットとして、パフォーマンスインサイトのホスト別集計で上限を超えた場合に、ホスト別情報が欠落してしまう点があります。
おわりに システムアラートが鳴ったのにDBの負荷系指標に問題がない場合、Performance Schemaの肥大化も疑ったほうがよいという事例を紹介しました。
今回は2つのperformance_schema関連のパラメータに上限値を設定して問題を解消しました。
他にも、アプリケーションとAurora MySQLの間にRDS Proxyを挟んで接続元HOSTを安定させるという手段も考えられます。
SRGにご興味がありましたらぜひこちらからご連絡ください。
採用情報 - CyberAgent SRG #ca_srg SRGについて SRG（サービスリライアビリティグループ）は、「メディア事業の信頼性を横断的に向上させる」というビジョンのもと、横断SREとしてメディア事業へのSRE導入を促進し、信頼性を向上するための取り組みを行っています。
業務内容としては、以下の3つを主軸に活動しています。
各事業の技術ノウハウを集約し、展開する https://ca-srg.dev/careers
原文を表示
HOME / 技術記事 / Aurora MySQLの負荷は高騰していないのにエラーレートが悪化した原因がPerformance Schemaだった話 Aurora MySQLの負荷は高騰していないのにエラーレートが悪化した原因がPerformance Schemaだった話 2026/4/2 8:35 2026/4/2 8:38 メディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。
#SRG （Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事では、ある日起きたAurora MySQLの障害対応事例を紹介します。
ある日突然アプリケーションのエラーレート悪化アラートが発報 初動調査 一件のブログ記事を見つける Performance Schemaを調査 根本原因 一次対応 おわりに ある日突然アプリケーションのエラーレート悪化アラートが発報 ある日突然、アプリケーションのエラーレートが悪化しアラートが発報されました。
初動調査 該当時間のAurora MySQLのRDSインスタンスのエラーログを確認すると、以下のようなログが残っていました。
Aurora MySQLがメモリ不足によるOOMの発生を回避するために、コネクションを切ったりクエリを拒否したりしていたようです。
メトリクスを確認してみると、ある日を境にFreeableMemoryが右肩下がりになっていることがわかりました。
時間差でSwapUsageも上がっています。
他にDB負荷に関連するメトリクスに変化がないか確認してみます。CPU使用率は1ヶ月のスパンで見ても大きな変化はなさそうです。
Database Insightで直近1週間の平均アクティブセッション（AAS）を見ても、悪化はしてなさそうです。スロークエリログも発生していませんでした。
クエリー数の傾向にも変化もなさそうです。
コネクション数の傾向にも変化はありません。
FreeableMemoryが右肩下がりをした日にアプリケーションの新機能リリースがあり、それが関係していそう。ということはわかりました。
しかし、メモリ逼迫以外のメトリクスが上昇しておらずどうしたものかと思っていました。
一件のブログ記事を見つける アンドパッドさんのこちらの記事で Performance Schemaが原因でFreeableMemoryが低下する という事象が紹介されていました。
Aurora MySQLにおけるPerformance Schemaの手動管理と自動管理の違い - ANDPAD Tech Blog こんにちは。アンドパッドでDBREを務めてます久保と申します。
こちらは ANDPAD Advent Calendar 2025 の24日目の記事です。
今日はAurora MySQLにおけるPerformance Schemaの手動管理と自動管理の違いについてお話しします。
背景 現在DBREではAurora MyS… https://tech.andpad.co.jp/entry/2025/12/24/100000 記事内の事例では Aurora MySQL 3.04(MySQL8.0.28)から3.10(MySQL8.0.42)にアップグレードによって、特定インスタンスのデフォルト挙動が変わった ことが原因でした。
今回私が見ていた環境はAurora MySQL 3.04でしたので、この記事とまったく同じ事象ではないのですが、要因として Performance Schemaが怪しい ということで調査しました。
Performance Schemaを調査 Performance Schemaの全体のメモリ使用量を確認したところ、約5.2GB消費していることがわかりました。
Currentの値と最大使用量の値が一致しており、いまだ消費が伸び続けていることがわかります。
消費メモリの内訳の上位を確認してみると、host/account別サマリが支配的ということがわかりました。
host/accountの件数をカウントしてみると、 約16000件 ずつあることがわかりました。
accoutsの中を見てみると、ユニークな接続元HOSTが大量に並んでおり、異なるIPアドレスで記録されていることがわかりました。
根本原因 Freeable Memoryが下がりはじめた日のアプリケーションリリースで、 Kubernates CronJobによる毎分実行のバッチ処理が追加されていた ことが判明しました。
これによって 短命のPodが毎回新しいPod IPでDBへ接続 され、 / が累積で増え続けて、 それぞれのサマリも増殖し、Performance Schemaのメモリ消費が肥大化していました。
その結果、Freeable Memoryが減り続け、Swap Usageも増加し最終的にAurora側のOOM回避挙動が出たため、クエリのKillが発生しアプリケーションのレイテンシ悪化につながりました。
一次対応 Aurora MySQLのパラメータグループの以下のパラメータを変更しました。
パラメータ名 デフォルト値 変更後の値 0 ( 自動管理 ) 1 (手動管理 ) -1 ( 無制限 ) 100 -1 ( 無制限 ) 100 Performance Schema関連のパラメータを変更するため、performance_schemaを手動管理に変更して、 と それぞれに上限値を設定しました。
この2つはデフォルトでは無制限のため、今回のように累積し続けることになってしまいました。
なお、これらのパラメータの変更の適用にはRDSインスタンスの再起動が必要な点には注意が必要です。
この対応によって、FreeableMemoryの右肩下がりの状況と、SwapUsageの発生を解消することができました。
と の2つに上限を設定した場合のデメリットとして、パフォーマンスインサイトのホスト別集計で上限を超えた場合に、ホスト別情報が欠落してしまう点があります。
おわりに システムアラートが鳴ったのにDBの負荷系指標が平和な場合、Performance Schemaの肥大化も疑ったほうがよいという事例を紹介しました。
今回は2つのperformance_schema関連のパラメータに上限値を設定して問題を解消しました。
他にも、アプリケーションとAurora MySQLの間にRDS Proxyを挟んで接続元HOSTを安定させるという手段も考えられます。
SRGにご興味ありましたらぜひこちらからご連絡ください。
採用情報 - CyberAgent SRG #ca_srg SRGについて SRG（サービスリライアビリティグループ）は、「メディア事業の信頼性を横断的に向上させる」というビジョンの元、横断SREとしてメディア事業へのSRE導入を促進し、信頼性を向上するための取り組みを行っています。
業務内容としては、以下の3つを主軸に活動しています。
各事業の技術ノウハウを集約し、展開する https://ca-srg.dev/careers
関連記事
AWSがS3 Filesを導入、S3バケットへのファイルシステムアクセスを実現
AWSはS3 Filesを発表し、ユーザーがAmazon S3バケットをマウントして標準ファイルシステムインターフェースでデータにアクセスできるようにした。アプリケーションは標準ファイル操作で読み書きでき、システムが自動的にS3リクエストに変換するため、コンピュートサービスがS3に保存されたデータを直接扱える。
AWSが自動インシデント調査のためのDevOpsエージェントを一般提供開始
AWSは、開発者と運用者がAWS環境での問題のトラブルシューティング、デプロイメントの分析、運用タスクの自動化を支援する生成AI搭載アシスタント「DevOps Agent」の一般提供を開始した。
Amazon Bedrockの詳細なコスト帰属機能の導入
AWSがAmazon Bedrockの推論コストをIAMプリンシパルごとに自動的に帰属する機能を発表した。これにより、コストの内訳把握、コスト最適化、財務計画が容易になる。