GCPのMySQL 「SQL」の機能でもあり、AWS「RDS」の機能でもあるディスクサイズがしきい値以下になると自動的にサイズ拡張してくれる機能があるが、その挙動を確認しました。
密かに尊敬の念を抱くエンジニアブログの触発されました。
RDS Storage Auto Scaling は Write-heavy なデータベースでも使えるか？
詳細は以下 cloud.google.com
ざっくり仕様
・ストレージ容量が500GB未満の場合は
しきい値 ＝ 5 + (provisioned storage)/25
・ストレージ容量が500GB以上の場合は
しきい値 ＝ 25GB
・増加ストレージ容量はしきい値と同じ
・チェック間隔は30秒ごと
・増加する上限設定可能
・増加したあとのクールタイムなし（連続でポンポン増加されることもあり）
SQLスペック
・MySQL 5.7
・vCPU 1
・メモリ 3.75GB
・Disk 50GB
検証
上記のブログと同じようにDBに対してデータ投入してDisk消費します。
GCPの場合「Cloud Shell」があるのでそこからDBにアクセスしました。
結果
以下グラフを見てもらえれば一目瞭然なのですがRDS同様にDisk自動拡張が実行されたとき（DiskUtilizationが下がったとき）にクエリ数とWrite数が上がっています。
内部的な挙動としてはRDSと同じようにresize2fs的なことをしてるとおもわれます。
アクセスピーク時に実行されないように気をつけないとですね！！！
またRDSと決定的に違うのが
「Disk自動拡張のクールタイムがない」
ということです。
AWSでは
DB インスタンスのストレージサイズを変更すると、DB インスタンスのステータスは Storage-optimization になります。ストレージ変更後、DB インスタンスは完全に動作します。ただし、6 時間 あるいは DB インスタンスステータスが Storage-optimization の間のいずれか長い方の間は、ストレージに変更を加えることはできません。
とあります。
6時間もしくはステータス：Storage-optimizationの間は自動拡張されない（最低6時間以上ってこと？）です。
GCPの場合このようなルールがないので以下のような状況にもなります。
後半４つの山で自動拡張されてます。
DBへデータ投入しながらなので絶えずしきい値をさがるような状況だとこうなります。
本番環境だと想定外の大量データ投入されるというのはなかなかないかもしれませんが（無いとは言ってない）問題まったないですね。
気をつけましょう。
以上
