GCP のスナップショットについて手を動かして学んだことをまとめる
はじめに
お仕事において、溜まっているスナップショットを削除したいのですが、このスナップショットについて ganyariya はあまり詳しくありませんでした。
このままではどのスナップショットを残すべきか確信が持てず、とりあえず残すか...という安牌になってしまいます。
そのため、実際にディスクに対してスナップショットを取って削除することで、スナップショットの挙動について学びました。
この記事では GCP における スナップショット で知っておきたい挙動について個人用にまとめます。
なお、 GCP のドキュメントですべて記載されている内容ですので、公式ドキュメントを優先して参考いただいたほうがよいです。
ただし、読む のと 実際に手を動かす では体験が異なるほか、視点も異なるためまとめておきます。
Scrap & Repository
自分は上記にまとめながらスナップショットの挙動を確認しました。
この記事で扱うこと
- ganyariya が手を動かしてあらためて確認したスナップショットの挙動
この記事で扱わないこと
- GCP におけるマシンイメージ・ディスク・スナップショットの違い
- スナップショットのベストプラクティス
- スナップショットの細かい挙動
- GCP におけるスナップショットの種類
参考リンク
前提知識
先に知っておくとよさそうな前提知識について記載します。
増分バックアップと差分バックアップの違いについて
増分バックアップ と 差分バックアップ は異なります。
上記の記事を参考ください。
GCP スナップショットは増分バックアップである
そのうえで、 GCP のスナップショットは 増分バックアップ です。
前回取得したスナップショットからの変更点のみを取得して新しいスナップショットとします。
GCP ディスクスナップショット増分バックアップの挙動について
行った手順とその結果については上記の Scrap を参考ください。
そこで得られた ganyariya のまとめのみ記載します。
1 つ前のスナップショットとの変更差分のみスナップショットに含める
GCP のスナップショットは 増分バックアップ です。
1 つ前のスナップショットとの変更差分のみ取得するため、新たにとるスナップショットのサイズが最小限になります。
実際に上記で行ったときも、ランダムに生成したファイル 10MB 強のみが差分として検知されました。
よって、ファイルを多く変更しないシステムがのディスクについては、増分バックアップを取ることでサイズが抑えられて費用削減に繋がりそうです。
一方で、ファイルを多く変更するシステムの場合、繰り返し増分バックアップを取ることで、総合すると元のディスクサイズを大幅に超えるスナップショットとなってしまいます。
たとえば、元のディスクが 10GB であるのに対し、毎回のスナップショットで 5GB ぶんのファイルが変更されるとします。
この場合 10 回スナップショットを取るだけで 50GB になり、元のディスクサイズを大幅に超えてしまいます。
重要: スナップショットでは、重複データに対する請求を避け、保存容量の使用量を最小限に抑えるために、増分のみがバックアップされます。ただし、スナップショットの履歴の信頼性を確保するために、スナップショットでディスク全体のイメージが取得される場合があります。これは、保存容量を最大化し、ストレージ費用を最小限に抑えるために自動的に行われます。増分スナップショットと完全スナップショットのどちらを作成するかを選択する必要はありません。スナップショットがディスクの完全なイメージをキャプチャしたとき、そのディスクの以前の増分スナップショットは変更されません。
しかし、上記のように記載があるため、変更が多い場合はフルバックアップを GCP が選択してくれるのかもしれませんね。
自分が扱うシステムにおいてはスナップショットを取る 2 点間において変更量が十分小さいため、増分バックアップで問題ありません。
X 番目のスナップショットを削除した場合 X+1 番目にマージされる
増分バックアップを定期的に取るたびに、スナップショットが溜まってきます。
放置しているとストレージ費用がかかってしまうため、古いものから削除したいです。
このとき、古いものを削除したときにデータが消えてしまわないか、途中のものを削除したときに不整合が起きないか心配になっていました。
GCP においては X 番目に取ったスナップショットを削除した場合、以下の挙動になります。
- X 番目のスナップショットデータは X + 1 番目にマージされる
- 1, 2, ... X-1 番目までのスナップショットは一切変更されない
- X 番目のスナップショットは削除される
- X + 1 番目のスナップショットにデータがマージされ、サイズが変わる
- X + 1 番目のスナップショットの参照先は X - 1 番目になる
中間のスナップショットを削除したとしても、そのときのデータがきちんと保持されるためありがたいですね。
X 番目のスナップショットをソースディスクに指定した場合 1 ~ X 番目までが適用される
新しいディスクを作成するときにソースディスクとしてスナップショットを指定できます。
このとき、好きな X 番目のスナップショットを指定でき、その際 1 ~ X 番目までのスナップショットが順に適用されます。
つまり、 X 番目のときのディスクがそのまま復元されます。
この挙動によって、もし N 番目のスナップショットのときに障害が発生してデータが壊れていたとしても、 N - 1 番目を指定することで無事だったころのデータが手に入ります。
最後に
今回の操作によって、スナップショットについて理解が深まりました。
この記事には記載していないですが、スナップショットスケジュールについても試しある程度理解が得られました。
あとは実際に業務のなかで残すべきものと削除すべきものを決めて費用削減していきたいと思います。
Discussion