re:Invent 2024: AWS Backupの最新機能とランサムウェア対策
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - What’s new with AWS Backup (STG203)
この動画では、AWS Backupの最新情報と活用事例について詳しく解説しています。現在14万を超える顧客が2.9Exabyteものデータを保護しているAWS Backupの機能と、新たに追加されたLogically Air-gapped Vaultによるランサムウェア対策について説明します。また、Freddie MacとSkyscannerの事例を通じて、大規模組織でのAWS Backupの実践的な導入方法や、Infrastructure as Codeを活用したRestore手法など、具体的な活用方法を紹介しています。特にSkyscannerの事例では、CloudFormationテンプレートとCICD環境を組み合わせた独自のRestore方法など、実践的な知見が共有されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS Backupの概要と本セッションの目的
おはようございます。re:Inventへようこそ。皆様がこのLas Vegasでのセッションを選んでくださり、大変嬉しく思います。AWS Backupの最新情報についてご紹介させていただきます。私はAWS BackupチームのシニアプロダクトマネージャーのBisman Sethiです。本日は、AWS BackupチームのワールドワイドソリューションアーキテクトであるSabith Venkitachalapathyと一緒に登壇させていただきます。彼は、世界中のお客様のデータ保護戦略をAWS Backupへ、コスト効率よく安全に移行するお手伝いをしています。また、素晴らしいお客様であるFreddie MacのFaheem LarikさんとSkyscannerのAlex Mackechnieさんにもご参加いただいています。朝9時にもかかわらず、会場が満員で大変うれしく思います。AWS Backupをご存知の方、あるいは実際に使用されている方は手を挙げていただけますでしょうか？ 素晴らしいですね。このセッションが終わる頃には、さらに多くのお客様に採用していただけることを願っています。
本日は、AWS Backupとは何か、そしてなぜこれほど重要なツールなのかについて詳しくご説明させていただきます。最近のリリース内容や、お客様からのフィードバック、そして最適なデータ保護を実現するために必要だと考えている要素についてお話しします。そして最も重要な部分として、実際にAWS Backupを使用されているお客様に、製品の活用方法や、データ保護の目標達成にどのように役立っているかについてお話しいただきます。
AWS Backupの重要性と最新機能
まず初めに、私たちがここにいる理由についてお話しします。ビジネスクリティカルなアプリケーションを支えるデータが指数関数的に増加していることは、皆様ご存知の通りです。企業もお客様も、そのデータを確実に保護し、ガバナンスとコンプライアンスを確保するためのツールを必要としています。もはやTerabyteやPetabyteの時代は過ぎ、私たちはExabyte規模の時代に突入しています。 このことがいかに重要であるかを示す数字として、現在14万を超えるお客様が私たちのサービスでデータを保護しており、その総量は2.9Exabyteに達しています。これは膨大な量のデータであり、今後もさらに増加し続けると予想しています。14万のお客様といっても、大手企業だけではありません。データ保護の取り組みを始めたばかりのスタートアップ企業も含まれており、私たちのサービスがいかに重要であるかを物語っています。
ありがとうございます。AWS Backupがお客様のデータ保護をどのような規模で行っているかをご理解いただいたところで、バックアップ分野で見られる3つのモデルについて振り返ってみましょう。最初は、バックアップベンダーが提供するソフトウェアを使用して、オンプレミス環境のバックアップアプライアンスに企業データセンターのデータをバックアップする戦略から始まりました。クラウドの出現により状況は変化し、主にオンプレミスのデータセンターに存在するデータをクラウドにバックアップし、データの2次コピーを確保するというハイブリッドモデルが登場しました。そして、よりクラウドネイティブなアプリケーションアーキテクチャの採用に伴い、AWSネイティブで実行されるワークロードが増加しています。
AWS Backupは、データ保護要件から逆算して作業できるポリシー駆動型のサービスです。データ保護要件や戦略を特定したら、AWS Backup内でポリシーを定義するだけで、AWS Backupが複雑な作業を代行してくれます。現在AWS Backupでサポートされているすべてのサービスは、単一のポリシーでバックアップすることができます。これには、バックアップの頻度、保存場所、コピー数、ライフサイクルなど、さまざまなバックアップ戦略が含まれますが、AWS Backupではそれらすべてが簡素化されています。
AWS Backupが得意とするいくつかのユースケースについて、より詳しく見ていきましょう。まず第一に、先ほど3番目のモデルとして説明したCloud nativeバックアップです。Cloud nativeバックアップでは、本番データが稼働している個々のサービスでデータ保護戦略を定義する必要がなく、AWS Backupが差別化されていない重労働を代わりに行ってくれます。これがCloud nativeバックアップの側面です。また、ヘルスケアや金融サービスなどの規制産業でワークロードを実行している場合もあるでしょう。
規制産業でワークロードを実行する場合、DORAのような規制要件に対応する必要があれば、規制要件から逆算して考えることができます。AWS Backupを使用してデータ保護戦略を定義すれば、バックアップを実行するだけでなく、社内外の監査人に提出できるレポートも提供されます。
3番目の重要な柱は、災害復旧です。システムの回復力と潜在的な障害に備える必要があります。運用上の復旧については、最初の柱で見たCloud nativeバックアップでカバーされます。リージョンの障害に対する回復力を考える場合は、マルチリージョンバックアップの戦略を策定する必要があります。
4番目の柱は、最近特に注目されているサイバー回復力です。これは、ビジネスのダウンタイムを最小限に抑え、ビジネス継続性を維持しながら、内部および外部の脅威から保護することを目的としています。これには、AWS Backupがバックアップの安全性、可用性、クリーンな性質を確保するランサムウェア復旧の側面も含まれます。 このサイバー回復力の分野で、AWS Backupは最近、新しいタイプのAWS Backup vaultである論理的なエアギャップ付きVaultの一般提供を発表しました。Backup vaultを使用すると、データ分類要件に基づいて、すべてのバックアップを論理的にグループ化し、単一のエンティティとして管理・維持することができます。
Vaultのコンセプトに2つの大きな変更を加えました。1つ目は、AWS Backup vaultの不変性が必須となり、論理的なエアギャップ付きVaultを作成する際にはデフォルトでComplianceモードが必要になりました。これは主に、攻撃者が最後の防衛線であるバックアップを標的にすることが多いためです。2つ目は、以前はCustomer-managed keyが単一障害点となっていたため、AWS Backup service-owned keyを導入しました。また、AWS Backup論理的エアギャップ付きVaultとAWS Resource Access Managerのシームレスな統合により、復元と検証のエクスペリエンス全体を簡素化しました。これにより、論理的なVaultのコンテンツを、AWS Organization内だけでなく、他のAWS Organizationの異なるアカウントとも共有できるようになりました。
論理的なエアギャップを持つVaultによるリカバリーポイントの保護に加えて、世界中の規制当局は災害時にバックアップがクリーンで復元可能であることを確認するよう求めています。AWS Backupは昨年、Restore Testingの一般提供を開始しました。この機能により、Backup Planの定義と同様に、テスト戦略に基づいてRestore Testing Planを作成することができます。リカバリーポイントの週次テストをスケジュールし、復元可能性を検証できます。さらに、サードパーティプロバイダーと連携して、Lambda関数を使用したランサムウェアスキャン、マルウェアスキャン、データベース検証などのバックアップコンテンツの検証を実行することができます。
AWS Backupのプロダクトマネジメントとエンジニアリングチームは、今年、エンドユーザーのために素晴らしい機能の開発に取り組んできました。 最近、S3バックアップの改善を行い、以前は最新バージョンのみだったものを、すべてのバージョンを復元できるようになりました。これは多くのお客様からのリクエストでした。また、特定のリソースタイプに対するクロスリージョン・クロスアカウントバックアップの機能を拡張し、AWS Backupの機能強化も行いました。
また、AWS Backup Calculatorの機能強化も行いました。お客様が大規模に導入を検討する際、コストが最重要課題であることは周知の事実です。これらについて、セッション後に詳しくお話しできればと思います。ここまで、Sabithと私はAWS Backupの素晴らしさと提供する機能について一日中話すことができますが、実際にこれを日々使用しているのは私たちのお客様です。ここで、Freddie Macのファヒーム・ラリクさんをステージにお招きして、彼の経験についてお話しいただきたいと思います。
Freddie Macにおけるデータ保護戦略の強化
ありがとうございます。私はFreddie Macのプラットフォーム・インフラストラクチャーチームに所属するFaheem Larikです。本日のセッションでは、AWS Backupを使用してデータ保護戦略をどのように強化したかについてお話しさせていただきます。プレゼンテーションは3つの主要なセクションに分かれています。まず、AWS Backupを導入した主な理由について説明し、次にソリューションの概要を簡単に説明し、最後に導入過程で得られた教訓についてお話しして締めくくりたいと思います。皆様にとって有益な情報となれば幸いです。
本題に入る前に、Freddie Macについて簡単にご説明させていただきます。Freddie Macの使命は、米国住宅市場に流動性、安定性、そして手頃な価格を提供することです。私たちは二次住宅ローン市場で事業を展開しています。これは本質的に、お客様に直接ローンを提供するのではなく、貸付機関からローンを購入し、証券化して資本市場に売却することを意味します。その見返りとして、貸付機関は受け取った資金で住宅所有者や借り手により多くのローンを提供することができます。私たちは、Single FamilyとMultifamilyの2つの事業セグメントで事業を展開しており、Capital Markets部門がこれらをサポートしています。お客様をサポートするため、様々なツール、テクノロジー、プログラム、サービスを提供しています。また、一般の方々の教育のために、住宅所有者向けの多くのリソースやツールも提供しています。
それでは、本題に戻らせていただきます。 まず、データ保護戦略における改善が必要な主要分野について説明させていただきます。6年前、私たちがAWSでの取り組みを開始した当時は、アプリケーションとインフラストラクチャのモダナイゼーションに注力していました。最初のバックアップ方式では、個々のAWSサービスをバックアップするためにAWSが提供するネイティブツールを使用していました。当時使用していたツールで十分にデータを保護できていましたが、利用規模が拡大するにつれて、より一元的な管理機能が必要だと認識するようになりました。そこで、AWS Backupを検討することになったのです。
バックアップの一元管理アプローチに加えて、業界のトレンドにも注目しました。マルウェアの脅威が業界でより巧妙化する中、私たちのセキュリティと運用レジリエンシーチームは、実装すべき指示事項や要件を継続的に更新していました。バックアップデータのイミュータブルコピーやクロスリージョンコピーなど、新たな要件も加わりました。Freddie Macには複数のインフラストラクチャ開発チームがあり、先ほど申し上げた分散型アプローチでは、それぞれのチームが独自の方法でネイティブツールを使用してサービスのバックアップを行っていました。一元的なアプローチでは、ポリシーが一貫して適用され、これらの様々なインフラストラクチャ開発チームに確実に採用されるようにしたいと考えていました。 これらの重点分野に対応するため、目標を設定しました。第一に、適切な実施メカニズムとモニタリングメカニズムを確保するための一元的な管理機能を実現することです。第二に、Recovery Time Objectiveを短縮することです。つまり、より迅速なデータのバックアップと復旧を実現したいと考えました。
具体的には、ソースデータが侵害された場合に備えて、バックアップのコピーが確実に完全な状態で保持されるようにする必要がありました。これが、データのイミュータビリティが重要となる部分です。運用上のニーズに対応するローカルバックアップに加えて、バックアップのクロスリージョンコピーも必要でした。サービスの管理や構築に時間を費やすのではなく、実際のバックアップサービスの重要な部分はベンダーに任せたいと考えました。エンジニアリングリソースは、導入と実装に集中させたかったのです。システムバックアップポリシーとサステナビリティも重要な目標でした。サステナビリティとは、ポリシーを一貫して適用し、モニタリングを行い、一定レベルの制御を持って異常が発生した際に対応することを意味します。
それでは、ソリューションの概要についてご説明します。このダイアグラムは、 AWS Backupを私たちの環境に統合した論理アーキテクチャの概要を示しています。上部には管理アカウントがあり、ここでポリシーを適用し、ポリシーへの継続的なコンプライアンスをモニタリングしています。AWS Audit Managerは、バックアップのステータスを監視するためのソリューションの重要なコンポーネントです。その下のセクションは、データ資産を持つリソースタイプを示しています。これらのリソースが存在する特定のリージョンには、ローカルバックアップを迅速に実行し、復旧することができるローカルバックアップVaultを設置しています。これにより、Recovery Time Objectiveを短縮することができます。バックアップのイミュータビリティという要件を満たすため、Compliance Lockを備えたクロスリージョンの論理的なAir-gapped Vaultを実装しました。
Freddie Macでは、Clean Roomという概念を導入しました。これは通常のアカウントと変わりありませんが、異なる目的で使用されます。アプリケーションチームやデータオーナーが、ターゲット環境に復元する前に、分離された環境でデータを検証することができます。これはオプションの中間ステップですが、アプリケーションオーナーに対して、実際の環境にデータを戻す前にVaultから復元されたデータを確認できるという安心感を提供します。AWS Backupの各コンポーネントの連携方法を設計する際、ほとんどの重要な作業はAWSによって行われています。スケール、パフォーマンス、可用性、データの整合性の保証など、これらすべてのコンポーネントを自分たちで設計する必要がなかったことは、大きな助けとなりました。
さらに、私たちはソースレベルでのコスト最適化も実施しました。AWS Backupがデータのコピーを作成し、不変なコピーを保持していることに気付いた時、コストの観点から検討を行いました。AWSリソースが存在するソースを調査したところ、S3ライフサイクルポリシーを使用していないことが分かりました。そこで、S3ライフサイクルポリシーを実装して、非カレントバージョンや不要なデータを削減しました。また、実行しているサービスの中には一時的な性質のものもあれば、永続的なデータとしてVaultに保存する必要があるものもあるため、除外プロセスも実装しました。これらがコストを抑制するために実施した追加的な施策の一部です。
次のスライドに移って、いくつか追加の事項についてお話ししたいと思います。
プレゼンテーションのまとめに入る前に、私たちの環境にAWS Backupを導入する過程で得られた教訓をいくつか共有させていただきたいと思います。これらは皆様の実装にも役立つかもしれません。タグベースのリソース包含により、バックアップ導入プロセスが簡素化されました。特定のタグを使用して、特定のリソースをバックアップシステムに含めるか除外するかを簡単に決定できます。実装はエンドユーザーやアプリケーション所有者にとって非常に透過的ですが、何を除外し、何を含めるかを把握し、そのためのプロセスを開発する必要がありました。データのソースを確認し、何が適切か、どのようなプロセスを設定する必要があるかを検討する必要があるでしょう。
コスト最適化について言及しましたが、S3ライフサイクルポリシーによる非永続的データの除外など、すでに触れた点もあります。AWSはすでにContinuous Backupを提供していますが、私たちは定期バックアップから始めて、その後Continuous Backupに移行しました。これはリカバリーポイントの観点だけでなく、コスト最適化の観点からも有効でした。S3上の削除マーカーに対処する必要があり、コストに影響を与えていた削除マーカーの除去も検討しました。
私が最も重要だと考える教訓は、検証済みのリカバリープロセスです。マネージドサービスを使用しているとはいえ、AWS Backupは復元機能を提供してくれます。インフラストラクチャを見たとき、一時的なリソースやクラウドネイティブアプリケーションが存在します。Infrastructure as Codeとしてのインフラストラクチャのエンドツーエンドのリカバリープロセスについて考えるとき、AWS Backupを使用してどのようにエンドツーエンドで復旧するかを理解する必要があります。データ資産だけでなく、アプリケーションも復旧できることを証明するために、広範なテストを実施する必要がありました。リカバリープロセスを実装する中でプレイブックを更新する際に多くのことを学べたため、この演習は非常に価値のあるものでした。
モニタリングと自動化は、私たちが重点的に取り組んだもう一つの分野です。AWS Audit Managerを使用し、Audit Managerを通じて異常を発見した際には、社内で使用しているインシデント管理プロセスと連携するための追加の自動化を構築しています。これにより、異常を非常に迅速かつ効果的に修正することができます。コアとなるモニタリングはAudit Managerを通じて行っていますが、それに加えて、インシデント管理プロセスとの連携のために独自に構築した自動化で補完しています。
最後の重要なポイントは、Platform EngineerとDeveloperのトレーニングです。冒頭で申し上げたように、私たちは分散型の複数のインフラ開発チームを持っています。バックアップ機能自体は一元化しながらも、その実施と採用が全チームで一貫して行われることを目指しました。ソリューション自体はインクルージョンとエクスクルージョンで単純明快ですが、リソースに関してどこに焦点を当てるかを理解することが重要です。これには、Kubernetesクラスターのようなワーカーノードが一時的なエフェメラルなインフラと、常に存在するペット型インフラに対して、バックアップソリューションをどう使用するかといったエフェメラルリソースの管理も含まれます。オンプレミスで使用される従来のバックアップシステムとは異なり、ここではインフラストラクチャコードのコンポーネントがあり、S3やデータベースのようなデータ資産だけでなく、私たちが注力したインフラストラクチャコードについても考える必要があります。人々は、それをサポートする復旧プロセスの使い方を理解する必要があります。
ここまでで終わりではありません。 リストアのテストの機能について述べたように、リカバリー検証の時間を節約できるこのプロセスの実装とテストを継続しています。また、すべてのリソースに対するContinuous Backupへの移行も進めています。
Skyscannerのバックアップとリストア戦略
ご清聴ありがとうございました。Banに残りのプレゼンテーションをお返しします。Faheemさん、ありがとうございました。お客様がAWS Backupをどのように使用し、適切なリソースのクリーンアップと製品の適切なサイジング、そしてコンプライアンス要件の確実な充足という journey を経ているかを聞くことができて良かったです。では、バックアップに関する全く異なるjourneyを持つAlexに引き継ぎたいと思います。
私はAlex Mackechnieで、スコットランドのGlasgowにあるSkyscannerのSenior Software Engineerです。現在、ProductionプラットフォームとSecurityトライブを横断して仕事をしています。本日は、過去数年間のSkyscannerにおけるAWS Backupのjourneyについてお話しさせていただきます。 私たちは旅行分野のグローバルリーダーとして、旅行者が簡単かつ確実に旅行を計画し予約できるようサポートしています。毎月1億1,000万人以上のユーザーが180カ国から33の言語でアクセスしており、1,200以上のフライト、ホテル、レンタカーのパートナーと旅行者をつないでいます。これらの旅行者のために、私たちは毎日800億以上の価格を検索することで、旅行の複雑さを簡素化しています。
まず最初に、私たちが解決しようとしていた問題について振り返ってみましょう。数年前、本番システムの運用に不可欠なデータの大部分が、データ損失のリスクから十分に保護されていませんでした。具体的には、運用データの話です。データ駆動型の企業である私たちにとって、これは重大な問題でした。克服すべき課題がいくつかありました。まず1つ目は発見です - 組織内のすべてのアカウントに存在するデータストアの全体像を把握できていませんでした。2つ目は所有権です - ほとんどのデータストアには所有者がいましたが、一部には所有者がいませんでした。3つ目は重要度です - 実際に本番トラフィックを処理するために使用されているのか、それとも全く使用されていないのかということです。最後にバックアップです - このデータのごく一部のみが、組織全体で一貫性のない様々なツールを使用してバックアップされている状態でした。
プラットフォームとセキュリティの機能として、私たちには明確な最初の目標がありました。それは、どのような運用データを持っているのか、誰が所有しているのか、そして運用にとって重要なのかを理解することでした。どのようなデータを持っているかを理解することは比較的単純な問題です - 既存のインベントリを拡張して、より多くのアカウント、リージョン、AWSサービスをカバーするようにしただけです。所有権の問題については、セキュリティチームが組織全体を調査して、所有者不明のデータストアの所有者を特定し、その所有権を帰属させるという素晴らしい仕事をしてくれました。そして重要度の問題に取り組んだとき、いくつかの問題に直面しました。サービスチームや自チームのメンバーにデータが重要かどうかを尋ね始めたとき、人々の回答は「重要」の定義に基づいていましたが、それは誰に聞くかによって全く異なることに気づきました。そこで、重要度の標準的な定義を設定し始めました。サービス所有者に、データが完全に失われたと仮定し、そのデータなしでビジネスを進める場合に重大な影響があるかどうかを尋ねることにしました。「いいえ」と答えた場合は、データをバックアップする必要はありませんでした。しかし「はい」と答えた場合は、フォローアップの質問をしました：そのデータは再作成できますか？データを再作成できず、失うと重大なビジネス影響が出る場合、それは間違いなくバックアップが必要なものです。
ただし、データが再作成可能な場合は、より微妙な考慮が必要です。データの再作成にどれくらいの時間がかかるのか、データ再作成期間中のビジネスや製品への影響はどの程度か、そしてそのデータをバックアップするコストはどれくらいかを評価する必要があります。この時点で、さらに多くの議論とトレードオフが行われました。
並行して、プラットフォームチームは、 AWS組織内で運用でき、AWS Backupを中核として持つ、すべてのアカウントに対応できる集中型バックアップソリューションの構築に取り組んでいました。左側には、実際のサービスワークロードを実行しているワークロードアカウントであるソースアカウントがあります。これらのサービス所有者向けに、AWS Backupのタグベースのリソース選択を使用して、データストアに単にタグを付けるだけで、同じアカウント内のソースボールトに直接オンボーディングできるようにしています。中間ボールトは一旦置いておいて、その後、中央バックアップアカウントにクロスアカウントでコピーし、リージョンとアカウントの境界を越えてコピーします。このアカウント内のすべてのボールトにはAWS Backup vault lockが有効化されており、完全な不変性機能を提供しています。これにより、サービス所有者側での非常に低摩擦なオンボーディングと、完全なデータ不変性の両立を実現しています。
では、中間ボールトについて説明しましょう。この中間ボールトは、私たちが遭遇したいくつかの問題を解決するために実装しました。EBSやRDSなど、AWS Backup内の一部のサービスは、独立した暗号化をサポートしていません。これらのサービスのバックアップを取得し、ソースアカウントのソースボールト内にリカバリポイントを取得すると、そのプロセス中に再暗号化されません。これは通常は許容できますが、Amazon管理のKMSキーで暗号化されたリソースでは問題が発生します。これらのリソースをバックアップすると、リカバリポイントはAmazon管理のKMSキーで暗号化されますが、これはアカウント間で共有できません。中間ボールトはカスタマー管理キーを使用し、同じアカウント内でコピーする際に再暗号化操作を実行することで、中央バックアップアカウントに直接コピーできるようにしています。
データに関する理解と、非常に低い障壁でバックアップを行える能力を持っていたため、サービスオーナーたちのオンボーディングを本格的に開始することができました。これは、AWS Backupへのオンボーディングの重要性とプロセスを説明する様々な組織内コミュニケーションとドキュメントを通じて実現されました。より正式には、これを運用効率化プロセスを通じて追跡しています。CloudFormationテンプレートに対してアサーションを実行する社内ツールがあり、重要なデータストアがすべてバックアップされているかを確認できます。サービスオーナーがこのチェックに失敗すると、PRsに報告され、すべてのPull Requestに表示されます。さらに、これは毎週レビューされる運用効率化プロセスにも報告されます。サービスオーナーとのこのような協力を通じて、運用上重要なデータの100%がAWS Backupにオンボードされた状態に達することができ、大変嬉しく思っています。
このプロセスを通じて何を学んだのでしょうか？まず、すべてのデータストアが同じバックアップ要件を持っているわけではないということがわかりました。当初、すべてのサービスオーナーに対して、日次バックアップの頻度と保持期間を設定すれば良いと単純に考えていましたが、これは間違いでした。特に大規模なデータストアを持つサービスオーナーの中には、ニーズを満たしコストを削減するために、より低頻度のバックアップを望む人もいました。逆に、頻繁に変更されるデータストアを持ち、より短いRecovery Point Objectiveを必要とするサービスオーナーは、より高頻度のバックアップの恩恵を受けられました。
次に、低い障壁でのオンボーディングが必ずしも良いとは限らないということを学びました。このプロセスの中で、900テラバイトのS3バケットを誤ってAWS Backupにオンボードしてしまいました。翌日コストを確認した際、追加のコストを防ぐために、すべてのRecovery Pointを見つけて削除する作業を急いで行いました。幸いなことに、これは強調しておきたいのですが、Vault Lockを有効にする前に発生したため、問題を解決することができました。私たちはこれらの課題を解決したいと考え、SkyscannerではAWS CDKを使用してコアインフラの大部分を定義しているため、バックアップインフラは実際にシンプルなPython AWS CDKアプリケーションを通じて構築されています。
ここで私たちが決めたのは、そのPythonアプリケーション内にSkyscanner固有のバックアッププランを表現するモデルを効果的に構築することでした。バックアッププランには、名前、Cron式の期間を持つルールのリスト、ターゲットとするタグ、ターゲットとするリソースがあります。これにより物事が大幅にシンプルになり、開発者は必要とするバックアッププランを正確に定義するだけで済むようになりました。
舞台裏では、AWS CDKがリソースの実際の構築に関するすべての重作業を処理します。バックアッププラン、リソース割り当て、コピージョブ、そして先ほど示した暗号化の複雑さのすべてが、組織全体にデプロイできるCloudFormationテンプレートに変換されます。さらなる利点として、除外リストを追加することにしました。組織内には、それらのバケットの性質と重要性から、AWS Backupにオンボードしたくないペタバイト規模のS3バケットが数個ありました。そこで、サービスオーナーがそれらのバケットをオンボードしようとしても機能しないように安全策を講じることにしました。ここで見ていただけるように、下部にこの除外リストがあります。
これまでバックアップについて多く話してきましたが、ここからはRestoreについて、私たちがどのように考えているかをお話しします。Skyscannerでは、通常とは少し異なる方法でRestoreを考えています。従来のバックアップの仕組みでは、Restore操作の一般的なワークフローは、必要なバックアップを見つけ、RestoreのAPIを呼び出し、環境で使用できるリソースを起動するというものでした。しかし、すべてがInfrastructure as Codeとしてバージョン管理システムに保存され、継続的インテグレーションとデプロイメントを通じて実行される場合、これらのツールにそれらの変更を反映させる方法に関して問題が生じます。
私たちは、サービスオーナーが他のアプリケーションの変更と全く同じ方法でRestore操作を実行できないかと考え始めました。例を挙げてみましょう。サービスオーナーがEC2インスタンスとEBSボリュームを含むCloudFormationテンプレートを作成し、それをバージョン管理システムにチェックインし、Pull Requestを作成し、承認を得て、マージし、CIとCDを通じてAWSアカウントにCloudFormationテンプレートとしてデプロイします。そのスタックの背後にはEC2インスタンスとEBSボリュームがあり、そのボリュームのデータは継続的に変更され、AWS Backupが毎日そのデータストアのRecovery Pointを取得しています。
私たちにとって重要な発見があったのですが、EBSのRecovery Pointは実際にはアカウント内で確認できるEBSスナップショットによってバックアップされており、そのIDを取得できるということでした。これと、CloudFormationテンプレート内でEBSボリュームを作成する際にスナップショットIDを指定できる機能を組み合わせました。最新のバックアップのスナップショットIDを取得し、それをCloudFormationテンプレート内のEBSリソースのスナップショットIDパラメータとして追加し、バージョン管理システムにチェックインし、Pull Requestを作成し、承認を得て、対象のAWSアカウントにCIとCDを通じてデプロイしました。この時点で、以前と全く同じ構成で、前回のバックアップと同じ状態のスタックが出来上がります。
その結果、これが私たちの組織での標準的なRestore方法となりました。開発者はRestore時でも、普段使い慣れているツールを同じように使用できます。特別な操作は必要ありません。Restoreが必要な場合でも、アプリケーションの変更と同じように、いつも通りにリクエストを作成するだけです。これにより、Restoreの摩擦と認知的負荷が大幅に軽減されました。現在、私たちはRestoreの本格的な運用を進めており、サービスオーナーが定期的にRestore操作を実行することを本番環境の標準として義務付けています。開発者からは多くのフィードバックを得て、頻度を下げる方法やサービスオーナーにとってRestoreをより簡単にする方法を理解しようとしています。Logically Air-gapped Vaultは、特にクロスアカウントのRestoreに大きく役立つでしょう。現在は、Recovery Pointをアカウント間でコピーするためにコピージョブを実行する必要があります。
しかし、Sabithが言及したように、Logically Air-gapped Vaultを使用すれば、AWS Resource Access Managerでリソースを共有するだけで済み、はるかにシンプルで時間を節約できます。先ほど述べたように、私たちは可能な限りこのRestoreプロセスを効率化し続けています。これが、問題提起から始まり、現在AWS Backupに100%移行するまでの私たちの全体的な journey です。
セッションのまとめと今後の展望
Sabithさん、Bismanさん、そしてAWS Backupチームの皆様には、このプロセスを通じて支援していただき、心から感謝申し上げます。チームと協働できたことは素晴らしい経験で、現在は非常に良い状態にあります。ご清聴ありがとうございました。それでは、Bisにバトンをお返しします。Alex、ありがとうございました。あなたとFaheemが、エンジニアリング主導のリストアからClean Room、そしてエアギャップソリューションまで、それぞれ異なる方法でプラットフォームを活用し、要件を満たしている様子を聞けて良かったです。
Q&Aセッションに入る前に、主要なポイントをいくつかお伝えしたいと思います。 Sabithが最初に言及したように、なぜお客様がAWS Backupを使用しているのかを強調したいと思います。お客様は規模に応じた容易な導入を求めていますが、同時にディザスタリカバリ、ランサムウェア対策、コンプライアンスのためにも必要としています。AlexとFaheem、お二人がまさにそのようにプラットフォームを活用されている素晴らしい例をお話しいただきました。全体として、私たちのプラットフォームがデータ保護の一元化、コンプライアンスと展開の効率性、そしてランサムウェア保護プラットフォームとして機能することを重視しています。私たちは新機能への投資を続けながら、お客様のニーズに応える形でプラットフォームを活用していただいています。
さて、週はまだ始まったばかりで、これから多くのセッションが予定されています。 Q&Aの間、このスライドを表示したままにしておきますので、ご覧いただければと思います。これらのトピックについて、リソース固有のランサムウェア対策や、Sabithやチームの他のエンジニアと直接手を動かして学べるコードトークやチョークトークなど、より深く掘り下げたセッションを開催する予定です。私たちは皆様とお話しすることを楽しみにしています。今週中ずっとここにいますので、私やサービスチームをお気軽に見つけてください。Alexも参加していますが、皆様からのフィードバックをお待ちしています。AWS Backupがどのようにお役に立っているか、どのような改善点があるか、そしてプラットフォームをどのように活用されているかについて、ぜひお聞かせください。カスタマースピーカーの皆様、本当にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion