効率的なデータバックアップを実現!Amazon EBSの新機能「時間ベースのスナップショットコピー」を解説

クラウドコンピューティングの世界では、データ保護と災害復旧(DR)戦略の重要性が日々高まっています。
企業がデジタル資産を守り、ビジネスの継続性を確保するためには、効果的かつ効率的なバックアップソリューションが不可欠です。
この度、AWSが発表した Amazon Elastic Block Store (EBS) の新機能「時間ベースのスナップショットコピー」は、まさにこのニーズに応える画期的なソリューションです。
この機能により、ユーザーはスナップショットを自動的に別のリージョンにコピーすることができ、より強固なデータ保護とDR戦略の実現が可能となります。
また、この機能が実装される前はスナップショットのコピーがいつ終わるかわからず、災害対策におけるRPOを満たすことができるか不安定という問題点がありました。
DR戦略の信頼性向上や関連する運用タスクのスケジューリングが容易になるなどのメリットが見込まれそうです。
本記事では、この新機能の詳細、その重要性、そして実際の設定方法について深掘りしていきます。
クラウド環境でのデータ管理に携わる方々にとって、非常に有益な情報となるでしょう。
企業がデジタル資産を守り、ビジネスの継続性を確保するためには、効果的かつ効率的なバックアップソリューションが不可欠です。
この度、AWSが発表した Amazon Elastic Block Store (EBS) の新機能「時間ベースのスナップショットコピー」は、まさにこのニーズに応える画期的なソリューションです。
この機能により、ユーザーはスナップショットを自動的に別のリージョンにコピーすることができ、より強固なデータ保護とDR戦略の実現が可能となります。
また、この機能が実装される前はスナップショットのコピーがいつ終わるかわからず、災害対策におけるRPOを満たすことができるか不安定という問題点がありました。
DR戦略の信頼性向上や関連する運用タスクのスケジューリングが容易になるなどのメリットが見込まれそうです。
本記事では、この新機能の詳細、その重要性、そして実際の設定方法について深掘りしていきます。
クラウド環境でのデータ管理に携わる方々にとって、非常に有益な情報となるでしょう。
機能概要
今回追加された機能は、スナップショットをAWSアカウント内、またはクロスアカウントでコピーを行う際に指定した時間以内に作業を完了するよう期間設定ができるという機能です。
例えば、今までだと夜中の1時に東京リージョンでスナップショットを取得して、大阪リージョンにコピーを行う際に、データ容量によっては数時間かかっていました。
つまり、災対環境の大阪にバックアップの退避が完了するのは、スナップショットの取得が完了してから数時間後という状況でした。
もし、このコピー時間中に災害が発生した場合はどうなるでしょうか?
退避が完了していないので、災対環境に切り替えたとしても直近である夜中の1時に取得したバックアップは大阪では使えません。
もう1世代前のコピーが完了しているものを使うしかなかったのです。
これではRPO要件を定めることが困難でした。
それが今回のアップデートではコピーの期間を最小15分から最大48時間まで指定できるようになったということです。
条件はありますが、最小の15分としておけば、夜中1時に取得したバックアップが1時15分には大阪リージョンにコピー完了しているという計算になります。
これであればRPO要件も定義できますし、満たすような設計も取りうると考えられます。
例えば、今までだと夜中の1時に東京リージョンでスナップショットを取得して、大阪リージョンにコピーを行う際に、データ容量によっては数時間かかっていました。
つまり、災対環境の大阪にバックアップの退避が完了するのは、スナップショットの取得が完了してから数時間後という状況でした。
もし、このコピー時間中に災害が発生した場合はどうなるでしょうか?
退避が完了していないので、災対環境に切り替えたとしても直近である夜中の1時に取得したバックアップは大阪では使えません。
もう1世代前のコピーが完了しているものを使うしかなかったのです。
これではRPO要件を定めることが困難でした。
それが今回のアップデートではコピーの期間を最小15分から最大48時間まで指定できるようになったということです。
条件はありますが、最小の15分としておけば、夜中1時に取得したバックアップが1時15分には大阪リージョンにコピー完了しているという計算になります。
これであればRPO要件も定義できますし、満たすような設計も取りうると考えられます。
注意点
本機能を使う上での注意点です。
スナップショットのコピーにおいて、スループットの制約が発生します。
つまり、どれほど大きなデータを持つスナップショットでも15分以内を確約できるというわけではありません。
なので、逆に15分以内でコピーを完了させる場合は、439GiB以下なら可能です。
累積も合わせて考えると、439GiBのスナップショットを4本同時に15分以内でのコピーは可能だと考えられます。
このように、スナップショットの容量を考慮して、同時にコピーする容量や本数を緻密にコントロールすることが必要になりそうですね。
大まかにスナップショット容量と可能な最速転送速度を表に整理します。
累積は考慮していないので、全て1つのスナップショットをコピーする場合で考えてください。
スナップショットのコピーにおいて、スループットの制約が発生します。
つまり、どれほど大きなデータを持つスナップショットでも15分以内を確約できるというわけではありません。
- 1つのスナップショットコピーでは、最大スループット:500MiB/秒
- 複数のスナップショットコピーでの累積最大スループット:2000MiB/秒
※この制約は上限緩和可能 - 時間は15分間隔で設定可能。(15分以内、30分以内、45分以内....)
- スループットの制約を超えるコピーリクエストが発生した場合、指定した時間内にコピーが完了しないことがある。
- 時間ベースのスナップショットコピーで転送したデータ料に応じて追加料金が発生する。
なので、逆に15分以内でコピーを完了させる場合は、439GiB以下なら可能です。
累積も合わせて考えると、439GiBのスナップショットを4本同時に15分以内でのコピーは可能だと考えられます。
このように、スナップショットの容量を考慮して、同時にコピーする容量や本数を緻密にコントロールすることが必要になりそうですね。
大まかにスナップショット容量と可能な最速転送速度を表に整理します。
累積は考慮していないので、全て1つのスナップショットをコピーする場合で考えてください。
スナップショット容量 | 最速コピー時間 |
---|---|
0GiB~439GiB | 15分 |
440GiB~878GiB | 30分 |
879GiB~1318GiB | 45分 |
1319GiB~1757GiB | 60分 |
機能検証
①適当に容量の大きいスナップショットを大阪リージョンにコピーしてみます。
たまたま、507GiBのものがあったので使ってみます。

②送信先リージョンを大阪(ap-northest-3)にして、時間ベースのコピーを有効化します。
時間は15分に設定してみます。
スループットの制限に引っかかるので、おそらく15分以内には終わらず、15~30分以内になるだろうと想定しています。
これでスナップショットのをコピー開始します。

③コピーを開始した段階で転送先にはガワだけ作成されるみたいですね。
転送タイプは「時間ベース」になっていますし、完了期間も「15分」となっていますので、ここで時間ベースのスナップショットコピーを行ったか否かを判断できそうです。

④無事にコピーが完了しました。
時間は11分54秒と想定より大幅に早い結果になりました。

⑤CloudWatchメトリクスの「SnapshotCopyBytesTransferred」で転送容量が見れるようなので、確認してみます。
このメトリクスは、1分間隔の合計転送容量になりますので、数式で1秒間の平均転送容量に直します。
表を見る限りでは、平均的に1GiB/s近くの転送速度が出ているように見えます。
もしかすると、AWSとして保証する最低速度が500MiB/sで状況によっては上振れすることもあるというものなのかもしれません。

たまたま、507GiBのものがあったので使ってみます。

②送信先リージョンを大阪(ap-northest-3)にして、時間ベースのコピーを有効化します。
時間は15分に設定してみます。
スループットの制限に引っかかるので、おそらく15分以内には終わらず、15~30分以内になるだろうと想定しています。
これでスナップショットのをコピー開始します。

③コピーを開始した段階で転送先にはガワだけ作成されるみたいですね。
転送タイプは「時間ベース」になっていますし、完了期間も「15分」となっていますので、ここで時間ベースのスナップショットコピーを行ったか否かを判断できそうです。

④無事にコピーが完了しました。
時間は11分54秒と想定より大幅に早い結果になりました。

⑤CloudWatchメトリクスの「SnapshotCopyBytesTransferred」で転送容量が見れるようなので、確認してみます。
このメトリクスは、1分間隔の合計転送容量になりますので、数式で1秒間の平均転送容量に直します。
表を見る限りでは、平均的に1GiB/s近くの転送速度が出ているように見えます。
もしかすると、AWSとして保証する最低速度が500MiB/sで状況によっては上振れすることもあるというものなのかもしれません。

まとめ
災対環境を用意するシステムも増えてきた中で、バックアップの退避は大きな課題でした。
特に大規模なDBを持つようなシステムでは、バックアップを災対環境に退避するだけでも大きな時間がかかりRPOが伸びる原因でもありました。
今後、スループットも増えていき、より高速に災対環境へのバックアップ転送が行えるようになるとよりDR対策が取りやすくなりますね。
ぜひ使ってみてください。
特に大規模なDBを持つようなシステムでは、バックアップを災対環境に退避するだけでも大きな時間がかかりRPOが伸びる原因でもありました。
今後、スループットも増えていき、より高速に災対環境へのバックアップ転送が行えるようになるとよりDR対策が取りやすくなりますね。
ぜひ使ってみてください。