EC2(EBS)のリストア時の性能低下を解消する方法3選！

EBSボリュームをスナップショットから作成した場合、ディスク性能が劣化するという問題があります。

これは、スナップショットからのディスク復元時に、データを全てEBSに投入した状態で復元はされず、初期状態ではS3に保管されているためこのような問題が発生します。

この問題を解消するには、「プレウォーミング」というボリュームの初期化処理が必要になります。

今回は、リストア時の性能低下を解消する方法を3つご紹介すると同時に実際に試して比較を行っていきます。

EBSスナップショットの復元時に性能低下が発生する理由は、スナップショットのデータがAmazon S3に格納されていることに起因します。

通常、EBSボリュームはAmazon Elastic Block Store (EBS)に直接保存され、高速な読み書きが可能ですが、スナップショットはコスト削減と耐久性向上のためにS3に保存されます。



復元時には、S3からEBSへのデータ転送が発生するため、最初のアクセス時にレイテンシーが増加し、IO性能が低下します。



S3に保存されているデータは、初回アクセス時に自動的にEBSにロードされるため、次回以降は通常の性能が出ます。



また、S3からEBSへのデータロードは逐次行われているため、時間が経てば自動的に性能が戻ります。

実際にEBSのスナップショットからリストアした直後はどの程度性能が劣化するのか確認してみます。

100GBでIOPSは3000、スループット125MB/秒のEBSを使用して検証してみます。

まずは、通常時の性能を測定します。

操作	IOPS	スループット
読み取り	1633 IOPS	6532 KiB/s
書き込み	2979 IOPS	11.6 MiB/s

■読み取りテスト(正常時)


■書き込みテスト(正常時)


次にスナップショットからリストアした直後の読み取りと書き込みを測定します。

操作	IOPS	スループット
読み取り	11 IOPS	44 KiB/s
書き込み	2767 IOPS	10.8 MiB/s

■読み取りテスト(リストア直後)


■書き込みテスト(リストア直後)


読み取りの速度が大幅に劣化しているのがわかります。

書き込み速度はほぼ変わらないので、リストア後に影響があるのは読み取り性能だけとわかりますね。
読み取り性能は、1/1000以下になっていますので、かなりの性能劣化です。

前からリストア後はウォームアップしないと性能が出ないことは知っていましたが、これほど落ちるとは予想していませんでした。

ちなみに、スナップショットからリストア後、24時間放置してみると読み取り性能は回復したので、放置してもいずれは復活するようです。

操作	IOPS	スループット
読み取り	1617 IOPS	6470 KiB/s

■読み取りテスト(24時間放置後)


ただ、いつ回復するかわからないので本番運用では使いづらいですね。

基本的にはこの後紹介する性能回復方法を採用するのがおすすめです。

手動ウォームアップ

スナップショットからリストア後に性能が劣化するのはデータがS3にあるからです。

ただし、データに一度でもアクセスすれば、EBSにロードされるので全てのデータに一度アクセスしてしまえば性能が回復するということです。

ということで、リストア後にEBSをEC2にアタッチし、OSにて全てのデータにアクセスするコマンドを実行するのが、「手動ウォームアップ」です。

■コマンド

dd if=<デバイスパス> of=/dev/null bs=1M

実際に100GBのEBSボリュームすると以下のような結果になりました。

■開始時刻	■終了時刻	■ウォームアップ時間
13時45分40秒	14時39分32秒	00時間53分52秒

100GB程度の容量だと、大体1時間以内くらいでウォームアップは完了しました。

そのまま、読み取り速度の計測を行ってみます。

若干、本調子ではないように見えますが、ほぼほぼ性能が回復しました。

操作	IOPS	スループット
読み取り	1406 IOPS	5628 KiB/s

■読み取りテスト

Fast Snapshot Restore (FSR)

Fast Snapshot Restore(FSR)は、AWSにて事前にスナップショットに対してウォームアップを掛けておいてもらい、リストア直後から性能劣化を起こさず復旧させる方法です。

取得したスナップショットに対して、この機能を有効化しておくだけで使えます。

ただし、リージョンごとに最大 5 つのスナップショットしか有効にできないうえ、有効化している間は1AZあたり$0.90/hの料金がかかります。

①スナップショットを選択し、「アクション」-「スナップショットの設定」-「スナップショットの高速復元の管理」を押下します。


②EBS復元するAZをチェックして、「有効化」を押下します。


③注意事項を確認して、「有効化」を押下します。


④ステータスが、「有効」になったら完了です。


実際にこの機能を有効化したスナップショットを復元して、性能を測定してみます。

復元して、即座に読み取りをしてみましたが、ほぼほぼ性能劣化無しの状態です。

これであれば、本番環境においてリストア後も性能影響なくサービスを再開させることができそうですね。

操作	IOPS	スループット
読み取り	1463 IOPS	5853 KiB/s

■読み取りテスト(リストア直後)

EBS Provisioned Rate Volume Initialization

EBS Provisioned Rate Volume Initializationは、2025年5月6日に提供が開始された機能です。

この機能ではスナップショットからEBSのリストア時に、「手動プレウォーム」で行ったような作業をAWSが自動で実行してくれるような機能になります。

プレウォームのための初期化速度を指定して実行することになるので、その速度に従って初期化を行ってくれます。

FSRと違い事前に終わらせておくわけでないので、スナップショットからEBSへの復元後、性能が回復しきるまでに時間は必要になります。

ただ、初期化の速度が指定できる関係で、いつプレウォームが終わるか予測しやすく、また自動で行ってくれる点でも運用を楽にしてくれる機能といえるでしょう。

料金は、設定した初期化の速度によって変わります。

ボリューム初期化レート	料金
100 MB/秒〜200 MB/秒	USD 0.00290/GB
201 MB/秒〜300 MB/秒	USD 0.00430/GB

この機能の使い方は、スナップショットからEBSボリュームを作成する画面で、「ボリューム初期化レート(MiB/秒)」を設定してリストアを行うだけです。


実際にこの機能でリストアしたボリュームの性能を測定してみます。

リストア完了した直後は性能が半分くらいまで落ちていますが、全くプレウォームしていない時と比較するとリストア直後でもある程度の性能回復が見込めそうです。

操作	IOPS	スループット
読み取り	945 IOPS	3780 KiB/s

■読み取りテスト(リストア直後)


そのまま20分程度何もせずに放置して、もう一度測定してみました。

今度は完全回復ですね。

リストア時に指定して、後は何もせずともこの速度で性能回復してくれるので結構便利ですね。

操作	IOPS	スループット
読み取り	1611 IOPS	6446 KiB/s

■読み取りテスト(20分後)

項目	①完全放置	②手動プレウォーム	③Fast Snapshot Restore (FSR)	④EBS Provisioned Rate Volume Initialization
回復時間	数時間〜数日 実際のアクセスパターンに依存	30分〜数時間 ボリュームサイズと実行方法に依存	即座 初回アクセスから高性能	数分〜1時間 設定速度と実使用容量に依存
手間・運用負荷	最小 設定不要、完全自動	大 スクリプト作成・実行・監視が必要	中 事前有効化が必要、運用は自動	低 ボリューム作成時の設定が必要
コスト	最安 追加費用なし	低 EC2インスタンス稼働時間分	高 \$0.75/月/スナップショット/AZ	中 初期化中の高速化分のIOPS料金
適用シーン	• 性能要件が緩い • コスト最優先 • 段階的性能向上で問題なし	• 一回限りの復元 • 柔軟な制御が必要 • 技術リソースがある	• 頻繁な復元作業 • 即座の高性能が必要 • コストよりも時間優先	• 予測可能な復元時間 • バランス重視 • 新機能を活用したい
メリット	• 設定不要 • 追加コストなし • シンプル	• 柔軟な制御 • カスタマイズ可能 • 既存技術で実現	• 即座に高性能 • 完全自動化 • 予測可能	• 時間とコストのバランス • 予測可能な復元時間 • 設定が比較的簡単
デメリット	• 性能回復が遅い • 初期性能が不安定 • 予測困難	• 手動作業が必要 • スクリプト管理 • 時間がかかる	• 高コスト • AZ毎の設定必要 • 使わない場合も課金	• 比較的新しい機能 • 追加コストが必要 • 設定が必要

スナップショットから復元時のEBS性能回復の方法をご紹介しました。

色々な手段がありますが、それぞれコストや手間という点でメリット/デメリットが分かれます。

運用において、EC2のリストアはどうしても発生することがあります。

いざ起きた時に急には決められないので、事前に設計しておき、必要に応じて手順も用意しておきたいところです。

今回の内容を参考に、自分のシステムがどのような手法が良いのか考える参考になれば幸いです。