EBSのFast Snapshot Restore（FSR）を試してみた

こんにちは！CSM課岩渕です。
EBSのFast Snapshot Restore（FSR）について全然知らなかったので、試してみました。

Fast Snapshot Restore（FSR）って何それ？　何がいいの？

Fast Snapshot Restore（FSR）は、EBSのスナップショットのリストアを高速でできちゃうよ！　という機能。
FSRを有効化した状態で、スナップショット復元を行うと、完全に初期化（事前ウォーミング）された状態でボリューム作成ができるので、初回アクセス遅延なしで、プロビジョンドパフォーマンスを即座に使用できる。というもの。

上記の説明で、「なるほどね～」と分かる方は以下の「FSRを使う上で知っておかなければならない事」まで読み飛ばして下さい～　因みに私は「何言ってるのかさっぱり分からん！」でした。。。
ということで、まずは「初期化と遅延」について調べてみました。

スナップショットから復元されたボリュームへのアクセスは、ストレージブロックがAmazon S3からプルダウンされてボリュームに書き込こまれると可能になります。この事前処理には一定の時間がかかるため、各ブロックへの初回アクセス時には、I/O 操作のレイテンシーが著しく増加する可能性があります。ボリュームのパフォーマンスは、すべてのブロックがダウンロードされてボリュームに書き込まれると正常値に達します。

Amazon EBS ボリュームの初期化
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-initialize.html

とあります。つまりはこんな感じですね。

スナップショットから復元されたボリュームにアクセスするとき、復元直後で手元に対象ブロックのデータがない場合は、S3に取りに行く。
取りに行くので時間がかかる（＝レイテンシー(遅延)発生）。取ったブロックデータは、手元のボリュームに落としておく。次回、同じデータにアクセスする場合は、手元のデータにアクセスするので、もう時間はかからない。
でも、違うブロックデータにアクセスする場合は、またS3に取りに行く。
取りに行くので時間がかかる（＝レイテンシー発生）。取ったブロックデータは、手元のボリュームに落としておく。を繰り返す。
全ブロックデータをボリュームに落とし込んだら、やっと、レイテンシー無しでの全データアクセスが可能となる。

※S3にアクセスする際のレイテンシー発生によりボリュームのパフォーマンスが５０％も低下する場合があるそうです！
※このスナップショットからの復元後の初回アクセス時の性能低下のことを
　・初回アクセス遅延
　・ファーストタッチペナルティ
　・ファーストタッチレイテンシー
　といったりするようです。

遅延については納得ですね。
と同時に、対策として、スナップショットから復元したら、使用開始する前に、全ブロックにアクセスしておけばいいんじゃない？　ということにもなりますよね。
そのためのコマンドがこれ↓

[ec2-user ~]$ sudo dd if=/dev/xvdf of=/dev/null bs=1M
または
[ec2-user ~]$ sudo fio --filename=/dev/xvdf --rw=read --bs=128k --iodepth=32 --ioengine=libaio --direct=1 --name=volume-initialize

Amazon EBS ボリュームの初期化 - [Linux の Amazon EBS ボリュームの初期化]
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-initialize.html

※ fioの方が高速
※/dev/xvdf の「xvdf」部分は、読み出しデバイスの名前に応じて変更する必要あり

このようにボリューム内の全ブロックに事前アクセスすることでパフォーマンス低下を回避することを
・初期化
・事前ウォーミング
・プレウォーミング
などというそうです。
で、このddやfioコマンドで「初期化」をしてあげればいいだけなら、それでいいような気がしますよね。
でも、これ時間がかかるんです。

3. デバイスのすべてのブロックを読み取るには、dd ユーティリティまたは fio ユーティリティを使用します。Linux システムにデフォルトでインストールされているのは dd コマンドですが、マルチスレッドの読み取りが可能な fio の方が、処理速度が大幅に速くなります。
注記
このステップは、使用している EC2 インスタンスの帯域幅、ボリュームに対してプロビジョニングされている IOPS、そしてボリュームのサイズに応じて、数分から数時間かかることがあります。

Amazon EBS ボリュームの初期化 - [Linux の Amazon EBS ボリュームの初期化]
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-initialize.html

開発環境だったら、待ってもらうのもありかもしれませんが、本番環境だったら１秒でも早く開始できるようにしたいですよね。
そこで、やっとFSRの登場です。

改めまして、
Fast Snapshot Restore（FSR）って何それ？　何がいいの？

Fast Snapshot Restore（FSR）は、EBSのスナップショットのリストアを高速でできちゃうよ！　という機能。
FSRを有効化した状態で、スナップショット復元を行うと、完全に初期化（事前ウォーミング）された状態でボリューム作成ができるので、初回アクセス遅延なしで、プロビジョンドパフォーマンスを即座に使用できる。というもの。

ここまでで、「FSRを使わない手はないじゃない！」って思ったあなた、ちょっと待って下さい！
FSRを使う上で、知っておかなければならない事があります。

FSRを使う上で知っておかなければならない事

コストに注意！

例えば、
・東京リージョンの1スナップショットに対して2つのAZを指定して、
　FSRを12時間有効にした場合
　０.９ × 1スナップショット × ２AZ × １２時間＝２１.６ドル！
・東京リージョンの1スナップショットに対して2つのAZを指定して、
　FSRを1か月有効にし続けた場合
　０.９ × 1スナップショット × ２AZ × ７４４時間＝１３３９.２ドル！

Amazon EBS Fast Snapshot Restore
Fast Snapshot Restore の課金は、それが有効化された各アベイラビリティゾーンでの、データサービス単位時間 (DSU) に基づきます。DSU への請求は、最低で 1 時間分から毎秒ごとに発生します。

Fast Snapshot Restore：有効化された各 AZ で 1 DSU 時間あたり0.90USD
※東京リージョン

Amazon EBS の価格 - [Amazon EBS Fast Snapshot Restore]
https://aws.amazon.com/jp/ebs/pricing/

なので、「必要な時間だけ」FSRを有効にすることが大事です。
そして、リストアが完了したら、FSRを無効に戻せば良いわけです。
※いつリストアが発生するか分からない状況で、FSRを有効化し続けるのは、予算が潤沢にあったとしても、かなり勿体ない気がします。そのコストをかけるくらいなら、初期化（事前ウォーミング）に時間がかかっても問題ない基盤設計に修正した方がいいですね。

こちらも、ぜひ参考にご一読ください。
設楽さんのFSRを数日間有効にしつづけた結果、課金がやばくなった話です。

AWS利用料を使いすぎた話
http://blog.serverworks.co.jp/tech/2020/03/16/awscost-overuse/

FSRを有効化するのに時間がかかるよ！

スナップショットのサイズに応じてFSRの有効化には時間がかかります。
TiBあたり60分かかるので、1GBあたり約3.51秒、100GBなら約351秒です。
「今すぐ、FSRを有効化して、リストアしたいんだ～」って言われても、すぐには出来ません。

スナップショットに対して高速スナップショット復元を有効にすると、以下のいずれかの状態になります。
enabling — 高速スナップショット復元の有効化がリクエストされました。
optimizing — 高速スナップショット復元の有効化中です。スナップショットの最適化には TiB あたり 60 分を要します。
enabled — 高速スナップショット復元は有効になっています。
disabling — 高速スナップショット復元の無効化がリクエストされました。または、高速スナップショット復元の有効化のリクエストが失敗しました。
disabled — 高速スナップショット復元は無効になっています。高速スナップショット復元は必要に応じて再度有効にすることができます。

Amazon EBS 高速スナップショット復元 - [高速スナップショット復元の状態]
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html

FSRを有効にした複数スナップショットを、一度に全てをリストアした場合、
全てが初期化された状態でリストアされるとは限らないよ！

これ、ちょっと分かりにくいんですが、初期化されるボリューム数は「クレジット」の数で決まります。

高速スナップショット復元のパフォーマンスの利点を全面的に享受するボリュームの数は、スナップショットのボリューム作成クレジットの数によって決まります。
・・・
たとえば、サイズが 100 GiB のスナップショットに対して高速スナップショット復元を有効にすると、そのクレジットバケットの最大サイズは 10 クレジットとなり、補充レートは 1 時間あたり 10 クレジットになります。クレジットバケットが満杯である場合、このスナップショットからは同時に 10 個の初期化済みボリュームを作成できます。

Amazon EBS 高速スナップショット復元 - [ボリューム作成クレジット]
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html

共有スナップショットには使えないよ！

他と共有しているスナップショットに対してFSRを有効化することはできません。

では、FSRを試行してみましょう

既にスナップショットが存在している状態から始めます。
スナップショットを作成すると同時にFSRを有効化することも可能ですが、ここではFSR設定していないスナップショットから始めます。
FSRが有効化されていないスナップショットの場合、以下のように「スナップショットの高速復元」の欄に何も表示されていない状態です。
[スナップショット] - [アクション] - [Manage Fast Snapshot Restore] を選択します。
次にAZを選択します。必要な分だけ、 AZ を選択して「Save」を押下して下さい。
「スナップショットの高速復元」のステータスが以下の順で変化します。
１．enabling — 高速スナップショット復元の有効化がリクエストされました。
２．optimizing — 高速スナップショット復元の有効化中です。
３．enabled — 高速スナップショット復元は有効になっています。
以下例では、100GBのスナップショットですので、計算通り約６分ほどで「enabled」になりました。
あとは、普通にボリュームを作成して、アタッチすればOKです。
因みにFSRが有効化されているスナップショットからボリュームを作成する場合、
以下のように「Fast Snapshot Restore」が「enabled」になっています。ボリュームを作成し終わったら、課金を抑えるために、さっさとFSRを無効に戻しておきましょう。
再び [スナップショット] - [アクション] - [Manage Fast Snapshot Restore] を選択して、
先ほどチェックONにしたAZをOFFにすることで無効化します。
無効にすると「スナップショットの高速復元」のステータスが以下の順で変化します。
１．disabling — 高速スナップショット復元の無効化がリクエストされました。
　　　または、高速スナップショット復元の有効化のリクエストが失敗しました。
２．disabled — 高速スナップショット復元は無効になっています。
　　　高速スナップショット復元は必要に応じて再度有効にすることができます。