Fast Snapshot Restore 利用時にはボリューム作成クレジットの枯渇に注意しましょう

Fast Snapshot Restore によるボリューム作成時にはボリューム作成クレジットにお気をつけください。

#Amazon EBS

#AWS

西野亘

2020.09.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

哈喽大家好、コンサルティング部の西野です。

Fast Snapshot Restore (FSR) によるボリューム作成がうまくいかない事象に遭遇したため、あらためてこの機能の仕組みと注意点についてまとめてみます。

最初に結論

FSR を利用してボリュームを作成するためには、スナップショットで FSR が有効化されているだけでは不十分であり、ボリューム作成クレジットが足りていなければなりません。
このボリューム作成クレジットが不足している状態でスナップショットからボリュームを作成した場合、FSR は実行されず（つまり通常通りスナップショットからの復元が実行され）、ファーストタッチペナルティを免れ得ません。

何のことを言っているかサッパリな皆さま！是非この続きをお読みください。

そもそも Fast Snapshot Restore (FSR) とは

スナップショットから作成されたボリュームにおいては、ストレージブロックへのアクセス前に当該ブロックを S3 からプルダウンし対象ボリュームに書き込むプロセスが必要です。

このため、EBS が本来持つパフォーマンスをすぐに発揮できず、I/O レイテンシーが高まる可能性がありました。この状態はファーストタッチペナルティと呼ばれています。

従来、ファーストタッチペナルティを避けるためには EBS 内の全ストレージブロックにあらかじめアクセスし S3 からのプルダウンを実施しておくプレウォーミング作業が必要だったのですが、FSR の登場によりこのプレウォーミングが不要になりました。

FSR についてはリリース時の下記ブログもご参照ください。

[新機能] リストア直後からフルパフォーマンス！EBS で Fast Snapshot Restore（FSR）が可能になりました

FSR をあらためて試してみる（失敗パターン）

FSR の有用性をご理解いただいたところであらためて実験をしてみましょう。下記の作業を実施します。

検証用の EBS ボリューム (10GB gp2) を作成
当該ボリュームのスナップショットを作成
当該スナップショットで Fast Snapshot Restore を有効化
このスナップショットから 11 個のボリュームを作成

元となるボリュームおよびスナップショットの作成方法については割愛します。

まずはスナップショットの FSR を有効化しましょう。対象スナップショットを指定し、下記コマンドを実行します。

$ aws ec2 enable-fast-snapshot-restores  \
   --availability-zones ap-northeast-1a \
   --source-snapshot-ids snap-025856e921e6fdec1
{
    "Successful": [
        {
            "SnapshotId": "snap-025856e921e6fdec1",
            "AvailabilityZone": "ap-northeast-1a",
            "State": "enabling",
            "StateTransitionReason": "Client.UserInitiated",
            "OwnerId": "272361093094",
            "EnablingTime": "2020-09-12T14:08:22.263000+00:00"
        }
    ],
    "Unsuccessful": []
}

FSR の有効化にはしばらく時間がかかります。（TiB あたり 60 分）
しばらく待ったあと、下記コマンドで状態を確認してみます。

$ aws ec2 describe-fast-snapshot-restores \
     --filters Name=snapshot-id,Values=snap-025856e921e6fdec1
{
    "FastSnapshotRestores": [
        {
            "SnapshotId": "snap-025856e921e6fdec1",
            "AvailabilityZone": "ap-northeast-1a",
            "State": "enabled",
            "StateTransitionReason": "Client.UserInitiated - Lifecycle state transition",
            "OwnerId": "272361093094",
            "EnablingTime": "2020-09-12T14:08:22.263000+00:00",
            "OptimizingTime": "2020-09-12T14:09:09.426000+00:00",
            "EnabledTime": "2020-09-12T14:09:44.691000+00:00"
        }
    ]
}

State が enabled となっているので、対象スナップショットにおいて FSR が有効化されている状態です。無事有効化できたので、このスナップショットからボリュームを作成してみましょう。
(矢印キー ↑と return キーを駆使し) 下記のコマンドを 11 回実行します。

$ aws ec2 create-volume --snapshot-id snap-025856e921e6fdec1 --availability-zone ap-northeast-1a
{
    "AvailabilityZone": "ap-northeast-1a",
    "CreateTime": "2020-09-12T15:21:46+00:00",
    "Encrypted": false,
    "Size": 10,
    "SnapshotId": "snap-025856e921e6fdec1",
    "State": "creating",
    "VolumeId": "vol-09294b66f11fd0346",
    "Iops": 100,
    "Tags": [],
    "VolumeType": "gp2"
}
※残り 10 回は割愛

温かみがあるコマンド入力が終わったところで、作成されたボリュームの状態を確認してみましょう。 $ aws ec2 describe-volumes の output には FastRestored というフィールドがあり、ここを見ることで FSR によって作成されたボリュームであるか否かを確認できます。

FastRestored -> (boolean)
Indicates whether the volume was created using fast snapshot restore.
https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-volumes.html

下記のコマンドを実行します。Snapshot ID でフィルターをかけたあと、CreateTime でソートし、VolumeId / CreateTime / FastRestored の値を表示させています。

$ aws ec2 describe-volumes \
  --filter "Name=snapshot-id,Values=snap-025856e921e6fdec1" \
  --query "sort_by(Volumes,&CreateTime)[*].[VolumeId,CreateTime,FastRestored]" \
  --output text
vol-09294b66f11fd0346	2020-09-12T15:21:46.330000+00:00	True
vol-0eab906e585e0b305	2020-09-12T15:21:49.452000+00:00	True
vol-0a302e5a9841bd80b	2020-09-12T15:21:51.788000+00:00	True
vol-0ebe694205c41d2e6	2020-09-12T15:21:53.893000+00:00	True
vol-09380dd2c803e52ce	2020-09-12T15:21:55.813000+00:00	True
vol-03d176b2e7d9e9b36	2020-09-12T15:21:57.766000+00:00	True
vol-04f8d54468f5f2791	2020-09-12T15:21:59.623000+00:00	True
vol-0ec045522f09eddcd	2020-09-12T15:22:01.367000+00:00	True
vol-0b5bbbcd593ebcc29	2020-09-12T15:22:03.305000+00:00	True
vol-061180ce63ff391dd	2020-09-12T15:22:05.138000+00:00	True
vol-02f78723e1c861983	2020-09-12T15:22:07.185000+00:00	None

11 個目に作成したボリューム (vol-02f78723e1c861983) の FastRestored (3列目) を見ると、None になっています。これは、Fast Snapshot Restore によって作成されたボリュームではない ことを表しています。

スナップショットでは FSR が有効化されており、そのスナップショットから作成された 1〜10 個目のボリュームは無事 FSR によって作成されています。

何故、 11 個目のボリュームのみこのようになってしまったのでしょうか？

なぜ失敗したのか？

実は、FSR によってボリュームを作成するためには下記の2つの条件を満たす必要があります。

ボリュームの作成元スナップショットにおいて FSR が有効化されていること
ボリューム作成クレジット (FastSnapshotRestoreCreditsBalance) が足りていること

前節の実験においては、作成元スナップショットの FSR が有効化されていたものの、11 個目のボリューム作成時点でボリューム作成クレジットが枯渇していました。これこそが FSR によってボリュームが作成されなかった理由です。

ここからこのボリューム作成クレジットについて詳しく見ていきましょう。

ボリューム作成クレジットとは

いくつか新しい用語が出てきますがご辛抱ください。

FSR が有効化されたスナップショットからボリュームを作成するためにはボリューム作成クレジットと呼ばれるクレジットが必要です。このボリューム作成クレジットはボリュームを 1 つ作成するたびに 1 消費されます。

ボリューム作成クレジットはスナップショットごとに用意されたクレジットバケットに補充され、CloudWatch メトリクス FastSnapshotRestoreCreditsBalanceで観測できます。

クレジットバケットにはサイズがあり、ボリューム作成クレジットはこのサイズを満たすまで時間経過とともに増加していきます。この際の増加量が補充レートです。

クレジットバケットのサイズと補充レートは下記のように計算されます。

クレジットバケットのサイズ

クレジットバケットのサイズはボリューム作成クレジットの最大量を規定する値であり、下記の式で計算できます。

MAX (1, MIN (10, FLOOR(1024/snapshot_size_gib)))

FLOOR は小数点以下を切り捨てて整数を返します。

先述の例だとスナップショットサイズは 10 GB であったため、MAX (1, MIN (10, FLOOR(1024/10))) = MAX (1, MIN (10, 102)) = MAX (1, 10) = 10となり、クレジットバケットのサイズは 10 です。

仮にスナップショットが 256 GB であった場合、MAX (1, MIN (10, FLOOR(1024/256))) = MAX (1, MIN (10, 4)) = MAX (1, 4) = 4 なので、クレジットバケットのサイズは 4 です。

クレジットバケットの補充レート

クレジットバケットの補充レートは 1 時間あたりに補充されるクレジットのことであり、下記の式で計算できます。

MIN (10, 1024/snapshot_size_gib)

先述の例だとスナップショットサイズは 10 GB であったため、MIN (10, 1024/10) = MIN (10, 102.4) = 10 となり、補充レートは 10 (1 時間あたり 10 クレジット) となります。

スナップショットが 256 GB であった場合、MIN (10, 1024/256) = MIN (10, 4) = 4 なので、補充レートは 4 です。

クレジットバケットのサイズと補充レートの例

スナップショットのサイズに応じたクレジットバケットのサイズおよび補充レートのサンプルを用意してみました。
参考までにご覧ください。

スナップショットのサイズ(GB)	クレジットバケットのサイズ	クレジットバケットの補充レート(per hour)
64	10	10
128	8	8
256	4	4
512	2	2
1024	1	1
2048	1	0.5
4096	1	0.25
8192	1	0.125
16384	1	0.0625

クレジットバケットのサイズはスナップショットのサイズが 1024 GB に達した時点で最小になり、それ以降減ることがありません。ボリューム作成時に 1 つのボリューム作成クレジットを消費しなければならないので、当然といえば当然ですね。

一方で、クレジットバケットの補充レートはスナップショットのサイズと反比例して減少し続けるので注意が必要です。

FSR の利用計画時に注意すべきこと

まずは下の画像をご覧ください。先の実験時におけるボリューム作成クレジット (FastSnapshotRestoreCreditsBalance) を表したスクリーンショットです。

（実験の裏でボリューム作成クレジットが 10 貯まる前に一度ボリューム作成をしていたため 23:15 過ぎに谷ができていますが、気にしないでください。）

あるスナップショットで FSR を有効化すると、ボリューム作成クレジットは 0 から補充されていきます。つまり、スナップショットにおける FSR の有効化直後には FSR を利用することができないということです。FSR を実際に利用するためには、ボリューム作成クレジットが少なくとも 1 貯まるまで待たないといけません。

FSR を有効化すると料金が発生するため、コストを抑える目的でボリュームの作成前後に FSR を有効化・無効化するケースもあるかと存じます。このような計画を建てる際はボリューム作成クレジットが補充される時間を考慮に入れてください。

先述した表の通り、たとえばスナップショットのサイズが 16,384 GB である場合、補充レートは 0.0625 です。したがって、ボリューム作成クレジットが 1 に達するまで (FSR によるボリューム作成が可能になるまで) 16 時間を要します。