re:Invent 2024: AWSストレージのデータ保護とレジリエンス戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Data protection and resilience with AWS storage (STG301)
この動画では、AWSのストレージサービスにおけるデータ保護とレジリエンスについて解説しています。データ保護の柱となる高可用性とバックアップの重要性を説明し、3-2-1-1-0データ保護アプローチに基づく具体的な実装方法を紹介します。AWS BackupやAWS Elastic Disaster Recoveryなどを活用した実践的なデータ保護戦略や、S3、EBS、EC2などの各サービスにおけるバックアップとレプリケーションの使い分けについて詳しく解説します。特に、Logically Air-gapped Backup Vaultを用いたサイバー攻撃対策や、Multi-Region Access Pointを活用した災害復旧など、最新のデータ保護機能についても具体的なデモを交えながら説明しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS Storageによるデータ保護とレジリエンスの概要
STG 301「AWS Storageによるデータ保護とレジリエンス」へようこそ。私はAWSのSenior Storage SpecialistのKenneth Huiです。来月で入社5周年を迎えますが、最近はデータ保護に注力しており、AWS Backupを含むデータ保護戦略について、お客様のサポートを行っています。皆様、こんにちは。AWS BackupのProduct Managementを率いているPalak Desaiです。本日は皆様とご一緒できることを嬉しく思います。
本日のアジェンダですが、まずレジリエンスとその重要性についてお話しします。次に、高可用性とデータ保護の戦略について説明します。その後、Kennethがデモンストレーションを行い、セッションを締めくくります。データは増加の一途をたどっており、多くの皆様がビジネス上の意思決定にデータを活用されています。今日では、多くのお客様がデータを基にビジネスを展開しており、この増加し続けるデータを損失から守り、ビジネス運営を継続できるようにすることが極めて重要です。
調査によると、データを保護せず、障害に対するレジリエンスを確保しないことは、実際に財務面および評判に大きな影響を及ぼすことが分かっています。良いニュースとしては、現在AWSが提供する多くの機能を活用することで、アプリケーションとデータのレジリエンスを確保できるということです。
レジリエンスと高可用性の重要性
まず、レジリエンスの定義から始めましょう。大まかに言えば、レジリエンスとは、ワークロードが様々なコンポーネントにおける完全な障害や一時的な障害に耐え、最終的にその障害から効率的に回復する能力のことです。データ保護には多くの柱と側面があります。
データ保護の第一の柱は高可用性です。例えば、アプリケーション内のコンポーネントに障害が発生したり、ネットワークに障害が発生したりした場合に、アプリケーションの運用を継続できるようにフェイルオーバーする能力を高可用性と呼びます。実生活での例を考えてみましょう。ChimeやZoomでビデオ通話をしているときに、インターネットの問題が発生したり、サービスが高負荷になったりすると、アプリケーションのパフォーマンスが低下することに気付くかもしれません。映像が不鮮明になったり、音声が途切れたりするかもしれませんが、アプリケーションは機能し続けます。これが高可用性の一例です。
障害の原因は数多く存在します。最も一般的な原因の1つは、人為的ミスまたは「Fat Fingering」と呼ばれるもので、設定作業の際に余分なゼロやパラメータを誤って入力してしまい、障害を引き起こすケースです。また、負荷による障害も考えられます。Black Fridayのショッピング時にEコマースサイトがダウンしてしまうような状況を想像してみてください。このような障害は、過剰な負荷であれ人為的ミスであれ、非常によく発生します。
もう一方の極端な例として、地域的な停電や天災があります。例えば、ハリケーンや地震が特定の地域に影響を与えてその地域がダウンした場合、Disaster RecoveryやData Protectionの概念について考える必要があります。これらの2つの概念をアプリケーションにどのように適用するかは、そのアプリケーションの重要度によって異なります。金融アプリケーションやミッションクリティカルなシステムの場合、ダウンタイムを許容できず、万が一アプリケーションがダウンした場合には効率的に復旧する必要があるため、High AvailabilityとData Protectionの両方を同時に考慮して設計する必要があります。
AWSのShared Responsibility Modelとデータ保護
AWSでは、Shared Responsibility Modelを採用しており、お客様はクラウド内のレジリエンシーに責任を持ち、AWS自身はクラウドのレジリエンシーに責任を持ちます。これは具体的にどういう意味でしょうか？
AWSは、お客様がアプリケーションを実行できるインフラストラクチャをホストし管理しています。この観点から、AWSはRegion、Availability Zone、Edge Locationといった、AWSのグローバルインフラストラクチャ全体のHigh Availabilityに責任を持ちます。これには、Compute、Storage、Database、Networkingが高可用性で冗長性を持つことや、AWSが運用する他のハードウェアサービスも含まれます。
例としてS3を見てみましょう。AWSは、S3が11ナインの耐久性を持つことに責任を持ちます。つまり、バケットに保存されたオブジェクトの状態が、そのRegionの全てのAvailability Zoneにわたって維持され、失われないようにすることを保証しています。しかし、データ自体の保護はお客様の責任となります。もしお客様が誤ってS3のデータを破損させてしまった場合、その破損したデータも11ナインの耐久性で保持されることになります。AWSは自動的にS3のデータをバックアップするわけではないので、それはお客様の責任として残ります。
これは、アプリケーションのレジリエンシーに対するお客様の責任を示す良い例です。アプリケーションのバックアップを取得し、不適切なアクセス制御による意図しない操作が行われないよう、適切なアクセス権限と許可を確保することは、お客様の責任となります。アクセスセキュリティポリシー、災害復旧シナリオの検討方法、サイバーレジリエンシー、そしてインフラストラクチャ上で実行されるアプリケーションの保護については、お客様に担っていただく必要があります。ただし、AWSでは、アプリケーションをレジリエントにするための十分な機能と仕組みを提供しています。
ポートフォリオの観点から見ると、私たちは幅広いサービスを提供しています。ストレージポートフォリオは、ブロックストレージのAmazon EBS、オブジェクトストレージのAmazon S3およびAmazon S3 Glacier、そしてファイルストレージのAmazon FSx、Amazon EFS、Amazon File Cacheをカバーしています。これらのストレージシステムにはそれぞれ、アプリケーションのレジリエンシーを確保するための様々な仕組みが用意されています。AWS Backupを使用することで、アプリケーションデータを保護するための一貫したバックアップメカニズムを実現できます。また、Object Lock、S3 Versioning、その他の災害復旧機能など、アプリケーションのレジリエンシーを確保するための様々な機能が用意されています。このセッションの後半では、データのレジリエンシーと保護を実現するために、お客様の環境で成功を収めている参照アーキテクチャをご紹介します。
AWSのRegionとAvailability Zoneの仕組み
ありがとうございます、Palak。それでは基本的な部分から始めていきましょう。 まず最初に、RegionとAvailability Zoneについて、そしてそれらがAWS内での高可用性の維持にどのように関係しているかについて、少しお話ししたいと思います。Regionとは、基本的にAWSがデータセンターを持つ地理的な場所のことです。これは、世界中のお客様がAWSのリソースに迅速かつ容易にアクセスできるようにするためのものです。また、Regionを使用することで、必要に応じてRegion間での災害復旧を設定したり、特定の場所にデータを保持する必要があるお客様の要件を満たしたりすることができます。例えば、AWSでは、特定のRegionに保存されたデータは、お客様自身が決定しない限り、他のRegionに移動することはないというルールを設けています。
各Regionには、複数の物理的なデータセンターが存在します。Regionでは、これらの物理的なデータセンターの一部をグループ化して、Availability Zoneと呼ばれる論理的なデータセンターを形成しています。Availability Zoneは単一の場所ではなく、複数の場所に分散された複数の物理的な機器をグループ化して、障害ドメインを形成しています。
各RegionのAvailability Zoneは、同じ電力グリッド、自然災害ゾーン、または地震ゾーンに属さない十分な距離を保って配置されていますが、Region内のAvailability Zone間で同期レプリケーションが可能な程度の近さを維持しています。これは高可用性を議論する際に重要となり、あるAvailability Zoneから別のAvailability Zoneへ非同期でデータをレプリケートすることができます。また、これにより単一のAvailability Zoneの障害にも耐えることができ、他のAvailability Zoneは影響を受けません。
各Data CenterとAvailability Zoneには、冗長化された電源とネットワーク接続が備わっており、それぞれが独立して冗長性を確保し、高可用性を実現しています。 AWSの各サービスは、Region内で異なるタイプの回復力を持っています。Zonal Serviceと呼ばれる特定のサービスの場合、すべてのデータは単一のRegion内の単一のZoneに格納されます。例えば、Amazon EBSボリュームを作成する際、格納したいAvailability Zoneを指定するか、AWSに選択を任せることができます。 このボリュームは、格納されているAvailability Zone以外からはアクセスできません。
次に、Amazon S3のようなRegional Serviceがあります。これは、データがRegion内の複数のAvailability Zoneにまたがって保存されるため、1つのAvailability Zoneが停止しても、データへのアクセスを維持できます。 さらに、AWS Identity and Access Management（IAM）のようなGlobal Serviceがあります。これは、US West（N. California）やUS East（N. Virginia）で別々のIAMサービスを持つのではなく、複数のRegionにまたがる単一のサービスとして提供されています。これは、AWSのストレージサービスを使用する際の検討材料として重要です。ZonalかRegionalかによって、必要な高可用性戦略が変わってくるからです。
Multi-Zonal ResilienceとMulti-Region Recoveryの実現
設計の観点から見ると、従来の企業では通常1つのData Centerを持っています。多くの場合、アプリケーションは1つか2つのラックに配置されているため、障害の影響範囲は1つのラックやData Centerに限定されます。高可用性を確保するために、もう1つのData Centerをセットアップすることを検討するかもしれません。AWSでは、サービスに応じて、回復力を設定するための様々な方法があります。 先ほど、Multi-Zonal Resilienceについて触れましたが、後ほど具体例をご紹介します。例えば、EBSボリューム上のAmazon EC2インスタンスは単一のZoneに配置されますが、様々なAWSの機能を使用することで、2つ目のZoneに高可用性ペアを設定することができます。
1つのZoneで障害が発生した場合、別のZoneで処理を引き継ぐことができます。これはMulti-Zonal Recoveryの考え方でもあり、EBSのようなリソースの場合、データのリカバリが必要な際に、そのRegion内にバックアップスナップショットを保持し、そのZoneへ復旧することができます。 また、特にバックアップと災害復旧の文脈で後ほど説明しますが、Multi-Region Recoveryもあります。これは、データを1つのZoneだけでなく、複数のZoneにまたがって保持する方法です。これにより、1つのZoneで何らかの問題が発生した場合、2つ目のZoneにフェイルオーバーするか、そこからリカバリすることができます。
NetflixやAmazon Primeのような企業は、複数のRegionでActive-Active構成を望んでいます。何らかの理由で1つのRegionが停止しても、すべてのRegionのユーザーを1つのRegionに誘導して、正常に運用を継続できるようにするためです。このような高レベルの概念を踏まえて、 これらの高可用性と回復力の特徴を示す非常にシンプルなアーキテクチャについてお話ししたいと思います。
これは複数のAvailability Zoneを含むシングルゾーンのシンプルなアーキテクチャで、アプリケーションはこれらの複数のAZにまたがって実行されています。NAT GatewayやElastic Load Balancingなどのサービスは、あるゾーンから別のゾーンへとトラフィックを効果的にリダイレクトできます。例えば、Webサービスを運用する場合、直接公開するのではなく、Load Balancerの背後に配置することがベストプラクティスとされています。これは、パフォーマンスのバランスを取るだけでなく、必要に応じて一つのAZから別のAZへトラフィックをリダイレクトする機能を持たせるためです。
この仕組みを第2のコンピュートレイヤーで実現するため、2つのAuto Scalingグループという概念があります。単一のゾーン内でAuto Scalingを行うことも可能ですが、ベストプラクティスとしては、シングルゾーン内の複数のAZにまたがってAuto Scalingを行うことを推奨しています。これにより、いずれかのAvailability Zoneで障害や問題が発生した場合、Load Balancerは他のAZで追加リソースを起動しながらトラフィックをリダイレクトできます。データベースレイヤーでは、Amazon RDSを使用することで、あるAZから別のAZへのレプリカスタンドバイコピーを設定できます。ゾーンAでデータベースの障害が発生した場合、自動的にゾーンBにフェイルオーバーされます。また、複数のAZにわたって同じデータベースの複数のコピーを持つようにレプリカを設定し、可用性を高めるためにトラフィックをリダイレクトすることも可能です。
データ保護戦略：RPO、RTOとバックアップの重要性
これは簡単な例に過ぎません。今日の本題として焦点を当てたいのは、データ保護戦略とそれがレジリエンシーの実現にどのように役立つかということです。では、Palak、この点について少し説明していただけますか？もちろんです。データ保護について考える際、まず最初に考えるべき重要な用語が2つあります。1つ目はRPO（Recovery Point Objective）で、これはアプリケーションとビジネスが耐えられるデータ損失の量を示します。2つ目の用語はRecovery Time Objectiveで、災害が発生した場合にどれだけ早く復旧する必要があるかを示します。これら2つの用語は、災害が発生した場合のビジネスの実行可能性を示す指標となります。
一般的に、3-2-1-1-0データ保護アプローチを適用します。プライマリリソースとは別に、常にデータの3つのコピーを持つ必要があります。そのうち2つのコピーはクロスアカウントコピーやクロスリージョンコピーなど、リモートロケーションに置く必要があります。1つのコピーは、RTOを削減するためにプライマリアカウントに置く必要があります。先ほど説明したRecovery Time Objectiveですが、RTOを削減するために、プライマリアカウントにコピーを持つことで、クロスリージョンコピーによる遅延に悩まされることなく、迅速に復旧できます。また、1つのコピーは必ずImmutable Vaultで不変な状態にしておく必要があります。これにより、ランサムウェアなどのインシデントが発生した場合でも、そのコピーから安全に復旧できます。
ある銀行での経験を少しお話ししましょう。具体的な銀行名は控えますが、彼らはデータセンター全体が一度に停止するという事態に遭遇しました。これはニューヨークでの出来事でしたが、彼らは別のデータセンターにアプリケーションを設定していたものの、残念なことにそのデータセンターは2ブロック先にあり、そちらも停止してしまいました。バックアップコピーを使用せざるを得なくなりましたが、コンサルタントが設定したバックアップは永続的な増分バックアップ方式で、環境内のサーバーを復元するのに30日もかかることが判明しました。実際に災害後の復元が必要になるまで、彼らは復元プロセスをテストしていなかったため、この事実を知りませんでした。これは、ビジネスにコミットしている時間内で確実に復元できること、そして復元するデータが既知の正常なソースであることを確認するため、定期的に復元訓練を行うべきことを示す良い例です。これは、プロセスをテストすることの重要性を示す素晴らしい例です - データが安全で保護されていることを確認する必要があります。プロセスは、効率的な復旧を可能にするために最悪のシナリオを想定しながら、データのセキュリティと保護を確実にする必要があります。
このスライドは、バックアップコピーの配置場所に関する前のスライドを反映しています。迅速な復旧のためのローカルコピー、クロスリージョンやクロスアカウントのリモートコピー、そしてセカンダリのリモートコピーには様々なテクノロジーが利用可能です。ユースケースに応じて、レプリケーションベースのコピーやバックアップの複製を選択できます。3つ目のコピーは常にサイバー復旧用であるべきで、イミュータブルで、セキュアで、分離されており、効率的な復旧のために定期的にテストされる必要があります。
バックアップは通常、コンプライアンス対応、ランサムウェアからの復旧、一般的なデータ保護のために使用されます。その指針となるのはRecovery Time Objectiveです。即時の復旧が不要で、データの復元に要する時間を許容できるアプリケーションの場合、バックアップはデータ保護を実装する優れた方法です。利用可能なBackupおよびRestoreテクノロジーを使用して、改ざん防止機能付きのイミュータブルなバックアップを作成できます。
次のような例を考えてみましょう：あるアカウントでプライマリリソースが正常に稼働している状況で、設定ミスによる人為的な破損が発生し、リソースが消失してしまいました。プライマリアカウント内にバックアップがあれば、迅速に復元してデータのクリーンな状態に戻れるため素晴らしいことです。しかし、アカウント全体が侵害されたり、リージョンの障害が発生した場合、クロスリージョンやクロスアカウント環境にバックアップコピーがあれば、影響を受けた場所から離れた場所で安全にデータを復旧できるため有益です。
ローカルリソースの復旧の70%以上が、作成から30日または60日以内のデータに関するものであることがわかっています。多くのお客様は、ランサムウェアへの懸念から、ローカルバックアップの保持期間を短くし、別のアカウントにより長期のバックアップコピーを保持するというベストプラクティスに従っています。リージョンの障害は非常にまれですが、アカウントの侵害は起こり得るため、アカウントを障害ドメインとして考えることが重要です。サイバーセキュリティのユースケースでは、ワークロードアカウントとは別の分離されたアカウントにデータのコピーを保管することに重点を置くべきです。
AWSのバックアップについて言えば、AWS Backupは、様々なAWSサービスやリソース、そしてハイブリッドワークロードにわたってポリシーベースのバックアップ管理を提供する一貫したプラットフォームです。特定のリソースをバックアップする唯一の方法ではありませんが、AWS Backupは、コンピュート、ストレージ、ファイルシステム、オブジェクトストア、データ転送テクノロジー、データベース、そしてVMwareやSAPのサポートを通じたハイブリッドアプリケーションにわたって、一貫したプラットフォームとポリシー駆動型のアプローチを提供します。AWS Backupを使用することで、バックアップにイミュータビリティを提供し、ポリシーベースの保持メカニズムとロックメカニズムを実装し、定期的に復元テストを実施し、アプリケーションのレジリエンスを規制当局に証明するための監査対応レポートを生成することができます。
データの保護にはBackupだけでなく、Replicationについても考える必要があります。先ほど説明したように、Backupは、RTOの時間的制約がそれほど厳しくない場合に、特定の時点のコピーを取得して復元するのに適しています。例えば、日次バックアップの場合、最大24時間分のデータが失われる可能性があります。しかし、アプリケーションがほぼゼロのRTOとRPOを必要とする場合、Replicationは業界で長年使用されてきた一般的なアプローチです。Replicationを使用すると、本番環境で書き込まれたものがほぼ即座にターゲット側に書き込まれます。これにより、必要に応じて新しい環境を起動でき、データの損失は数分程度に抑えられます。使用するツールによっては、まったくデータを失わないケースもあります。
Replicationは、低いRTOやRPOを維持するためのコストがかかるため、通常はすべてのアプリケーションに使用されるわけではありません。
Amazon S3のデータ保護：バージョニング、レプリケーション、バックアップの活用
ビジネスオーナーやマネージャーに、許容できるデータ損失量を尋ねると「ゼロ」と答え、許容できるダウンタイムを尋ねると「なし」と答えるでしょう。しかし、コストを説明すると、通常は妥協できる部分があると言い出します。ReplicationとBackupを検討する際は、ツールを選択する前に、アプリケーションを分類する必要があります。シンプルなモデルとして、Platinum、Gold、Silverなど、お好みの名前でティアを設定します。各ティアにRPOとRTOを設定し、保護が必要なすべてのアプリケーションをそれぞれのティアに振り分けるのです。これにより、アプリケーションの重要度に応じた適切なデータ保護アーキテクチャを構築できます。アプリケーションが重要であればあるほど、低いRTOとRPOが求められますが、それだけコストも高くなります。
ここで、Replicationを提供するサービスの例をいくつか紹介しましょう。Amazon S3にはCross-Region Replicationがあり、アカウント間でも実行できます。S3 Replicationには2つのモードがあります。基本モードでは、あるBucketで変更を行うと、ベストエフォートベースで別のRegionやアカウントの別のBucketにそのオブジェクトを複製します。また、Time Controlという機能もあり、ターゲットBucketが15分以上遅れることを許可しないというSLAを定義できます。S3サービスは、その15分のSLA内にソースの変更がターゲットに確実に反映されるよう優先的に処理します。S3でBackupを取得できることから、そのBackupを別のアカウントやRegionにコピーして不変にすることもでき、マルウェア攻撃の際の迅速な復旧を可能にします。
FSx for NetApp ONTAPをご利用の方はご存知かと思いますが、このサービスにはSnapshotやBackupの作成、さらには別のRegionの別のFSxインスタンスへのSnapshot Replicationなど、多くのデータ保護機能が標準で備わっています。FSx for NetApp ONTAPをご利用のお客様で、そのレベルの重要性がある場合は、これらの機能をお勧めしています。また、弊社のElastic File SystemであるAmazon EFSには、Backupだけでなく、別のRegionやアカウントの2つ目のFile Systemへの複製機能も組み込まれています。
レプリケーションを使用したDRアーキテクチャの例をご紹介します。この例では、AWS Elastic Disaster Recoveryを使用しています。ソース側では、オンプレミス環境やAWS Regionで、すべてのサーバーやEC2インスタンスにエージェントが稼働しています。これらのエージェントは、基盤となるストレージへの書き込みを分割するフィルタードライバーです。ストレージはソース側に書き込まれ、その書き込みは別のAWS Regionにレプリケートされて保存されます。レプリケーション自体は継続的で準同期的に行われます。
バッチ処理で実行され、時間の経過とともにターゲット側が更新され続けます。データはAWS Region内のEBSボリュームに保存されます。災害が発生した場合、DRSはレプリケートされたデータを使用して新しいEC2インスタンスを起動することができます。オンプレミスまたはソースリージョンで災害が発生し、数分以上のデータ損失が許容できない場合、DRSは迅速な起動を可能にします。VMwareを使用するオンプレミス環境の場合、DRSはそれらのVMwareインスタンスをAWS内のEC2インスタンスに変換する機能を備えています。
Amazon S3について話しましょう。S3を使用している方はどのくらいいますか？S3のバージョニングを有効にしている方は？S3でレプリケーションを使用している方は？S3をバックアップしている方は？予想通り、統計によると、ほとんどのお客様はバージョニングを使用しておらず、さらに少ない数のお客様しかデータをレプリケートしていません。データ保護が重要である理由についてはすでにお話ししましたが、S3の耐久性が11ナインであることから、S3バケットの自動バックアップがあると誤解しているお客様もいらっしゃいます。実際、S3のプロダクトマネージャーの一人と話をしたのですが、誤って削除した場合でも、S3でデータを削除すると、その削除が11ナインの耐久性で確実に行われることを、サポートチームに説明するためのスクリプトを書かなければならなかったそうです。
Palakが話した3-2-1-1原則を使用して、S3内の最も重要なデータを保護する方法について説明しましょう。この場合、特定のリージョンのワークロードアカウントにS3バケットがあります。バージョニングは基本的な機能ですが、バックアップの原則の一つは「ソースに依存してはいけない」というものなので、バージョニング自体は本当の意味でのバックアップとは言えません。バージョニングでは、バケットに何か問題が発生すると、すべてのバージョンにアクセスできなくなってしまいます。バージョニングは運用上、非常に迅速な復旧を可能にしますが、バケット全体が削除されたり破損したりした場合からは保護できません。
そこでバックアップの出番です。AWS Backupのようなツールを使用すると、バケットのポイントインタイムコピーを作成し、そのアカウント内の別の場所に保存することができます。必要に応じて、バックアップボールトと呼ばれる場所からデータを迅速に復旧することができます。これが最初のコピーです。最も重要なデータについては、実際には3つの復旧用コピーを持つことをお勧めしていることを覚えておいてください。最初のコピーは、バージョニングとバックアップを組み合わせたローカルコピーです。2番目のコピーは、主にサイバーレジリエンスのために使用される2番目のアカウントに保存されます。例えば、プライマリアカウントが侵害され、ランサムウェア攻撃によってローカルボールトにアクセスできなくなった場合などです。S3をバックアップする場合、2番目のコピーを作成し、そのコピーを別のアカウントやリージョンにレプリケートすることができます。最も脆弱になりやすいのはアカウントレベルなので、少なくとも別のアカウントを使用することをお勧めします。
2番目のリカバリーアカウントでは、Logically Air-gapped Backup Vaultと呼ばれる機能の使用をお勧めしています。8月に私たちはこの機能を作成し、ランサムウェアなどによってアカウントが侵害された場合に、安全にリカバリーできる分離されたコピーを提供しています。このLogically Air-gapped Vaultは、分離環境を提供することで保護を実現します。これはサービスが管理するアカウントで、サービスが管理する暗号化を使用するサービス管理型のVaultです。そのため、プライマリーアカウントが侵害されて暗号化キーにアクセスできなくなったり、プライマリーリソースや既存のバックアップが暗号化されたりした場合でも、このLogically Air-gapped Vaultから確実にリカバリーできます。これは分離されており、サービス所有の暗号化で管理されているためです。
さらに、昨年から素晴らしいパートナーロゴが追加されています。お客様には、継続的なマルウェアスキャンの使用をお勧めしています。これにより、災害時に確実にリカバリーできる完全にクリーンなコピーを1つ確保できます。先ほど申し上げたように、継続的なテストは常に重要です。Cyber Vaultingの戦略の中でリストアテストを実施し、少なくとも1つのコピーが確実にリカバリー可能な状態を維持することができます。
3番目のコピーの主なユースケースは、非常に低いRPOとRTOを必要とする重要データの災害復旧です。バックアップは、ローカルでもCyber Vaultのコピーとしても素晴らしい選択肢ですが、災害が発生して迅速な復旧が必要な状況では、私がお客様によく申し上げる考え方があります。最も速いリストアとは、実はリストアを行う必要がない状態、つまりフェイルオーバー先に既にデータが存在している状態なのです。この場合、先ほどお話しした時間制御機能付きのS3 Replicationを使用します。これにより、設定したSLA内で、ソースバケットの複製を別のリージョンとアカウントに確保できます。
また、Amazon S3 Multi-Region Access Pointも活用します。これは非常に長い名前ですが、要するにS3バケットの上に配置できる仮想エンドポイントです。アプリケーションの設定方法としては、バケットに直接アクセスするのではなく、このMulti-Region Access Point、つまり仮想アクセスポイントを経由してソースバケットにアクセスします。そして災害が発生してフェイルオーバーする際には、このアクセスポイントをフェイルオーバー用バケットに切り替えることで、迅速に運用を再開できます。
この方法は、フェイルオーバー先のバケットが最新バージョンであることを前提とした場合に最も効果的です。お客様からよくいただく質問の1つに、レプリケーションをバックアップとして使用できるかというものがありますが、私の答えは端的に「いいえ」です。それは本来の用途ではないからです。良い例を挙げましょう：レプリケーションを行っている場合、常に最新のコピーと全バージョンがレプリケートされるため、以前のバージョンに戻れると考えるかもしれません。少数のオブジェクトであれば、それほど難しくありません。しかし、バケット内に100万個のオブジェクトがあり、ランサムウェアの影響で5日前の状態に戻したい場合はどうでしょうか？レプリケーションを使用してこれを実現するには、5日前のバケットの状態を表す各オブジェクトのバージョンを把握する必要があります。レプリケーションにはチェックポイントの概念がないため、変更を追跡するためのデータベースカタログを自作し、必要なバージョンを公開するソフトウェアを構築しない限り、現状では不可能です。お客様がそれを自力で実現できたとしたら、おめでとうございます - それはAWS Backupを作り上げたことになり、今やあなたが製品チームですね。
データ保護戦略を考える上で非常に重要なポイントですが、S3 Replicationは最新のコピーへのフェイルオーバーには優れていますが、特定の時点からの復旧を目指す場合はバックアップを使用すべきです。なぜなら、それこそがバックアップの本来の役割だからです。
次に、Amazon EC2とAmazon EBS、そしてこのアーキテクチャのデモについてお話ししたいと思います。 EBSとEC2をご利用の方はどのくらいいらっしゃいますか？はい、かなりの数ですね。現在、EBSを保護する方法としては、スナップショットを使用するのが一般的です。例えば、AWS Backupやその他のバックアップアプリケーションは、EBSスナップショットと連携して、同一リージョン内にスナップショットのコピーを作成します。
ここで明確にしておきたいのですが、EBSスナップショットという名称は少し誤解を招きやすいかもしれません。従来のスナップショットは、ソースシステムの仮想コピーのようなものでしたが、この場合、すべてのEBSスナップショットは実際にはAmazon S3に保存されます。増分バックアップを永続的に行っているにもかかわらず、完全なイメージコピーとなっています。スナップショットのアーキテクチャにより、任意のスナップショットポイントや時点で、常に完全なEBSボリュームを復元できるようになっています。 バックアップコピーを作成することができ、そのコピーを論理的にエアギャップされたVaultを持つ別のアカウントに送ることをお勧めしています。これにより、ソースサイトで何か問題が発生した場合でも復旧が可能になります。
論理的にエアギャップされたVaultの重要な機能の1つは、そのVaultを異なるアカウントと共有できることです。例えば、ワークロードが侵害されて信頼できない状況や、セキュリティチームがフォレンジック用のアカウントが必要と判断した場合、あるいは保険目的で隔離が必要な場合を想像してみてください。このような場合、侵害されていない新しいアカウントを作成し、そのアカウントとVaultを共有して、そのアカウントで直接再起動することができます。先ほど説明したように、最新の対策を使用することで、バックアップをスキャンして、復元しようとしているものが実際にクリーンなコピーであることを確認できます。これがサイバーリカバリーコピーです。
そして3つ目が、先ほど話したDRコピーです。 EBSのバックアップは通常、日次バックアップが一般的です。より頻繁に実行することも可能ですが、スナップショットの性質上、おそらく1時間おきか、その程度の間隔で実行することが多いでしょう。もちろん、それにはコストが伴います。先ほど説明したElastic Disaster Recoveryのような仕組みを使用すると、別のリージョンへの準同期レプリケーションが行われるため、数分の遅延で済みます。その後、任意のタイミングで起動できます。つまり、災害を宣言してフェイルオーバーを実行すると、DRリージョンに保存されているデータを使用して新しいインスタンスが起動します。必要に応じて、元に戻すこともできますし、新しいアカウントにフェイルオーバーして、そのアカウントを新しいソースとすることもできます。
EC2とEBSのデータ保護デモンストレーションと結論
これが、ローカルリカバリー、サイバーリカバリー、そしてDRの全てを実現したい場合の推奨アーキテクチャーです。次に、このデモをご紹介したいと思います。特にEC2 EBSに焦点を当て、AWS Backupを使用してローカルコピー、サイバーリカバリーコピー、そしてDRSを使用してDRコピーをどのように保護できるかをお見せします。 このアカウントでは、Doc Server 21とDoc Server 2という2台のサーバーがあり、それぞれに2つのボリュームが接続されているのがわかります。
ボリュームを見てみましょう。 各インスタンスには2つのボリューム、つまりルートボリュームと、ユーザーデータを保存するDoc Repositoryボリュームがあります。これらは Windowsサーバーで、Dドライブ（ボリュームの1つ）には2つのフォルダがあります。1つはマーケティングチームが作成した マーケティング動画用のフォルダで、もう1つはPublishingフォルダで、音楽レビューや動画レビューが保存されています。
では、Doc Server 2のドキュメントボリュームを デタッチしていきます。障害をシミュレートするために強制デタッチを行い、その後ボリュームを削除します。デタッチには数分かかりますので、 その間にBackupコンソールに移動しましょう。このアカウントには複数のローカルVaultがあることがわかります。Local-Vaultに移動すると、 様々なリカバリーポイントが表示されます。これらがバックアップで、サーバー、ルート、ルートファイル、そしてDoc Repositoryボリュームの異なるリカバリーポイントがあります。
Doc Repository ボリュームがデタッチされたので、このボリュームを削除します。 リモートデスクトップに 戻ってフォルダを開くと、Dドライブが消えており、全てのドキュメントとデータが失われていることがわかります。AWS Backupコンソールに戻り、Doc Repository 2の最新のコピーの1つからリストアを開始します。 そのボリュームのゾーンサービスを選択し、 リストアを開始します。スナップショットを見つけ、そのスナップショットのデータを使用して新しいボリュームを作成する必要があるため、数分かかります。
ここで、Doc Repository Volume 2が再び利用可能になったことがわかります。あとはDoc Server 2に アタッチするだけです。 これで復旧完了です。 リモートデスクトップに戻ると、まるで消えていなかったかのようにDドライブが戻っているのがわかります。これが先ほど説明したローカルリカバリーコピーですが、次は アカウントが侵害され、インスタンス全体を失い、さらにそのローカルコピーにもアクセスできなくなった場合について説明します。
Doc Server 1に移動して、インスタンスを終了することで障害をシミュレートしてみましょう。この時点でシャットダウンが行われ、インスタンス全体にアクセスできなくなります。次に、バックアップコンソールに戻ります。 私のVaultに移動しますが、このデモでは、ローカルのVaultにアクセスできない状況を想定します。そこで、このアカウントと共有されているLAG_Vault-01という共有Vaultに移動します。ご覧のように、このLAG VaultはアカウントID「30」で始まるアカウントに属しており、ローカルのEC2インスタンスが存在するアカウントとは異なります。
この別のアカウントで、LAG Vaultに入ると、多数のリカバリーポイントが確認できます。これらのリカバリーポイントはソース側で作成され、その後、2番目のアカウントのLAG Vaultにコピーされたものです。
それでは、リストアを開始しましょう。仕様を入力して、削除されたボリュームやサーバーの仕様をそのまま複製するか、新しく更新された仕様を作成するかを選択できます。今回は、インスタンス全体のリストアを実行します。リストアの開始には1分ほどかかります。これにより、AMIとEBSボリュームが再作成され、2番目のアカウントのリカバリーVaultからソースアカウントのVPCにプルされます。
先ほど申し上げたように、この演習では元のアカウントにストリーミングしていますが、実際の運用では新しいアカウントを使用することをお勧めします。ご覧のように、Doc Server 2が素早く復旧して稼働しているのが確認できます。次は、DRSについてお話しします。このアカウントには、アプリケーションを構成する2つのサーバー（DBサーバーとWebサーバー）があります。
このサーバーはUS West 1（カリフォルニア）にあります。DRSを使用して複製されている様子をお見せしましょう。この場合、DRSコンソールではUS West 2、つまり私たちのDRリージョンを見ています。すでにレプリケーションを開始しており、リカバリーの準備が整っている状態であることがわかります。インスタンスIDによって、ソースサーバーが何であったかを確認することができます。
それでは、Source Regionで障害をシミュレートしてみましょう。 この時点でシャットダウンされました。一方、Target側では、DRSがSourceサーバーのレプリケーションが停止したことを検知すると、 1分ほど経過しているため、どれくらい遅延が発生しているかが表示されます。そして、リカバリーの準備が整ったことを示しています。
この時点で、フェイルオーバーしたいサービスを選択できます。ここでフェイルオーバーを実行してみましょう。 ここで注目すべき点は、DRSが2つのインスタンスのスナップショットやチェックポイントを作成することです。これにより、サーバーの以前のコピーに戻ることができます。特定の時点を選択してリカバリーを開始します。 詳細を確認すると、現在プロセスが進行中で、利用可能な最新バージョンのスナップショットを取得し、その後、準備のための変換プロセスを実行していることがわかります。例えば、これはレプリケーション対象のVMwareインスタンスで、その変換プロセスで実際に変換が行われます。
早送りすると、 リカバリーインスタンスが正常に起動されたことがわかります。Recovery Instancesタブでは、 US West 2とUS West 1で新しく実行されている2つのインスタンスが確認できます。US West 1に戻ると、 まだ停止したままです。US West 2に切り替えると、 リカバリーされたインスタンスが実行されているのが確認できます。
ここで重要なポイントをいくつか共有させていただきます。 先ほど申し上げたように、ワークロードの分類を適切に行うことが重要です。すべてに同じ戦略を適用するのは適切ではないでしょう。AWSアカウントチームと協力することも大切です。以前お話ししたように、ほとんどのお客様がS3バケットでバージョニングを使用していないため、アカウントチームと協力することで、現在の環境を分析し、何が保護されているか、されていないかを把握できます。すべてのデータサービスには、高可用性とデータ保護のための複数の機能があります。そして、先ほど述べたように、複数のコピーを保持することが、異なる場所に複数のコピーを保存することで障害から守る最善の方法です。
以上でセッションを終了しますが、 今週は素晴らしいセッションが多数ありました。まだご覧になっていない方のために、いくつかのセッションは録画されYouTubeで公開されています。すべてのブレイクアウトセッションは録画され、現在公開中です。AWS Backupの新機能や、STG 409で説明したRansomware対策などをご覧いただけます。もちろん、このセッションも録画されています。これらのセッションにアクセスするには、AWSチャンネルではなく、AWS EventsチャンネルのYouTubeをご利用ください。来週には、re:Invent 2024のプレイリストが公開され、そこでカテゴリー別にすべてのブレイクアウトセッションを閲覧できるようになります。
本日は私たちと時間を共にしていただき、ありがとうございます。皆様がReplayやその他の夕方のイベントの準備をされている最中だと存じますが、ぜひアンケートにご協力いただき、フィードバックをお寄せください。そうすることで、私たちのセッションをより良いものにし、来年も皆様とお会いしてアプリケーションのResiliencyについてお話しできればと思います。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion