Aurora PostgreSQL の空きローカルストレージがスケールダウン時に減少してしまう現象

いわさです。

Auroraはストレージが自動でスケールされるので、「ストレージ周りはよしなにしてくれる。シビアに監視する必要はないだろう。」と思っていたのですが間違っていました。
共有クラスターストレージは自動でスケールしますが、インスタンス個別のローカルストレージは違います。
そのあたりをまとめたので記事に残しておきます。

スケールアップ、スケールダウンに伴うローカルストレージの変化

Aurora PostgreSQL のマルチAZ構成で、同じサイズのライターインスタンスとリーダーインスタンスを用意していました。
リーダーインスタンスをスケールダウンした際に、空きローカルストレージ (MB)の変化を確認していました。

db.t3.large から db.t3.medium へスケールダウンします。

改めて、空きローカルストレージ (MB)を確認してみましょう。

リーダーインスタンスのローカルストレージが減りました。

漠然と"Auroraのストレージ"とひと括りにしてしまっていましたが、よく考えたらローカルストレージとはなんでしょうか。
枯渇したりするのでしょうか。

Auroraのローカルストレージ

ローカルストレージはクラスターがデータ保存に使うストレージとは違います。
以下に記載があります。

永続データに使用されるストレージが共有クラスターストレージで、これは使用状況に応じて自動拡張されます。
共有クラスターストレージに関するメトリクスは、Cloudwatchメトリクスでは クラスターの VolumeBytesUsed が該当します。

一方、今回確認していたものは一時的なデータとログに使用されるストレージで、これをローカルストレージと言います。
用途としては、エラーログ・一時ファイル・一時テーブルなどはローカルストレージに保存されます。

ローカルストレージは自動スケールされません。
よって、状況によってはストレージ不足でエラーが発生する場合があります。

また、このストレージサイズは次に記載のとおりインスタンスサイズで決まります。

各 Aurora DB インスタンスには、DB インスタンスクラスによって決定される制限された量のローカルストレージが含まれています。通常、ローカルストレージの容量は DB インスタンスのメモリ容量の 2 倍です。

だから、スケールダウンで、リーダーレプリカのローカルストレージが減っていたのですね。

何か対処方法はあるのか

ローカルストレージサイズについてはインスタンスサイズのスケールアップ以外に調整する方法はありません。

ただし、ローカルストレージサイズをどの程度使うかに関するオプションがいくつか用意されています。

前述したトラブルシューティングの記事から抜粋すると、インスタンスパラメータで調整可能な設定項目があります。
インスタンスパラメータの log_temp_files です。
デフォルトは-1でログ記録を無効化しています。0だと有効化され一時ファイル情報をログに記録します。正の数値の場合指定されたキロバイト数異常のファイルのみをログに記録します。

0 の場合は log_retention_period を気にしたほうが良いです。
なお、ドキュメントでは rds.log_retension となっていますが、 rds.log_retention_period が正しいです。
これはログのローテーション期間を示しています。

一時的にログを出力するとして、残す期間を短くすることで枯渇を防ぐということですね。

単位は分で、デフォルトは 4320分=72時間=３日 です。
ウォッチして枯渇しそうであればこのあたりのパラメータを調整すると良さそうですね。

まずはrds.log_retention_periodを確認するのが有効ですが、トラブルシューティング記事は他にもいくつか関連するオプションについて言及されていますのでそちらも参照してください。

まとめ

• Auroraのストレージは何でも自動スケールしてくれるわけではない。
• ローカルストレージは使用状況を確認したほうが良い。
• 逼迫している場合は、スケールアップするかパラメータグループを調整すると良い。

参考