re:Invent 2024: AWSがEBS Snapshotsでデータ保護を解説 - FSRやDLMの活用法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Protect critical data with ease using Amazon EBS snapshots (STG205)
この動画では、Amazon EBSのProduct Managerらが、EBS Snapshotsの基本的な仕組みから高度な活用方法まで詳しく解説しています。EBS Snapshotsの増分バックアップの仕組みや、暗号化、Block Public Access、Snapshot Lockなどのセキュリティ機能について説明した後、RISE with SAPの事例として、24テラバイトの大規模HANAシステムでの活用方法が紹介されます。特に、Fast Snapshot Restore（FSR）を活用した本番環境での運用方法や、Amazon Data Lifecycle Manager（DLM）によるポリシーベースの自動化、Recycle Binを使った誤削除対策など、実践的な運用に関する具体的な知見が共有されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
EBS Snapshotsの概要と本セッションの目的
皆様、STG 205「Amazon EBS Snapshotsを使用した重要データの簡単な保護」へようこそ。本セッションにご参加いただき、ありがとうございます。私はAmazon EBSのProduct Managerを務めるSurabhi Sinhaです。一緒に登壇するJPをご紹介します。はい、私はSAPのJP Jayaprakasanです。SAPのBusiness Continuity Architectureチームを率いており、本日はEBS Snapshotの機能についてお話しできることを嬉しく思います。私はDenton Heと申します。EBS SnapshotsとVolumesチームのProduct Managerの一人です。
本日はEBS Snapshotsに焦点を当てていきます。まず質問させていただきます。EBS Snapshotsについてご存知の方はどのくらいいらっしゃいますか？かなり多いようですね。では、EBS Snapshotsを使用している、または使用したことがある方は？これは私の説明がしやすくなりそうですね。本日は、EBS Snapshotsとは何か、その仕組み、そして活用方法について、まず最初のパートでお話しします。次に、Snapshotsに関連するセキュリティの側面について説明します。多くの組織がバックアップのセキュリティ態勢を強化することに関心を持っているので、それを実現する機能についてお話しします。その後、JPがRISEについて、そしてソリューションに対する不変性とランサムウェア対策をどのように実装しているかについて説明します。最後に、Dentonがデータ保護について説明します。
AWSストレージポートフォリオとEBS Snapshotsの基本
Snapshotsの詳細に入る前に、AWSのストレージポートフォリオ全体について少しお話ししましょう。データアーキテクチャの中心にはデータの保存場所があり、AWSにはお客様のニーズに合わせた様々なソリューションがあります。中央には、コアサービスがあります。オブジェクトレベルのストレージにはAmazon S3、ブロックレベルのストレージには私たちのAmazon Elastic Block Store（EBS）、そしてファイルレベルのストレージにはAmazon EFSとAmazon FSxがあります。右側には、AWS DataSyncやAWS Storage Gatewayのようなデータ移動サービスと共に、ハイブリッドおよびエッジベースの機能があります。左側には、AWS BackupやAmazon EBS Snapshotsなどのデータ保護およびワークフローサービスがあります。これらのソリューションはすべて相互にシームレスに統合され、安全で信頼性の高いデータ基盤の構築を支援します。
では、ブロックストレージのポートフォリオについて詳しく見ていきましょう。ブロックストレージは、Instance StorageとElastic Block Storageという2つの大きなカテゴリーで考えています。Instance Storageは、EC2インスタンスに接続される一時的なストレージです。SSDストレージの例としてはI4インスタンス、HDDストレージの例としてはD3インスタンスがあります。Amazon Elastic Block Storeでは、SSDの例としてGP3やIO2 Volumeがあり、HDDの例としてSC1やST1 Volumeがあります。
それでは、Snapshotsとは何かについて説明しましょう。お客様はEBS VolumeのバックアップにSnapshotsを使用しています。 Snapshotsについて最初に知っておくべきことは、これがEBS Volumeのポイントインタイムコピーだということです。各Snapshotには、そのSnapshotが作成された時点のVolumeの状態に復元するために必要なすべてのデータが含まれています。Snapshotからボリュームを作成すると、元のボリュームの完全なレプリカとして始まります。素晴らしいのは、データが常にバックグラウンドでロードされるため、すぐにボリュームの使用を開始できるという点です。
Snapshotについて2つ目に注目すべき点は、増分方式であるということです。これは、前回Snapshotを取得してから変更されたデータのみが、現在のSnapshotに保存されるということを意味します。これには2つの利点があります。1つ目は、Snapshotの作成速度が向上すること、そして2つ目は、毎回データの完全なコピーを保存する必要がないためコストを抑えられることです。 また、多くのお客様は、1つのインスタンスに接続された複数のボリュームにまたがる大規模なデータベースやファイルシステムを持っています。私たちは、1回のAPI呼び出しで、クラッシュ整合性のあるSnapshotを取得できる機能を提供しています。インスタンスを停止したり、ボリューム間のデータを調整したりする必要はありません - 1回のAPI呼び出しで、データの整合性が取れた、クラッシュ整合性のあるSnapshotを取得できます。
EBS Snapshotsの主要ユースケースと仕組み
お客様がSnapshotを使用する主なユースケースには4つあります。 1つ目は、皆様の多くがご存じかもしれませんが、最も一般的なバックアップと災害復旧です。お客様はSnapshotを使用してEBSボリュームのデータをバックアップします。
また、災害復旧のために、そのデータを他のリージョンやアカウントにコピーすることもあります。
2つ目のユースケースは、リフレッシュ、スケールアップ、データ受け渡しのワークフローと呼ばれるものです。多くのお客様の組織には、数多くのビジネスユニットがあり、それぞれのビジネスユニットが複数のアカウントを持っています。承認されたロギングやモニタリング、最新のセキュリティパッチを含む最新バージョンのAmazon Machine Image（AMI）を構築する中央チームがあるかもしれません。組織内のすべてのチームが最新のAMIを使用していることを確認したい場合、SnapshotやAMIベースのSnapshotが非常に有効です。
3つ目のユースケースは、EBS以外のユースケースで、データセンターのデータをバックアップしてクラウドに復元する際にSnapshotを使用できるというものです。多くのお客様がこの目的でSnapshotを使用しています。さらに、多くのサードパーティソリューションがEBS Snapshotを基盤としたソリューションを構築しています。 これらは、お客様のRecovery Point ObjectiveやRecovery Time Objectiveを満たすのに役立つ自動化およびオーケストレーションソリューションです。
それでは、Snapshotの基本的な仕組みについて説明していきましょう。 EBSボリュームを作成して1テラバイトのデータを割り当てたものの、まだ何も書き込んでいない場合、それは基本的に空のボリュームということになります。このボリュームのSnapshotを取得しても、そのSnapshotも空の状態となり、データが書き込まれていないため課金も発生しません。ただし、ボリュームに3つのブロックまたは3つのファイルのデータを書き込んでからSnapshotを取得すると、Snapshot1には、Snapshot取得時にボリュームに書き込まれた3つの課金対象ブロックまたは3つのファイルが含まれることになります。さらに3つのファイルを書き込んで別のSnapshotを取得すると、ブロック4、5、6が増分となり、Snapshot2ではこれらのブロックに対して課金されます。一方、ブロック1、2、3についてはSnapshot1が参照されます。この例をさらに進めて、3つのブロックを追加すると、これらの3つのブロックはSnapshot3の一部となりますが、ブロック1から6までは引き続きSnapshot1とSnapshot2から参照されることになります。
まとめると、Snapshotに関して覚えておくべき重要なポイントは以下の通りです。Snapshotはボリュームを復元するために必要なすべてのデータを含むポイントインタイムコピーです。また、増分方式で保存され、連続する2つのSnapshot間の変更分または増分ブロックに対してのみ課金されます。
EBS Snapshotsのセキュリティ機能と運用方法
次に、セキュリティの側面について説明しましょう。多くのお客様は、バックアップがビジネス上重要であるため、バックアップのセキュリティ態勢の強化を求めています。また、Snapshotに関しては、遵守すべきビジネス要件やコンプライアンス要件もあります。これらの目標を達成するためにEBSで利用可能な機能について説明していきます。最初に説明する機能は暗号化です。
EBSはAWS Key Management Service（KMS）と連携して暗号化を提供し、AES-256暗号化を使用しています。暗号化されたEBSボリュームについて説明すると、ボリューム内のデータが保存時に暗号化され、ボリュームとインスタンス間を移動するデータも暗号化されます。 Snapshotに関しては、暗号化されたボリュームからSnapshotを作成すると、そのSnapshotも暗号化されます。 そのSnapshotを使用して別のボリュームを作成すると、そのボリュームも暗号化されます。暗号化されていないSnapshotがある場合、そのSnapshotをコピーする際にキーを指定することで、暗号化されたSnapshotを作成できます。また、別のキーを使用したい場合は、そのキーを指定してSnapshotをコピーすることで、再暗号化されたSnapshotを作成することもできます。
暗号化に関して注意すべき重要な概念の1つは、アカウントのデフォルトKMSキーです。デフォルトではAWS管理キーが使用されますが、これは変更可能です。アカウントレベルでの変更は非常に簡単です。このキーの役割は、リソースを作成する際に暗号化を指定した場合、デフォルトでこのキーが暗号化に使用されるということです。
カスタマーマネージドキーに変更することも可能です。EBSに関する非常に強力なアカウントレベルの設定として、「EBS encryption by default (EBD)」と呼ばれる機能があります。これは、お客様が利用している各リージョンのアカウントレベルで有効化でき、アカウントレベルで暗号化を強制することができます。この設定を有効にすると、それ以降に作成されるすべてのリソースがデフォルトで暗号化されます。つまり、作成されるすべてのボリュームとそのスナップショットが、その時点から暗号化されるようになります。
これは、今後作成されるすべてのリソースが確実に暗号化されるようにする、非常に簡単な方法です。暗号化されていない既存のリソースについては、いくつかの対処方法があります。暗号化されていないブートボリュームの場合は、CreateReplaceRootVolumeTask APIを使用して、ルートボリュームを暗号化されたものに復元できます。暗号化されていないデータボリュームの場合は、スナップショットを作成し、そこから暗号化されたボリュームを作成できます。暗号化されていないスナップショットの場合は、コピーを作成する際に、使用したい暗号化キーを指定することができます。
スナップショットに関する非常に強力な機能の一つが、リージョン間やアカウント間でのコピーです。お客様は主に3つの大きなユースケースでこれを活用しています。多くのお客様は、別のリージョンにデータのコピーを保持する必要があるディザスタリカバリの要件を持っています。また、別のリージョンでアプリケーションを起動したい場合や、異なるリージョンやアカウントでテストを行いたい場合など、拡張の要件を持つお客様も多くいます。このような場合に、スナップショットのコピーが非常に有効です。
最近、Time Based Snapshot Copyという新機能をリリースしました。特にディザスタリカバリのワークフロー向けにスナップショットをコピーする際、厳密なRPO（Recovery Point Objective）要件を持つお客様が多くいます。この機能を使用すると、スナップショットのコピープロセスに要する時間を15分から48時間の間で指定できます。RPOが15分の場合、それを指定すれば、その要件を満たすことができます。これにより、ワークフローの予測可能性と一貫性が確保され、必要に応じて高速なコピーを実現できます。
この機能は、毎日特定の時間にデータを利用可能にしたいテストや開発のワークフローでも特に有用です。コピースナップショットのリクエストごとに指定でき、標準コピーのような同時スナップショット制限もありません。アカウントレベルのスループット制限内であれば、必要な数のスナップショットをコピーできます。デフォルト値は約2000 mbpsですが、要件に応じて柔軟に対応可能で、必要な場合は制限の引き上げをリクエストすることもできます。
Snapshotの共有についてお話しすると、Snapshotを作成した時点では、デフォルトでプライベートな状態になります。 特定のアカウントを指定することで、そのアカウントとプライベートに共有することができます。また、Snapshotをパブリックに共有することもでき、その場合はすべてのAWSユーザーがそのSnapshotにアクセスできるようになります。これは推奨されない方法ですが、テストデータをユーザーに配布する目的で使用されているお客様もいます。もしそれが目的でない場合は、EBS Snapshotに対するパブリックアクセスのブロック機能を使用できます。 これはアカウントレベルで有効にできる設定で、非常に簡単に有効化できます。考慮すべきモードが2つあります：新規共有のブロックと全共有のブロックです。
新規共有のブロックでは、今後共有される可能性のあるSnapshotに対して、パブリックアクセスが禁止されますが、既存のパブリックSnapshotは引き続きパブリックな状態を維持します。私たちが推奨する、より強力な設定である全共有のブロックを使用すると、既存のものや現在パブリックなものかどうかに関係なく、すべてのSnapshotへのパブリックアクセスを禁止することができます。
これらの設定は、コンソールのデータ保護とセキュリティ設定にあります。先ほどお話しした2つのモード、つまり全パブリック共有のブロックと新規パブリック共有のブロックがあります。 有効にすると、数分で設定が反映されます。ご覧のように、 この例ではすべての共有がブロックされています。アカウントでSnapshotを共有しようとすると、パブリックオプションがグレーアウトされているのがわかります。つまり、誰もSnapshotをパブリックにすることができなくなります。
次に説明する機能は、Snapshot Lockです。 多くのお客様が、業界用語でWORM（Write-Once-Read-Many）と呼ばれる保護に関する要件を持っています。データの不変性を確保するためのビジネス要件やコンプライアンス要件があるのです。Snapshotはデフォルトで変更できません - Snapshotを作成すると、上書きや修正はできませんが、適切な権限があれば削除することはできます。Snapshot Lockが役立つのは、Snapshotにロックをかけることで、アカウント内のどのユーザーもそれを削除できなくなることです。コンプライアンス要件に応じて、例えば30日間などの特定期間ロックをかけることができ、その間は誰もそのSnapshotを削除できないことが保証されます。
これはランサムウェア対策の文脈で重要であるだけでなく、 コンプライアンスの観点からも重要です。特に金融業界やヘルスケア業界には、このような管理を必要とする規制が多く存在します。Snapshot Lockは、ComplianceモードとGovernanceモードの2つのモードで有効にできます。Governanceモードは、Complianceモードよりも柔軟で、必要に応じて特定のユーザーにロックの解除や変更の権限を付与することができます。Complianceモードは、より制限の厳しい設定で、誰もロックを変更することはできません。できるのはロック期間の延長だけで、期間が終了するまで削除することはできません。
これはスナップショットの設定を有効にする方法を示すコンソールの例です。Lock Snapshotをクリックすると、選択可能な2つのモードが表示されます。これはGovernanceモードの例で、スナップショットをロックする日数を指定することができます。Complianceモードを選択した場合も、1日から3日間のCooling-off期間を指定することができます。このオプションの期間により、スナップショットをロックした後も数日間は設定を編集することができます。
スナップショットをロックすると、誰かが削除しようとしても、スナップショットがロックされているためエラーが発生します。また、Complianceモードでは設定を変更することができず、誰もロックを削除したり解除したりすることはできません。できることは、ロックの期間を延長することだけです。では、イミュータビリティとランサムウェア保護について、JPに説明を譲りたいと思います。ありがとうございます、Rabbiさん。改めましてこんにちは。本日は、EBSスナップショットがRISE with SAPのイミュータビリティとランサムウェア保護にどのように役立つかについてお話しします。技術的な詳細に入る前に、RISEとは何かについて俯瞰的な視点でご説明させていただきたいと思います。
RISE with SAPにおけるEBS Snapshotsの活用
これは当社のCEOであるChristian Kleinからのメッセージです - CEOのChristian Kleinは、パートナーシップとコラボレーションが重要であることを強調しています。私たちはAmazonとの間で強力なコラボレーション関係を築いています。お客様により良いサービスとソリューションを提供するため、ERPポートフォリオ全体でAWSのサービスを活用しています。さらに、RISE with SAPプログラムでもAWSと効果的に協力しながら、AWSのサービスを広範に活用しています。例えば、大規模なHANAマシンや大規模インスタンスでは、現在24テラバイトのマシンを運用しており、さらに多くの展開を予定しています。
私たちは誰よりもこれらのマシンの運用方法を熟知しているため、プライベートプレビューインスタンスを受け取って検証し、AWSにフィードバックを提供しています。AWSは本番展開前に改善を実装しています。このようなコラボレーションは特定の分野に限定されません。コラボレーションが必要な場所であれば、私たちの専門家とAWSの専門家が協力して、お客様により良いソリューションと価値を提供しています。
RISE with SAPは、お客様にCloud ERPのマネージドサービスを提供するためのプログラムです。RISE with SAPには3つの主要な特徴があります。1つ目はCloud ERPで、将来性のあるビジネスソリューションをCloud ERPとしてお客様に提供します。2つ目は運用に関するもので、マネージドサービスとして、AWSインフラストラクチャを使用して、お客様のシステムをグローバルで標準化された方法で運用します。3つ目はSAPのメソドロジーで、定期的にCloud ERPソリューションを更新します。すべてのイノベーションと新機能は自動的に実装され、お客様は直接その恩恵を受けることができます。
エンタープライズアプリケーションとバックアップは非常に重要なトピックです。なぜなら、これは常に最後の砦として考えられているからです。災害やランサムウェア攻撃、データセンターの障害、自然災害などで何か問題が発生してシステムがダウンした場合、データを復元して通常業務を再開するための最後の手段がバックアップなのです。現在、データの容量は継続的に増加しています。システムからデータを取り出してベンダーソリューションやクラウドストレージなどのバックアップインフラにアップロードする従来のバックアップ方法では、複数の課題が生じています。
第一の課題は、データサイズが原因でバックアップと復元に時間がかかることです。第二の課題は回復性で、ゾーン障害に対応するためにバックアップデータのレプリケーションが必要となります。第三の課題は、システムやインスタンスからデータを取り出す際にアプリケーションのパフォーマンスに影響を与えないようにする必要があることです。例えば、20〜30テラバイトの大規模システムの場合、3〜4時間という短時間でデータを取り出そうとすると、ストレージのスループットを全て使用することになります。つまり、この間にアプリケーションが読み書きを試みると、パフォーマンスに影響が出てしまいます。さらに、RPOに関して言えば、バックアップが4〜5時間かかる場合、このバックアップ時間中のデータは復旧できません。
最後に重要な側面は、セキュリティと暗号化です。バックアップをストレージに保管する際は、適切なセキュリティ対策なしでは復元できないよう、確実に安全である必要があります。では、EBS Snapshotがこれらの課題にどのように対応するのか説明しましょう。
まず、EBS Snapshotは増分方式で動作するため、バックアップと復元が高速化されます。毎日バックアップを実行する場合、3〜4時間もかからず、数分で完了します。EBS Snapshotはデフォルトでリージョン単位で保存されるため、1つのゾーンがダウンしても、別のリージョンでデータを利用できます。そこからボリュームを作成してインスタンスにアタッチし、システムを復旧できます。スナップショットはストレージレベルで実行されるため、ストレージのスループット、メモリ使用量、CPU使用量の面でアプリケーションへの性能影響はありません。
柔軟なライフサイクル管理により、システムごとに異なる保持要件に対応できます。例えば、システムAが30日間の保持期間、システムBが20日間、システムCが7日間必要な場合、システムと保持期間に基づいて各スナップショットにタグを付けて管理します。Lambda関数を実行して毎日すべてのスナップショットを読み取り、これらの値に基づいてライフサイクルを管理します。このアプローチはコスト効率も優れています。増分スナップショットでは、最初のスナップショットだけが比較的高コストになります。その後の日次スナップショットは、システムの負荷に応じて2〜6%程度の変更分のみを取得するため、その増分分のコストだけで済むのです。
先ほど暗号化について触れましたが、私たちはスナップショットの暗号化にAWS KMSキーを使用しており、データと通信の両方が暗号化されています。 また、お客様が求めているもう一つの重要な機能が、不変性とランサムウェア対策です。Snapshot Lockという機能がこれらのリスクの軽減に役立ちます。チームと何を実現したいのか、どのように有効にするのかについて詳しく話し合いましたが、実際の実装は非常に簡単で、スナップショットを作成する際にチェックを入れるだけです。
不変なバックアップにより、バックアップ後のデータ改変、削除、上書きができなくなります。これらの重要な機能はSnapshot Lockによって実現されています。Snapshot Lockを有効にしてスナップショットを作成する際、15日や10日などの保持期間を指定できます。Snapshot Lockにはガバナンスモードとコンプライアンスモードの2つがあります。ガバナンスモードではロックを解除できますが、コンプライアンスモードでは解除できません。15日のロックを設定すると、その期間を短縮したりロックを解除したりすることはできません。ただし、お客様がバックアップをより長期間保持したいと要望した場合は、延長が可能です。例えば、15日の保持期間でスナップショットを取得し、お客様がさらに30日間の保持を希望した場合、延長できます。これはまさに私たちが求めていた機能で、すでに6ヶ月から9ヶ月ほど使用しています。
このSnapshot Lock機能は、不変性とランサムウェア対策の観点から私たちの要件を満たしています。もちろん、一度設定した保持期間を短縮することはできませんが、延長できる柔軟性があることでデータのセキュリティを維持しながら運用が可能です。
スナップショットの実装方法について、高レベルのアーキテクチャを説明させていただきます。 複数のEBSボリュームが接続されたEC2インスタンスがあり、これらのEBSボリュームのスナップショットを取得します。ライフサイクル管理にはLambda関数を使用しています。EC2インスタンスには20～30個のEBSボリュームが接続されていることがありますが、すべてのボリュームのスナップショットを取る必要はありません。スナップショット作成時のクラッシュ整合性を維持しながら、特定のEBSボリュームを除外できる機能が必要です。
スナップショットを実行する際、クロス整合性も必要です。例えば、私たちの環境ではLVMストライピングを使用して複数のEBSボリュームから1つのファイルシステムを作成しています。5つのEBSボリュームでファイルシステムを作成している場合、クロス整合性のために全ボリュームを同時にスナップショットする必要があります。また、24テラバイトのHANAシステムを扱う場合、バックアップが不要なボリュームもあるため、それらのボリュームをスナップショットプロセスから除外できるよう識別しています。
スナップショット作成のワークフローについてご説明します： まず、スナップショットを作成する対象のボリュームを特定し、アプリケーションやデータベースと連携して整合性を確保します。スナップショットを作成した後、ロックを有効にし、保持期間とライフサイクル管理のためのタグを付与します。例えば、保持期間が20日の場合、Lambda関数がこれらの値を読み取り、それに応じてライフサイクルを管理します。 リストアプロセスについては、スナップショットはバックエンドにS3ストレージを使用するリージョナルストレージに保存されます。これらのスナップショットから新しいEBSボリュームを作成し、復旧対象のシステムから既存のボリュームをデタッチし、新しく作成したボリュームをアタッチして、システムを再度オンラインにします。
パフォーマンスに関して重要な考慮事項があります。スナップショットからEBSボリュームを作成する際、スナップショットはEBSボリュームと比べて性能の低いS3ストレージであるリージョナルストレージに保存されています。ボリュームの作成自体は即座に完了しますが、データがまだスナップショットストレージから転送されている段階では、100%の読み取り性能は得られません。AWSはこの課題に対処するためにFast Snapshot Restore（FSR）という機能を提供しています。ボリュームを作成する前に、選択したスナップショットに対してFSRを有効にし、ターゲットゾーンを選択します。データはスナップショットストレージから特定のゾーンのEBSストレージにコピーされます。FSRが完了すると、100%の読み取り性能でボリュームを作成できるようになり、これはHANAワークロードにとって非常に重要です。これは特に重要で、完全な性能が得られないと、HANAの起動自体やその上で動作するアプリケーションの実行に相当な時間がかかってしまうためです。
起動後も、すべてのデータをメモリにロードするのに時間がかかります。これは本番システムに影響を与えるため、Fast Snapshot Restore（FSR）なしでは本番環境で使用することはできません。パフォーマンスへの影響が通常の運用を妨げるほど大きいため、FSRは本番環境でHANAベースのシステムを効率的に維持するために不可欠な機能となっています。
これが私たちのワークフローです：まず、特定のユースケースに関連するスナップショットを特定し、それらのスナップショットに対してFSRを有効にします。FSRが完了したら、そこからボリュームを作成し、既存のボリュームをデタッチして、新しいボリュームをアタッチします。デタッチする際には、デタッチの理由と保持期間を示すタグを付与します。何らかの理由で元に戻す必要が生じた場合に備えて、デタッチしたEBSボリュームをすぐには削除したくないため、数日間保持します。その期間が経過すると、Lambda関数がこの情報を読み取り、自動的にライフサイクル管理を行います。
私たちの環境には、EBSスナップショットとスナップショットロック機能を使用している多くのデータベースがあります。24テラバイトまでのシステムを運用しており、さらに多くのシステムが追加される予定です。スケールアウトシステム、EBSボリューム、そしてEBSスナップショットを、SAP ASEシステム、IQボックス、MaxDB、およびこれらのシステム上で動作するアプリケーションに使用しています。数字で見ると、私たちの環境では約40,002インスタンスを実行しており、AWS環境内に7,000以上のHANAボックスがあります。まとめると、Compliance modeを備えたEBSスナップショットは、RISE with SAPプログラムの一環として、お客様のシステムに対する不変性とランサムウェア保護を実現するのに大きく貢献しています。
Amazon Data Lifecycle Managerの機能と特徴
ご清聴ありがとうございます。このセッション後に質問をお受けしたいと思います。ありがとうございます。JPさん、RISE with SAPをご利用のお客様がEBSスナップショットを使用してワークロードを保護する方法についての説明をありがとうございます。他のお客様向けには、 AWS BackupとAmazon Data Lifecycle Managerを提供しており、EBSボリュームのデータ保護を自動化するお手伝いをしています。
本日は、Amazon Data Lifecycle Manager（略してDLM）についてお話しさせていただきます。DLMは、EBS スナップショットのポリシーベースのライフサイクル管理ソリューションです。お客様はポリシーを作成し、タグを使用してスナップショットを作成したいボリュームを指定します。また、ボリュームのスナップショットを作成する頻度や、それらのスナップショットを保持する期間も指定します。スナップショットが作成されると、DLMはJPが説明したFast Snapshot Restoreの有効化や、スナップショットのアーカイブ、異なるリージョンへのコピーなど、スナップショットのライフサイクル管理をサポートします。ポリシーの作成、使用、管理は無料で、お客様はEBSスナップショットに関連するストレージコストのみをお支払いいただきます。
本日は、DLMの他のサービスとは異なる特徴的な機能についてお話ししたいと思います。その一つが、アプリケーション整合性のあるスナップショットの作成の自動化です。JPはすでにSAP HANAの場合について説明しましたが、他のワークロードでもDLMをどのように使用できるかについてお話ししたいと思います。その前に、DLMで作成できる3つの異なるポリシータイプと、それらがアプリケーション整合性のあるスナップショットソリューションとどのように適合するかについて説明させていただきます。左側にあるのは、単一のEBSボリュームから単一のスナップショットを作成する「シングルボリュームスナップショット」ポリシータイプです。
真ん中にあるのは、EC2インスタンスにアタッチされているすべてのボリュームの「マルチボリュームクラッシュ整合性スナップショット」と呼ばれるセットを作成するものです。先ほど説明したように、データボリュームやブートボリューム、スナップショットを作成する必要のない一時的なボリュームを除外することもできます。3つ目は、別のEC2インスタンスを起動する際に使用できるEBSバックのAmazon Machine Imageを作成するものです。
アプリケーション整合性のあるスナップショットを作成するために導入した機能は、真ん中のポリシータイプ、つまりマルチボリュームクラッシュ整合性スナップショットに基づいています。DLMはAWS Systems Managerと連携して、アプリケーション整合性のあるスナップショットの作成をサポートします。これは私たちが新しく導入した機能です。この機能は主に、MySQLやPostgreSQL、Windowsアプリケーション、そしてSAP HANAなど、自己管理型データベースをお使いのお客様を対象としています。アプリケーション整合性のあるスナップショットを使用することで、データベースの復旧がより迅速かつ容易になります。この機能を持つポリシーの作成は無料で、実質的にEBSスナップショットのコストのみをお支払いいただくことになります。
この機能を使用するには、EC2インスタンスにAWS Systems Manager Agentがインストールされて実行されていること、DLMがSSMエージェントを介してEC2インスタンスへの呼び出しを開始できるようにするIAMパーミッション、DLMポリシー、そしてデータベースの照会とThawを行うための指示が含まれているRun Commandドキュメントが必要です。 こちらがその動作の簡単な流れです。左下にDLMポリシーがあり、SSM Run Commandドキュメントに含まれる指示を調整しています。プリスクリプトのセクションでは、データベースに照会を行い、メモリからディスクへバッファをフラッシュします。EC2インスタンスでこのアクションが実行されると、DLMはアプリケーション整合性のあるクラッシュ整合スナップショットのセットを作成します。その後、フォローアップとして、ポストスクリプトコマンドを実行してデータベースをThawし、正常に動作していることを確認します。
この機能は、コンソールだけでなく、API、CLI、CloudFormationを通じても実行できます。コンソールでは、SAP HANAとVSSバックアップを直接選択することができます。これにより、AWSが提供・作成したこれらのデータベース用のSSMドキュメントが実行されます。MySQLやPostgreSQLなどの自己管理データベースの場合は、カスタムSSMドキュメントを選択できます。実際、MySQLとPostgreSQLのテンプレートを用意しており、これを独自のSSM Run Commandドキュメントにコピー＆ペーストすることができます。また、プロセスの所要時間や、リトライなどの動作を調整するための設定も用意されています。
昨年リリースしたもう一つの機能が、デフォルトポリシーと呼ばれるものです。この機能により、特にストレージ管理者は、アカウント内のすべてのEC2インスタンスとEBSボリュームが確実にバックアップされるようにすることができます。同時に、すでにバックアップがあるボリュームのスナップショットを重複して作成しないことでコストを削減できます。 これは、マルチテナントアカウントで顧客がよく目にする典型的な例です。異なるチームが、異なるボリューム、データボリューム、ブートボリュームを持ち、それぞれ異なる方法でスナップショットを作成し、バックアップを管理しています。ストレージ管理者にとって、重要なボリュームすべてが組織の要件に従ってバックアップされているかを確認することは困難です。赤で強調表示されているのは、重要ではなくバックアップの必要のないボリュームの例です。これらのボリュームをすべてバックアップすることもできますが、スナップショットは増分的であるとはいえ、追加のコストが発生します。
デフォルトポリシーを使用すると、リージョン内にポリシーを作成し、保護したいボリュームの範囲を指定できます。デフォルトポリシーは定期的にこれらのボリュームをスキャンし、どのような方法でもそれらのボリュームのスナップショットが作成されているかをチェックします。このように、チームやユーザーが持っている他のスナップショット作成・管理ソリューションと連携して動作します。最近のスナップショットが作成されていないことに気付くと、デフォルトポリシーがスナップショットを作成し、保持期間が終了するまで管理します。他の方法ですでにスナップショットが作成されていることに気付いた場合、デフォルトポリシーはリソースを作成せず、これによって顧客のコストを節約します。
Recycle Binとセッションのまとめ
スナップショットの作成に加えて、EBSスナップショットとAmazon Machine Images用のRecycle Bin があり、これにより顧客は誤った削除や悪意のある削除から保護することができます。顧客はRecycle Binを使用する際、リージョンとアカウントで保持ルールを作成し、削除された際にRecycle Binに保管されるべきスナップショットとAMIを指定します。Recycle Binに入ると、パソコンと同様に、これらのリソースを標準領域に復元したり、スナップショットからボリュームを作成したり、それらのボリュームを使用したりすることができます。悪意のある削除から顧客を保護するため、Recycle Binにルールロック機能をリリースしました。顧客は保持ルールにルールロックを適用できるため、悪意のある攻撃者がアカウントにアクセスしてスナップショットを削除しても、スナップショットはRecycle Binに移動します。ルールロックが有効な場合、悪意のある攻撃者は保持ルールを即座に削除または変更することができず、ルールを変更するには7〜30日間待つ必要があります。
お客様は、リージョンレベルでアカウントレベルのルールを設定して、すべてのSnapshotやAMIを保護することができ、削除された場合は一定期間Recycle Binに保管されます。あるいは、特定のSnapshotやAmazon Machine Imageのみを保護するTag基準のルールを作成することもできます。 アカウントレベルの基本ルールを使用するお客様向けに、先月、除外Tagをサポートする機能をリリースしました。これにより、保護が不要な重要度の低いSnapshotやAMIを除外することができます。これは特に、セキュリティスキャン用にSnapshotを作成するセキュリティスキャンプロセスを使用しているお客様に便利です。これらのSnapshotはリカバリ目的で使用されることがないため、Recycle Binで保護する必要はありません。お客様は保持ルールに除外Tagを追加することで、削除時にそれらのSnapshotやAMIがRecycle Binをバイパスするようになります。
まとめますと、ミッションクリティカルなEBSボリュームをEBS Snapshotでバックアップすることの重要性と、暗号化、Block Public Access、Snapshot Lockなどのセキュリティ機能についてお話ししました。JPからは、RISE with SAPでお客様がこれらの機能をどのように活用しているかについて素晴らしい事例を紹介していただきました。また、Amazon Data Lifecycle Managerの機能についてもお話しし、Time Based Snapshot CopyやRecycle Binの除外Tag機能など、最近追加された機能を試していただき、皆様のニーズに合うかどうかを確認していただくことをお勧めします。 このあと約40分後に、Mandalayで、今回のプレゼンテーションで説明した機能の一部を実際に体験できるEBS関連のセッションがもう1つ予定されています。それでは、SerbianとJPを代表して、皆様のご参加に感謝申し上げます。イベントの残りの時間もお楽しみください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion