![[新機能] リストア直後からフルパフォーマンス！EBS で Fast Snapshot Restore（FSR）が可能になりました](https://devio2023-media.developers.io/wp-content/uploads/2019/05/amazon-ebs.png)
[新機能] リストア直後からフルパフォーマンス！EBS で Fast Snapshot Restore（FSR）が可能になりました
こんにちは、菊池です。
熱いアップデートがきました。EC2で利用するブロックストレージ、Amazon EBS でリストア直後からフルパフォーマンスを発揮できる Fast Snapshot Restore（FSR）が登場しました！
これにより、スナップショットから作成したEBSでもプレウォーミングなしで本来の性能が発揮できるようになります。
そもそもプレウォーミング（初期化）って？
スナップショットから作成したEBSは、初回のアクセス時にS3からプルダウンされることになります。そのため、作成直後はアクセス時のレイテンシが通常よりも大きく、本来EBSに割り当てられたIOパフォーマンスを下回る状態です。そのため、100%のパフォーマンスを発揮するには、ボリュームの全ブロックに対しアクセスをかける必要があります。
通常OSのシステム領域などであれば問題になることはほとんどありませんが、データベースのデータ領域のようにIO性能を求められる用途の場合、スナップショットから復元時の初期化作業が必要で、フルパフォーマンスを発揮するまでに時間がかかっていました。
Fast Snapshot Restore
FSRの特徴
今回登場したFSRをスナップショットに対して有効化することで、そのスナップショットからのEBS作成時に、プレウォーミングなしでフルパフォーマンスが出せるようになります。
- スナップショットのオプションとして設定
- AZ単位で有効/無効が設定可能
- 追加の料金が発生
料金
FSRを有効化すると追加のコストが発生します。（執筆時点、日本語ページは未更新だったため英語ページで確認）
有効化するAZと保持時間（最小1時間）ごとに1DSUという単位で課金されます。東京リージョンの場合、1DSU あたり $0.90です。上記リンクに記載の例だと、あるスナップショットに対し、3つのAZで、1.5時間保持した場合、$0.90 x 3 AZ x 1.5時間 = $4.05の利用料が発生します。
FSRを試してみる
早速試してみます。
FSRの有効化
すでに取得済みのスナップショットを指定して、[Manage Fast Snapshot Restore] を選択します。
有効化するAZを選択できます。ここではap-northeast-1aを選びました。
すると、設定したスナップショットで[スナップショットの高速復元] が [optimizing] というステータスになっています。
ap-northeast-1aがoptimizingであることがわかります。
しばらくすると、[enabled]になりました。ドキュメントによると、1TiBあたり60分程度かかるようです。
設定したスナップショットからの復元は通常の手順です。AZを選択すると、FSRが有効化どうかが確認できます。
パフォーマンス
FSRあり、なしそれぞれの状態で復元したEBSのパフォーマンスを確認します。100GBのEBSのスナップショットからEBS復元し、Amazon Linux 2、m5.largeのインスタンスにアタッチして、作成直後の状態で以下のコマンドでIOをしばらくかけました。
# fio --filename=/dev/nvme2n1 --rw=read --bs=16k --iodepth=32 --ioengine=libaio --direct=1 --name=volume-initialize
FSRなし
FSRなしで復元したEBSでは、600IOPSに届かない程度です。
FSRあり
一方、FSR有効の状態で復元したボリュームは、バーストした最大値である3000IOPSが安定して出ています。FSRの効果がはっきりと確認できました。
まとめ
新機能であるEBSスナップショットのFSRを試しました。
スナップショットから復元してすぐにフルパフォーマンスでの利用が可能になるので、IO性能を要求するワークロードで嬉しい機能です。一方で、利用コストはかなり大きくなりますので、複数世代のスナップショットのうち直近世代のみ有効化する、必要なAZのみ有効化するなど、うまく利用していくことが求められるかもしれません。
追記：DLMを使った世代管理をこちらのエントリにて紹介しました。
