Snapshot & Backup

社内勉強会で発表した内容です。

Transcript

1. Snapshot & Backup 2020.10.06 第54回 このサービスは俺に聞け勉強会 (クラスメソッド社内勉強会) Takuya Shibata
2. 2 自己紹介 Takuya Shibata - AWS事業本部 コンサルティング部 - ソリューションアーキテクト - 2018年12月入社 - Microsoft MVP (PowerShell) - 好きなAWSサービス
3. 3 はじめに 私はストレージガチ勢ではありません 発表内容に誤りがある場合はやさしく ご指摘いただけると助かります
4. 4 今日お伝えしたいこと Snapshot ≠ Backup スナップショットはバックアップではない
5. 5 今日お伝えしたいこと Snapshot ≠ Backup スナップショットは バックアップになる場合もある
6. 6 ご清聴ありがとうございました？
7. 7 アジェンダ 1. スナップショットとは？ 2. スナップショットとバックアップ 3. AWSにおけるスナップショット • Amazon EBS編 • Amazon RDS編 • その他サービス
8. 8 スナップショットとは？
9. 9 スナップショット ここで言う「スナップショット」はもちろん ストレージデバイスにおけるスナップショット • ストレージデバイス上の特定時点におけるイメージ
10. 10 スナップショットの方式 代表的なスナップショットの方式 1. Clone / Split mirror 2. Copy on Write (COW) 3. Redirect on Write (ROW) 4. Copy on Write + Background copy
11. 11 1. Clone / Split mirror • 単純に実データの複製を取るClone • コピー中は複製元に対する書き込みを止める必要有り
12. 12 1. Clone / Split mirror • ミラーリングしているボリュームを切り離し、 その間にCloneを取るSplit mirror
13. 13 2. Copy on Write (COW) • スナップショット取得時はメタデータをコピー • データ更新時に当該領域のコピーを生成
14. 14 3. Redirect on Write • スナップショット取得時はメタデータをコピー • データ更新時は新領域に書き込み
15. 15 4. Copy on Write + Background copy • 基本はCopy on Write • スナップショット取得と同時にCloneを作成開始
16. 16 スナップショット と バックアップ
17. 17 スナップショットとバックアップ スナップショットはバックアップになるか？ 方式 複製の有無 バックアップになるか Clone / Split mirror 〇 〇 Copy on Write × × Redirect on Write × × Copy on Write + Background copy 〇 〇
18. 18 スナップショットとバックアップ バックアップの要件として データが複製されることは必須
19. 19 シンプルな問い データが複製されていれば バックアップ足りえるのか？
20. 20 バックアップの整合性 (Consistency) バックアップがバックアップ足りえるためには、 対象に応じた整合性(Consistency)が求められる 整合性が無ければ壊れたデータの複製に過ぎない • (ストレージ)デバイスとしての整合性 • ファイルシステムとしての整合性 • OSとしての整合性 • アプリケーションとしての整合性
21. 21 (ストレージ)デバイスとしての整合性 大抵の場合ストレージデバイスは固有のブロックサイズ 単位でデータを保持する • ブロックコピー中の状態で複製されない 大抵のストレージデバイスはキャッシュを持つ • キャッシュ上のデータがデバイスに書き出されて いる • デバイスのメタデータと実データが一貫している
22. 22 ファイルシステムとしての整合性 デバイスと同様にファイルシステムもブロックサイズ 単位でデータを保持する • ブロックコピー中の状態で複製されない 大抵のファイルシステムもキャッシュを持つ • キャッシュ上のデータがファイルに書き出されて いる • ファイルシステムとしてデータが一貫している
23. 23 OSとしての整合性 OSはファイルシステム上の各種ファイルの集合体 • ファイルシステムとしての整合性がある • 構成するファイルが不足なく複製されている OSは性能のため様々なキャッシュを持つ • メモリ上のデータがファイルに書き出されている • OS全体として一貫している
24. 24 アプリケーションとしての整合性 アプリケーションはOS上に構成されるが、OSの状態 に依存しないことも多い • ファイルシステムとしての整合性がある • 構成するファイルが不足なく複製されている アプリケーションの種類によってはキャッシュを持つ こともある • メモリ上のデータがファイルに書き出されている • アプリケーション全体として一貫している
25. 25 整合性を保つための重要な要素 • スナップショット取得中のデバイスへの書き込みを どう防ぐか？ • スナップショット取得に際し中途半端なコピーを どう防ぐか？ • スナップショット取得時にキャッシュ(メモリ)上の データをどう書き出すか？ • 対象における「整合性」の定義を把握する
26. 26 AWSにおけるスナップショット (Amazon EBS編)
27. 27 Amazon EBS スナップショット ポイントインタイムスナップショットを作成することで、Amazon EBSボリュームのデータを Amazon S3 にバックアップできます。スナップショットは増分バックアップです。つまり、最後に スナップショットを作成した時点から、ボリューム上で変更のあるブロックだけが保存されます。こ れにより、スナップショットを作成するのに要する時間が最小限に抑えられ、データを複製しないこ とで、ストレージコストが節約されます。各スナップショットには、(スナップショットを作成した 瞬間から) データを新しい EBS ボリュームに復元するために必要な情報がすべて含まれます。 スナップショットに基づいて EBS ボリュームを作成すると、新しいボリュームは、スナップショッ トの作成に使用された元のボリュームの完全なレプリカとなります。すぐに使用を開始できるよう、 レプリケートされたボリュームはバックグラウンドでデータを読み込みます。まだ読み込まれていな いデータにアクセスした場合、ボリュームは要求されたデータを Amazon S3 から即座にダウン ロードし、引き続きボリュームの残りのデータをバックグラウンドで読み込みます。詳細については、 「Amazon EBS スナップショットの作成」を参照してください。 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSSnapshots.html
28. 28 Amazon EBS スナップショット EBSスナップショットの実装方式は非公開 • Copy on Write + Background copyに近い (+増分も) • S3に複製を作成するためバックアップ足りえる
29. 29 Amazon EBS スナップショット EBSスナップショットの整合性は「クラッシュ整合性」 (ただし、なぜかドキュメントでは明言されていない…) • デバイスとしての整合性 ファイルシステム/OS/アプリケーションレベルの 整合性では無い このためいくつかの追加機能が提供されている • マルチボリュームクラッシュ整合性 • Volume Shadow Copy(VSS)を使った アプリケーション整合性を保ったスナップショット
30. 30 マルチボリュームクラッシュ整合性 EC2インスタンスに紐づく複数のEBSボリュームに 対し同時にスナップショットを取得 • 複数EBSでRAIDを組んでいる場合などに有効
31. 31 VSSを使ったスナップショット Volume Shadow Copy (VSS)の機能を使い、 アプリケーション整合性を持ったスナップショットを取得 • Windows EC2インスタンス専用機能 • 専用コンポーネント＋SSM Run Commandを使用
32. 32 AMI作成時の大事なオプション 「インスタンスの停止」は整合性を取る一番わかりやすい方法
33. 33 AMI作成時の大事なオプション インスタンスを停止せずに取得したAMI(EBS)は 「掃除のおばちゃんが稼働中サーバーの電源 ケーブルを引っこ抜いた状態」 に近い (注：おばちゃん以外の清掃員の場合も同様である) • メモリ上にあるデータが保存されていない
34. 34 余談 EBSスナップショットの増分管理については以下の EBS Direct APIの紹介記事がわかりやすい • https://aws.amazon.com/jp/blogs/aws/new-programmatic-access-to-ebs-snapshot-content/
35. 35 AWSにおけるスナップショット (Amazon RDS編)
36. 36 DBスナップショット Amazon RDSの物理バックアップ方式として 「DBスナップショット」が提供されている • DBスナップショットの実装方式は非公開 • EBSスナップショットを拡張したものに見受けられる • RDBMSはそれぞれ固有の方式で整合性を保つ物理バックアップ が可能であり、おそらく、 DBスナップショットはそれを実装 していると予想 • スナップショットの整合性はAWSが担保 • 明記されたドキュメントは無い、が、そもそも論として 整合性を担保してくれないとリストアできない…
37. 37 AWSにおけるスナップショット (その他サービス)
38. 38 その他サービスのバックアップと整合性 • 主要なAWSサービスのバックアップ方式は非公開 • 手動バックアップはスナップショットを使ったものに見受けられる • とはいえ、EFSのバックアップはスナップショットを使ってなさそうだが… サービス バックアップ方式 整合性に関する記述 備考 Amazon Aurora 非公開 ・バックアップの保存先 はS3 「Aurora のバックアップは継続的 かつ増分的であるため、バック アップ保持期間の任意の時点にす ばやく復元できます」 自動または手動バック アップ Amazon DynamoDB 非公開 ・バックアップの保存先 はS3とされる 「DynamoDB バックアップでは、 項目間の因果整合性は保証されま せん。ただし、バックアップの更 新間のスキューは、通常 1 秒未満 です」 自動またはオンデマン ドバックアップ Amazon EFS 非公開 ・AWS Backupによる独自 方式 ・増分バックアップ 「バックアップの実行中にファイ ルシステムに変更が加えられると、 データの重複、相違、欠落などの 不整合が生じる場合があります」 2020年7月から自動 バックアップもサポー ト
39. 39 まとめ Snapshot ≠ Backup スナップショットはバックアップではない
40. 40 まとめ Snapshot ≠ Backup スナップショットは バックアップになる場合もある