AWS RDSの「storage-full」状態からの復旧：即時の解決策と長期的な予防策

RDSの「storage-full」によるパニック

通常、それは最悪のタイミングで発生します。アプリケーションが500エラーを出し始め、AWSコンソールには恐ろしい赤色のステータスが表示されます。storage-fullです。これは単なる警告ではありません。データベースエンジンが書き込みを受け付けなくなるクリティカルな状態です。多くの場合、ファイルシステムの整合性を保護するために、既存の接続を完全に切断します。

RDSインスタンスのディスク使用率が100%に達すると、「Available」ステータスを失います。具体的には以下のエラーメッセージが表示されます。

DB instance is in storage-full state. The instance may not be able to accept connections or perform writes.

60秒でできる復旧手順

AWS RDS コンソールを開きます。
データベースを選択し、修正をクリックします。
ストレージ割り当てを見つけます。値を少なくとも20%または50 GB増やし、余裕を持たせます。
一番下までスクロールして続行をクリックし、すぐに適用を選択します。
ステータスが「Modifying」から「Available」に戻るのを待ちます。

なぜディスクがいっぱいになったのか？

データ増加だけが原因であることは稀です。多くの場合、隠れたオーバーヘッドが容量を消費しています。たった一つの暴走したバックグラウンドジョブが原因で、100 GBのボリュームがクラッシュするのを何度も見てきました。以下の主な要因に注意してください。

未コミットのトランザクション： MySQLやPostgresでは、長時間実行されている1つのトランザクションがバイナリログのパージをブロックすることがあります。これらのログは数時間で簡単に50 GB以上に膨れ上がります。
一時ファイルのアウトオブメモリー： RAMに収まらない複雑な結合や大規模なORDER BY操作は、ディスクにtmpファイルを書き込みます。1つの不適切なクエリが、数分で20 GBのスペースを食いつぶすことがあります。
ログの肥大化： log_outputを「FILE」に設定し、ローテーションをスキップすると、スロークエリログはボリュームが枯渇するまで増え続けます。

解決策1：スピード重視のAWS CLI活用

障害発生中にコンソールが重いときは、ターミナルが最適です。このコマンドは即座にストレージ拡張を実行します。

# ストレージを100GBから150GBに増量
aws rds modify-db-instance \
    --db-instance-identifier my-production-db \
    --allocated-storage 150 \
    --apply-immediately

警告： ストレージの増量は永続的です。一度プロビジョニングしたRDSボリュームを縮小することはできません。スケールアップ後、インスタンスは数時間「storage-optimization」状態になります。このプロセスが完了するまで、再度ストレージサイズを変更することはできません。

解決策2：手動でのクリーンアップ

インスタンスクラスの最大ストレージ制限に達している場合は、手動でデータを削除する必要があります。まだ接続を試みることができる場合は、以下のコマンドを試してください。

MySQL/MariaDBの場合：

内部ログを強制的にローテーションして、すぐに容量を回収します：

CALL mysql.rds_rotate_general_log;
CALL mysql.rds_rotate_slow_log;

PostgreSQLの場合：

ストレージを圧迫している最大のテーブルや、孤立した一時ファイルを見つけます：

SELECT relname, pg_size_pretty(pg_total_relation_size(relid))
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 10;

解決策3：オートスケーリングで「設定したらおまかせ」

このエラーを手動で直すのはやめましょう。AWSが代わりに処理してくれます。ストレージのオートスケーリングは、空き容量が一定期間10%を下回ると自動的に増量をトリガーします。

RDSインスタンスの修正メニューに移動します。
ストレージのオートスケーリングを有効にするチェックボックスをオンにします。
ストレージの最大しきい値を設定します（例：1000 GB）。この上限設定により、バグによる暴走で数千ドルのコストが発生するのを防げます。

検証：本当に修正されたか？

緑色の「Available」ライトだけを信じてはいけません。以下の3つのチェックでシステムの健全性を確認してください：

書き込みテスト： 小さなテストテーブルを作成し、エンジンが再びデータを受け付けているか確認します。

CREATE TABLE rds_check (id INT); INSERT INTO rds_check VALUES (1); DROP TABLE rds_check;

  
  - **CLIステータスの確認：**
    ```
aws rds describe-db-instances --db-instance-identifier my-production-db --query 'DBInstances[*].DBInstanceStatus'

CloudWatchの監視： FreeStorageSpaceメトリクスが上昇傾向にあるか、安定していることを確認します。

重要な注意事項

6時間の待機期間： ストレージを一度変更すると、AWSはその後6時間、さらなるストレージ変更をロックします。1 GBだけ追加するのではなく、少なくとも24時間は持つ分を追加してください。
IOPSのスケーリング： プロビジョンドIOPS（io1）を使用している場合、パフォーマンス比率はストレージサイズに依存します。速度を維持するために、ストレージと一緒にIOPSもスケールする必要があるかもしれません。
パフォーマンスの低下： 拡張は稼働中のボリュームに対して行われます。基盤となるEBSボリュームの最適化中、レイテンシが5〜10%増加する可能性があります。