Amazon RDS_DBインスタンスのストレージサイズを縮小するには #374
Amazon RDSとは
Amazon RDSは、クラウド内でデータベースのセットアップ、運用、およびスケールを簡単に行うことのできるマネージド型サービスの集合体です。MySQLやPostgreSQLなどの人気エンジンを簡単にセットアップして使用できるようになります。
RDSのストレージはGB単位で設定でき、かつそれをオートスケールするようにできます。また、オートスケールの上限を決めることも可能です。
ただ注意点として、RDSにおいて、DBインスタンスはストレージのサイズダウンができません（上記のようにサイズアップは可能ですが）。
なぜサイズダウンできないか
これはRDSのパフォーマンス効率の最大化、およびデータの完全性と安全性を確保するための設計上の決定です。データベースのストレージサイズを縮小すると、データ損失のリスクが生じます。
より具体的には、RDSではストレージサイズに応じて複数のディスクが割り当てられており、データはこのディスク群全てに均等に保存されます。例えばあるストレージを確保するために5つのディスクが割り当てられたとしたら、データはこの5つに分散して保存されます。
ストレージサイズを縮小＝割り当てるディスクを削減することですが、上記のようにRDSでは全てのディスクにデータが均等に保存されているため、ストレージサイズの縮小（＝ディスクの削除）はリスクが大きいです。そのため設計上サイズダウンできないようにしている、ということですね。
余談ですが、RDSだけでなくオラクルもこの仕様になってるらしいです。
サイズダウンしたい場合はどうするか
とはいえ元々想定したよりストレージが小さく、サイズダウンしてコスト削減したいケースはあると思います。その場合は新しいDBインスタンスを小さいサイズで作成し、そちらにデータを移行することで実現します。
我々のチームではMySQLのサイズダウンに取り組みました。この時は元のDBインスタンスを論理バックアップ（DBの中身をSQL文（CREATEとINSERT）に変換する）し、そのSQL文を新しいDBインスタンスに実行することで対応しました。
論理バックアップは、ビュー（仮想的な表）を持つデータベースで実行する場合はSQLの実行順に注意が必要です。ビューは特定のテーブルから値を取得するため、元のテーブルを先に作成する必要があるためです。
補論：オートスケールのロジック
公式に以下のように記載されています。
ストレージの自動スケーリングが有効になっている場合、Amazon RDS でデータベースでの空き領域が不足していることが検出されると、自動的にストレージがスケールアップされます。次の要因が当てはまる場合、Amazon RDS によって自動スケーリングが有効な DB インスタンスのストレージ変更が開始されます。
・使用可能な空き領域が割り当てられたストレージの 10% 未満
・低ストレージ状態は 5 分以上続く
・最後のストレージ変更、あるいはインスタンスでストレージの最適化が完了してから少なくとも 6 時間経過
追加のストレージは、次のうちいずれか大きい方の増分です。
・5 GiB
・現在割り当てられているストレージの 10%
・直近 1 時間の FreeStorageSpace メトリクスの変動に基づいて予測される 7 時間のストレージの増分
論理バックアップを適用する際、「直近 1 時間の FreeStorageSpace メトリクスの変動に基づいて予測される 7 時間のストレージの増分」が非常に大きくなる可能性があるのでご注意ください。
仮にサイズダウンしたDBインスタンスに論理バックアップを実行した際、ストレージが足りずにオートスケールが発動してしまった場合などは注意です。直近で大量にデータを挿入しているため、一気に大規模なストレージ増加を引き起こしてしまいます。
オートスケールを有効にする場合は、ストレージ上限の設定は欠かさない方が良さそうです。
おわりに
DBのストレージをどの程度に設定すべきかの判断は、アプリケーションを新規開発する時などは特に難しい問題です。どの程度のサイズになりそうか見積もることはできても、実際に使ってみないと分からないことも多いと思います。
上記のような対応を身につけて、最適化していけるようにしたいですね。
ここまでお読みいただきありがとうございました！
参考
https://pages.awscloud.com/rs/112-TZM-766/images/01_RDS_Architecture.pdf
この記事が気に入ったらサポートをしてみませんか？