![[アップデート] 複数のEBS間でクラッシュ整合性を持ったAMIをオンラインで作成できる様になりました](https://devio2023-media.developers.io/wp-content/uploads/2019/05/amazon-ec2.png)
[アップデート] 複数のEBS間でクラッシュ整合性を持ったAMIをオンラインで作成できる様になりました
しばたです。
先日AWSから「 Amazon EC2 now allows you to create crash-consistent AMIs from instances with multiple EBS volumes without rebooting instances 」という内容の更新が発表されました。
これに合わせてAWS Backupでも同様の更新が発表されています。
この更新は非常に誤解を生みやすい内容なので、本記事ではその辺の注意喚起も一緒に解説していきます。
いったい何が更新されたのか？
まずは今回の更新がどういうことか解説します。
Amazon Machine Images(AMI)はAWSで使用する仮想マシンイメージであり内部的にEBSスナップショットが構成情報として紐づけられています。
(https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html より)
これまでEBSスナップショットでは1つのEC2インスタンスで使用されている複数のEBS間でクラッシュ整合性のあるスナップショットを取得する事ができたのですが、AMIの作成(CreateImage API)においては対応していませんでした。
今回の更新でこの複数EBS間でクラッシュ整合性のあるスナップショットをAMI作成時にも取得できる様になったとされています。
これにより、従来AMI作成において複数のEBSボリュームに対してクラッシュ整合性を担保したい場合はインスタンスをシャットダウンしなければならなかったのですが、今後はオンラインでAMIを取得する場合でも担保される様になったというわけです。
少しややこしいのですが単一のEBSに対するスナップショットは以前からクラッシュ整合性を担保しているので単一EBSしか紐づいていないAMIは特に影響は受けないはずです。
今回の更新は「 AMIに紐づくすべてのEBSに対して同時に クラッシュ整合性を担保する様になった」というのが要点となります。
そもそもクラッシュ整合性とは何なのか？
ここで大事なのが「 クラッシュ整合性 (crash-consistent) 」とは何なのか？ということです。
残念ながらEBSにおけるクラッシュ整合性を明確に定義したドキュメントは存在しません。
なのでストレージにおける一般用語としてのクラッシュ整合性を簡単に説明すると、クラッシュ整合性は特定時点におけるストレージデバイスとしての整合性です。
例えば巨大データをコピー中にスナップショットを取得しても中途半端な書き込みが混ざること無くストレージデバイスとして整合している、ストレージデバイスとしてエラー無くリストアできる状態を指すものです。
あくまでもストレージデバイスとしての整合であるため、上記の様なコピー中データは高確率で中途半端な状態になりますし、加えて、ファイルシステムやアプリケーションがメモリ上に持つ未書き込みのデータ[1]にも一切関知しません(＝保存しません)。
有り体に言ってしまうと「 今この瞬間のストレージデバイスの状態はいい感じに保存するよ。ただし中にあるファイルとかの状態は一切知らんけど。 」という事です。
加えて今回は複数EBS間でクラッシュ整合性ですので「デバイスレベルで同時に取得されていることを担保する」という要素も加味する必要があります。
クラッシュ整合性 と アプリケーション整合性
ちなみにですが、クラッシュ整合性に対してストレージデバイス中のファイルやアプリケーション全体の整合性を保った状態を「 アプリケーション整合性 (application-consistent) 」と呼びます。
一般的にアプリケーション整合性を担保するにはOS内部に専用のエージェントプログラムを導入してやる必要があり、このエージェントプログラムがアプリケーションとストレージデバイスの調整を行いより高度な整合性を担保するわけです。
みなさんが期待するものでは無い、という話
おそらく今回の更新を知った皆さんは最初に「これでオンラインでAMIを取得して良い感じのバックアップに使えるんだ。」と考えたのではないでしょうか？
ここまでの説明でそんな皆さんの期待と誤解を打ち砕くことができたと思っております。
AMI(およびEBSスナップショット)をバックアップとして使いたい場合、原則として必要とされるのはクラッシュ整合性ではなくアプリケーション整合性です。
今回の更新はあくまでも「複数EBS間でクラッシュ整合性を担保する」だけですのでほとんどの方にとってはこれまで通り何も変わりません。
今回の更新に関わらず、AMIをバックアップとして使いたい場合は
- インスタンスをシャットダウンする
- インスタンス停止により クラッシュ整合性＝アプリケーション整合性 となる
- Volume Shadow Copy Services(VSS)を使ったEBSスナップショットを使う
- 専用エージェントとVSSがアプリケーション整合性を担保する
などの方式を採りアプリケーション整合性を担保する様にしてください。
参考情報 : スナップショットはバックアップではない
以前スナップショットとバックアップについて社内勉強会で発表した際の資料がありますので、こちらも併せてご覧ください。
では今回の更新の意義はどこにあるのか？
今回の更新の恩恵を受けるのは以前から複数EBS間でクラッシュ整合性のあるスナップショットを利用している方となります。
これまで複数EBS間でクラッシュ整合性のあるスナップショットをバックアップとして使っていた方にAMIという選択肢が増えたのが一番のメリットです。
AWSで紹介されている一例を出すと、複数EBS間でクラッシュ整合性のあるスナップショットをOracle Databaseのバックアップとして利用しているケースで、こういった場合にEBSスナップショット以外にAMIを取得する選択肢が増えた形となります。
(ちなみに上記はEBSはクラッシュ整合性のままOracleのOracle Storage Snapshot Optimization[2]とインスタンスリカバリ[3]を使いリカバリするというちょっと複雑な手順なので十分内容を理解したうえで参考にしてください...)
上記以外でもAMIに紐づいているEBSスナップショットがすべて 同時に取得されている ことが要求される場合にも恩恵があるでしょう。
最後に
長々と書きましたが以上となります。
更新自体はシンプルに記載されていますが非常に誤解を生みやすい内容なので慎重に読み解く必要があります。
この記事が誤解を解くための一助になれば幸いです。
