Cloud SQLのストレージ自動増量の注意点

こんにちは。次世代システム研究室のM.Mです。

あるプロジェクトでGCPのCloud SQL(PostgreSQL)を使い始めて約1年経過しました。
そのCloud SQLを利用しているサービスも成長して、登録されているデータもかなり多くなってきました。

登録されるデータが増えても、Cloud SQLのストレージ自動増量の設定のおかげで、勝手に利用しているストレージサイズが増えていくため、運用が楽だなと思っておりました。
実際に、約1年の間で数回ストレージサイズが自動で増えました。

約1年が経過し、そろそろデータ削除の運用も始めたほうがよいと考え、不要になった古いデータを削除した際に問題が起きてしまいました。

1. Cloud SQLのストレージ自動増量の注意点と起きた問題

注意点については、ちゃんとマニュアルに記載がありました。

データベースに対する書き込みが多いと、大量のトランザクション ログが生成され、かなりのディスク スペースを消費する可能性があります。ストレージの自動増量が有効になっているインスタンスでは、ディスクが増大する原因になります。インスタンスのストレージ サイズは、トランザクション ログの保持を考慮して調整することをおすすめします。

今回起きた問題は、上記に記載があるトランザクションログの保持を考慮して調整することに失敗したことが原因です。

• ストレージ自動増量でストレージサイズが増える状況になっていた
• トランザクションログの保持期間内に大量のデータ更新を行った

このケースに当てはまると、一時的なデータ更新・削除だったとしても、ストレージサイズが増える可能性が高くなります。
ストレージサイズが増えると、トランザクションログの保持期間が経過してトランザクションログが削除され、ストレージ使用量が減っても、一度、ストレージサイズが増えると減ることはないので、ストレージに対する料金が上がったままになるので要注意です。

以下のグラフは実際にデータ削除を行った際のストレージサイズとストレージ使用量の傾向になります。
トランザクションログの保持期間はデフォルトの7日にしておりました。
トランザクションログは1日1回削除されるので、毎日、ストレージ使用量が徐々に増えた後に、一気に減るというような動きになっています。

■実施内容
・6/9から大量データ削除を開始、数日間実施しました。

上記グラフから、データ削除を始めた6/9あたりから、トランザクションログ保持期間中(7日間)はストレージ使用量が大きく増え続け、ストレージ自動増量でストレージサイズが増えていることが分かります。
その後、トランザクションログ保持期間後からストレージ使用量が減り始めているのが分かります。

数日間の一時的な大量データ削除運用ではありましたが、逆にストレージサイズを増やしてしまうという問題を起こしてしまいました。

2. Cloud SQLのストレージ使用量の比較検証

Cloud SQLには自動バックアップ、ポイントインタイムリカバリ、可用性構成といった設定が可能です。
先ほどのトランザクションログはポイントインタイムリカバリに関わってくるログになっています。
可用性構成、バックアップの保持期間、トランザクションログの保持期間の違いで、ストレージ使用量にどのような違いがでるか比較します。

■ストレージ使用量を比較するCloud SQLの構成

• A: トランザクションログ 7日間保持
• B: トランザクションログ 保持なし
• C: トランザクションログ 2日間保持

※バックアップあり/なしによるストレージ使用量の違いはありませんでした。
※シングル構成/可用性構成によるストレージ使用量の違いはありませんでした。（可用性用のストレージ料金が適用される）

■実施する内容
上記A, B, Cに対して

• 10,000,000件 insertする (DBデータサイズは約1G程度になりました）
• 全件 deleteする

A: トランザクションログ 7日間保持

・10,000,000件 insert後
⇒ ストレージ使用量は約5.7G

・全件 delete後
⇒ ストレージ使用量は約7.4G
※ 削除のトランザクションログが増えた。

B: トランザクションログ 保持なし

・10,000,000件 insert後
⇒ ストレージ使用量は約2.7G
※ トランザクションログが保持されず、上記Aと比較して3G程度の差がでた。

・全件 delete後
⇒ ストレージ使用量は約1.5G
※ 削除のトランザクションログが増えることもなく、ストレージ使用量が減少した。

C: トランザクションログ 2日間保持

・10,000,000件 insert後
⇒ ストレージ使用量は約5.7G
※ 上記Aと保持期間は違うもののトランザクションログは有効にしているので上記Aと同じ結果になった。

・トランザクションログ保持期間(2日)経過後
⇒ ストレージ使用量は約2.7G
※トランザクションログが削除され上記Bのinsert後と同じ状態になった。

・全件 delete後
⇒ ストレージ使用量は約4.4G
※ 削除のトランザクションログが増えた。

・トランザクションログ保持期間(2日)経過後
⇒ ストレージ使用量は約1.5G
※ 削除で増えたトランザクションログが削除されて、上記Bのdelete後と同じ状態になった。

3. まとめ

トランザクションログの保持期間の違いで大きな違いがでることが分かりました。
ただ10,000,000件 insert後のDBデータサイズはSQLで調べたら1G程度でした。
他にもWALファイルやアーカイブログなどがあるとしても、上記Aの5.7Gは多いなという印象を受けました。
Cloud SQLはサーバーレスなので、SQLで調べられる範囲でしか、何にどれぐらいストレージが利用されているかが分からないのが残念です。

クラウドサービスには便利な機能が多くありますが、デフォルト設定のまま何も気にしないで利用するのは、思わぬ課金につながることがあります。
ストレージ自動増量でもしっかりストレージ使用量を気にしておくべきでした。

今回、データ削除にてストレージサイズに影響がでてしまいましたが、トランザクションログの保持期間をしっかり検討して設定する。
あらかじめトランザクションログがでないようtruncateで削除できるようなテーブル設計にする。
しばらく放置してデータが多くなってから削除する方針にしない。などできることはあったと思います。

最後に、次世代システム研究室では、グループ全体のインテグレーションを支援してくれるアーキテクトを募集しています。アプリケーション開発の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ募集職種一覧からご応募をお願いします。

皆さんのご応募をお待ちしています。