Slide 1

Slide 1 text

Snapshot & Backup 2020.10.06 第54回 このサービスは俺に聞け勉強会 (クラスメソッド社内勉強会) Takuya Shibata

Slide 2

Slide 2 text

2 自己紹介 Takuya Shibata - AWS事業本部 コンサルティング部 - ソリューションアーキテクト - 2018年12月入社 - Microsoft MVP (PowerShell) - 好きなAWSサービス

Slide 3

Slide 3 text

3 はじめに 私はストレージガチ勢ではありません 発表内容に誤りがある場合はやさしく ご指摘いただけると助かります

Slide 4

Slide 4 text

4 今日お伝えしたいこと Snapshot ≠ Backup スナップショットはバックアップではない

Slide 5

Slide 5 text

5 今日お伝えしたいこと Snapshot ≠ Backup スナップショットは バックアップになる場合もある

Slide 6

Slide 6 text

6 ご清聴ありがとうございました?

Slide 7

Slide 7 text

7 アジェンダ 1. スナップショットとは? 2. スナップショットとバックアップ 3. AWSにおけるスナップショット • Amazon EBS編 • Amazon RDS編 • その他サービス

Slide 8

Slide 8 text

8 スナップショットとは?

Slide 9

Slide 9 text

9 スナップショット ここで言う「スナップショット」はもちろん ストレージデバイスにおけるスナップショット • ストレージデバイス上の特定時点におけるイメージ

Slide 10

Slide 10 text

10 スナップショットの方式 代表的なスナップショットの方式 1. Clone / Split mirror 2. Copy on Write (COW) 3. Redirect on Write (ROW) 4. Copy on Write + Background copy

Slide 11

Slide 11 text

11 1. Clone / Split mirror • 単純に実データの複製を取るClone • コピー中は複製元に対する書き込みを止める必要有り

Slide 12

Slide 12 text

12 1. Clone / Split mirror • ミラーリングしているボリュームを切り離し、 その間にCloneを取るSplit mirror

Slide 13

Slide 13 text

13 2. Copy on Write (COW) • スナップショット取得時はメタデータをコピー • データ更新時に当該領域のコピーを生成

Slide 14

Slide 14 text

14 3. Redirect on Write • スナップショット取得時はメタデータをコピー • データ更新時は新領域に書き込み

Slide 15

Slide 15 text

15 4. Copy on Write + Background copy • 基本はCopy on Write • スナップショット取得と同時にCloneを作成開始

Slide 16

Slide 16 text

16 スナップショット と バックアップ

Slide 17

Slide 17 text

17 スナップショットとバックアップ スナップショットはバックアップになるか? 方式 複製の有無 バックアップになるか Clone / Split mirror 〇 〇 Copy on Write × × Redirect on Write × × Copy on Write + Background copy 〇 〇

Slide 18

Slide 18 text

18 スナップショットとバックアップ バックアップの要件として データが複製されることは必須

Slide 19

Slide 19 text

19 シンプルな問い データが複製されていれば バックアップ足りえるのか?

Slide 20

Slide 20 text

20 バックアップの整合性 (Consistency) バックアップがバックアップ足りえるためには、 対象に応じた整合性(Consistency)が求められる 整合性が無ければ壊れたデータの複製に過ぎない • (ストレージ)デバイスとしての整合性 • ファイルシステムとしての整合性 • OSとしての整合性 • アプリケーションとしての整合性

Slide 21

Slide 21 text

21 (ストレージ)デバイスとしての整合性 大抵の場合ストレージデバイスは固有のブロックサイズ 単位でデータを保持する • ブロックコピー中の状態で複製されない 大抵のストレージデバイスはキャッシュを持つ • キャッシュ上のデータがデバイスに書き出されて いる • デバイスのメタデータと実データが一貫している

Slide 22

Slide 22 text

22 ファイルシステムとしての整合性 デバイスと同様にファイルシステムもブロックサイズ 単位でデータを保持する • ブロックコピー中の状態で複製されない 大抵のファイルシステムもキャッシュを持つ • キャッシュ上のデータがファイルに書き出されて いる • ファイルシステムとしてデータが一貫している

Slide 23

Slide 23 text

23 OSとしての整合性 OSはファイルシステム上の各種ファイルの集合体 • ファイルシステムとしての整合性がある • 構成するファイルが不足なく複製されている OSは性能のため様々なキャッシュを持つ • メモリ上のデータがファイルに書き出されている • OS全体として一貫している

Slide 24

Slide 24 text

24 アプリケーションとしての整合性 アプリケーションはOS上に構成されるが、OSの状態 に依存しないことも多い • ファイルシステムとしての整合性がある • 構成するファイルが不足なく複製されている アプリケーションの種類によってはキャッシュを持つ こともある • メモリ上のデータがファイルに書き出されている • アプリケーション全体として一貫している

Slide 25

Slide 25 text

25 整合性を保つための重要な要素 • スナップショット取得中のデバイスへの書き込みを どう防ぐか? • スナップショット取得に際し中途半端なコピーを どう防ぐか? • スナップショット取得時にキャッシュ(メモリ)上の データをどう書き出すか? • 対象における「整合性」の定義を把握する

Slide 26

Slide 26 text

26 AWSにおけるスナップショット (Amazon EBS編)

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

28 Amazon EBS スナップショット EBSスナップショットの実装方式は非公開 • Copy on Write + Background copyに近い (+増分も) • S3に複製を作成するためバックアップ足りえる

Slide 29

Slide 29 text

29 Amazon EBS スナップショット EBSスナップショットの整合性は「クラッシュ整合性」 (ただし、なぜかドキュメントでは明言されていない…) • デバイスとしての整合性 ファイルシステム/OS/アプリケーションレベルの 整合性では無い このためいくつかの追加機能が提供されている • マルチボリュームクラッシュ整合性 • Volume Shadow Copy(VSS)を使った アプリケーション整合性を保ったスナップショット

Slide 30

Slide 30 text

30 マルチボリュームクラッシュ整合性 EC2インスタンスに紐づく複数のEBSボリュームに 対し同時にスナップショットを取得 • 複数EBSでRAIDを組んでいる場合などに有効

Slide 31

Slide 31 text

31 VSSを使ったスナップショット Volume Shadow Copy (VSS)の機能を使い、 アプリケーション整合性を持ったスナップショットを取得 • Windows EC2インスタンス専用機能 • 専用コンポーネント+SSM Run Commandを使用

Slide 32

Slide 32 text

32 AMI作成時の大事なオプション 「インスタンスの停止」は整合性を取る一番わかりやすい方法

Slide 33

Slide 33 text

33 AMI作成時の大事なオプション インスタンスを停止せずに取得したAMI(EBS)は 「掃除のおばちゃんが稼働中サーバーの電源 ケーブルを引っこ抜いた状態」 に近い (注:おばちゃん以外の清掃員の場合も同様である) • メモリ上にあるデータが保存されていない

Slide 34

Slide 34 text

34 余談 EBSスナップショットの増分管理については以下の EBS Direct APIの紹介記事がわかりやすい • https://aws.amazon.com/jp/blogs/aws/new-programmatic-access-to-ebs-snapshot-content/

Slide 35

Slide 35 text

35 AWSにおけるスナップショット (Amazon RDS編)

Slide 36

Slide 36 text

36 DBスナップショット Amazon RDSの物理バックアップ方式として 「DBスナップショット」が提供されている • DBスナップショットの実装方式は非公開 • EBSスナップショットを拡張したものに見受けられる • RDBMSはそれぞれ固有の方式で整合性を保つ物理バックアップ が可能であり、おそらく、 DBスナップショットはそれを実装 していると予想 • スナップショットの整合性はAWSが担保 • 明記されたドキュメントは無い、が、そもそも論として 整合性を担保してくれないとリストアできない…

Slide 37

Slide 37 text

37 AWSにおけるスナップショット (その他サービス)

Slide 38

Slide 38 text

38 その他サービスのバックアップと整合性 • 主要なAWSサービスのバックアップ方式は非公開 • 手動バックアップはスナップショットを使ったものに見受けられる • とはいえ、EFSのバックアップはスナップショットを使ってなさそうだが… サービス バックアップ方式 整合性に関する記述 備考 Amazon Aurora 非公開 ・バックアップの保存先 はS3 「Aurora のバックアップは継続的 かつ増分的であるため、バック アップ保持期間の任意の時点にす ばやく復元できます」 自動または手動バック アップ Amazon DynamoDB 非公開 ・バックアップの保存先 はS3とされる 「DynamoDB バックアップでは、 項目間の因果整合性は保証されま せん。ただし、バックアップの更 新間のスキューは、通常 1 秒未満 です」 自動またはオンデマン ドバックアップ Amazon EFS 非公開 ・AWS Backupによる独自 方式 ・増分バックアップ 「バックアップの実行中にファイ ルシステムに変更が加えられると、 データの重複、相違、欠落などの 不整合が生じる場合があります」 2020年7月から自動 バックアップもサポー ト

Slide 39

Slide 39 text

39 まとめ Snapshot ≠ Backup スナップショットはバックアップではない

Slide 40

Slide 40 text

40 まとめ Snapshot ≠ Backup スナップショットは バックアップになる場合もある

Slide 41

Slide 41 text

41