re:Invent 2024: AWSが語るAmazon S3の11ナイン耐久性とデータ保護戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Beyond 11 9s of durability: Data protection with Amazon S3 (STG339)
この動画では、Amazon S3の11ナインのDurabilityを実現する仕組みと、データ保護の方法について詳しく解説しています。S3の耐久性を支える3つの柱として、デバイス障害、ゾーン障害、人的要因への対策を説明し、1秒あたり1ペタバイトを超えるデータ処理を実現する具体的な仕組みを紹介しています。また、Versioningによる上書き保護、Object Lockによる削除防止、S3 Replicationによるクロスリージョンでのデータ保護など、様々なデータ保護機能の実装方法や、AWS Config、Storage Lens、Trusted Advisorを活用した監視・監査の手法まで、S3におけるデータ保護の全体像を包括的に解説しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon S3の11ナインDurabilityと本セッションの概要
Amazon S3における11ナインのDurabilityデータ保護についてご紹介させていただきます。オレンジセクションにいる私たちは、オレンジのヘッドフォンとオレンジの靴を身につけており、この一体感は明らかです。本日は、Amazon S3のSenior Manager of Software DevelopmentであるIan Mc Garryをお迎えしています。彼はVPC Endpoints、Replication、ネットワーキング、そしてLoad Balancerを担当しています。私はRob Wilsonと申しまして、S3 Tables、今週初めにローンチしたS3 Metadata、その他のData Lake機能、セキュリティ、暗号化、Batch Operationsを担当するプロダクトマネージャーチームを率いています。セッション後のQ&Aでは、これらのトピックについて喜んでお話しさせていただきます。
本日のアジェンダでは、いくつかのトピックを取り上げます。まず、Amazon S3が掲げる耐久性の指標である11ナインについての背景から始めます。Ianが、データが正しく保存され長期間維持されることを保証する内部メカニズム、チェック、バランスについて説明します。次に、データ保護に移ります - Amazon S3がどのようにデータを保護し、上書きや誤削除などのシナリオに対する追加の保護を実現するためにどのような機能を使用できるかについて説明します。データ保護の連続体について探り、単一のBucket内でできることから、より強力な回復力のための複数のRegionやアカウントにまたがる追加の保護まで取り上げます。
S3の11ナインDurabilityを支える3つの柱とデータ保護メカニズム
S3をご利用の方なら、この数字をご存知でしょう - 99.999999999%のDurability、つまり11ナインのDurabilityです。これは私たちが基準としている数字です。社内では、完全なデータ損失ゼロを目指しています。11ナインのDurabilityは重要ですが、日々の運用では一切のデータ損失を防ぐことを目指しています。この数字を達成するためのメカニズムは、規模の面では単純に見えるかもしれませんが、運用の範囲における複雑さが課題です。お客様のデータを保存するために何百万台ものドライブを使用しています - すべてのドライブを積み重ねると、国際宇宙ステーションに何度も到達できるほどの高さになります。
私たちが処理しているデータ量は、1秒あたり1ペタバイトを優に超えています。S3に入社した当時は、テラバイト単位でした。これを分かりやすく説明すると、高品質な画像の平均サイズを3メガバイトとすると、毎秒約4,100万から4,200万枚の画像を転送していることになります。Durabilityに関して私たちが考える3つの重要な柱があります：実際のハードディスクの故障に関するデバイス障害、Availability Zoneが機能し、完全なAZの損失に耐える必要があるゾーン障害または施設障害、そして最後に人的要因 - 日々の運用、コードのデプロイ、設定変更がDurabilityにどのように影響するかということです。
これらの柱について詳しく見ていきましょう。まずはデバイス障害から始めます。 最初の柱について、問題提起から始めましょう。これはドライブの故障に関することです。故障したり、保存中のビットが破損したりする可能性のあるドライブ上のデータを保護する必要があります。保存中のビットの破損は、ストレージメディアの現実的な問題です。ハードディスクドライブにビットを保存する際、故障してデータが破損する可能性があります。
では、これらの問題から自身を守るための実際のメカニズムとは何でしょうか？3つあります。 1つ目は整合性チェックです。これはチェックサムを使用して、お客様から送信されたデータが実際に私たちが保存しているものと同じであることを検証します。 2つ目はデータ冗長性、つまりドライブ冗長性です。これは、データを複数のドライブに分散して保存することで、単一のドライブの障害によってデータが失われないようにします。 そして3つ目は定期的な耐久性監査です。これは、保存したデータを取り出そうとした時に同じデータが取り出せることを確認し、さらに時間の経過とともにデータが劣化していないかを継続的にチェックしています。この監査は非常に重要な要素です。データを長年にわたって保存する方法を考える上で重要なので、後ほど詳しくお話しします。
それでは、最初の要素であるリクエストのエンドツーエンドの整合性チェックがどのように機能するのか見ていきましょう。リクエストのライフサイクルを見てみましょう。 お客様がPut Objectリクエストでデータを送信し、それが私たちのリクエストプレーンまたはデータプレーンに到達すると、そのオブジェクトに対して直ちにチェックサムの計算を開始します。これにより、後でこのデータに変更を加える際に、お客様から送信されたデータが私たちが保存しているものと同じであることを確認できます。この過程でデータは変換されます - 暗号化されたり、フレーム化されたりして、最終的にイレイジャーエンコーディングを行う段階に到達します。 ここでデータをシャードに分割し、それらのシャードのコピーを作成して、多数のドライブに分散して保存します。これにより、後でデータを再構成することができます。
これが前方へのパスの様子ですが、では戻りのパスはどうでしょうか？データが保存されたことをどのようにお客様にお伝えするのでしょうか？私たちはこのプロセスを「ブラケティング」と呼んでいます。 これは、チェックサムを計算し、イレイジャーエンコーディングを使用してデータをシャード化し、保存した後、チェックサムを再計算して戻るということです。これにより、私たちが行った作業がデータの本質を変更していないこと、そして同じチェックサムを持っていることを確認します。前方に計算して進み、その後、後方に戻って再度計算することで、データを保存するために行った変更後も、お客様が送信したのと同じデータを保持していることを確認します。 これらすべては、お客様に200 HTTP成功レスポンスを送信する前に行われます。つまり、お客様のデータが多数のチェックサムと共に複数のドライブに確実に保存されていることをお知らせできます。これは大量のチェックサム計算に聞こえるかもしれませんが、実際その通りで、私たちは1秒あたり約40億回のチェックサムを計算しています。これは膨大な計算量ですが、耐久性は私たちにとって非常に重要なので、この投資を行っています。
S3のデータ耐久性を確保するための監査と修復プロセス
次に話したのはドライブ冗長性についてです。ここに非常にシンプルな図があります。実際には5台ではなく、もっと多くのドライブがありますが、実際の仕組みを理解しやすくするために簡略化して説明します。 それぞれ異なるデータの断片が保存された5台のデバイスがあります。ドライブが故障すると、そのドライブ上のチャンクA、B、Dのデータにアクセスできなくなります。しかし、ドライブが故障した時、私たちは内部で「修復」と呼ぶプロセスを使用して、そのデータを別のドライブに再構成します。 1台目のドライブからチャンクA、4台目からチャンクB、5台目からチャンクDを取得していることがわかります。これにより、そのドライブ上のデータを全く同じ方法で再現することができます。先ほど述べたように、このプロセスを内部では修復と呼んでいますが、実際にはドライブを修復しているわけではありません - そのドライブのビューを修復しているのです。つまり、そのドライブにあったデータを取り出して、他のドライブで利用可能にしているのです。
これをより大きなスケールで見てみましょう。この興味深い図では、ドライブが継続的に故障し、私たちが継続的に修復を行っている様子が分かります。データが複数の冗長ドライブに分散されているため、すべてのドライブに実際にデータが存在していることがわかります。修復を待つ空のドライブを大量に用意しているわけではなく、すべての異なるドライブにわたって空き容量を確保しています。これにより、修復時にはそれらのディスクすべての処理能力を活用して修復を支援できます。多数のドライブ間でデータを移動する場合、1台のドライブに高速でデータを詰め込むよりも、修復時に大きなスループットを得られます。このように、非常に大規模なスケールで処理が行われているのです。
これがドライブの冗長性と、私たちが修復プロセスと呼んでいるものです。 3番目に説明したのは、ドライブにとって重要な監査についてです。ドライブは故障時に単に通知するだけではありません - アクセス不可能になることもあり、その場合はエラーが発生するため簡単に検出できますが、静かにビット反転を起こすこともあります。これが私たちが懸念している部分です。私たちは以前に計算したチェックサムを使用して、定期的にデータを取り出し、チェックサムを再確認して一致することを確認することで、これらのドライブを継続的かつ積極的にチェックしています。一致しない場合、そのドライブがビット反転を起こしていることがわかります。これは常時行われているプロセスで、レプリケーションシステムを活用してそのドライブを故障したものとして扱い、他の場所からデータを修復して取得することができます。
これらすべてを組み合わせると、 実際には故障率が得られます。これはドライブがオフラインになるケースやビット反転を起こすケースを含み、それに対して修復率があります。これを数理モデルに組み込んで、11個の9で表される耐久性を計算します。ドライブが特定の率で故障している場合、その前を行くために必要な修復率を把握し、11個の9を計算します。私たちは11個の9を基準としていますが、常にその目標を確実に達成できるよう、それを大きく上回る水準を維持しています。
Availability Zone障害に対するS3の耐性と迂回ルーティング
ゾーン損失について話しましょう。私たちの課題は、ゾーン全体が予期せず失われた場合でも、保存されているデータを保護しなければならないということです。単一の施設がいつでも故障する可能性があることを前提とし、その中に保存されているデータの耐久性を保護し続けなければなりません。 先ほどの例に戻りますが、これを12台のドライブに拡張すると、これは実際にはRegionを表しています。これを分解すると、各Availability Zoneにドライブがあります。ほとんどのStorage ClassはすでにマルチAZなので、これについて心配する必要はありませんが、これが内部的な仕組みです。
整合性チェックの際に説明したのと同様のリクエストの流れを見ていきましょう。リクエストを受け取ると、途中でチェックサムを実行し、逆ブラケット処理を行って、送信されたものを正確に保存していることを確認します。イレイジャーエンコーディングから生成されたデータのシャードとそのコピーは、複数のAvailability Zoneにわたって保存されます。200レスポンスを返す時点で、データは3つのAvailability Zoneの多数のディスクに耐久的に保存されています。
データの取得に関して、私たちはAvailability Zone全体が予期せず失われた場合でも利用可能な状態を維持しなければなりません。単一の施設がいつでも故障する可能性があることを前提とし、ゾーン全体がオフラインになっても要求に応え続けなければなりません。 先ほど述べたように、データは3つのAvailability Zoneに保存されています。オブジェクトを取得しようとした時にAZ3がオフラインになっていても、他の2つのAvailability Zoneに十分なデータシャードがあるため、オブジェクトを再構成し、チェックサムを行って返すことができます。AZが故障しても、ほとんどの場合気付くことはないでしょう。これは耐久性ではなく可用性に関することです。なぜなら、データを返すことについて話しているからです。耐久性はデータを保存した時点のPutで保証されており、それによって後で故障が発生しても対応できるのです。
AZに障害が発生した場合の迂回ルーティングの仕組みについて、原理的な観点から説明させていただきます。これは私がS3チームに入社した当初に担当した分野で、DNS、ルーティング、ネットワーキングに焦点を当てていました。表面上はシンプルですが、内部は複雑な仕組みになっています。皆さんがご存知かもしれない、あるいはSDKに隠れていてお目にかかることのないS3のDNS名について、Northern Virginiaを例に挙げると「s3.us-east-1.amazonaws.com」があります。このエンドポイントに対してdigコマンドを実行すると、us-east-1のIPアドレスが返されます。これを繰り返し実行すると、複数のIPアドレスが表示され、それらは異なるAvailability Zone上のサーバーのIPアドレスであることがわかります。特に優先順位はなく、トラフィックをフリート全体に均等に分散させるためにランダムに返されます。停電やネットワーク障害などでAZに障害が発生した場合、それをすばやく検知してそれらのIPアドレスをDNSから削除するため、エンドポイントの名前解決時には正常なサーバーのIPアドレスのみが返されます。
この処理は非常に迅速に行われます。そのため、DNS名前解決時にDNSから返されるTTL（Time To Live）、つまりそのIPアドレスをキャッシュしておける時間を必ず守ることが重要です。S3の場合、TTLは5秒という非常に短い値に設定されています。これは、障害が発生した場合に、最初のDNS解決から再解決までの時間を極めて短くし、実際に使用可能なIPアドレスのみを取得できるようにするためです。
DNSのTTLを遵守することは非常に重要です。SDKではデフォルトでこれが行われるため、特に気にする必要はありません。ただし、カスタムクライアントやVPC内、あるいはオンプレミスでカスタムDNSリゾルバーを使用している場合は、デフォルト値で上書きするのではなく、S3のDNSを尊重するように設定することが非常に重要です。これが可用性の姿勢であり、Availability Zoneの障害時の迂回ルーティングの仕組みです。
S3のデータ保護機能とVersioningの重要性
Availability Zone間の障害分離は、電源、ネットワーク、冷却、水などのハードウェア自体の分離だけでなく、 実際の運用のフレームワークとしても機能し、非常に有用なメカニズムとなっています。なぜなら、AZの障害が発生しても、ユーザーが気付くことなくリクエストの処理を継続できることがわかっているからです。そのため、デプロイメントを行う際は、常に1つのAvailability Zoneずつ実施します。日常的なメンテナンスや運用を行う際、私たちのツールではこの方法でのみ作業が可能です。ソフトウェアのデプロイ、設定変更、新しいハードウェアの導入など、あらゆる作業をAvailability Zone単位で行います。
常に1つのAvailability Zoneでのみ作業を行うという考え方は、エンジニアやマネージャーに深く根付いています。これにより、バグが発生したりエラーが起きたりしても、そのゾーンの可用性がリージョン全体の可用性に影響を与えることはないため、リージョン全体に影響を及ぼすことなく対処できることがわかっています。 これまでお話ししてきたのはデバイスの障害についてです。また、ゾーンの障害と、私たちがどのようにゾーンの障害境界を活用して変更を加えているかについても説明しました。私たちは正しく動作するようにシステムを構築しており、それらは非常に堅牢です。私たちのコードや、サービスの変更、ツールの大部分は、その正確性を維持することに重点を置いていますが、それでも不正確である可能性を想定し、変更による問題を軽減するための追加的なガードレールを設けています。
これらのガードレールの具体例を2つご紹介します。1つ目は、新しいハードウェアに対するControl Planeの制限です。先ほど申し上げたように、新しいハードウェアの導入は一度に1つのAvailability Zoneでのみ行います。しかし、Control Planeはオブジェクトのデータが新しいハードウェアに不均衡に配置されることを防いでいます。これは、新しいハードウェアに問題が発生した場合でも、他のディスクからデータを取り出せるようにするためです。修復プロセスは、これが新しいハードウェアであることを認識し、オブジェクトやシャードを過度に新しいハードウェアに配置することはありません。
もう1つのガードレールは、Shadow Mode（メトリクスモードとも呼ばれます）です。これは、必ずしも外部への副作用を持たない大規模な変更を、既存のコードと並行して実行する方法です。リクエストやメタデータの処理時に、新しい変更をデプロイして新しいコードでそのメタデータを同時に処理することがありますが、新しいコードでの変更は永続化しません。新しい変更に対してメトリクスを出力し、既存のコードと新しいコードの結果を比較します。何か異常が見つかった場合は、デプロイ前にコードを修正することができます。すべてのメトリクスが完全に一致することを確認できれば、そのコードは大規模にデプロイしても安全だと分かります。この方法ではコードのリリースに時間がかかりますが、私たちの運用規模で変更が非常に安全であるという確信を得ることができます。
失敗ドメインとガードレールについてお話ししてきましたが、ここでS3の興味深い歴史についてお話ししたいと思います。S3はグローバルサービスですが、リージョン単位で分離されています。 S3は全てのAWSリージョンで3つ以上のAZで運用されており、どのリージョンのどのAvailability Zoneの障害にも対応できます。しかし、ここで
私たちは、予期せぬゾーン全体の損失に対しても、保存されているデータを保護しなければなりません。どの施設も任意のタイミングで障害が発生する可能性があると想定し、その中に保存されているデータの耐久性を確保する必要があります。現在の構造では、AZが停止しても対応できるため、この脅威は比較的簡単に対処できます。
S3が当初はグローバルサービスとしてスタートしたことをご存知の方はいらっしゃるでしょうか。2006年から2010年の間、私たちは2つのリージョンを持っていましたが、それらは単一のエンドポイント、つまり単一のストレージサービスとして提供されていました。東海岸にはVirginiaがあり、西海岸にはWashingtonがありました。これは当時のビジョンの一部でした。というのも、私たちはまだリージョン分離について十分に理解していなかったのです。これは時間をかけて理解していったプロセスでした。私たちはグローバルサービスを目指していました。その一つの理由として、Webサイトがグローバルなリソースとしてアクセス可能な形で提供されているように、私たちのストレージもそれを模倣したいと考えていたのです。
このアプローチにはいくつかの欠点があることに気づきました。データを配置する際、バイトは到着した場所に保存されることになります。Washingtonの近くに配置すれば、Washingtonに保存され、Virginiaの近くに配置すれば、Virginiaに保存されます。データは1か所にしか存在せず、一方でデータの場所を検索してアクセスするためのインデックスは2つのリージョン間でレプリケーションされていましたが、そのデータのレプリケーションは結果整合性でした。これには、インデックスの結果整合性や、WashingtonからVirginiaに保存されているデータにアクセスしようとする際の遅延といった問題がありました。さらに、インターネットに問題が発生した場合、データがVirginiaに保存されているにもかかわらず、Washingtonからアクセスしようとすると、そのデータの可用性に影響が出る可能性がありました。
そこで私たちはRegional isolationへの移行を始めました。当時、EC2は勢いを増しており、パフォーマンスの観点から、ストレージへのアクセスは常にローカルで行うことが望ましいとされていました。 しかし、グローバルストレージがS3を構築する方法として望ましくないとしても、グローバルストレージを構築するために必要なプリミティブを提供することは依然として重要だと認識していました。そのため、数年前にS3 ReplicationとS3 Multi-Region Access Pointsをリリースしました。S3 Replicationを使用すると、データを異なるバケット間でグローバルにレプリケートでき、S3 Multi-Region Access Pointsは、その上にシンプルなルーティング層やルーティング構造を提供し、グローバルにリクエストをルーティングすることができます。
これは数分で説明するには多くの情報でした。しかし、私が伝えたかった主なポイントは、これが2006年からの学習プロセスだったということです。Regional isolationの方法を学び、ディスクの管理方法や障害の発生について学び、Availability Zoneの障害について学びました。電力、水、冷却など、さまざまな障害の可能性があります。非常に複雑ですが、これは私たちの文化やDNAの一部となっています。Availability Zoneの障害のことだけを考え、1つのAvailability Zoneでのみ運用するという考え方は、時間とともに培われてきたものです。これらの話が、皆さんご自身のソフトウェアのデプロイ方法や運用管理の方法を考える上で参考になれば幸いです。これこそが、私たちがS3で長年にわたって行ってきたことなのです。
S3のデータ保護機能の連続性と監視ツール
ここまで、11 9sのデータ耐久性についてお話ししてきました。これからRobが11 9s以上の世界へと私たちを導いてくれると思います。この話題について私たちは十分な時間を費やしてきましたが、11 9s以上を目指すためには、まず11 9sから始めるのが良いでしょう。次のスライドとこのセクションでは、Ianが説明した基盤、つまりデータストレージにAmazon S3を選択するという点から発展させていきます。すべてのストレージクラスで11 9sの耐久性が得られます。One Zone-Infrequent AccessやExpress One Zoneのような単一のAvailability Zoneのものもありますが、これらに対して追加の耐久性を持たせる方法についても説明していきます。
しかし、11 9sの耐久性があっても、データに影響を与える可能性のある事象は存在します。例えば、削除リクエストを送信したり、データにLifecycleルールを設定したりした場合、これはプロバイダーとカスタマーの関係性の一部です。データの削除を希望される場合、私たちはそのデータを削除します。認証され、承認された削除リクエストは処理されます。そのため、このようなシナリオからも保護したい場合は、これから説明する追加機能について見ていきましょう。
データ保護の目的について説明しますと、まず第一に、偶発的な削除から保護することです。これには、誤った削除やデータの上書き、あるいはライフサイクルポリシーの設定ミス（日数の指定を間違えるなど）といったものが含まれます。また、悪意のある行為や、データの可用性に影響を与える地域的な問題に対する回復力を高めることも重要です。そして最後に、ガバナンスとコンプライアンスの要件についてですが、これは特に現在クラウドを使用していない場合に関係します。多くのお客様から、データの複数コピーを保持し、それらを一定の距離や異なる地理的リージョンに分散して保存する必要があるという要件をよく耳にします。
Ianが説明したようなReplicationなどのツールを使用することで、地域的な回復力を備えたストレージを構築し、そういった目標を達成することができます。
このスライドでは、データ保護とセキュリティについて詳しく見ていきます。IAMロールやパーミッションの設定などを考えると、この2つの境界線は少しあいまいです。データ保護とセキュリティの両面で効果を発揮するベストプラクティスがいくつかあります。 これを見ていくと、実際には多層的なモデルになっています。IAMポリシーで最小権限アクセスを使用することは、データや環境に変更を加えられる人数を制限するベストプラクティスの一つです。
Multi-Factor Authentication（MFA）は、バケットの設定面でもメリットがありますが、データの削除時にMFAを要求する機能としても有用です。例えば、組織にとって重要なデータがある場合、そのデータは誰も削除すべきではありません。この後、そのための保護機能をいくつか説明しますが、MFAは偶発的な削除を防ぐための最も効果的な機能の一つです。 次に、イミュータブルなバックアップについてです。Object Lockには、GovernanceモードやComplianceモード、Legal Holdなど、さまざまな設定があります。これにより、一定期間、またはObject Lockのlegal holdが解除されるまで、データが確実に保持されるようになります。
暗号化については、セキュリティの側面とデータ保護の両方に関わります。セキュリティの観点では、データへのアクセスを制限し、保存データの暗号化を確保します。また、AWS Key Management Service（KMS）を使用することで、データを読み取る権限だけでなく、データを復号化する能力とKMSキーへのアクセス権も必要になります。これにより、S3内のデータに対する追加のセキュリティ保護層が提供されます。
次に、物理的セキュリティと役割のデジタル分離について見ていきましょう。つまり、プライマリーコピーとバックアップの両方にアクセスできる同一の役割を持たせないということです。なぜなら、もし両方にアクセスできてしまうと、同じエラーが両方の場所で発生する可能性があるからです。物理的セキュリティについて話す際、これはMFAトークンの場合もありますし、データコピーの保存方法に関する他の側面もあります。 そして監査追跡ですが、データ保護の連続性について話す中で、データの追加コピーを保存したり、偶発的な削除から保護したりする機能だけでなく、AWS Trusted Advisor、AWS Config、S3 Storage Lensなどのツールについても説明していきます。
これらのツールは、環境への変更を監査し、さまざまな機能を有効にした場合のコストへの影響を理解し、支出を監視するのに役立ちます。データの何パーセントが複製されているかなどを監視できます。集計された形でこれを行うツールがあるので、Bucketの設定状況や環境全体でのデータ保護の状況をスナップショット的に非常に簡単に確認できます。 これらすべてがバックアップとデータ保護の物語の一部であり、これからさらに詳細に入っていきます。錨を上げて遠くへ向かっていきましょう。後でわかりますが、もっと航海に関する表現を忍ばせていきます。
S3のVersioningとObject Lockによるデータ保護の詳細
データ保護の連続性について、これらの機能のすべてについて様々なレベルで詳しく説明していきます。これらを覚えておいてください。セッション後に質問がある場合は、また後で取り上げて話し合いましょう。お話ししたように、これらの機能の一部は同じBucket内で機能し、一部はクロスアカウント、クロスリージョン、マルチBucketの保護を提供します。 最初の機能であるVersioningから始めましょう。会場の多くの方がVersioningについてご存知だと思いますが、今日はその細かな部分まで見ていきます。これは単一のBucketに対して有効にできる設定です。これがS3におけるデータ保護のレベル1です。より重要なデータに対しては、何らかの保護レベルが必要です。
Versioningを有効にすると、最初から多くの機能が付いてきます。次に、Multi-Factor Authentication（MFA）ですが、これはBucketのVersioningステータスを制御するだけでなく、誰もVersioningをオフにできないようにMFA保護を設定できます。これはこの2つの機能の素晴らしい相乗効果であり、追加の保護層として使用できます。 そして最後に、Object Lockについて話しました。Object Lockについては後ほど設定や詳細を説明しますが、これは非常にコスト効果が高いです。オブジェクトをS3に最初に保存する時に有効にすれば無料で、保存期間を日数で設定したり、Legal Holdなどを使用したりできるので、完全にカスタマイズ可能です。
ここで素晴らしい例を挙げたいと思います。環境内でログファイルを保存する場合、単一のBucketに集中させるにせよ、S3全体に分散したBucketに保存するにせよ、すべてのログファイルを必ず30日間保存するとします。質問の余地なく、すべてのログを最低30日間、一部のログはもっと長く保存するかもしれませんが、必ず30日間は保存するというケースです。そのような場合、すべてのログ用BucketでObject Lockを有効にし、30日間ロックされるように設定します。そうすれば、ログを確認しようとした時に「誰かがBucketを空にしてしまった」というような事態に遭遇することは二度とありません。
Object Lockは、Versioningの上に構築された無料の保護機能です。4日、7日、30日、90日など、お好みの保持期間を選択できます。これはバケットレベルで実装され、保存時に全てのオブジェクトにObject Lock設定が付与され、そのレベルのデータ保護が確実に行われます。これは単純な例ですが、Object Lockでは他にもさまざまなことができます。
複数のバケット、複数のリージョン、クロスアカウントのシナリオにおける保護については、後ほど詳しく見ていきます。先ほど、プライマリデータへのアクセスは誰も持つべきではないという話をしましたが、このような機能が利用できることは特に重要です。何人かの方がヘッドホンを指さしているようですね。後ろの様子を確認させてください。後ろから大丈夫のサインが出ましたね。では、Object Lockについて簡単に振り返った後、マルチバケットやクロスアカウントの保護について、Delete Marker Replicationなどの機能を例に挙げながら、S3 Replicationについて説明していきます。
S3 Replicationによって、マルチバケットの保護が実現できます。S3 Batch Operationsをご存じない方のために説明しますと、最もよく見られるユースケースはReplicationと組み合わせて使用するケースです。Replicationを有効にすると、新しいデータのレプリケーションが開始されますが、そのバケットに既に15テラバイトのデータがあり、それもレプリケーションする必要があることに気付くかもしれません。Batch Replicationを使用すれば、バケット内の既存のオブジェクトを簡単にフィルタリングしてレプリケーションすることができます。
また、非常に分離されたバックアップを提供するAWSサービスであるバックアップソリューションやパートナーソリューションについても説明します。これらは、お客様が管理するものではないため、IAMパーミッションを正しく設定しようと苦心する必要はありません。代わりに、AWSサービスやパートナーソリューションがバックアップを管理し、アクセス、リストア手順、その他の側面を制限します。
監査や異なるバケットでの適切な設定の確認に関して、これらのツールすべてを例を交えて詳しく見ていきます。このプレゼンテーションの準備中、各サービスのドキュメントを確認するのが本当に楽しかったです。というのも、これらのサービスは毎年新しい保護機能を追加し続けているからです。数年前にAWS Config rulesをセットアップした方は、AWSの環境を監視するための新機能が継続的に追加されているため、もう一度見直してみる価値があるかもしれません。
このプレゼンテーションのパートでは、誤削除防止から始まり、上書き、誤削除、そしてライフサイクル管理まで、様々な具体例を交えながら説明していきます。これらのシナリオとその対策方法、監査の方法、そして想定される脅威について見ていきましょう。
上書きの観点から例を挙げてみましょう。あなたのバケットに大切な潜水艦の画像が保存されているとします。ある日、上書きのリスクにより、突然その画像がタグボートに置き換わってしまったとします。これは望んでいた結果ではありませんよね。おもちゃのような画像ではなく、かっこいい潜水艦の画像が必要だったはずです。私たちは大切なデータを失わないように、上書きから保護する必要があります。
上書きは、「cat.jpeg」や「submarine.jpeg」のような同じキー名のオブジェクトを上書きする際に発生します。多くのお客様は、S3に保存するデータに時間軸やGUIDを適用してユニークなキー名を付けることで、ランダム性を持たせています。これは良いアプリケーション設計ですが、もしそのプロセスにエラーが発生し、10億個に1つのオブジェクトが同じキー名を持ってしまった場合、既存のオブジェクトは上書きされてしまいます。バージョニングを有効にしていない場合、元のデータは完全に失われてしまいます。「設計上、データを上書きしない」と言うだけでは十分ではありません。追加の保護が必要なのです。また、あるアプリケーションがデータを上書きしないよう監査されていても、新しいクライアントや他のアプリケーションがバケットにアクセスして上書きを引き起こす可能性もあります。
これらのリスクから保護するため、まず基本レベルで実装するのがバージョニングです。これはS3バケットで有効にすることができます。バージョニングには多くの利点がありますので、ここで説明していきましょう。
バージョニングを使用すると、同じキー名のオブジェクトを新しく書き込むたびに、新しいバージョンが作成されます。この簡単な例では、バージョン1、バージョン2、バージョン3というように示していますが、実際にはもっと多くのバージョンを持つことができます。特定のオブジェクトが数万から数十万のバージョンを持つ例も見てきました。アプリケーションの動作によっては珍しくありません。バージョニングを有効にすると、各オブジェクトに固有のバージョンIDが付与され、必要なバージョンIDを指定して読み取ることができます。最初に書き込んだバージョンを読み取りたい場合は、そのバージョンIDを指定するだけです。
バージョニングを有効にすると、上書き保護だけでなく、削除リクエストに対する保護も得られます。バージョンIDを指定せずにcat.jpegを削除すると、バケットからオブジェクトを削除する代わりに削除マーカーが追加されます。その後、cat.jpegを取得しようとすると、オブジェクトが見つからないというエラーが返されます。これらのバージョンは依然として存在していますが、その上に削除マーカーが書き込まれているのです。削除マーカーや特定のバージョンを削除するには、特定のバージョンの削除機能を使用できます。
コスト管理のために、特定のバージョンを削除したり、オブジェクトを削除したりする必要がある場合があります。バージョニングを有効にして全てを永久に保持することは、通常すべてのバケットで一般的ではありません。クリーンアップポリシーが必要になります。バケットレベルでは、非カレントバージョンのストレージを監視できます。時間とともにファイルを上書きし、削除マーカーを追加していく場合、Storage Lensメトリクスを使用して、バケット内のカレントバージョンと非カレントバージョンの割合を確認できます。
オブジェクトを繰り返し上書きしている場合、データの半分以上が非カレントバージョンで構成されていることに気付くかもしれません。これは一部のアプリケーションには理にかなっていますが、すべてのアプリケーションにとってそうではありません。オブジェクトが上書きされた後に期限切れにしたり、7日後に古いバージョンを削除したりするライフサイクルルールを簡単に設定できます。ライフサイクルにバージョン数フィルターを指定できる機能をリリースしました。カレントバージョンと2つの非カレントバージョンを維持し、それ以外をクリーンアップすることができます。これは、頻繁に上書きされるか、まったく上書きされないかに関わらず、何百万ものオブジェクトを持つバケット全体で効果的に機能します。
一般的にライフサイクルルールは作成日に基づいて動作しますが、非カレントバージョンポリシーはオブジェクトが上書きされた時点で動作します。これは優れた設計上の判断です。例えば、オブジェクトが上書きされてから4日後に期限切れにしたい場合があります。オブジェクトは5年前のものかもしれませんが、非カレントになってから指定した日数後にトリガーが発生します。この機能はAmazon S3で直接利用可能です。
AWS Trusted Advisorは、どのバケットでバージョニングが有効になっているかを可視化します。この例では、28個のバケットのうち13個でバージョニングが有効になっていません。Trusted Advisorをチェックして、それらのバケットに対して適切かどうかを判断したり、さらに詳しく調査するためのアクションを促されたりする場合があります。これを大規模に適用する場合、どのバケットでこれらの設定が有効になっているかを正確に確認する効果的な方法です。ここではレプリケーションの可視性も得られます。
AWS Config の画面では、MFAやその他の設定、そしてVersioningが有効になっているかどうかが確認できます。Config ruleを設定しておけば、誰かがVersioningを有効にせずに新しいバケットを作成した場合にアラートを受け取ることができます。このルールが満たされていない場合、バケットが作成されてすぐにそれを知ることができます。お客様がTerraformやCloudFormationを使用してベストプラクティスに従ってリソースを作成している場合でも、このような監査による保護機能によってコンプライアンスを確実に維持できます。
これらのConfig rulesは、環境内のすべてが意図した設計プラクティスに従っていることを確認するための優れた監査保護の手段です。Storage Lensの側では、Versioning、Replication、Object Lockに関するメトリクスが提供されています。無料枠では14日間のデータを利用できます。
私は Amazon S3 Storage Lensの無料枠が大好きです。まだ試したことがない方は、今日帰ってから是非試してみてください。無料枠もAdvanced tierも非常に優れた機能を備えています。Advanced tierでは新しい可視性が多く追加されますが、無料枠に含まれる機能も本当に素晴らしく、完全に無料で利用できます。
下の方にはデータ保護に関するメトリクスがあります。Advanced tierでは5ヶ月分のデータが保持されるので、Advanced tierを有効にすると、追加のメトリクスと、より長期間の履歴メトリクスを振り返ることができます。 バケットの上書きパターンを理解するために非現行バージョンのバイト数を監視し、適切な有効期限ルールを設定してコストを節約することができます。Advanced tierでは、ルール数や削除リクエストの数に関する可視性も得られ、優れた可視性を提供します。
偶発的な上書きから保護するために、2024年の新機能としてconditional if-not-matchを導入しました。これは、バケットへの新しいPutリクエストごとに、そのキー名に既に何かが存在するかどうかをチェックします。これはリクエストレベルで設定する条件で、このバケット内のすべてが一意であることを保証します。これは S3 に同時に書き込みを行う場合に便利ですが、データ保護の目的でも有用です。最近、新しいアップロードすべてにこの条件付き保護を有効にすることを強制する機能を追加し、if-none-match条件なしではこのバケットに書き込めないようにしました。
オブジェクトの存在確認は、リクエストごとの操作として行われます。これは新規バケットすべてに設定する必要があり、バケットレベルの設定として強制されます。また、ETag matchのような機能も導入されており、アプリケーションがS3のファイルを更新する際に、意図したバイトデータであることを確実に確認できます。新規リクエストすべてにこのETag matchを設定することで、上書きしようとしているバージョンが想定通りのものであることを確実に確認できます。
ライフサイクルポリシーやバケットポリシーなど、設定変更が頻繁に行われないバケットについては、AWS CloudTrailを使用してManagement EventsとData Eventsを設定できます。バケットレベルの設定変更などのManagement Eventsは、CloudTrailで簡単に変更を確認することができます。事前に2名によるレビューを設定したり、迅速なアラートが必要な予期せぬ変更を監視したりすることができます。
S3 Replicationとバッチ操作によるクロスリージョン・クロスアカウントのデータ保護
これまで単一バケットの保護について詳しく説明してきましたが、複数のリージョンでの保護や、複数リージョンが提供する追加の耐障害性が必要となる要件もあるでしょう。これから、Replication、Batch Operations、バックアップソリューションについて説明していきます。
お客様によって、さまざまなアプローチがあることがわかっています。別のアカウントや、誰も触れない低コストのストレージクラスを使用する別のバケットへのReplicationを使用するお客様もいます。一方で、Multi-Region Access Pointsを使用してReplicationを行い、すべてのリクエストを両方のリージョンにルーティングし、いずれかのリージョンがオフラインや利用不可になった場合は自動的に再ルーティングする可用性を確保しているお客様もいます。
Same-RegionとCross-Region Replicationがあります。約5年前にSame-Region Replicationを追加した際、データ転送料金がかからないため、非常に低コストでデータをレプリケートする方法を提供することができました。同じリージョン内で分離された、別のアカウントにローカルコピーを持つことができます。
レプリケーションを行う際には、低コストのストレージクラスを選択したり、クロスアカウントで作業したり、複数の宛先にレプリケートしたりすることができます。ここ数年で導入された機能により、ヨーロッパやアジアだけでなく、同一リージョン内の異なるバケット間や、クロスリージョンでのレプリケーションが可能になりました。リージョンごとに1つのコピーという制限はありますが、柔軟な設定オプションを提供しています。
いくつかのメトリクスの例を見ながら、S3 Replication Time Controlを使用してSLAに裏付けられたレプリケーションを実現する方法について説明します。Northern Virginiaにアップロードされた重要なデータを15分以内にOregonにコピーすることが可能です。
これは、何か問題が発生した場合に備えて、データを迅速にOregonに転送したい場合に特に有用です。S3 Replication Time Controlがその解決策となり、さらにすべてが適切なタイミングでレプリケートされていることを確認するためのメトリクスも提供されます。
いくつかの例と設定について見ていきましょう。先ほど、Delete Markerレプリケーションの有効化について質問がありました。US EastからUS Westへの単純な例では、設定内のDelete Markerフィールドでレプリケーションを有効にしているのが分かります。これは、誰かがソースバケットでDeleteリクエストを発行してデータを削除した場合、その削除を宛先リージョンにレプリケートするか、または宛先コピーを削除の伝播なしで分離するかを選択できることを意味します。この機能のオン/オフを切り替えることができます。レプリケーションルールには後で編集しやすいように名前を付け、レプリケート先のバケットを指定します。
この例では、ソースとは異なる宛先ストレージクラスを設定しています。ソースではStandardデータを持っていても、宛先ではS3 Glacier Instant Retrievalの価格帯を利用したい場合があります。通常、宛先ではデータの読み取りが少ないため、低コストのストレージクラスが非常に理にかなっています。ここでは、Account AとAccount B間のクロスアカウントの例について説明します。これも設定は非常に簡単で、バケットを指定し、アカウントを指定し、ストレージクラスやDelete Markerレプリケーションなどの設定を行います。
こちらは、Primary CopyとSecondary Copyを使用した場合の、様々な障害シナリオにおけるReplicationの動作についての別の例です。 先ほどBatch Replicationについて説明しましたが、既存のオブジェクトをレプリケートするだけでなく、障害にも対応することができます。新しいReplicationルールを設定した際に、権限が正しく設定されておらず、問題が特定されるまでの間Replicationが失敗し続けるような場合でも、Batch Replicationを使用して失敗したオブジェクトを遡って再レプリケートすることができます。 Replicationの再試行に関しては、数多くのチェック機能を備えた永続的なシステムとなっています。権限が正しく設定されていれば、すべてのものがレプリケートされ、成功するまで試行し続けます。設定ミスや権限エラーの場合は、Batch Replicationを使用するか、その場でコピーしてReplicationを再トリガーするまで、永続的な致命的エラーとなります。
先ほど説明したメトリクスは、視覚化するのに最適です。ソースと送信先の間のReplication遅延が何分あるか、レプリケート待ちのバイト数とオブジェクト数、そしてReplicationに失敗したオブジェクトの数を表示します。この最後のメトリクスは、失敗を即座に知るためにアラームを設定したい項目の一つでしょう。イベントやメトリクスを設定してこれを監視することができます。 Replication Time Controlを使用すると、15分のSLAが得られ、その時間を超えて遅延が発生した場合にイベントが発生します。遅延時にしきい値超過イベントが発生し、正常にレプリケートされた時に2番目のイベントが発生するため、その情報を即座にシステムの他の部分にパイプすることができます。
Batch Operationsでは、フィルターを使用するか、リストを自分で送信することができます。これはBatch Replicationと組み合わせて使用することで、既存のオブジェクトや失敗したオブジェクトがすべて正常にレプリケートされることを確認できます。カスタムマニフェストやS3 Inventoryを使用してオブジェクトを指定できます。ここでのベストプラクティスは、Batch Replicationやその他の操作を実際に実行する前に、ジョブのサイズを確認することです。バックアップソリューションについては簡単に説明します。データを別のAWSアカウントにバックアップすることができ、サービスによって管理され、完全に分離されており、特定の時点への復旧機能を提供します。継続的なバックアップまたは定期的なバックアップを行うことができます。これらのソリューションは、AWSのものでもパートナーのものでも、バックアップコストを適切に管理し、必要な方法で復旧できるような様々な設定オプションを提供しています。
まとめと今後の学習リソース
適切なデータ保護機能を選択し、それらを新しいバケットのデフォルトとして設定してください。変更や予期しないイベントを監査し、アラームを設定し、これらの設定を定期的に見直してください。先ほど、AWS ConfigやTrusted Advisorの新機能を確認するために戻ることについて言及しましたが、それらを確認することをお勧めします。AWS Skill Builderで学習を継続し、利用可能なトレーニングで知識を深めることができます。QRコードと簡単なURLが用意されています。
最後になりましたが、IanとPrivateは本日ご参加いただき、ありがとうございました。S3ストレージを監視し、長年にわたって保護するための様々な方法について、私たちと一緒に学んでいただき、ありがとうございます。アンケートへのご記入をお忘れなく - 私たちにとって非常に有益です。私たちは毎年、昨年のアンケート結果と自身のセッションを見直し、何を追加し、何を削除し、どこにより多くの時間を割くべきかを判断しています。ぜひアンケートにご協力ください。本日は時間を割いてご参加いただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion